#ubuntu-devel 2004-11-08
<mdz> Kamion: nice!
<thom> Kamion: very cool
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=2817
* mdz wonders what to do with #2817
<thom> assign it to elmo
<jdub> haha
<jdub> awesome
<thom> actually, no
<thom> find someone to make that as a mask
<thom> and then we can give it to elmo at decConf
<mdz> 482 >= normal bugs to review
<mdz> lamont: ping?
<lamont> yo
* lamont doesn't do masks
<mdz> lamont: how is amd64 coming along?
<lamont> hoary.all.amd64:Total 616 package(s) in state Needs-Build.
<lamont> hoary.all.powerpc:Total 52 package(s) in state Needs-Build.
<lamont> starting to look at bugs, pondering gnutls1[01] 
<__daniel> hmmmmm, why does noflushd depend on ed?! :-)
<lamont> __daniel: because some things are sick, that's why
<lamont> depend, or build-depend?
<__daniel> depend
<lamont> ew!
<azeem>         printf "%%s?^ *$1=.*?$1=\"$new\"?\nw\nq\n" | ed -s "$CONFFILE"
<azeem> it's used in the postinst
<lamont> azeem: warn me before you do that, so I can puke other than on the keyboard...
<azeem> lamont: heh, you might want to read the comment before that line one day...
<lamont> azeem: please tell me it's an apology?
<azeem>         # Careful here! Both DISKS and PARAMS may contain '/' (or just about
<azeem>         # any other character. In order not to confuse ed, we use a delimiter
<azeem>         # for the regexp that very rarely occurs in path names.
<lamont> AAAAAAAAAAAAAIIIIIIIIIIIIIIIIIIIIIEEEEEEEEEEEEEEEEEEEE!
<lamont> " very rarely occurs"
<azeem> oops, lamont just did another edwards
<azeem> "it's perfectly safe"
<__daniel> WOW
<lamont> "hundreds and hundreds of times, ain't nothing happened"
<__daniel> this is something even <b>I</b> wouldnt have thought of
<__daniel> good night everyone, hopefully ed won't blow up my box tonight ;-)
* lamont dinners
<mjg59> Is / an accepable character in disklabels?
<jdub> heh
<jdub> rock
* jdub upgrades his desktop to hoary ;)
<lamont> packages with at least one failed arch: dh-kpatches, linux86, rrdtool
<lamont> jdub: so what's uninstallable, I wonder?
<jdub> well, gdm no longer wants to be removed or upgraded
<jdub> so i'm chancing it
<lamont> oh, and planner
<lamont> jdub: lol
<jdub> only thing that wanted to be removed on this run was python2.3-generic (replaced without 2.3)
<jdub> so i'm upgrading without losing anything
<jdub> which is a good start ;)
<mdz> jdub: I fixed the removing-alsa-utils bug earlier today
<mdz> then upgraded my laptop
<mdz> the only issue I ran into was a segfaulting gnome-settings-daemon, which seb fixed
<lamont> do we have a list of the needs-review packages?
<lamont>   libgnomevfs2-dev,libgnutls10-dev
<lamont>   libcupsys2-dev,libgnutls10-dev
<lamont> grumble
<jdub> hrm, so
<jdub> i have two binary packages in the same source package
<jdub> one of which incorrectly had files that should've been in anoother
<jdub> so now when i go to upgrade, i borks on replacing those files
<jdub> the one which should have those files depends on the Source-Version of the one which shouldn't
<jdub> shouldn't that be upgraded first?
<jdub> or do i have to do something with Replaces?
* lamont goes to town for a bit
* lamont changes mind, stays home
<mdz> jdub: you need to add a Conflicts:
<jdub> versioned?
<mdz> lamont: the list of needs-review packages is pending the latest reduction through Keybuk magic
<lamont> mdz: ah, ok
<fabbione> morning guys
<tseng> hi
<hornbeck> tseng: that libdbus-cil did not work
<hornbeck> sorry I did not get to it sooner
<lamont> hoary.all.amd64:Total 256 package(s) in state Needs-Build.
<mdz> morning, fabbione
<fabbione> i was wondering...
<fabbione> in a changelog
<fabbione> * blabla:
<fabbione>   + foobar:
<fabbione>     - dkdkdk:
<fabbione> and then?
<fabbione> what is the next symbol to use?
<mdz> =?
<fabbione>  / ?
<fabbione> ~ ?
<mdz> I would go with = or .
<fabbione> sqrt() 
<mdz> 
<mdz> 
<lamont> night all
<lamont> ?
<mdz> night
<lamont> hoary.all.amd64:Total 204 package(s) in state Needs-Build.
<lamont> hoary.all.i386:Total 4 package(s) in state Needs-Build.
<lamont> and really off to bed
<mdz> 52 packages in the past 40 minutes, not bad
<fabbione> night lamont 
<fabbione> uhuh
<fabbione> 97 lines of changelog already
<fabbione> and it is not even that detailed
<fabbione> ahhh there is a new server
<fabbione> #if defined(XdmxServer) && XdmxServer
<fabbione> XCOMM
<fabbione> XCOMM distribued multihead Server
<fabbione> XCOMM
* fabbione wonders what that is...
<fabbione> daniels: ping
<mdz> fabbione: this hardware cursor thing is becoming a FAQ
<mdz> is there anything we can do?
<mdz> can we just disable it by default?
<geppy> How does one go about becoming a ubuntu packager?
<pitti> Morning, guys!
<mdz> pitti: morning
<AndyFitz> afternoon
<pitti> Hi mdz!
<pitti> mdz: AFAICS you did not yet send out the announcements?
<mdz> geppy: http://www.ubuntulinux.org/community/maintainers
<mdz> pitti: that is correct
<mdz> pitti: I can run amber if you have tested the packages
<pitti> mdz: so far I'm prepared for glibc and tetex-bin
<mdz> pitti: which USN number is each?
<pitti> mdz: glibc: 4-1, tetex-bin: 9-1
<fabbione> mdz: no we can't.. on quite a bunch of hardware it works fine
<geppy> mdz:  Thank you.
<fabbione> mdz: if we disable it by default, someone will complain of the opposite
<fabbione> mdz: as usual.. no win2win situation here
<mdz> fabbione: what will they complain about?
<fabbione> mdz: welcome to X :-)
<fabbione> that the cursor is not accelerated in hardware
<mdz> pitti: both installed, templates are on their way
<mdz> will they even notice?
<pitti> mdz: got them
<fabbione> mdz: people will complain just because there is the option in the config. i don't know at visual level
<fabbione> + each driver has it's own option
<fabbione> one has SwCursor another HwCursor
<fabbione> so you get the picture...
<mdz> what is the cause of the bug, where there are two cursors on the screen?
<fabbione> AND THE FONTS BUILD FLAGS in X.org are borked!
<fabbione> mdz: apparently there is the default black X cursor printed on the screen, but the real mouse works
<mdz> fabbione: right, it is as if there are two cursors
<mdz> one hardware and one software? two hardware?
<mdz> or is it even something else?
<mdz> perhaps there is a bug that can be fixed
<pitti> mdz: odd, the libc6 thingy contains two package versions
<mdz> pitti: yes
<mdz> pitti: it had to be fixed so that it would build
<pitti> mdz: right, but can't we just drop the ubuntu2.1?
<mdz> pitti: yes, you can drop it from the advisory
<mdz> amber needs to process it, though
<mdz> it probably should be omitted from the template
<mdz> pitti: send mail to elmo about it
<elmo> or just tell me now
<fabbione> mdz: i think one is the hardware and one is the software
<fabbione> mdz: yes.. it might be a bug.. and i don't know 1) how to reproduce it 2) if it can be fixed
<mdz> elmo: wtf are you doing awake?
* mdz yawns
<jdub> mdz: ... 5.04 or 5.4?
<elmo> mdz: fell asleep at my desk, got woken by cron.daily
<mdz> jdub: 5.4 would be more accurate
<pitti> mdz: out
<mdz> elmo: tell me you're joking
<elmo> mdz: ...
<fabbione> this is going to be so cooooool
<fabbione> mdz: do you feel lucky today?
<mdz> fabbione: why, do you want to upload X? :-)
<elmo> pitti: oh, I thought you guys were talking about nothing-to-merge syncs.. and you weren't.. do mail me about/explain whatever you were talking about ;-)
<pitti> elmo: the only problem was that the glibc amber output contained two versions (2.1 and 2.2); I deleted all 2.1 package lines
<mdz> elmo: glibc had two versions in accepted/
<mdz> elmo: I passed them both through amber at the same time, as I understand I'm supposed to
<elmo> yeah, definitely
<mdz> elmo: and amber included md5sums for both versions in the template
<mdz> which I think it has always done, but it occurred to me that it doesn't make much sense
<elmo> well, easy workaround is to run amber twice, that works too
<elmo> as long as you do it in the right order ;-)
<elmo> but yeah, I'll TODO hiding anything-but-latest version from template
<mdz> thanks
<mdz> and lamont will TODO having everything in warty actually buildable :-)
<mdz> s/warty/hoary/
<mdz> wartylog: TOO LATE FOR YOU
<fabbione> mdz: no... i need someone to help me debugging a 22K lines Makefile
<pitti> mdz: did you already approve the two messages? I did not get them yet
<mdz> fabbione: I am feeling so tired suddenly
<elmo> hehe
<fabbione> mdz: but still lucky, eh?
<fabbione> elmo just woke up... so he should be fresh :P
<mdz> pitti: done
<pitti> mdz: thx. I also added them to the website (works now)
<mdz> great
<pitti> mdz: BTW, any idea how to delete this test item?
<mdz> pitti: test item?
<pitti> mdz: the USN page contains a "testing manager permissions" item
<pitti> mdz: maybe lulu created it to check something
<mdz> pitti: oh, who did that? :-)
<pitti> mdz: its state is "obsolete", but it still appears
<mdz> pitti: I changed it to in-progress
<mdz> so it should not appear
<mdz> but I do not know if it is possible to delete anything
<pitti> mdz: ah, right, as soon as I log out, it does not appear any more
<mdz> elmo: I don't suppose you have a handy list of all the little gotchas for ambering, to give to pitti?
<pitti> mdz: but neither do my newly added items. Gosh - I changed them to "published"...
<pitti> mdz: oh, now they do. Please forget that
<mdz> our website is SO SLOW
<elmo> the lack of caching probably isn't helping
<elmo> but yes, it is painful
<mdz> elmo: does the load spike on gentoo every time someone clicks a link?
<elmo> heh, well it has jumped a lot since we broke the caching
<sid77> 'morning
<mdz> elmo: was that intentional in order to un-break the authentication?
<mdz> gah, falling asleep. night, all
<fabbione> night mdz
<elmo> mdz: they're trying to get it caching with auth, yeah, but broke it entirely in the process. woo
<elmo> night
<pasc> elmo: sounds like you need to run anacron later ;-)
<elmo> pasc: I was more thinking I should sleep in a bed instead
<elmo> radical idea, I know, but..
* jdub wipes tears from his face, reading mako's STUPID protein joke
<fabbione> pitti: are you sending out the USN, BEFORE or AFTER the packages are available on the main mirror?
<pitti> fabbione: after
<jdub> hoary is back to the glory days of warty
<pitti> fabbione: mdz ambers them (which should mean to push them to the mirror), then I send out the announcement
<fabbione> pitti: imho you should wait a coule of hours to give time to the mirrors to sync
<jdub> every time you update, even if it's only 15 minutes apart or less, there'll be new packages ;)
<pitti> fabbione: hmm, mdz wanted me to send out the announcements immediately. mdz, what do you think?
<fabbione> pitti: mdz is asleep
<pitti> fabbione: oh
<fabbione> i am afraid that in this way mirror maintainer will be bombed of requests to sync more often
<pitti> fabbione: hmm, mirroring is a good point; OTOH, further delay of updates is not the best thing either
<fabbione> pitti: i completed my mirror 10 minutes before the USN
<pitti> fabbione: maybe there could be some sort of a mirror pulse whenever a new security upload is available? It's not that much to sync
<fabbione> and the packages were not there
<pitti> fabbione: maybe this should be discussed on the ML?
<fabbione> on Debian they usually wait that it is available
<elmo> no they don't fabbione
<elmo> they tell people not to mirror security.debian.org
<pitti> nevertheless folks do it
<fabbione> elmo: i still see the DSA and i have the packages on the local mirror
<elmo> yes, but the point is they don't delay DSAs for the sake of mirrors
<fabbione> and i mirror debian much less often than ubuntu
<elmo> because there are no official ones
<elmo> and I don't think we should delay our USNs either
<fabbione> elmo: it's not like delaying them 24Hours
<pitti> me neither, I rather think the mirroring strategy should be fixed then
<fabbione> pitti: i agree
<elmo> what mirroring strategy?
<pitti> fabbione: would this be technically possible to send out a mirror pulse?
<fabbione> elmo: the point is that we don't have a fully separate archive for security
<fabbione> pitti: yes. that can be done
<fabbione> pitti: but it's up to elmo to implement it
<elmo> not to fabbione's personal mirror it won't
<fabbione> i use ssh triggers for that
<fabbione> elmo: nahh... i am not that selfish you know :-)
<fabbione> i can handle stuff for myself.. i am more concerned about normal users that do not understand all the details behind stuff and that usually tends to panic when they read "security"
<fabbione> elmo: allow me that at least :P
<elmo> normal users are going to be pointed at security.ubuntu.com
<fabbione> not in big company environments
<fabbione> anyway
<elmo> we wouldn't be triggering big company environments, so what's your point?
<elmo> dude, we can not "fix" this
<fabbione> it's pitti and mdz call for that
<fabbione> elmo: companies like Ericsson (just to make an example) have their own internal mirrors
<fabbione> and you might end up triggering them
<elmo> err, no I wouldn't?
<pitti> fabbione: it certainly makes sense to have a local mirror; maybe we can introduce a kind of "sync subscription" process?
<pitti> elmo: why do you think it's bad to send out sync triggers?
<elmo> pitti: I didn't say it was
<fabbione> elmo: if company $FOO comes here and say: we pay XXXXX USD/month to be triggered....
<fabbione> elmo: aren't we going to trigger it?
<elmo> pitti: but you have a hiearchahal structure
<elmo> not a flat one where you trigger every mirror and his dog
<pitti> elmo: so we do trigger some main mirrors?
<elmo> pitti: no not right now, but what's your point?  even if we do, we should NOT delay USNs for that
<elmo> and triggers are triggers - you have no idea when the mirror is up2date
<pitti> elmo: no, we shouldn't delay USNs, that was not my question
<elmo> or often, even if the trigger's worked, they're not some magic solution
<pitti> elmo: I just thought about shortening the mirroring delay
<fabbione> ok... and another bug in X.org is fixed
<fabbione> now let's wait these... few hours to complete the compilation
<sid77> c'mon fabbione you are doing it for "the cause" ;)
<fabbione> elmo: all our amd64 and ppc buildd are in single cpu mode, right?
<fabbione> but the i386 is SMP
<thom> fabbione: correct
* fabbione has some kind of insane IDEA
<thom> uh oh
<thom> these are never good
* thom adopts the crash position
<sid77> lol
* sid77 wears an helmet
<pitti> elmo: do package syncs need to be approved my mdz?
<pitti> elmo: imagemagick can be synced from sid
<fabbione> thom: not that bad... but the i386 buildd will save a bunch of time
<fabbione> thom: they started implementing the target DONE inside X.org, to mark a subdir as such
<fabbione> thom: i can easily detect if the target is there or not
<fabbione> and parallelize building of docs and fonts
<fabbione> according to /proc/cpuinfo
<__daniel> good morning
<AndyFitz> morning __daniel
<__daniel> hai AndyFitz
<daniels> fabbione: pong
<fabbione> daniels: libXaw.a disappeared from X.org
<fabbione> how are we supposed to ship libXaw*-dev ?
<fabbione> daniels: http://people.ubuntulinux.org/~fabbione/006_update_fonts_Imakefiles.diff
<fabbione> please apply upstream if it is not there alredy in 6.8.1+CVS
<fabbione> it fixes fonts build
<daniels> fabbione: what the hell? disppeared?
<daniels> probably because no-one cares
<daniels> fabbione: ok, I'll check it out
<daniels> brb
<bob2> xaw = athena?
<fabbione> daniels: no it's not upstream
<fabbione> argh
<fabbione> daniels: wait.. there is a missing bit in the patch
<fabbione> daniels: it should be ok now
<thom> pitti: you need to fix the desktop seed - libhal-storage is in universe
<pitti> thom: argh, thanks for that hint
<pitti> thom: can I do that myself?
<thom> i don't know
<thom> sorry
<pitti> thom: I'll mail matt
<jdub> hrm
<jdub> so
<jdub> does germinate pull from the new wiki or the old wiki? :)
<jdub> pitti: approved
<thom> jdub: i was wondering that
<jdub> pitti: but i imagine it will make most sense on the old wiki atm
<pitti> jdub: okay, then I'll add it there
<thom> old wiki is read only
<jdub> oh
<jdub> already
<pitti> then new wiki... :-)
<pitti> jdub: if it does not work with the new wiki, I can still bother mdz; it's not that urgent, nothing uses this library yet (I think)
<pitti> jdub: no, sorry, hal itself uses it
<thom> well, hal depends on it
<thom> so trying to use just hoary will break
<jdub> yeah
<sivang> thom : around?
<seb128> morning
<danielshower> hai seb128
<danielshower> /nickt __daniel
<thom> sivang: yo?
<thom> sivang: in general, please just talk. if i'm not around, i'll have an away log set
<sivang> thom : just remembered something from my past, you ever heared of TANDEM / HIMALAYA ?
<thom> nope
<sivang> thom : or should I say Compaq TANDEM :)
<thom> nope, no bells are being rung here
<sivang> thom : ok
<pitti> jdub: currently I think germinate uses the Warty seeds; but I can't possibly change them, right?
<jamesh> hi seb128
<pitti> jdub: that is, I shouldn't
<seb128> hey jamesh 
<jdub> pitti: oh, true, germinate is totally unrelated to hoary so far
<daniels> bob2: X Athena Widgets
<jdub> pitti: perhaps just put it on SupportedSeed proposals for hoary if it needs to go there (isn't it a depends?)
<bob2> daniels: ah
<pitti> jdub: it is a depends, that's why I'm wondering why it got to universe
<pitti> jdub: seems like germinate did not run recently
<pitti> jdub: I shouldn't need to modify the seeds
<jamesh> seb128: w.r.t. the new drive mount applet and Hoary, would it be easier if I backported it to 2.8, or just leave it for a 2.9 release.
<jamesh> ?
<seb128> just leave it, I'll package the 2.9 branch
<seb128> 2.9.1 is due next week, right ?
<jdub> pitti: i don't think we're germinating hoary at all yet
<pitti> jdub: so maybe we should? New upstream versions are flooding Hoary
<pitti> jdub: they could introduce more of these problems
<|trey|> Is Xorg in Hoary yet?  Breakages are welcome, filing bugs makes me feel needed  8)
<daniels> |trey|: we will tell you when xorg is in hoary.
<daniels> nothing about hoary (it being ready for use, xorg entering, everything) will creep up on you
<pitti> Hi Keybuk!
<|trey|> daniels, just thought I would ask here due to "Happy Hoary Trail"... I usually use Sid anyways, so know what to expect  :)
<jdub> morning Keybuk 
<jdub> Keybuk: dude, you still doing germinate stuff?
<Keybuk> nope, Colin's been looking after that for a while now
<bob2> |trey|: hoary contains nothing exciting atm
<jdub> ok
<|trey|> bob2, anything new = exciting... new features are fun  :)
<jdub> tjere
<jdub> there's nothing particularly featureish
<daniels> bob2: http://www.livejournal.com/users/ajaxxx/33986.html
<Keybuk> we're still very much resynchronising with Debian
<bob2> daniels: hah, saw that
<bob2> daniels: and liw* removed sex
<robtaylor|away> amu: ping?
<amu> robtaylor: pong
<daniels> bob2: mmm
<robtaylor> amu: hey :) have you seen the bug i logged about hotplug not working on the live cd?
<robtaylor> amu: well, hal not working, but i'm pretty sure hal doesnt work cause hotplug isnt being run from the pivot_rooted root..
<amu> robtaylor: strange, looks like matt thinks the same, i tried with a ext fs, looks working, but it wasnt automountet.  
<robtaylor> amu: yeah  i cant quite figure whats wroing - i've but debug code in /sbin/hotplug on a running livecd system, and it never gets called
<amu> hmm, i've still no idea, what's different if you compare a chroot or a "normal" sys 
<robtaylor> amu: well doenst morphic pivot_root twice?
<robtaylor> or is it chroot?
<amu> pivot_root
<robtaylor> right, so that uses a new namespace
<robtaylor> its possible the kernel is trying to run hotplug in one of the other namespaces..
<robtaylor> but the only problem with this hypothesis is that i find it hard to belive noones ever noticed hotplug not working...
<amu> robtaylor: i think, thats should be problem for hotplug, doent matter at which time you insert you hardware, hotplugs job is loading the module, if you chroot to somewhat else, it should work also. Sounds funny if you chroot into a chroot and you have no disk left.         
<amu> or a missing ethernet interface, cause of the chroot 
<robtaylor> amu: yep, it'd definitly a bug if its not working they way we expect it to work..  it could be some 2.6 kernel bug and maybe only occus after two pivot_root, or some such obscureness
<amu> probably hotplug is the (main) problem. 
<robtaylor> amu: or are you saying you'd expect hotplug to run from the main system, not the pivot_rooted system?
<robtaylor> amu: chroot is very different to pivot_root
<amu> mdz: we should discuss a redesign :) i've some ideas    
<amu> robtaylor: just a minute ...
<robtaylor> amu: np :)
<amu> robtaylor: your localtime 10:08 is correct ?
<amu> ....i've to wait for mdz 
<robtaylor> amu: yep :)
<robtaylor> amu: ok. what's his TZ?
<robtaylor> amu: so i dont get what you're saying.. are you saying that this is how hotplug works by design?
<amu> probably : TIME reply from mdz: Thu Oct 28 02:10:11
<sivang> hey sparkes
<robtaylor> amu: ah , we'll be waiting a long time..
<robtaylor> amu: i'm not convinced, as i see it a pivot_root call *should* change current->fs->root
<amu> robtaylor: i tried with RC2, a ext3 on it, device is detected but not automounted. if i mount it by hand it works    
<enrico> Hello, good morning.  I posted the question about Wiki contents licensing in the warthogs list some days ago, but I haven't got any answer.  However, it'd be important for the doc team to know about that
<robtaylor> amu: if you run syslog, do you get any hotplug messages?
<robtaylor> amu: bear in mind that morphix adds a fstab entry for sda1 by default
<robtaylor> and that if the device is plugged in at boot, it gets detected by the coldplugging
<amu> robtaylor: yap, without any error 
* robtaylor has been looking at this problem for a couple of days =)
<amu> robtaylor: impossible, if you run a scsi-sys, extern scsiCDrom, sata disks  
<robtaylor> amu: well it should work. the coldplugging is just script running in whereever you did your /etc/rc.0/Sxxhotplug
<robtaylor> amu: eh?
<amu> ... sda1 by default   
<robtaylor> amu: boto up the livecd with no scsi devices added, and /etc/fstab will have an entry for sda1. yes its broken.
<robtaylor> amu: try it of you dont beleive me =)
<amu> robtaylor: first thing i've to do, i must reach mdz. If he say ok, you spend much time as you need on this bug, thats fine for me. 
<robtaylor> amu: if he says ok to what?
<robtaylor> amu: right now the livecd is very broken... i dont see how you can release a warty livecd with no working hal..
<amu> robtaylor: right, cause of this, i need mdz, the liveCd isnt designed for hal.  
<robtaylor> ah
<robtaylor> thats very broken then
<amu> so there are some feature plans, but first we have to discuss them, fixing a bug is no problem, we should find a solution for feature development.   
<jdub> enrico: it's being discussed
<pitti> Can somebody please proofread an USN? TIA! https://chinstrap.warthogs.hbd.com/~pitti/usn-libxml.txt
<enrico> jdub: where?
<jdub> enrico: it was brought up off-list
<robtaylor> amu: what's your plan?
<amu> robtaylor: just hold on a little. btw. the FAT16 is orginal one with done with mkfs 
<__daniel> pitti: i can't read it :-)
<Keybuk> Kamion: do you want to double-check things like anna which have translation skew?
<jdub> i don't think it'll last long there
<pitti> __daniel: well, it's not yet public, so this is on purpose :-)
<amu> s/one/one, or 
<enrico> jdub: ah, I see.  Could you please keep me updated?   I took care of sorting this out
<jdub> enrico: i don't think it'll be off-list for long
<enrico> jdub: ok, I'll wait then.  At least now I know that my message didn't go ignored like I was thinking
<robtaylor> amu: umm, i belive the 1st key key was created with syslinux.  the 2nd key used for testing is as-new
<sivang> pitti : need password for that
<pitti> sivang: it's only readable for canonical folks. Sorry, I posted in the wrong channel
<sivang> pitti : ah nevermind :)
<amu> robtaylor: with the existing packages, building the liveCD
<amu> bbiab
<sabdfl> jdub: saw your lsb-release upload
<sabdfl> can we make that explicitly "development" please?
<sabdfl> same for any other version indicators
<sabdfl> i've added lsb-release to the ReleaseChecklist so we don't forget to set it correctly for release
<sabdfl> jdub: ^^ ack?
<fabbione> Keybuk: ping
* fabbione -> food
<jdub> sabdfl: ahr, yeah
<sabdfl> jdub: cool
<jdub> sabdfl: btw, was going to ask mdz, should we make it like this:
<sabdfl> anywhere else we should do that?
<jdub> DISTRIB_DESCRIPTION="Ubuntu (Hoary Hedgehog)" ?
<jdub> or perhaps, given development
<jdub> DISTRIB_DESCRIPTION="Ubuntu Development Branch (Hoary Hedgehog)" ?
<sabdfl> The Hoary Hedgehog Release
<jdub> DISTRIB_DESCRIPTION="Ubuntu, The Hoary Hedgehog Development Branch" ?
<jdub> and then s/Development Branch/Release/ later on?
<sabdfl> prefer the ()'s
<jdub> ok
<sabdfl> Ubuntu (The Hoary Hedgehog Release) Unfer Development
<sabdfl> d
<sabdfl> any is good
<jdub> ok
<Keybuk> fabbione: ello
<seb128> jdub: gst-python has been upload (it's in NEW)
<seb128> uploaded even
<jdub> aha
<jdub> rad
<jdub> thanks
<sabdfl> gst-python?
<jdub> gstreamer
<jdub> python bindings
<robtaylor> ooh :)
<jdub> which are used by FLUMOTION
<sabdfl> nice
<sabdfl> seems rather perfect for ubuntu
<jdub> indeedy
<jdub> hopefully i'll have flumotion in such a state that we can use it in december :)
<jdub> ah, crap
<jdub> lamont, elmo: ping?
<fabbione> Keybuk: can you put back online the xfree86 diff from ubuntu1 up to ubuntu25 ?
<Keybuk> as a single diff?
<fabbione> if possible as separate diff it would be nice
<Keybuk> http://people.ubuntu.com/~scott/xfree86-patches
<fabbione> thanks
<fabbione> 23 24 and 25?
<jdub> NOOOOOOOO
<jdub> argh
<jdub> i thought we locked warty-updates
* fabbione laughs
* jdub hopes the change accept email doesn't mean it'll hit the archive
<Keybuk> jdub: who uploaded what?
<Kamion> Keybuk: yes please, where?
<jdub> i uploaded hoary's lsb-release to warty
<seb128>  lsb-release (1.4-7.1ubuntu5) warty; urgency=low
<Kamion> jdub: hm, I thought we agreed 5.04 rather than 5.4 ages ago ...
<Keybuk> Kamion: in about 10-15 minutes
<jdub> Kamion: mdz seemed to think 5.4 yesterday
<Kamion> jdub: yeah, I saw that
<Keybuk> ugh, 5.4 is harder to compare than 5.04
<Keybuk> we should try and be clear
<Kamion> mkay
<jdub> to be fair, 5.4 -> 5.10 is okay by dotversion comparison generally
<Kamion> not that bothered, just surprised
<Keybuk> descent scott% touch 5.10
<Keybuk> descent scott% touch 5.4
<Keybuk> descent scott% ls -1 5.*
<Keybuk> 5.10
<Keybuk> 5.4
<jdub> Keybuk: that's numeric, not version :)
<jdub> apache will sort it the right way :)
<Keybuk> jdub: FTP won't though
<sabdfl> 5.04 ould be more accurate
<Keybuk> so anyone using a mirror, or grabbing via FTP, will pick the wrong one
<seb128> 5.04 is better imho
<fabbione> Keybuk: can you put online also 23, 24 and 25?
<Keybuk> fabbione: cooking atm
<fabbione> Keybuk: great!
<jdub> non-date version numbers would be ideal! :)
<sabdfl> jdub: nice
<sabdfl> lucky it wasn't x.org :-)
<jdub> yeah
<jdub> has it hit the archive?
<fabbione> eheheh
<sabdfl> jdub: reactionary
<jdub> dude
<jdub> so far you have called me a terrorist and a reactionary
<jdub> and that's just today
<jdub> 'freedom fighter' is preferable ;)
<fabbione> sabdfl: did you hear the news about x.org?
<sabdfl> it's the hair
<sabdfl> and the reactionary, terrorist attitude
<sabdfl> "desktop icons" indeed
<sabdfl> walk freely into the future dude!
<sabdfl> let go!
<sabdfl> fabbione: no?
<fabbione> sabdfl: that it takes approx 60% more build resources that Xfree86?
<Keybuk> fabbione: ok, up now
<fabbione> Keybuk: cool!
<jdub> sabdfl: i should point out that you didn't manage to express the whole scheme until a couple of weeks before the preview - had you done so, the changes would have been simple :)
* jdub goes to find a che guevara tshirt and matching lipstick
<sabdfl> which scheme?
<fabbione> oh and that's with ccache :-)
<sabdfl> fabbione: why?
<jdub> sabdfl: no desktop icons at all, handle the problem elsewhere (ie. the panel changes were the result, not the goal)
<fabbione> sabdfl: it's bigger.. it has more stuff inside.
<fabbione> sabdfl: more extensions, mode libraries
<fabbione> sabdfl: one server more
<fabbione> (that i still need to figure what it does)
<fabbione> Keybuk: i downloaded them. if you want you can remove the dir on people
<fabbione> Keybuk: thanks a lot :-)
<sivang> jdub:  che guevara ?
<sabdfl> jdub: speaking of which, any candidate for the slicker "places" menu in both nautilus and panel?
<sabdfl> jdub: find a win-xp box, and check out how they handle it
<sabdfl> they have two icons sizes
<sabdfl> and for their places menu they use the more compact one
<jdub> sabdfl: yeah
<sabdfl> which allows you to fit a lot in there
<jdub> sabdfl: had some ideas, will run them by you
<sabdfl> ok
<jdub> sabdfl: oh, btw, you got time for a quick call?
<sabdfl> we need to spec and bounty this 
<sabdfl> jdub: sure
<jdub> related stuff
<pitti> any C guru around here?
<pitti> can I always expect "long long int" to be (at least) 64 bit?
<Keybuk> sabdfl: nautilus, panel *and* GtkFileChooser please <g>
<jdub> yeah, those will all be integrated
<sabdfl> Keybuk: absoloodle
<jamesh> pitti: on interesting platforms yes, but in general you can't rely on "long long" existing (it was only standardised in C99, iirc)
<jdub> Subject: Porposing libgnomesu for 2.10
<jdub> ^ dolphins in gnome 2.10, good for ubuntu :)
<Keybuk> plus I don't think C99 actually specifies a size anyway
<pitti> jamesh: I need a reliable way to detect overflow of multiplication of two 32-bit-ints
<Keybuk> "longer than a long int" is about as far as it goes
<seb128> jdub: I've uploaded libgnomesu in debian yesterday
<jdub> cool
<Mithrandir> pitti: use int_64 or whatever it's called?
<robtaylor> jdub: libgnomesu?
<pitti> Keybuk: any better method to check for integer multiplication overflow?
<Keybuk> pitti: asm
<pitti> Mithrandir: oh, if that exists and is portable?
<jdub> robtaylor: see the post, it's kinda what the library name implies ;)
<jamesh> pitti: there is some code in Python's int class to do that portably
<Keybuk> pitti: there's also imaxdiv in C99
<Mithrandir> pitti: uint64_t
<Mithrandir> afaik, it's portable.
<pitti> Mithrandir: thanks, this is great
<pitti> Keybuk: thanks as well, now I have some ideas
<jamesh> pitti: the Python code uses floating point multiplication and compares the result with an integer multiplication.
<robtaylor> jdub: ah, nothing too exciting then..
<pitti> jamesh: hmm, that's a bit ugly but could be a last resort
* robtaylor and carlos need to write authd some day..
<robtaylor> though if gnome apps standardise on using libgnomesu, that'll make integration nice an easy :)
<pitti> Keybuk: sivang is right, http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html says it's 64 bit minimum
<pitti> Keybuk: but I think uint64_t is nicer
<Mithrandir> pitti: I could see if it exists on irix, if we have the SGI compiler there.. if it exists there, it exists everywhere ;P
<pitti> Mithrandir: well, above link is just for gcc...
<jamesh> pitti: how portable does it really need to be?
<pitti> Mithrandir: which would be okay for a security fix, however, I'm interested in a generic solution
<pitti> jamesh: it's just a security fix for Ubuntu
<jamesh> I mean, long long is available on pretty much all modern systems.
<jamesh> ah.
<pitti> jamesh: so gcc is enough
<sivang> tseng : gemme the apt source for tomboy :)
<Keybuk> pitti: sizes are *officially* implementation defined, but I suspect all unixes define long long as at least 64-bits :)
<pitti> Keybuk: I think I will rely on uint64_t. The advantage is, if it does not exist on a platform, you get a compiler error
<Keybuk> indeed
<pitti> Keybuk: instead of making it silently work
<sivang> pitti : or loose bits off at a functino call :)
<pitti> sivang: this is indeed the critical part
<jamesh> Keybuk: I thought they had some set minimums for certain sizes though.
<Keybuk> pitti: long long is defined as being "at least as wide as long"
<pitti> I currently need to fix libgd2, and it uses malloc(width*height) style
<jamesh> certain types, even.
<Keybuk> jamesh: god no, that'd limit C to 8-bit architectures
<pitti> both width and height are 32 bit
<Mithrandir> seems to exist on IRIX 6.5 just fine.
<pitti> so I want to multiply into a 64 bit int, then compare against UINT_MAX or so
<Kamion> Title             Comp.compilers: Re: ANSI portable overflow detection
<Kamion> Current URL       http://compilers.iecc.com/comparch/article/94-05-045
<sivang> Mithrandir : you have access to an IRIX ? cool
<Keybuk> 32-bit machines "long int" and "int" are the same width, 16-bit "long int" is twice as wide as "int" for example (generally speaking)
<Mithrandir> sivang: for some value of cool, sure. ;)
<Mithrandir> just an old indigo 2, though
<sivang> Mithrandir : what's hardware is it running on?
<sivang> Mithrandir : desktopish like? 
<jamesh> on ILP32 systems, int and long int are the same :)
<jamesh> good thing there aren't many LP32 ones.
<Mithrandir> a 250MHz R4400, the box itself is a bit biggish desktop case.
<pitti> jamesh: why, int and long int are the same also on i386
<jamesh> pitti: i386 is ILP32 (== ints, longs and pointers are 32-bit)
<Keybuk> pitti: in fact, obviously now I think about it, LP64 and ILP64 architectures have "long int" as 64-bit
<pitti> jamesh: ah
<pitti> Keybuk: right, but my numbers are explicitly declared as 32-bit ones
<Mithrandir> Keybuk: what arches are ILP64?
<jamesh> Keybuk: and Windows 64 is neither LP64 or ILP64 ..
<Keybuk> LLP64?
<jamesh> yeah
* Keybuk hides
<jamesh> longs are smaller than pointers on win64.
<rburton> jdub: plop
<thom> fabbione: theme song for the X Sprint: "happiness is free when you lose your mind"
<seb128> hey rburton 
<rburton> hi seb128 
<jdub> rburton: grr, on phone, and have to go away for a couple of hours
<jdub> rburton: will ping when i get back
<rburton> jdub: k :)
<sabdfl> seb128: how does the trash applet use the keyring?
<sabdfl> hmm... does it make sense to but 5.04 in for hoary now?
<sabdfl> what if gnome slips?
<seb128> ? I don't understand the question ? It uses it in the same way as the other GNOME apps do ...
<sabdfl> seb128: how is that?
<seb128> there is a gnome_authentication_manager_init () to call and the GNOME libs do all the work
<jamesh> sabdfl: before adding the gnome_authentication_manager_init(), I'd need to check all the sync. gnome-vfs calls
<jamesh> since you can get a deadlock if you do a synchronous vfs call while holding the GDK lock and gnome-vfs wants to pop up an auth dialog.
<seb128> jamesh: ? I've already uploaded a trashapplet using it, is there a problem ?
<jamesh> seb128: possibly.
<seb128> hum, ok
<jamesh> seb128: basically, an app using gnome-authentication_manager_init() needs to be a threaded GTK program
<seb128> let me know if you get a problem, seems to work fine here
<jamesh> (normally, no GTK calls are made in gnome-vfs's worker threads so you don't need to turn on GTK threading(
<jamesh> but the auth dialogs change that.
<seb128> ok. How do you check there is no problem so ?
<jamesh> well, all idles and timeouts that make GTK calls need to call gdk_threads_enter() and gdk_threads_leave()
<Kamion> sabdfl: if we have to remove the Under Development thing anyway, we've got time to change it
<jamesh> and all sync gnome-vfs calls need to be surrounded by gdk_threads_leave() and gdk_threads_enter().
<Keybuk> sabdfl: then we slip and change to 5.05 :)
<sabdfl> Kamion: ok, i was just thinking we should maybe put no version number in there while it's under development
<fabbione> thom: lol
<seb128> jamesh: ok
<jamesh> seb128: I'll look at it tomorrow.  I also noticed that the trash applet wasn't resizing quite right too, which should be pretty easy to fix.
<seb128> yes, there is a bug open about this
<seb128> the resizing is not correct with some panel width
<fabbione> UUHAA
<fabbione> and another bit is fixed
<pitti> Can somebody please review the patch for #2810?
<pitti> Mithrandir: since you are a security crack, mind to have a look? ^
<jono> is there a guide to writing FDI files for HAL anywhere?
<pitti> jono: hal-doc contains a decent specification
<thom> look at an existing one, change what you need? they're very simple
<jono> cool :)
<sivang> what are FDI files?
<sivang> FreeDesktop something?
* lamont wakes up, throws his vote behind 5.04 rather than 5.4
<sivang> oh, these are probably the XML dockies for hardware specs or hal behavior..
<lamont> any french speakers here?
<tseng> sivang: gimme? no thanks
<tseng> sivang: and its up there
<lamont> "Il faut combien pour une mini-tour PC pour ubuntu et/ou serveur debian?"
<tseng> sivang: minor bug in it, missing a ) in debian/control i havent gotten to yet
<lamont> I think I understand it, but not sure.
<sivang> tseng : I installed it on my other machine yesterday, hornbeck provided me with the sources URLs ..It worked very nicely IMHO
<tseng> ok
<sivang> tseng : you would like me to use proper english ? :)
<tseng> please works.
<sivang> tseng : oh sorry :( didn't notice I forgot that in the hurry of typing.
<tseng> nps
<fabbione> lamont: ask seb128 :-)
<fabbione> lamont: or msg bubulle 
<seb128> hum
<lamont> fabbione: yeah - was hoping he'd show up..
<fabbione> see
<lamont> <lamont> "Il faut combien pour une mini-tour PC pour ubuntu et/ou serveur debian?"
<seb128> lack of contexte
<fabbione> he works only on my summon :-9
<lamont> seb128: or I could forward you the email and you could reply in french....
<lamont> talking about liveCD
<seb128> he's probably asking which kind of configuration he needs to run ubuntu (mini-tower or server)
<seb128> or it could be "how much does it cost to get a working config for ubuntu" .. but probably that's probably the first option
<seb128> lamont: feel free to forward any french mail if you want
* lamont forwards
<seb128> ok
<lamont> seb128@c.c?
<seb128> yes
<lamont> sent
<pasc> that's a weird way of phrasing it though. It literally means "You need how much for a mini-tower PC for ubuntu and/or a debian server"
* sivang waits for firefox to load
<sivang> up
<lamont> could be asking for system specs?
<lamont> kids->school.  bbl
<fabbione>   * Remove xprt, libxp6-* and libxp-dev packages.
<fabbione> AHHH
* thom waves to NetworkManager
<thom> it *really* doesn't like ESSIDs with spaces
<pitti> thom: please fix it! My ESSID at home has a space :-/
<seb128> lamont: that's what I was saying, he's probably asking for the minimal hardware requirements ... do we have "official" requirements ?
<sjoerd> pitti: the plugdev group, does that have read/write permissions or only read ?
<pitti> sjoerd: r/w
<pitti> sjoerd: it's similar to 'disk'
<thom> pitti: so does mine, so I will
<sjoerd> pitti: why is write permission usefull?
<pitti> sjoerd: users are able to partition, format and label devices
<sjoerd> hmmm
<pitti> sjoerd: you can start with having the device nodes 640, if you like
<T-Bone> hi
<pitti> sjoerd: but I think Marco should device that, as udev maintainer :-)
<pitti> Hi T-Bone
<sjoerd> pitti: oh i'm just wondering how it all works out.. i wouldn't really want all users who can mount, to also be able to have direct write perms
<pitti> sjoerd: well, they can do pretty much anything with USB devices anyway
<jono> where are the fdi files in ubuntu located?
<sjoerd> pitti: the user can, not the programs running as user
<pitti> sjoerd: we wanted to keep it compatible to 'disk', but if Debian wants to have the permissons as 640, Ubuntu can adopt this, too
<pitti> sjoerd: personally, I don't have a very strong preference, but I like to be able to partition my devices without becoming root
<rburton> jono: i imagine /usr/share/hal/fdi
<pitti> sjoerd: also, hal will not be able to change device labels without write permission as plugdev
<pitti> sjoerd: according to the reply to my question on the hal list, hal will support that 
<sjoerd> i know
<sjoerd> i'm not really happy with it though
<pitti> sjoerd: I would have preferred a database maintained by g-v-m
<sjoerd> pitti: explain
<pitti> sjoerd: but it would only apply to one host and not to other OS
<pitti> sjoerd: instead of writing the device label to the device, g-v-m could maintain a persistent mapping UUID -> label
<pitti> sjoerd: s/writing/using/
<sjoerd> one could do that mapping in hal, user specific fdi's would be nice for that
<sjoerd> for the labelling, why not have an external program that signals hal to reread the label
<pitti> sjoerd: in fact storing the labels in hal (persistently in /var/lib/hal or so) was my idea
<rburton> (speaking of which, any idea how to change the label on vfat without booting windows)
<pitti> sjoerd: and the reason why I asked on the ML whether hal supports persistent keys
<jono> are these fdi files probed each time you plug a device in?
<sjoerd> pitti: sorry forgot the exact reasoning :)
<sjoerd> jono: yes
<pitti> sjoerd: both approaches have pros and cons
<jono> sjoerd, does it load each file one by one and check the pci/usb id?
<pitti> sjoerd: device labels are very limited, but aren't restricted to one host
<sjoerd> pitti: long time ago there was a discussion about the exact goal of hal.. and one of the outcomes was that hal wasn't ment as system configurator
<pitti> sjoerd: I always understood it as hardware database
<pitti> sjoerd: so I think persistent keys fit into the idea
<sjoerd> pitti: so why they want to put labelling inside...
<jono> how can I probe the vendor id and device of a usb device?
<sjoerd> jono: at which level ? hal can tell you those 
<pitti> sjoerd: don't ask me...
<pitti> sjoerd: I would prefer hal to stay read-only
<pitti> sjoerd: this would fit with the host-based database of device labels
<jono> ahhh it says them in the device manager - I am writing an fdi file for my mouse
<sjoerd> pitti: i'm not asking you, i'm explainig why i find it weird :)
<pitti> sjoerd: sorry
<sjoerd> pitti: i'm probably not completely clear, my fault 
<sjoerd> pitti: we don't have to follow hal in the labelling part though.. 
<sjoerd> hal upstream thatis
<pitti> sjoerd: right
<pitti> sjoerd: but if we use the physical device labels, the user still needs to have write access to the device
<pitti> sjoerd: (the label writing could be done by another process)
<sjoerd> true
<sid77> hi
<sjoerd> pitti: but to give the user full write access, just for labelling..
<pitti> sjoerd: and partitioning, and formatting
<sjoerd> still.. well need to think about it, i guess
<pitti> sjoerd: yes
<pitti> sjoerd: I'm currently drowning in work, not really the best time to make design decisions... :-(
<pitti> sooo many security bugs...
<sjoerd> pitti: no need to rush into things, better to wait some time and do it right :)
<pitti> agreed :-)
* fabbione hits libxp6 with a huge cluebat
<pitti> fabbione: still no luck with the damn beast^W^WX.org?
<fabbione> pitti: i have done 70% of the boring job
<pitti> congrats
<fabbione> now i am working on trying to figure out all the changes
<fabbione> pitti: "boring"
<pitti> fabbione: you mean reviewing the 300K+ lines changes?
<fabbione> once we take that away it comes all the messy part
<fabbione> pitti: i finished that 2 days ago :-)
<fabbione> that was easy
<pitti> oh
<fabbione> the boring part is to reallign the MANIFEST checks
<fabbione> and to see what is changed across the entire tree
<pitti> I did nothing else that reading patches and doing security uploads in the last days, I did not listen to any news :-(
<fabbione> like for example check why fonts were not build properly
* pitti understands what fabbione means with "boring"
<fabbione> or why all of a sudden libXaw.a is not shipped anymore
<fabbione> and it takes forever to do a test build
<fabbione> to see if the flags you change will put the stuff back
* robtaylor remembers having to do custom xfree86 packaging.. 
* robtaylor sympathises with fabbione
<fabbione> robtaylor: xfree86 is a nice walk compared to x.org
<fabbione> x.org takes 60% more time to build
<fabbione> time and space actually
<robtaylor> fabbione: oh no! i thought it was supposed to be getting better!!
<pitti> robtaylor: ever saw a new upstream version that was leaner and faster than it's predecessor? :-/
<robtaylor> fabbione: any ideas why? is x.org still using imake or have they transitioned to autotools now?
<fabbione> robtaylor: not when tons of people have cvs commit to it
<robtaylor> pitti: heheh good point ;)
<fabbione> robtaylor: the problem is not Imake or autocrap
<pitti> robtaylor: about the only thing that would possibly help was to rewrite it from scratch
<fabbione> robtaylor: the problem is the amount of (useless) code that has been committed
<pitti> robtaylor: but not for Hoary then... :-)
<fabbione> and i am pretty sure there is something badly wrong with the build system
<robtaylor> pitti: i thought that was the plan.. ;) 
<pitti> sjoerd: oh, providing a wrapper around pmount is really a good idea
<fabbione> because i noticed that timestamps are not in order as they should
<fabbione> and the build dir is full of .bak files
<robtaylor> fabbione: quit epossible, thats why i asked if they'd transitioned yet
<pitti> sjoerd: it should be in a package pmount-hal or so
<fabbione> robtaylor: but i don't have this problem with Xfree86
<fabbione> so it must be something they introduces recently
<robtaylor> probably :(
<robtaylor> check the changelog for anything suspicious..
<fabbione> robtaylor: one thing at a time :-)
<robtaylor> heh
<fabbione> point is that they didn't check what they checked out of xfree86
<fabbione> and their cvs is kinda borked
<fabbione> so it's not even easy to do so
<robtaylor> uurgh
<fabbione> for example...
<fabbione> the Imakefiles.inc in xc/fonts/bdf/75dpi
<fabbione> that one is 4 and half years old
<fabbione> and buggy
<fabbione> but the one in xfree86 (still the real free version)
<fabbione> is 1 year old
<fabbione> and it works fine
<fabbione> so i suspect that their fork hasn't been done properly
<fabbione> at all
<robtaylor> oh god. thats just horrific
* pitti cheers fabbione and gives him a pot of motivation
<Keybuk> http://people.ubuntu.com/~scott/merge/review/
<Keybuk> (and read http://people.ubuntu.com/~scott/merge/README)
<robtaylor> daniels: explain yourself, man!
<robtaylor> Keybuk: out of interest, on avarage, how well have warty patches made it back upstream?
<fabbione> Keybuk: SEXY!
<fabbione> Keybuk: drop xfree86
<fabbione> don't even spend time on it
<Keybuk> robtaylor: reasonably, maybe half of them
<Keybuk> fabbione: sure, those are for everyone else to spend time on :)  I've done 150 :p
<Keybuk> just ignore it
<fabbione> Keybuk: sure.. i was helping :-)
<Keybuk> robtaylor: one nice thing about this is we end up with a fresh set of patches to ping people with
<Keybuk> (after we've filtered out branding and so-on)
<Kamion> Keybuk: might want to deal with things like the removal of vi.po throughout d-i
<Keybuk> heh, yeah I noticed that one <g>
<Kamion> Keybuk: (it was removed in Debian because it wasn't well-enough maintained, but your hoary patch adds it back in)
<Keybuk> I deliberately ignored debian-deletion of translations
<Keybuk> just incase you screamed at me
<Kamion> also, uh, debian/templates seems to be added back in for anna?
<Kamion> I bet it's called anna.templates now
<Keybuk> there's a reason those are all in "review" :o)  they need a human to check them because the automatic stuff went "uhh..." at them
<Kamion> which will probably require .po changes
<Kamion> ok, fair enough
* Kamion will snag all the d-i ones later, then
<Keybuk> it'd be good if people could note what they had to fix as well, because then we can fix that kind of stuff automatically next time
<robtaylor> Keybuk: good going :)
<Kamion> Keybuk: ready/kbd-chooser/ has the same problem with ga.po and vi.po though
<Kamion> might want to add an "uhh..." when Debian deletes a translation
<Keybuk> ah, ok, I'll fix that one manually
<fabbione> cache hit                         129731
<fabbione> (btw ccachetop rocks)
<Keybuk> Kamion: ok, does kbd-chooser look right now?
<Kamion> Keybuk: I think that UML-addition hunk is a duplicate
<Kamion> Keybuk: that code got merged in Debian
<Kamion> Keybuk: note the diff -p header
<Keybuk> yeah was just noticing that
<Kamion> the only change should be the high->critical bit, I think
* Keybuk wonders why he didn't spot that before (I did diff -p for that reason) :p
<Kamion> nice work, though :)
<robtaylor> amu: well, i've been grokking kernel sources all day, and as far as i can tell the rootfs of the kernel helper thread that start the process that execve's to /asbin/hotplug should have had its root changed by pivot_root...
<Kamion> robtaylor: I'm missing context; but you don't have /sbin/hotplug in the initrd do you?
<robtaylor> amu: so either a) the hypothesis is wrong or b) its a subtle kernel bug
<robtaylor> Kamion: context is http://bugzilla.ubuntu.com/show_bug.cgi?id=2758
<robtaylor> bascially on the livecd, /sbin/hotplug doesnt seem to ever get called
<robtaylor> (except when coldplugging)
<Kamion> might be worth making sure /sbin/hotplug only exists in the final pivot_rooted filesystem
<robtaylor> Kamion:  might be, but even then, if the kernel helper thread has the wrong fs->root, then its'll fail to execve it..
<Kamion> true
<Kamion> was thinking more of the problem I had last night where udevd was running in the wrong root
<Kamion> thereby making it hard to umount it
<robtaylor> Kamion: it does appear that minimod has /sbin/hotplug
* Kamion -> lunch
<robtaylor> Kamion: intersting.. how did you reach that state?
<robtaylor> Kamion: wow. late lunch!
<thom> hrm, lunch sounds like a stunning plan
* thom -> lunch
<Micksa> oh my
<Micksa> I just came home to the cow screensaver on the live cd :)
<Micksa> welp, apart from a few glitches, it's looking good guys
<pitti_> pitti_: can I read this?
<Kamion> robtaylor: I only started at about 11
<Kamion> robtaylor: I had all the hotplug and udev infrastructure in the initrd; you pretty much have to, because of the way d-i's early putting-itself-together process works
<Kamion> robtaylor: so a hotplug event fired just after init started, and triggered udevsend, which started udevd before /sbin/init got around to doing pivot_root
<Keybuk> Kamion: btw, is there any consideration for binaries in d-i?
* Keybuk is knocking up the map parser at the moment
<Keybuk> I suspect there won't be an issue, because it's written to be tiny and not depend on anything in /usr anyway
<Kamion> Keybuk: what do you mean?
<Kamion> oh, you mean something written in C? go ahead, shouldn't be a problem
<Keybuk> yeah, something small and fast
<fabbione> robtaylor: got it! the install targets relinks all the binaries around!
<fabbione> creating all .bak files
<fabbione> that's so SAD
<Kamion> somebody make hotplug's init script less insanely verbose, too
<Kamion> it's really ugly as d-i starts now
<Kamion> hmm. it's safe to run /etc/hotplug/*.rc start multiple times, isn't it?
<sladen> daniels: to you have a handied separated copy of the -noswitchvt patch ?
<robtaylor> Kamion: should be
<Kamion> good, I'll need that
<robtaylor> Kamion: hmm, but for you, after the pivot_root, its running the /sbin/hotplug in the pivoted root?
<Micksa> is it just me or is the teams' development process maginificently streamlined?
<robtaylor> fabbione: thats pretty grim
<Kamion> robtaylor: yep, definitely
<Micksa> anyway, how can I find out about the team's development methods? is there much info on the wiki or whatever?
* lamont returns
<Kamion> apart from {WartyWarthog,HoaryHedgehog}/ReleaseSchedule and the various plans and meeting agendas and stuff, we mostly just do stuff and try not to get in each others' way :-)
<Micksa> well
<Micksa> okay
<Micksa> that was anti-climactic :)
<Micksa> has some sort of structure/procedures/etc arisen out of that?
<lifeless> yeah, cutting code :)
<Micksa> heh, okay
<Micksa> so basically it comes down to you people generally knowing how to Get Shit Done
<Micksa> guess it helps that you can all cut code in your sleep huh :)
<Micksa> uhm, is the wiki on ubuntulinux.org public?
<lifeless> I hope so :)
<Kamion> yes, but you need to log in
<lifeless> what sort of tree?
<Micksa> to log in you need an account right? :)
<Micksa> ahem. I can't find the "create new account" thingy, if there's meant to be one
<lifeless> dude.
<lifeless> oh, has it gone to zwiki yet ?
<lifeless> is it a moin moin or a zwiki you are seeing ?
<Micksa> zwiki
<lifeless> ah, no idea.
<Micksa> :) okay
<Micksa> phew, I thought I was about to be LARTed into next week
* lifeless larts because he can
<jdub> rburton: around?
<rburton> jdub: yes
<jdub> jabber keeps kicking me off
<jdub> gar
<jdub> excellent
<jdub> home?
<rburton> aye
<lamont> jdub: why does clicking on the terminal icon on the panel give me _2_ terminal windows?
<robtaylor> Kamion: boh.. well this livecd issue is looking weirder by the minute.. i'm tempted to blame mini_fo =)
<pitti> sjoerd: I'm currently at fixing pmount
<pitti> sjoerd: if pmount shall get a "-t" option for specifying the fs type
<pitti> sjoerd: what shall pmount then do with the mount options?
<pitti> sjoerd: currently it uses appropriate mount options for each file system type (i. e. whether it supports rw, uid=, etc.)
<sjoerd> pitti: with the other mount options you mean ?
<pitti> sjoerd: yes, like -o uid=1000 or so
<pitti> sjoerd: some file systems don't support them and will fail to mount
<Micksa> ah, I see. the doc team are establishing a structure in the new wiki.
<pitti> sjoerd: so either I keep a mapping of valid file systems and only allow keys of this mapping as -t
<pitti> sjoerd: s/so either/A solution would be that/
<pitti> sjoerd: any better idea?
<sjoerd> pitti: i guess that's the best 
* pitti wishes ANSI C had a ready-to-use mapping type
<sjoerd> pitti: letting the calling process indicate the options is insecure, so the only way is internal
<pitti> sjoerd: ?
<pitti> sjoerd: please try to reexplain that, my brain is already very boiled today :-(
<sjoerd> pitti: your solutions is doing it internal, map the given filesystem to sane options right..
<pitti> sjoerd: yes, that was my intention
<pitti> sjoerd: if no -t is specified, I try every entry in succession
<sjoerd> pitti: doing it !internal -> external, would be to have for example the calling process specify the options
<pitti> sjoerd: if -t is specified, I look it up (and fail if it is not found)
<sjoerd> but that's insecure
<pitti> sjoerd: I still don't understand
<pitti> sjoerd: you mean that I put the mapping into a conffile?
* pitti is too lazy to parse it
<Micksa> hrmyes.
<Micksa> oops
<pitti> sjoerd: what do you mean with "external mapping"?
<sjoerd> pitti: external == something else then pmount :)
<pitti> sjoerd: but then pmount had to check the options for validity
<sjoerd> yep, so that sucks 
<pitti> sjoerd: there really isn't much you can change
<pitti> sjoerd: apart from sync/async
<sjoerd> hence your option is the best :)
<pitti> sjoerd: also, it does not require to parse something :-?
<hornbeck> what happened to the new wiki?
<hornbeck> nevermind I guess my settings got changed
<sjoerd> pitti: btw do you want to package a hal-pmount wrapper seperate from pmount? 
<pitti> sjoerd: I don't want the core pmount package depend on hal
<pitti> sjoerd: because it is also useful without hal at all
<sjoerd> s/hal/libhal{,-storage}0
<pitti> sjoerd: so the source package could produce another .deb (arch-all) which depends on pmount and hal
<pitti> :w
<sjoerd> my first choice would be to implement it in C.. there are no language bindings for the hal libs
<pitti> argh, wrong window
<sjoerd> hehe
<pitti> sjoerd: not? there is hal-get-property, not?
<pitti> sjoerd: you mean there is no shell binding for hal-storage?
* sid77 -> quit, bye
<sjoerd> ok, you could call that a binding.. 
* sjoerd always find shell to get cumbersome very quickly
<pitti> sjoerd: I actually thought of a simple shell wrapper
<pitti> sjoerd: well, python would be okay, too :-)
<sjoerd> then you have the language bindings problem.. you can talk to hal directly like h-d-m, but still
<pitti> sjoerd: hmm, we should start with a shell wrapper
<sjoerd> maybe it's simple enough to be plain shell, haven't thought about it enough
<pitti> sjoerd: if it gets too clumsy, we can change the language at any time
<sjoerd> pitti: agreed
<pitti> sjoerd: so it shouldn't actually do more than specify (or not) --async and the device label, right?
<pitti> sjoerd: sounds like a four-line script by now
<sjoerd> hmmm.. the default policy defines more options, probably not usefull for us
<pitti> sjoerd: which options?
<sjoerd> nosuid, noexec, noauto, ro
<sjoerd> first three are obvious
<pitti> sjoerd: hmm, pmount policy fixes this
<sjoerd> yeah, so their useless for us
<pitti> sjoerd: not only for us - allowing suid mounts is kind of insane...
<mdz> morning
<sjoerd> pitti: fstab-sync isn't very sane :p
<sjoerd> pitti: to be serious, it's indeed just sync and suggested label for now.. so a shell script should do the trick
<pitti> sjoerd: don't tell me that fstab-sync currently respects the nosuid value from hal!
<sjoerd> pitti: i won't say a word about that then :)
<pitti> :-)
<pitti> whoever... nevermind
<mdz> pitti: no, no approval is needed for syncs at this stage, just verify against the changelog
<pitti> mdz: oh, good morning!
<pitti> mdz: okay, good to know
<daniels> robtaylor: i'm not responsible for imake; right now, I'm leading the charge to kill the monolithic tree.
<pitti> mdz: BTW, do you know how to get a CAN number?
<robtaylor> daniels: i know, i was just teasing you ;)
<mdz> pitti: in most cases I can assign one
<pitti> mdz: I already mailed cve@mitre.org to get one for #2808
<pitti> mdz: but I did not get an answer so far
<mdz> however, if a vulnerability is publicly known, it must be assigned by MITRE in order to avoid duplicate assignments
<daniels> robtaylor: heh
<mdz> pitti: I usually mail  "Steven M. Christey" <coley@mitre.org>
<pitti> mdz: hmm, it's on bugtraq, I guess that counts as public
<robtaylor> mdz: that livecd bug's just looking worse by the day :/
<pitti> mdz: hmm, I followed the FAQ and mailed cve@
<mdz> robtaylor: which one?
<mdz> pitti: they probably go to the same place
<pitti> mdz: what do you think, shall I upload the package without a CAN or wait?
<robtaylor> mdz: http://bugzilla.ubuntu.com/show_bug.cgi?id=2758
<mdz> robtaylor: I didn't realize until that bug that the live CD wasn't running in the real root
<mdz> it was impossible to fix in time
<robtaylor> mdz: yeah, whats the plan going forward?
<mdz> pitti: wait, the bug is not serious
<mdz> robtaylor: fix it :-)
<pitti> mdz: well, if you trust your ISP, it is not really serious
<pitti> mdz: but ppp is very common also with p2p connections
<robtaylor> mdz: its a bit weird, tho, i cant see why the kernel isnt running the current /sbin/hotplug
<pitti> mdz: so I would still like to fix that in warty; you don't?
<robtaylor> mdz: it just executes it in the context of the kernel helper thread, which should have had its root changed by pivot_root
<mdz> robtaylor: it is running the only one it could possibly choose, the real one
<mdz> the CD doesn't use pivot_root, no? that's the whole problem
<mdz> pitti: what kind of p2p connections?
<robtaylor> mdz: ah, it doesnt? that would explain it.. what is it doing?
<pitti> mdz: not the warez ones :-)
<mdz> robtaylor: chroot
<mdz> robtaylor: as I discussed in the bug
<robtaylor> mdz: ahhhh....
<mdz> either that one, or another one
<pitti> mdz: I just meant I can talk to the modem of my friend directly over ppp
<robtaylor> mdz: hmm, are you familiar enought with the morphix stuff to point me in the right direction for fixing this?
<mdz> robtaylor: no, I am not
<robtaylor> boh
<mdz> pitti: yes, your friend :-)
<pitti> mdz: or believed friend :-)
<mdz> pitti: if you truly want to release without a CAN, you may
<mdz> pitti: it creates more work for _you_ though, to track it
<pitti> mdz: since it's not that critical, I can wait for another day or two
<pitti> mdz: I also created a patch for #2810 (this one is truly serious)
<mdz> pitti: when did you send the mail?
<pitti> mdz: I asked for review, but did not get one so far
<mdz> mitre is UTC-4
<pitti> mdz: Thu, 28 Oct 2004 15:00:04 +0200
<pitti> mdz: so, 9:00 am of their time
<mdz> yes
<mdz> pitti: where did you ask?  I will review it if needed
<robtaylor> lamont: ping?
<pitti> mdz: on the Debian bug and on the Warty one (and on IRC)
<lamont> robtaylor: yo
* Kamion wonders why the sk98lin-update patch in our kernel hasn't gone upstream yet
<Kamion> the lack of MODULE_DEVICE_TABLE killed my first d-i pure hotplug test
<robtaylor> lamont: so does the livecd actually chroot rather than pivot_root?
<lamont> robtaylor: 2 minutes
<robtaylor> lamont: np :)
<lamont> and I'll be back...
<lamont> robtaylor: I think it does chroot.  dunno actually
<mdz> pitti: mail to ubuntu-devel would probably be good practice
<lamont> but pretty sure.
<lamont> brb
<mdz> it is timezone-skew-friendly
<pitti> mdz: right, I'll do that
<pitti> mdz: BTW, I uploaded a libxml2 security patch, USN is prepared
<pitti> mdz: https://chinstrap/~pitti/usn-libxml.txt
<jdub> mdz, pitti: can you guys read the following thread, tell me what you think?
<jdub> http://mail.gnome.org/archives/desktop-devel-list/2004-October/msg00419.html
<Kamion> Keybuk: your .po merge seems to have thrown away lots of non-ISO-8859-1 characters ...
<mdz> pitti: hmm
<Kamion> look at anna_hoary.patch debian/po/cs.po, for instance
<Kamion> msgid "Loading components of the Ubuntu installer"
<Kamion> msgstr "Nahrvaj se komponenty instalanho programu"
<Kamion> #~ msgid "Loading components of the Debian installer"
<Kamion> #~ msgstr "Nahrvaj se komponenty instalanho programu"
<mdz> pitti: what type are rowbytes and height?
<pitti> jdub: I don't really see the reason why it shouldn't use sudo, though
<pitti> mdz: png_int_32 or so
<pitti> mdz: 32 bit in all cases
<mdz> pitti: signed or unsigned?
<pitti> mdz: unsigned
<pitti> mdz: nevertheless, I compare it to INT_MAX, not to UINT_MAX
<jdub> pitti: i gather the only reason he's not doing sudo so far is because he hasn't figured out how to do it nicely, within his framework
<pitti> mdz: since size_t (the actual type of malloc) is signed
<pitti> jdub: right, but gksudo calls sudo asynchronously
<mdz> pitti: 2^32-1 * 2^32-1 > 2^64-1
<pitti> jdub: I don't know why this shouldn't work for him
<mdz> oh, no it isn't
<Kamion> Keybuk: hm, mind you, the old translation was broken in a different way
<pitti> mdz: ?
<pitti> mdz: okay
<mdz> pitti: I think this is probably safe, but the usual way to do the check is somewhat different
<pitti> mdz: I don't know the "official" way. I asked the guys on IRC, thoug
<pitti> mdz: and we agreed that this one is feasible
<mdz> pitti: the way it is done later in the patch
<pitti> mdz: what's the official?
<mdz> +      if (height >= INT_MAX/sizeof(png_bytep)) {
<pitti> mdz: but that does not work too well for bigger numbers, since it's integer
<mdz> for a possible overflow X*Y, you test X >= INT_MAX/Y
<pitti> mdz: I only did that for numbers which are fixed and 1,2,4 or so
<sivang> howdy again all
<mdz> pitti: it works fine, since integer division is rounded down
<sivang> hi hornbeck
<pitti> mdz: ah, right, I mixed the rounding up
<sivang> mdz : I think I have an idea for that performance bug on my dekk
<sivang> mdz : dell
<thom> so what's the go with ~ ?
<pitti> mdz: okay, then I change the patch 
<sivang> mdz : do you have a minute for me?
<mdz> sivang: I cannot give you my undivided attention, but please don't wait, just describe your idea
<robtaylor> lamont: back yet?
<lamont> robtaylor: sorry, yes.
<mdz> pitti: there is no patch available upstream for libgd?
<robtaylor> lamont: i've been trying to figure where the pivot_roots/chroots happen, do you knwo enough morphix to point me in the right direction?
<lamont> not really.
<sivang> mdz : I've tried to play several media file on the dell, using the debian kernel (on the bugtrail), when I'm constantly at the machine - It seems like its responsivness goes bit higher.
<lamont> I'd expect to find them in the people.ubuntulinux.org/~lamont/LiveCD/morphix tree though
<robtaylor> lamont: thanks :)
<sivang> mdz : My assumption is, that this which menifests lightly on the debian kernel, probably takes much nastier form on the ubuntu ones
<sivang> mdz : which results in the system barely usabe.
<seb128> jdub: here ?
<jdub> yeah
<jdub> sivang: the machine is running awfully slow?
<mdz> sivang: what is the bug #?
<sivang> mdz : If only I could disable altogether ubunut's support for fan control, thermal and cpu freq
<sivang> mdz : I think it might be solved.
<seb128> jdub: I'm packaging gnome-vfs2 2.8.3 for hoary, good time to add the build-dep on libhowl-dev, right ?
<sivang> jdub,mdz : sec
<mdz> sivang: why?
<jdub> seb128: yes, rock and roll :-)
<seb128> ok, cool :)
<sivang> jdub,mdz : #2315
<sivang> mdz : the fact that the system goes into a much more usable and responsivness when using it constantly, cliking windows, playing media files , accessing the hd etc
<sivang> mdz : suggest to me that when I leave it to idle,
<sivang> mdz : it enters power/cycle saving mode that it has trouble getting out of
<mdz> sivang: I agree, it sounds like it is overheating
<mdz> sivang: is the CPU fan coming on at all?
<sivang> mdz : now I could nicely invesitage it using the media files playing thing, I first tried to play it off  after just firing up the mahicne - no go
<sivang> mdz : I tinkered with it a bit,
<sivang> mdz : casued to do disk access and some massive gnome works, and it suddenly worked
<lamont> robtaylor: yeah - I pruned the knoppix tree down to just wjat'
<lamont> s used, but the morphix one is still full.
<sivang> mdz : the cpu comes relatively long after the system starts.
<sivang> mdz : the fan
<sivang> mdz : could you supply me with a kernel that doesn't do powersaving/cycle down/ fan control at all? I want to machine to be working at it's full speed all time to test
<mdz> sivang: is there anything in /proc/acpi/thermal_zone ?
<sivang> mdz : btw, even when it starts the fan never goes to it's fullest rpm like on XP
<mdz> sivang: try booting with acpi=off
<jdub> sivang: have you booted that machine with acpi=force or acpi=off?
<elmo> GAR
<sivang> jdub : never tried acpi=force
<mdz> sivang: don't, use acpi=off
<sivang> jdub : all the others, I did
<elmo> jdub: you know you uploaded the "Hoary Hedgehog" lsb-release to warty, right? 
<thom> elmo: did you just wake up?
<jdub> pipka's toshiba runs horribly slowly on the ubuntu kernel
<mdz> sivang: check /proc/acpi/thermal_zone please
<jdub> elmo: one, yes, it was a mistkae - did it hit the archive?
<elmo> yes
<jdub> if she runs it with acpi=force, then it's fine
<jdub> elmo: cock
<jdub> elmo: i thought uploads were restricted anyway?
<elmo> they go to warty-updates
<elmo> but it's still in warty-updates now
<jdub> they don't require manual auth?
<mjg59> sivang: acpi=off disables the kernel's control of all power saving except CPU frequency scaling
<mdz> jdub: acpi=force can help sometimes if ACPI is being disabled by default; in sivang's case it is enabled properly
<elmo> jdub: no, I was told manual auth wouldn't be necessary :P
<mjg59> Stopping the powernowd service will disable the latter
<mdz> elmo: can we make it so that things uploaded to 'warty' are rejected, and warty-updates must be uploaded explicitly to warty-updates?
<sivang> mdz : I have THM under /proc/acpi/thermal_zone
<elmo> yeah, probably, I'll look at doing that
<elmo> thom: pretty much, I woke up (again) a couple of hours ago
<thom> elmo: ouch
<pitti> mdz: sorry, phone. There's no new upstream version and I did not find a public CVS for libgd
<sivang> mjg59 : I want to disable cpu freq scaling also
<sivang> mdz : polling_freq = disabled
<sivang> mdz : state = ok
<sivang> mdz : temp = 52C
<sivang> mdz : critical(S5) = 94C
<mjg59> sivang: Stop powernowd
<sivang> mjg59 : it's doing cpu freq scaling?
<sivang> mjg59 : what about cpu scaling accoridng to battery charge?
<mjg59> There isn't any
<sivang> mjg59 : ok, I hope this is not the case of buggy hardware..
<sivang> mdz,jdub : I will try acpi=force
<mjg59> sivang: No, acpi=force will do nothing
<mjg59> All that does is force acpi to be enabled. It already is enabled for you.
<mdz> pitti: I will see what I can find
<mdz> sivang: I already explained the same thing that mjg59 said
<pitti> mdz: BTW, I'm at updating it to use the division method
<mdz> pitti: I will see fi I can find a semi-official patch
<sivang> mdz : k :)
<mjg59> sivang: acpi=off will disable the kernel's management of power saving and leave it up to the hardware. Stopping powernowd will stop frequency scaling.
<elmo> GAR god damn it keybuk
<bluefoxicy> so, naked men, and a whorey branch?
<bluefoxicy> :)
<sivang> mjg59 : can I disable entirely the scaling modules that probably interacts with the userlan powernowd ?
<Keybuk> elmo: ?
<lamont> mjg59: is there a FM I can go read to tell me how to have acpi/whoever not do anything when i close the lid?
<mjg59> lamont: It's managed by /etc/acpi/events.d
<mjg59> s/.d//
<lamont> thanks
<mdz> Kamion: any fun new stuff in anna?
<robtaylor> lamont: so is a knoppix-based one something your looking at?
<lamont> robtaylor: no. morphix uses 3 knoppix packages
<robtaylor> lamont: ah, ok, good :)
<lamont> specificaly, the hw detection/setup...  which goes away/merges for hoary
<mjg59> Is powernowd actually doing the right thing on startup?
<mjg59> Does an Ubuntu system have anything in /lib/modules/`uname -r`/kernel/drivers/cpufreq ?
<pitti> mdz: I updated the patch and put it in bz
<robtaylor> lamont: that'd be cool
<mdz> pitti: bug#?
<pitti> mdz: 2810
<lamont> robtaylor: it's kinda like a hoary-requirement
<robtaylor> lamont: it dioes seem to chroot, according to http://am.xs4all.nl/morphix/diagrams/base-module-complex.png, i just need to figure out why..
<pitti> mdz: I added rowbytes >= INT_MAX before division checking to avoid problems with signed/unsigned autoconversion with the division
<Kamion> mdz: some more lowmem support, bit of extra error checking, preseeding support
<jdub> PREEEEEESEEEEEEED!
* Kamion dives into the base-installer .po merging nightmare
<Kamion> I *so* need to get sarge out so that we can merge some of that stuff back to Debian
<pitti> the Release Manager has spoken :-)
<sivang> Kamion : you work with Joey Hess right? :)
<Kamion> in some projects, yes
<sivang> mdz,jdub : acpi=off halts the boot process on detecting IDE drives.
<elmo> mdz: done ('warty' uploads being rejected)
<sivang> Kamion : he also working on D-I right?
<sivang> mdz : acpi=force yeilds the same prformance resluts, I recall something with epic=somethign you told me
<sivang> mjg59 : I apt-get removed powernod, however on startup I still get a message that thermal and fact control modules are loaded.
<mjg59> sivang: Yes. Pass acpi=off
<sivang> mjg59 : acpi=off just hangs the machine when it detects IDE drives, thuse render it unbootable.
<mjg59> sivang: For the last time, acpi=force will do precisely nothing on your computer. Ever.
<mjg59> sivang: Right. That's an entirely separate problem
<sivang> mjg59 : ok. 
<sivang> mjg59 : maybe disable acpi on bios?
<mjg59> If the BIOS lets you disable acpi, then yes
<mjg59> It's unlikely that it will
<mjg59> If you're using acpi, you must load the thermal and fan modules
<mjg59> Otherwise your computer will potentially be damaged
<sivang> mjg59 : what happens if I dont? Can't I not use if my system hangs the kernel due to it?
<mjg59> If your machine hangs when you try to boot without acpi, you must use acpi
<mjg59> If you use acpi, you must load the thermal and fan modules or your computer will be physically damaged
<sivang> mjg59 : ok then. 
<mdz> elmo: great, thanks
<robtaylor> mjg59: ah, that explains why my laptop burnt itself out at debconf...
<robtaylor> ah no, that was apm ..
<Kamion> sivang: joeyh started the d-i project and has written a vast amount of its code, yes
* elmo prepares to make mdz and baby jesus cry
<Keybuk> elmo: what are you doing?
<elmo> preparing the latest mail about hoary seed syncage - there's a dep chain of despair that's going to pull in a bunch of packages we've been trying to avoid in main since forever
<mdz> gah
* mdz wields the dependency machete of DOOM
<hornbeck> sivang: hello
<bluefoxicy> is the devel list slow?
<lamont> fabbione: should I expect toresetXbeforethespacekeymapping is correctwhenIchangekyeboards?
<elmo> btw, the testing page is actually looking sane now, compared to yesterday (err, or whenever it was I was last up)
<elmo> aiee, keybuk
<elmo> guys, don't upload stuff that has no changes from Debian, with the same version
<elmo> it'll be synced automatically
<elmo> and if and old 'ubuntu' version needs overridden, just let me know
<Keybuk> elmo: agh
<Keybuk> that's a "stupid keybuk", I uploaded the wrong thing anyway
<Keybuk> bleh
<Kamion> $ debdiff base-installer_1.12.dsc base-installer_1.12ubuntu1.dsc | wc -l
<Kamion> 15219
<Kamion> $ debdiff base-installer_0.087ubuntu13.dsc base-installer_1.12ubuntu1.dsc | wc -l
<Kamion> yay for base-installer
<Kamion> 29610
* lamont comes to the conclusion that a session manager is pretty useless to him unless he can find a _reliable_ way to get his ssh passphrase intered into ssh-agent _BEFORE_ALL_THE_&*^$^(&^%)*_WINDOWS_START_
<Kosai> lamont: This is why we have a priority variable for the startup programs in g-s-m.
<mdz> |diffstat is a better metric than |wc -l
<lamont> Kosai: nope.
<lamont> that _starts_ gnome-ask-pass, but doesn't block for it to finish.
<tseng> lamont: there is a gtk2 ssh askpass i used to use
<lamont> see "_reliable_"
<tseng> that goes full screen
<tseng> seemed to prevent other stuff from working until it returned
<lamont> tseng: but still doesn't stop everything else from starting and asking for the passphrase before you can enter it into ssh-agent
<Kamion>  1 files changed, 5339 insertions(+), 1840 deletions(-)
<Kamion>  1 files changed, 8454 insertions(+), 6226 deletions(-)
<Kamion> (respectively)
<lamont> prevents keyboard focus, iirc
<tseng> well i was runing it from xinitrc also
<Kosai> lamont: I see.
<Kamion> (although the "1 files changed" is bogus)
<tseng> if you had a .xsession that read
<tseng> ssh-askpass &
<tseng> exec gnome-session
<Kosai> I use x11-ssh-askpass; even if other windows are opened, x11-ssh-askpass refuses to give up focus to them.
<tseng> i imagine that would be it
<tseng> ?
<Kamion> do ssh-add, not ssh-askpass &
<Kosai> So, gnome loads, ssh-askpass comes up, I start typing my passphrase, if some xterms appear on top of it I just keep typing and hit return.
<lamont> Kosai: but if you're not there to type the passphrase quickly enough, then all the ssh windows block _WANTING_THE_PASSPHRASE_
<Kamion> simply don't put ssh-add in the background in .xsession. easy.
<lamont> in short, it's not integrated.
<Kamion> $ cat .xsession
<Kamion> #! /bin/sh
<Kamion> ssh-add
<Kamion> exec fluxbox
* lamont beats on jdub with ssh-askpass
<mdz> Kamion: I don't know what it is, but that seems to confuse everyone (ssh-add vs. ssh-askpass)
<lamont> Kamion: that'll block everyting?
<Kamion> ssh-askpass asks for a passphrase, it doesn't *do* anything with it :-)
<Kamion> lamont: yes
<mdz> Kamion: I know that, you know that
<lamont> what's fluxbox?
<mdz> Kamion: but I've seen dozens of people go down the wrong road :-)
<Kamion> lamont: lightweight window manager
<mdz> maybe ssh-askpass should be renamed to tnhoenushoeuo
<mdz> youdontwanttorunthisprogram
<Kosai> I know it too, since if I wasn't running ssh-add my passphrase would never get anywhere, just forgot it for this conversation.  :)
<mdz> Kamion: in fact, maybe it should go in /usr/lib
<mdz> probably too late for that
<Kosai> mdz: Yeah, like people pay attention to what filesystem hierarchy means.  :)
<Kamion> mdz: compatibility implications, ssh-add calls it and there are several filesystems involved ...
<Kosai> (See:  "Dude, where the hell is traceroute?  This sucks.")
<Kamion> er, not filesystems, packages
* Kamion temporarily went into Hurd mode there or something
<mdz> Kosai: (see: "sbin directories are in the default PATH in Ubuntu") :-)
<Kosai> mdz: Coo.  Okay, then.
<mdz> when The World straightens itself out wrt FHS, we can revisit that
<lamont> does .xsession need to be +x?
<Kamion> -rw-r--r--  1 cjwatson cjwatson 33 2003-12-24 12:04 /home/cjwatson/.xsession
<elmo> Out-of-date BUT modified: 175 (17.01%)
<elmo> Updated:                    0 (0.00%)
<elmo> Ubuntu Specific:           19 (1.85%)
<elmo> Up-to-date [Modified] :    157 (15.26%)
<elmo> Up-to-date:               678 (65.89%)
* lamont brb
<mdz> it really _ought_ to be +x, and executed
<mdz> what if I want to write my .xsession in python? :-P
<elmo> (main only)
<mdz> elmo: that's after this batch of uploads from Keybuk?
<mdz> or before?
<elmo> after
* lamont begins to wonder if Kamion uses gdm to log in
<lamont> ~lamont/.xsession is never executed in the normal login path that I can see.
<elmo> updated http://people.ubuntu.com/~james/packages_to_merge.txt
<Kamion> lamont: yes, I do
<Kamion> lamont: you may have to change the session option from the gdm login screen
<lamont> from, to?
<Kamion> there are only a few options, try them ... :)
<Kamion> I think I use "Xsession"
<lamont> heh.
<mdz> yow
<mdz> popularity-contest merged?
<mdz> didn't thom basically rewrite it?
<mdz> oh, probably as a separate program for the submission
<seb128> lamont: system session is ~/.xsession
<Keybuk> yeah, two separate programs
<mdz> Kamion: how hairy is the d-i merge so far?
<Kamion> tolerable; about me-hairy rather than elmo-hairy
<Kamion> (the other extreme, obviously, being mdz-hairy)
<thom> mdz: seperate program, just the cron job changed
<lamont> the other cute one is the way gnome-session fires up a new firefox for each window that was open when you logged out, and n-1 ask for which profile you want...
<lamont> so the session manager is launched in the background...  GRUMBLE!
<mdz> elmo: we talked a while back about having notifications sent to -changes for syncs from sid, is that still on your list?
<Kamion> Keybuk: do you know what causes Report-Msgid-Bugs-To: to be shifted around in all your .po merges?
<Keybuk> Kamion: msgcat, I think
<Kamion> hm, ok
<Keybuk> I can't work out whether Linux's support for printers sucks, or my ability to use printers sucks
<mdz> Keybuk: neither. printers suck
<lamont> I win.
* lamont hugs dpkg-divert
<Keybuk> lamont: ?
<pitti> mdz: any news regarding libgd?
<lamont> local diversion of /usr/bin/gnome-session to /usr/bin/gnome-session.real
<lamont> more /usr/bin/gnome-session
<lamont> #!/bin/sh
<lamont> ssh-add
<lamont> exec /usr/bin/gnome-session.real "$@"
<lamont> _THAT_ does what I want
<Keybuk> heh
<Keybuk> I put ssh-add into "Startup Programs"
<lamont> doesn't block
<mdz> pitti: I found nothing so far
<Keybuk> aye
<lamont> my solution blocks. :-)
<Keybuk> why not just use .xsession for that? :p
<mdz> Kamion: what would be a good unique string to search for to detect debbugs bug closures by searching bugzilla comments?
<lamont> gnome-session also fails miserably in tracking applications that open multiple windows, it appears...  Each window gets a new invocation of the program upon logging out (save changes) and back in.
<lamont> Keybuk: because .xsession also doesn't block
* lamont tried that...
<lamont> hrm... /me verifies.
<Kamion> mdz: do you get the Received: headers?
<Keybuk> at some point, we should teach lamont about Xnest
<mdz> http://pacsec.jp/advisories.html
* mdz makes a note to NEVER EVER use ieee1394 for anything
<Keybuk> mdz: should I not write grepmap --ieee1394map then? :p
<jdub> mdz: *boggle*
<mdz> Kamion:     want_headers = ('message-id', 'date', 'from', 'to', 'cc', 'subject')
<Kamion> mdz: if you can get the Received: headers again, you could take the very first one and search for /\(at [^)] *-(?:done|close)\)/ in it
<pitti> mdz: well, if you have physical access to a computer, all security bets are off anyway, not?
<mdz> Keybuk: that, or explain to the ipod users that they could get r00ted by their ipod
<pitti> mdz: still, this is scary. Thanks for that link!
<mdz> Kamion: the received headers are gone...it doesn't need to be perfect, though, I  just want to make a report that I can quickly skim over and close bugs which have been fixed in the merge
<Kamion> mdz: I guess you could look for -done or -close in To:/Cc: then
<Kamion> mdz: in future I suggest you take X-Debian-PR-* ...
<jdub> gcc-3.4 depends on kdebindings? crack!
<Javi> hi, people, do you know how is Ubuntu sound system configured ? I'd like my debian sound system like my ubuntu sound system, but I can't find diff on configuration, but ubuntu is better than debian on this feature
<mdz> Kamion: the reason I trim them is that they appear at the beginning of every comment
<mdz> Kamion: but, point taken
<mdz> Javi: please /join #ubuntu for support questions
<jdub> (build-depends)
<Kamion> mdz: you can also use the standard dpkg regex for closes:, which may help
<Kamion> mdz: maybe they could be stashed somewhere else eventually ...
<mdz> Kamion: searching for 'source-version' seems to do well enough
<Kamion> mdz: not guaranteed not to get that on bug openings too
* lamont wonders why there are 2800 more non-{uni,multi}verse source packages in hoary
<Kamion> but yeah, that'll appear in all recentish katie closing mails
<lamont> than warty
<Kamion> mdz: that often won't appear when the maintainer closed the bug by hand
<Kamion> which is why I suggested looking in To:/Cc: ...
<mdz> Kamion: good point
<mdz> of course, that won't find stuff closed with control@, right?
<Kamion> indeed not
<Kamion> /^\s+close\s+\d+/
<Kamion>  /^\s+close\s+\d+/
<Kamion> (ish)
<Javi> mdz: ok, thanks you, i'll go there
<mdz> Keybuk: I'm sending you some bugs which would be closed by merges; if they end up falling into the manual pile, send them back
<Keybuk> ah right
<Keybuk> was just muttering "why's he assigned these to me?" :)
<Keybuk> http://people.ubuntu.com/~scott/merge/README
<Keybuk> http://people.ubuntu.com/~scott/merge/review/
<Keybuk> ^ is the to-review stuff
<Kamion> I was gonna say, the grub-installer thing's probably mine, since I'll be reviewing that ...
<Keybuk> Kamion: yeah, just reassigned that one to you :p
<Keybuk> alsa-base hasn't got warty changes, has it?
<Keybuk> ah, alsa-base = alsa-driver
<hornbeck> can one of you dev's write up a chroot doc for me, so I can start working with it?
<hornbeck> please :-)
<Kamion> what kind of document?
<Kamion> like http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot ?
<Kamion> or like http://archive.ubuntulinux.org/ubuntu/dists/warty/main/installer-i386/release/doc/manual/en/apcs03.html (note, you can use the Ubuntu system built thereby without considering it an "installation" if you want)?
<lamont> Keybuk: so those are all ready for people to start working on?
<mdz> Kamion: regex searching doesn't seem to work properly anyway, and is horrifically slow
<hornbeck> Kamion: thanks
<jdub> mdz: happy for me to make the gamin/polypaudio seed changes for hoary now?
<mdz> jdub: yes
<mdz> jdub: should we upload a new ubuntu-desktop to propagate them?
<jdub> not jsut yet ;)
<mdz> hmm, that shouldn't be a question.  the seeds and ubuntu-desktop should match
<mdz> if they're not ready to be pushed out to hoary users, they shouldn't go in the seed yet
<jdub> can u-d be updated automagically?
<mdz> yes
<mdz> there's a script in the source package which pulls the stuff from the wiki
<jdub> cool
<mdz> it's totally trivial
<Kamion> presumably the new wiki now, though?
<jdub> i'm, um, waiting for the new wiki to load...
* jdub twiddles.
<Kamion> www.u.o isn't giving me any love either
<lamont> mdz: re 2756 - we still have -2ubuntu1
<Kamion> can somebody give me the new URLs so I can update germinate?
<jdub> mmm, seems to be a distinct lack of all love
* lamont remembered looking at it, couldn't remember why he hadn't done something with it.
<Kamion> elmo: do you need to run germinate for warty any more?
<Keybuk> lamont: yup, start taking them, fixing them and uploading
<Kamion> maybe I should tag the last warty revision or something
<mdz> lamont: yes, but I saw nothing in the bug report which stated whether it affected that version or not, which is why I gave it to you
<lamont> Keybuk: are there bugs filed, or how are we synchronizing things?
<Keybuk> lamont: ask mdz
<mdz> Keybuk: how many source packages?L
<Keybuk> 250-odd
<elmo> Kamion: not particularly - I'm only running it on hoary atm
<lamont> mdz: yeah.  -2ubuntu1 is installed in hoary on all 3.  Probably need to see if it's on keybuk's sync list.
<Keybuk> most of them are fairly trivial and just have one or two drops that should be obvious to fix
<lamont> mdz: I'll take care of either requesting the sync back to debian, or what not.
<mdz> Keybuk: http://people.ubuntu.com/~scott/merge/review/ ?
<Keybuk> yeah
<Keybuk> there's a README one level up saying what the files mean
<mdz> I'll file bugs about them
<Kamion> elmo: ok ... well, colin.watson@canonical.com--2004/germinate--tags--4.10 is the warty version if you need it
* lamont will definitely want postfix... Need to merge a bunch of the warty fixes _into_ debian still :-(
<Kamion> Keybuk: wouldn't ddetect have been better merged starting from 1.03?
<Kamion> rather than 1.00?
<Keybuk> Kamion: we probably never had 1.03 in our archive
<Kamion> ah, I see
<Keybuk> it doesn't actually seem to make much difference ;o)
<Kamion> snapshot.debian.net maybe
<Kamion> well, it means .po files have to be merged
<Keybuk> evolution it did both sides from 1.4 to 2.0
<Keybuk> Kamion: it merges po files from latest debian, so that generally works
<Kamion> it produced lots of unnecessary .po patches
<Kamion> look at them :)
<Keybuk> shouldn't make a difference ?
<Kamion> no, but it's more merge work for later
<Keybuk> was the warty side 1.00 or 1.03 ?
<Kamion> 1.03ubuntu14 I think
<Kamion> I'm merging it now anyway, just a suggestion for the next merge run :)
<Keybuk> ok, then it would've applied the debian changes to that, ignoring any that already were there
<Keybuk> ah, but yeah
<Keybuk> if there were .po changes from 1.00 to 1.03, then it would do merging of those
<Keybuk> but that's because it can't understand "already there" like it does with ordinary changes
<Keybuk> ho-hum
<Keybuk> (btw, feel free to steal stuff out of rookery:~scott/sources if you want the unpacked debian or warty versions)
<Kamion> Keybuk: the other difference it makes is that it duplicates changelog entries :)
<Keybuk> heh
* jdub goes to sleep for a few hours
<Keybuk> LOOK OVER THERE!  A THREE-HEADED MONKEY!
* Keybuk runs the other way
* lamont still wonders why he gets _2_ of things he launches..
<mdz> justdave: here?
<mdz> justdave: emailed you a list of components which need to be present in order for me to mass-file these merge bugs
<bluefoxicy> bah my post to the ML got ignored
<justdave> ok.
<elmo> mdz: err, will your script error out if I give it a non-existent component?
<mdz> elmo: yes
<mdz> er
<mdz> elmo: which script?
<justdave> mdz: I have a script that takes a text file with one component per line and checks the entire thing against the component list and creates any component from the list that's missing.
<mdz> justdave: ok, that's what I sent you
<elmo> mdz: the bugzilla.py thing from debzilla
<mdz> elmo: yes
<elmo> duh, that sucks
<justdave> If we can come up with a standard place to get that text file from we could cron the script
<mdz> elmo: doing anything else requires uber privilege
<lamont> germinate output comes to mind...
<mdz> elmo: well, I suppose it could fall back to UNKNOWN, but that's pretty crap too
<mdz> the right thing is to just have the components exist
<justdave> yeah, I've used germinate for that in the past.
<mdz> justdave: the way to generate that text file is to grab Sources.gz from the archive and, do: zcat Sources.gz | grep-dctrl -nsPackage ''
<mdz> elmo: you should be happy it detects that bugzilla blew up in that case; that was SO non-trivial
<mdz> justdave: grep-dctrl is in the package of the same name
<elmo> mdz: yeah, I wasn't saying your script was crap, just that it was a PITA, but if you guys are going to cron the component generation, that's fine
<mdz> cron is probably fairly reasonable
<mdz> it should do binaries as well
<mdz> but that's somewhat more of a pain due to having to iterate over known architectures
<elmo> and fricking bugzilla needs to stop overloading the word 'component'.  debian was here first damn it :-P
* lamont notices that his name occurs in 93 of the warty.patch files. :-(
<mdz> justdave: let me know when you've run that list through the script
* lamont lunches, fetches kids.  back in a while
<justdave> mdz will do.  should be up in a couple minutes
<pitti> mdz: without wanting to bother you, shall I upload the libgd package into the queue to have it built?
<justdave> mdz: done
<justdave> 54 new components created
<seb128> elmo: gthumb good to overwrite with a sync from debian
<elmo> seb128: done
<seb128> thanks
<mdz> justdave: thanks
<mdz> hmm
<mdz>     You must choose a component to file this bug in. If necessary,
<mdz>     just guess.
<mdz> KEYBUUUUUUK
<mdz> there are universe packages in that list
<elmo> use mine, if you want?
<mdz> elmo: I'm just letting it fail for stuff which is missing from bugzilla, which is ~= universe
<mdz> didn't see what you said in time
<mdz> that means <<250 bugs to file, though
<mdz> which is nice
<elmo> should be 169, by my count
<elmo> Rejected: cdrtools_2.0+a38-1ubuntu1.dsc refers to cdrtools_2.0+a38.orig.tar.gz, but I can't find it in the queue or in the pool.
<elmo> ^-- someone
<pitti> elmo: sorry, that's me
<pitti> elmo: forgot -sa
<Kosai> Hm.  Can OS X HFS partitions be resized non-destructively?  Gf just bought a powerbook, wondering whether installing Ubuntu on it can wait a while.
<Kamion> I wouldn't trust warty's parted to deal with HFS+ correctly.
<Kosai> Maybe the resizing could be done in OS X?
<Kamion> Not sure about HFS; but it's probably best to use OS X's tools to do it.
<Kamion> When I got mine, I "resized" by reinstalling OS X from the provided media ...
<Kamion> (but with a smaller partition for OS X)
<Kosai> Yeah.  Don't think Mad'll want to do that, I'm not gonna see her again until Christmas, she'll have built up a lot of stuff on the OS X partition.
<Kamion> yeah, can imagine
<Kamion> there may be pointy-clicky tools if you boot from the OS X CD
<Kamion> "Disk Utility" is the name, I think
<Kamion> but best check google
<Kosai> Okie.  Thanks.
* Kamion -> pub while he still has an outside chance of getting food there
<Kosai> gl :) I just decided I'm not going to make it in time, will eat at home first.
<cenerentola> Any Italian around HERE?
<seb128> elmo: python-gtk2 sync too please
<elmo> http://www.redhat.com/archives/fedora-devel-list/2004-October/msg01484.html 
<elmo> ^-- that's not terribly encouraging for polpyaudio and hoary
<elmo> seb128: done
<seb128> thanks
<seb128> elmo: http://lists.gnome.org/archives/desktop-devel-list/2004-October/msg00436.html
<seb128> too
<seb128> no problem described in this thread for the moment ...
<seb128> (too=on the same subject, not a "not terribly encouraging")
<elmo> hmm?
<elmo> http://lists.gnome.org/archives/desktop-devel-list/2004-October/msg00449.html
<elmo> seems just as negative to me :)
<seb128> uh, I've not read this one yet
<seb128> I've just get this mail
<mdz> 166
<mdz> ok, it is seriously annoying that bugzilla doesn't show the component in search results
<mdz> justdave: is that possible?
<justdave> mdz: click the "change columns" link at the bottom
<justdave> you can show whatever columns you want
<mdz> justdave: dthanks
<mdz> justdave: is it possible to set it as default for our instance?
<justdave> sure
<justdave> done
<justdave> (note it sets your column list in a cookie if you've ever set the columns via the change-columns page)
<cenerentola> all: just an hint: how do i sign mail in evolution after ive set the sign?
<elmo> oh, kick ass, benh has done sleep for modern powerbooks
<cenerentola> sorry i mistook chan
<chrisa> elmo: Oh? Is that a recent patch?
<sjoerd> elmo: yeah, it works very nice :)
<sjoerd> chrisa: yesterday 
<chrisa> I wonder if that covers the ibooks as well (some of which use the same ATI chipset)
<elmo> he says it doesn't - check out the debian-powerpc@l.d.o archives
<sjoerd> chrisa: not yet, but he asked for testers 
<amu> on the new pb4 it works 
<chrisa> ah, haven't read ppc in a day or two
<mdz> justdave: it seems to truncate the component at 8 characters, which is too short for most packages. can we increase that?
<justdave> mdz: done
<justdave> removed length restriction, renamed column header to "Package" :)
<elmo> justdave: rock
<mdz> justdave: thanks
<elmo> argh.  this component thing just became critical - libhowl0 is same version in warty/hoary and needs promoted to main
<elmo> 'cos the enitre gnome world now depends on it
<mdz> elmo: please clobber kernel-source-2.6.7
<mdz> elmo: would it make your life exceedingly difficult to purge a bunch of the Debian kernel stuff?
<mdz> (to clarify, for kernel-source-2.6.7 I meant to overwrite with the Debian version for now)
<seb128> elmo: sound-juicer sync please
<seb128> hum
<seb128> gnome-gv is 2.8.0-0ubuntu1 in warty and 2.6.2-3 in debian ... why do we get a bug report for a sync if the warty version > debian version ?
<mdz> seb128: my list came from Keybuk
<mdz> if there were some errors, I apologize on his behalf, and please close any erroneous bugs :-)
<seb128> ok, and he left :)
<seb128> no problem
<seb128> I was just wondering
<seb128> elmo: gossip sync too please
<justdave> anyone had any thoughts yet on how we should handle warty vs hoary identification on Bugzilla?
<justdave> warty might be good as a flag...  so if someone things something should be fixed in warty, they can request it, and mdz can give it a + or a - if he agrees or doesn't
<tseng> milestone?
<tseng> ive seen what you are talking about on other bugzillas
<doko> thom, elmo: would it be possible to have a hoary amd64 chroot on yellow?
<elmo> seb128: done
<seb128> elmo: thanks
<elmo> doko: yeah, give me a bit
<elmo> mdz: purge how?
<mdz> elmo: remove from the archive
<elmo> even universe?
<doko> elmo: thanks!
<elmo> kernel-source-2.6.7 clobbered
<mdz> elmo: yeah
<mdz> thanks
<elmo> mdz: hmm, no not particularly, I'll just have to maintain a blacklist of stuff we don't want to sync from sid to universe, no big
<mdz> elmo: we've talked about it before, I think, but I assume it makes your life a lot more interesting with regard to processing new stuff added to sid
<mdz> hmm, ok then
<mdz> email?
<elmo> sure, or here, whichever
<mdz> kernel-source-2.4.24
<mdz> kernen-source-2.4.25
<mdz> kernel-source-2.4.26
<mdz> kernel-source-2.6.5
<mdz> kernel-source-2.6.6
<mdz> kernel-source-2.6.7
<mdz> kernel-image-2.4.26-i386
<mdz> kernel-image-2.6.7-i386
<mdz> can all go
<mdz> s/kernen/kernel/
<jdub> mdz: http://www.redhat.com/archives/fedora-devel-list/2004-October/msg01484.html
<jdub> heh
<jdub> I downloaded the code and took a look. I think its actually worse than
<jdub> esd as an implementation. As a protocol well that may be a different
<jdub> matter.
<mdz> "No rate adaption"??//
<mdz> wtf is the point of this thing, then?
<jdub> conversation continues on d-d-l
<elmo> mdz: done
<mdz> thanks
<doko> what is the procedure for packages to be merged, if they should be synced from unstable again?
<doko> just email the usual suspects? ;)
<elmo> doko: ask me
<elmo> no, just me, no approval needed - and you can do it via IRC, if I'm around
<doko> ok
<elmo> hmm, why does a warty chroot come without shadow by default..
<jdub> mdz: i don't get the rate adaption thing; polypaudio uses libsamplerate
<elmo> doko: okay, hoary chroot exists on yellow now
<jdub> dudes
<jdub> floppies
<jdub> is the only sane way of doing on-demand mounting of floppies... automount?
<doko> elmo: thanks!
<mdz> seb128: g-v-m quit unexpectedly during an upgrade just now; is that normal?
<mdz> jdub: there is no sane way of doing on-demand mounting of floppies
<mdz> floppies are so 1980
<seb128> mdz: hal has been updated ?
<jdub> mdz: would you be 100% opposed to automount running for floppies only?
<seb128> elmo: screem and libxklavier synchros please
<mdz> seb128: hal seems to be ahead of Debiain
<mdz> Debian
<sjoerd> mdz: check experimental :)
<seb128> mdz: yeah, but did hal get upgraded when g-v-m crashed ?
<doko> hmm, can we have latex2html and graphviz in restricted? the former to build the python docs, the latter to build the libstdc++ docs
#ubuntu-devel 2004-11-09
* lamont sees many bugs.  sigh/
<elmo> doko: no, that's not what restricted is for
<mdz> seb128: oh, I lost the context, sorry :-)
<mdz> lamont: most of them are trivial to fix, though
<lamont> doko: restricted == binary-blob of code, but otherwise main.
<lamont> mdz: yeah
<mdz> it's not nearly as bad as it looks
* lamont will chunk through the ones assigned to him, and then move on to other and better ones.
<elmo> seb128: done
<seb128> thanks :)
<doko> so it's ok to move them from sid/non-free to hoary/main?
<elmo> doko: err, hell no
<doko> s/main/universe/
<elmo> doko: no - multiverse 
<lamont> mdz: although I'm going to save postfix for a while, since I want to merge many of the warty changes over to debian, and that'll simplify the hoary patch.  (That and there aren't any significant fixes in sid atm.)
<elmo> they should already be there, in fact
<lamont> mdz: these aren't RC bugs, eh?  hrm.. guess not really for the most part
<elmo> latex2html | 2002-2-1-8 | warty/multiverse | source, all
<elmo>   graphviz |     1.14-1 | warty/multiverse | source, amd64, i386, powerpc
<doko> sorry, added to my sources.list ...
<elmo> woops, forgot to enable auto-update of universe.. lala
<mdz> elmo: please clobber john
<elmo> done
<pitti> elmo: can you please sync libgcrypt7?
<elmo> pitti: sync over the ubuntu changes?
<pitti> elmo: yes, please
<elmo> done
<pitti> elmo: thanks!
<seb128> pitti: did you get some g-v-m crash recently during dbus/hal updates ?
<pitti> seb128: hmm, yes, now when you say it
<pitti> seb128: I remember that this happened to me once
<seb128> mdz got it too
<pitti> seb128: so it seems this was no random crash then
<seb128> and one debian guys reported a similar problem today
<seb128> yeah, apparently ...
<sjoerd> seb128, pitti: i've seen crashes with hal 0.4.0 restarting.. somewhere in the dbus code, haven't had the time to debug it yet..
<seb128> ok, so definitively a bug
<seb128> sjoerd: please keep us informed if you find it :)
<sjoerd> correction.. with dbus restarting
<pitti> sjoerd: Ubuntu's dbus-1 package contains a fixed patch for dbus-monitor; I think this should apply to Debian as well
<sjoerd> pitti: oh nice
<sjoerd> pitti: patch as in make it actually work ?
<pitti> sjoerd: shall I send you the patch?
<pitti> sjoerd: yes, seems so
<pitti> sjoerd: or can you grab it from our source package?
<sjoerd> pitti: btw do you read my mind,  i was going to ask daniels if i could do another nmu rsn :)
<pitti> sjoerd: I thought the same :-)
<pitti> sjoerd: if you adopt the patch, we could actually resync to Debian, which would be nice
<sjoerd> for other bugs though :)
<sjoerd> pitti: i'll check the source package..
<__daniel> bye
<sjoerd> pitti: getting #277148 would probably be nice for ubuntu too (if it isn't already fixed)
<pitti> sjoerd: right. If we can sync, we get Debian fixes automatically :-)
<sjoerd> i'll see what i can do tomorrow
<jdub> oh
<jdub> sjoerd
<jdub> sjoerd simons
* jdub makes connections
<jdub> hi! :-)
<sjoerd> jdub: should i be afraid ?
<jdub> heh
<jdub> connecting your nick here to your name on hal list and debian's hal :-)
<sjoerd> ah 
<azeem> jdub: heh, so after Alan trashed it to pieces, are you still willing to get polypaudio into Debian? =)
<azeem> if yes, I've got some time for over the weekend to upload it, if you need a sponsor
<seb128> elmo: gnomemeeting sync please
<jdub> azeem: yeah :)
<jdub> lennart will come back with the goods ;)
<pitti> Good night, everybody!
<seb128> 'night pitti !
<geppy> g'night
<sjoerd> pitti: later
<jdub> seb128: heh, new howl :)
<seb128> cool :)
<azeem> hmm, where is keybuk when you need him?
<jdub> in london
<jdub> or birmingham
<jdub> or oxford
<azeem> figured.
<jdub> at least, that's been my experience
<azeem> did we agree that those "W: polypaudio: binary-or-shlib-defines-rpath" are okayish because those are modules/plugins? (can't remember)
<jdub> we did, but it's still kinda suboptimal
<jdub> hrm
<jdub> Package: howl-utils
<jdub> Depends: ${shlibs:Depends}, libhowl0 (= ${Source-Version})
<jdub> 
<jdub> Package: mdnsresponder
<jdub> Depends: ${shlibs:Depends}, libhowl0 (= ${Source-Version})
<jdub> 
<jdub> howl-utils_0.9.7-1ubuntu1_i386.deb
<jdub>  Depends: libc6 (>= 2.3.2.ds1-4), libhowl0, libhowl0 (= 0.9.7-1ubuntu1)
<jdub> 
<azeem> polypaudio uses some moderately funky LDADD automake directives which might lead to those rpaths, so I hoped Keybuk would know about htat
<jdub> mdnsresponder_0.9.7-1ubuntu1_i386.deb
<jdub>  Depends: libc6 (>= 2.3.2.ds1-4), libhowl0 (= 0.9.7-1ubuntu1)
<jdub> 
<mdz> jdub: you want shlibs.local
<jdub> ^ gar.
<mako> hey, there is a question on -users that didn't get an answer last week that i think should
<mako> Where would be the correct place to report packaging bugs in multiverse
<mako> packages?
* jdub checks man dh_shlibdeps
<jdub> mdz: thanks
<mdz> mako: that's because that question doesn't have an answer
<mako> yeah, i know :)
<mdz> other than "wait"
<mako> right, i'm going to post that
<seb128> elmo: vnc also please
<mako> "wait" EOF
<mako> mdz: we talked about it at the last CC meeting a bit
<lamont> off to a concert at the school, should be online for a bit in a while, working on bugs, etc.. :-)
<lamont> syntax error at /usr/share/perl5/dtd.pl line 99, near "$ANY             "
* lamont giggles
<seb128> elmo: yelp too
<seb128> elmo: and startup-notification :)
<mdz> mako: add it to the FAQ
<mdz> mako: "wait"
<jdub> aha, excellent response from lennnart
<seb128> jdub: yeah, good reply :)
<seb128> BTW are KDE people really that reluctant to use glib ?
<jdub> well
<seb128> that's a low level lib, not really a "gnomish" stuff ...
<jdub> they already depend on glib for a number of things
<mjg59> Arts already uses glib
<mjg59> It just has its own copy in its source tree
<jdub> so it'd be pretty silly if they didn't accept a glib-based polypaudio
<jdub> mjg59: basically no one builds it that way, though
<jdub> afaik
<tseng> hornbeck: your post, fair idea, but it doesnt seem much needed
<tseng> hornbeck: its pretty easy for us to make apt repos on joe random webhost
<elmo> seb128: done
<seb128> elmo: thanks .. I've started to list them in fact, new serie : libgnomecanvasmm2.0 gtkmm2.0 libgnomecups :)
<elmo> done
<kapputu> hi everyone
<usual> I get a error trying to load a module at boot called hw_random or something like that....can someone tell me why and how to fix it
<usual> it happened in rc and release
<mdz> usual: please use #ubuntu for support issues
<usual> mdz, my mistake, I read the topic wrong
<usual> ;)
<kapputu> hi md
<kapputu> mdz
<mdz> hi
<kapputu> I want to contribute to Ubuntu 
<kapputu> I'm a good programmer 
<mdz> what sort of program would you like to write?
<kapputu> I learn quickly though I have been actively using linux only since the beginning of this year 
<kapputu> I'm good at Java, Perl 
<kapputu> I know C well but haven't used it in 3 years
<kapputu> and I learn new languages very quickly 
<mdz> if you are an experienced programmer, a good way to contribute would be to write and maintain an open source application
<kapputu> I have a problem with getting started on anything
<kapputu> I need directions
<mdz> a good start would be to find something that you feel is missing for you, personally.  that way it will be something which will hold your interest
<kapputu> hmm 
<seb128> elmo: syncs for gnome-libs libgnomeprint libgnomedb please :)
<kapputu> I would like to do some web stuff
<kapputu> are there any good remote development tools ?
<kapputu> I'm looking for something like EditPlus in Windows
<elmo> seb128: done ... your packages are clearly too easy ;-P
<seb128> ah ah
<seb128> thanks :)
<mdz> elmo: he makes up for it in volume :-)
<seb128> I'm keeping the hard ones for tomorrow :p
<mdz> kapputu: eclipse and emacs come to mind
<kapputu> for remote development ??
<kapputu> i use emacs a lot but not sure how to set it up for remote development
<seb128> ok, time to sleep, 'night
<mdz> thom: around?
<daniels> mdz: 0300
<mdz> daniels: it wouldn't be the first time
<jdub> mdz: http://lists.debian.org/debian-devel-0307/msg01708.html
<mdz> jdub: creating a temporary directory under $HOME is also popular
<mdz> I've thought that it might be nice to just change tmpfs to prevent temporary file attacks
<mdz> by revoking some of the cleverer filesystem semantics that allow them
<jdub> tollef is upstream for that, btw
<mdz> Mithrandir: poke
<jdub> (for context, martin just pointed it out to rob and i, and suggested that it might be cool for ubuntu)
<mdz> daniels: yes, I know he's asleep. he'll read scrollback :-)
<jdub> ah, and lifeless just cced you on his mail
<mdz> no mail yet
<lifeless> matt.zimmerman@canonical.com ?
<mdz> lifeless: that should get to me about 10 expansions later, yes :-)
<lifeless> aha
<daniels> mdz: heh
<mdz> there it is
<daniels> mdz: (whoomp)
<hornbeck> tseng: sounds good to me, on random repos
<fabbione> morning guys
* fabbione tags 2987 INVALID WITH BIG SATISFACTION
<Micksa> teehee
<Micksa> where's the bugzilla?
<lifeless> bugzilla.ubuntu.com
<Micksa> I should have guessed huh :)
* lifeless nods
* lifeless grins
<fabbione> new comment on it :-)
<Micksa> haha
<Micksa> ding dong, the witch is dead
<fabbione> Micksa: it's not like x.org is any simpler or smaller....
<mdz> fabbione: one more time, with FEELING
<daniels> Micksa: we can sing the ding dong song ... maybe after we get the modular tree.  definitely after someone's rewritten the server from the ground up.
<fabbione> mdz: ahaha
<fabbione> mdz: i got a bunch of merging bugs
<fabbione> do you want me to spend time on them?
<fabbione> i am kinda into X.org these days
<mdz> fabbione: I gave you about 3 I think
<fabbione> 11
<fabbione> well 10
<mdz> ok, 7 :-)
<fabbione> mdz: up to you.. i don't mind either way
<fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=3008
<mdz> fabbione: I think it should not be more than an hour's work
<fabbione> mdz: i think this should go to "ubuntu-desktop"
<fabbione> mdz: sure.. no problem
<mdz> fabbione: a nice diversion for a little bit from X.org :-)
<fabbione> mdz: you gotta be kidding! :)
<fabbione> i can do an entire build (almost) in one hour!
<fabbione> ahaha
<mdz> hehe
<mdz> something to keep busy during the build, then :-)
<fabbione> exactly
* fabbione enables multitasking pre-emptive
<daniels> mdz: same question from my side wrt the merge bugs I got
<mdz> daniels: you said the X.org work was serial, please tend to your bugs
<fabbione> mdz: it is at this point in time yes
<fabbione> because we are fixing small build issues and syncing sanity checks
<fabbione> it won't be from today or monday
<mdz> fabbione: it takes an hour for a ccached build?
<fabbione> mdz: yes.. slightly more than that
<fabbione> i found a bug in the install target
<fabbione> that makes the build much longer
<daniels> mdz: ccache doesn't deal with linking, remember, and there's also fonts and stuff to take care of
<mdz> fonts schmonts, who needs 'em
<fabbione> i don't think i can make fix it for today
<fabbione> mdz: 1 hours is without FONTS
<fabbione> and without XPRINT
<mdz> fabbione: how big is the tree?
<fabbione> (that btw we had to re-enable)
<mdz> (built)
<fabbione> u -sk build-tree/
<fabbione> 4614484 build-tree
<fabbione> wait
<fabbione> 3830636 build-tree
<fabbione> this one
<fabbione> mdz: there is a damn bug in the install target
<fabbione> that basically relink everything
<fabbione> creating duplicates of each binary files in the tree
<fabbione> (it moves the old ones as .bak)
<fabbione> that's one of the reason why it takes so much longer
<fabbione> daniels: do you think you can try to fix it while flying?
<fabbione> you don't need to build all the tree to see it
<fabbione> just the server or a small xc/programs/<whatever>
<daniels> fabbione: i can try, yes, but IBM have tanked my order, and I won't have the extended life battery before I leave
<fabbione> crap
<fabbione> ok
<daniels> so I'm going to find one in either cph or london
<daniels> i think that still gives me about 6h of battery, though
<daniels> so I should get about 12h all up while flying
<fabbione> daniels: lon -> cph is like 2 hours flight
<fabbione> not even worth the time to turn on the lappy
<daniels> mel -> sin is 8h, sin->lhr is 12h
<daniels> and if I'm conscious while I'm at LHR, I can hack while I'm waiting
<daniels> ditto SIN
<fabbione> daniels: get some sleep too :)
<daniels> yeah, given I arrive at like 5am
<fabbione> while $STOP; do clear && ccache -s && sleep 1; done
<fabbione> ccache top ^^
<fabbione> too nice to have in a little window while compiling X
<fabbione> 48x14 is perfect :-)
<Micksa> so what proportion of the (official) team IS australian?
<daniels> not quite enough
<jdub> no dude
<jdub> there's enough
<jdub> we just have to overcome the brits
<Micksa> haha
<Micksa> the wiki says 40% somewhere
<daniels> it's not 40%
<Micksa> I didn't think so
<jdub> daniels, lifeless, bob2, jamesh, jdub
<Micksa> is that 5/40?
<jdub> spiv
<jdub> stub
<daniels> Micksa: it's around 20%
<jdub> though spiv and stub have lots of beer to drink to reaustralianise
<Micksa> >:)
<daniels> heh
<daniels> as opposed to malibu and coke :P
<jdub> (stfu.)
<Micksa> well I'm totally unaustralian then
<daniels> by that metric, I'm probably closer to Russian than anything else
<jdub> nono
<jdub> they've been overseas for ages
<jdub> they just have to reaustralianise
<jdub> then they can drink whatever they want
<Micksa> ah, okay.
<daniels> 'Welcome to re-education.  This is your friend for the next month, Mr. Coopers.'
<jdub> HEAD, KEG, NOW!
* lamont finally gets back in from the concert etc.
<Micksa> heh, I'm visualising the wrathful look on jdub's face as he shoves the guy's head into the beer
<lifeless> not wrathful, merciful
<pasc> heh
<pasc> sounds like I need to hang out with jdub more often
<pasc> if only I didn't live so far away...
<hornbeck> night
<Micksa> lifeless: I was sorta thinking of it as an act of exorcism :)
<jdub> pasc: haha
<daniels> pasc: you can bond over peter's
<pasc> heh
<pasc> I still haven't been there
<pasc> (since I moved that is)
<lifeless> pasc: PING
<lifeless> :)
<pasc> that time of the month again already?!?
<pasc> hmm
<fabbione> mdz: 3008 ... ubuntu-desktop? or do you really want me to depend on libglide2?
<mdz> fabbione: I need more information
<mdz> I don't have one of those cards
<fabbione> the tdfx driver needs libglide to work properly, but theoretically it shouldn't fail like that
<fabbione> i have one but it's a newver version that that
<fabbione> so i can't see that problem
* lamont sleeps
<fabbione> night lamont 
<fabbione> mdz: we were already talking about moving libglide3 to desktop
<fabbione> it means adding libglide2 too
<fabbione> mdz: there is a new apache1.3 release that fixes 2 security problems. One is already backported.
<fabbione> pitti: ^^same goes to you
<mdz> fabbione: ok, I think we talked about this already, ythen
<fabbione> not with me
<mdz> fabbione: send an email to -devel proposing the seed change, I don't see a problem with it
<fabbione> [CAN-2004-0492 (cve.mitre.org)] 
<jdub> http://ubuntu-art.org/ <- boggle
<fabbione> this is fixed
<fabbione> [CAN-2004-0940 (cve.mitre.org)]  this one no
<fabbione> mdz: ok
<mdz> jdub: intense
<mdz> fabbione: please file a bug and assign to pitti
<fabbione> mdz: if you want i can handle it. i will have to do it for Debian too i guess
<fabbione> but if pitti will make a patch for me, i would be even more happy :P
<fabbione> mdz: 3011
<mdz> fabbione: thanks
<fabbione> mdz: no problem
<fabbione> i wonder how long time it will take before a RC bug is filed against apache in debian
<fabbione> usually they take less than 30 secons
<fabbione> seconds
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE, long live Hoary | http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html
* fabbione updates his workstation to hoary
<fabbione> no
<fabbione> actually.. not on a friday
<fabbione> mdz: if a package can be synced safely from debian, what should i do? tell who?
<mdz> fabbione: elmo
<mdz> either mail or IRC, no need for approval
<mdz> you can also reassign the bug to him, but that seems to take an extra day to process :-)
<fabbione> mdz: ehehe ok
<fabbione> mdz: is that ok that synced packages will pull in build-deps from universe?
<fabbione> or do we need to fix the packages...
<fabbione> (if fixable)
<mdz> fabbione: it depends on which packages
<pitti> Morning!
<pitti> mdz: thanks for approval, I upload libgd2 to the queue now
<pitti> mdz: USNs for libxml2 and libgd2 are on https://chinstrap.warthogs.hbd.com/~pitti/
<mdz> pitti: which bug # is libxml2?
<pitti> mdz: #2809
<fabbione> mdz: 2 binaries that we have in universe, but the source and the main binary in main
<fabbione> python2.1 and 2,2-numeric
<pitti> mdz: I still did not get a CAN for ppp, I upload the thing without one now.
<mdz> pitti: ok
<mdz> fabbione: ick, what depends on them?
<fabbione> pyopengl2.1 and 2.2
<mdz> gah
<mdz> we didn't prune python2.1 or python2.2 from warty/main
<fabbione> mdz: i am adding all the info to the bug with you and james in cc
<mdz> we should do that for hoary
<mdz> pitti: security bugs should not be closed until the package has actually entered the archive
<pitti> okay
<mdz> pitti: I will process ppp as soon as it is built, if you are ready
<pitti> mdz: I still need to write the USN for ppp
* sid77 hi!
<pitti> mdz: ppp USN uploaded, again to https://chinstrap.warthogs.hbd.com/~pitti/
<Mithrandir> mdz: pong
<mdz> pitti: I would write the first sentence of details as "'It has been discoveerd that ppp does not properly verify certain data structures used in the CBCP protocol."
<mdz> (only without the typo)
<pitti> mdz: okay
<pitti> mdz: uploaded
<fabbione> mdz: i love you :P
<fabbione> not everything that has X11 in the middle of the name is kinda... related to X11 :)
<mdz> fabbione: I did not consider whether they were related to X11; xfree86 you got because you own that component in bugzilla
* fabbione was just kidding
<fabbione> mdz: is there ANY reason why we still need qt-x11-free?
<fabbione> it's a bunch of FTBFS
<mdz> fabbione: check germinate
<mdz> I think we would have more FTBFS if we removed it :-)
<robtaylor|away> mdz: whehay.. morphix hotplug issue now fixed upstream :)
<robtaylor|away> mdz: and your 1st hypothesis was spot on :)
<Keybuk> robtaylor|away: oh?
<Keybuk> newer hotplug than the one I just uploaded?
<robtaylor|away> Keybuk: nope, just fixed it to use pivot_root in its last stage
<Keybuk> ah, morphix upstream not hotplug? :)
<robtaylor|away> Keybuk: yep :)
<robtaylor|away> Keybuk: on the bugzilla, do would i merk the bug as 'upstream' or 'pending upload'?
<Keybuk> no idea
<robtaylor|away> heh :)
<robtaylor|away> i'll put an appropriate comment in then, and let someone eslse fix it :)
<mdz> robtaylor|away: great, could you add a note to the bug report with that information?
<mdz> ah, you already decided to do so
<robtaylor|away> mdz: heh :)
<rburton> jdub: ping?
<seb128> hello rburton 
<rburton> hi seb128 
<seb128> what's up ?
<rburton> i just discoved that my speakers have a low hum when there is no cd playing, and i can't figure out where it is coming from 
<rburton> probably the gas meter right behind the amp
<rburton> that is my major worry at the moment :)
<seb128> ah ah
<rburton> i also wish SA wouldn't decide to rebuild its database when i want it to get mail
<mdz> Kamion, elmo: have you guys made any attempts to point germinate at the new wiki yet?
* Keybuk wonders where his dustmen have got to
<thom> mdz: morning
<seb128> hello thom 
<thom> g'morning *
<Keybuk> I've decided to rename "morning" to "killev"
<seb128> mdz: the debian package for evolution doesn't have a evolution1.5 transitionnal package ... do we want to get it, or we can drop it now ?
<mdz> thom: morning
<mdz> seb128: I'm not sure I understand
<mdz> evolution1.5 was in debian experimental and warty pre-releases?
<seb128> mdz: I've added a dummy evolution1.5 -> evolution for evolution 2.0
<seb128> kitame didn't in debian
<seb128> so if we sync with deb we remove the dummy
<thom> mdz: you pinged last night?
<mdz> seb128: was evolution1.5 ever in debian unstable?
<seb128> no
<Keybuk> seb128: people have 'evolution' installed on their warty machines?
<mdz> thom: yeah, don't remember what that was about
<Keybuk> which has the real files?
<mdz> seb128: then we do not require the dummy package
<seb128> Keybuk: yes (only people with first warty RC who have not updated might still have evolution1.5)
<mdz> seb128: if you can avoid a merge by dropping it, it is fine with me
<seb128> ok, thanks
<thom> mdz: fair enough. was there a resolution on what i should version firefox as?
<seb128> elmo: libsoup sync please
<mdz> thom: what's the upstream version?
<thom> 1.0rc1
<seb128> mdz: evolution-data-server has been splitted to a bunch of binary packages for differents libs. Do we need to update a seed or something before uploading it ?
<Keybuk> thom: the build worked with a tilde in the directory name?
<mdz> thom: how about 0.99+1.0RC-0ubuntu1?
<mdz> s/RC/RC1/
<mdz> that should be >> 0.99+1.0PR.1...
<thom> mdz: oh, duh. of course that sorts higher than PR.1 
<Keybuk> heh, 'R' > 'P' ... that's so cheating :p
<thom> yeah, sounds good
<Keybuk> RC.1 for consistency ?
<mdz> don't care as long as it sorts
<thom> Keybuk: no, since pr.1 was a point release to 1.0PR
<Keybuk> ahh ok
<thom> mdz: ok, will go with that
<mdz> sounds good
<mdz> bed also sounds good
<mdz> night all
<thom> g'night
<Keybuk> nite dude
<pitti> mdz: good night
<robtaylor|away> mdz: night
<seb128> mdz: 'night ! (and about e-d-s ?)
<robtaylor|away> carlos: heyy :)
<carlos> robtaylor|away: hi!
<robtaylor> heh, i'm ovbiously not away now, am i ;)
<robtaylor> carlos: so hows things with you?
<carlos> robtaylor: fine, thanks
<carlos> robtaylor: I will try to resume the auth work this weekend
<robtaylor> carlos: wow, cool. I dont have a working computer at home at the moment, but i'm sure be able to find a bit of time at work to help out :0
<robtaylor> :)
<seb128> ok
<robtaylor> carlos: so does the previous plan still hold?
<seb128> so anybody has an idea if I need to update a seed before uploading the new e-d-s which has been splitted to differents libs ?
<carlos> robtaylor: yes, until we could check if there are any performance problems, I don't see why it should be removed
<robtaylor> carlos: cool :)
<rburton> anyone know if there is a way to extract a single file from a deb with libapt-pkg?
<robtaylor> carlos: all my archives of the discussions and planning are on a hd in a broken computer atm... have you got them archived, and if so, can you send them me?
<carlos> robtaylor: you put them into my subversion repository
<carlos> http://carlos.pemas.net/svn/public/accessd/
<robtaylor> carlos: ah brilliant. is your svn repo set up for svn+ssh?
<carlos> no
<carlos> robtaylor: and I'm moving to arch
<carlos> so it should die soon
<robtaylor> carlos: oh god.. i need to learn arch....
* robtaylor is scared#
<carlos> :-)
<robtaylor> heh
<robtaylor> this gives me a good excuse to try fai :)
<carlos> robtaylor: http://www.canonical.com/projects/bazaar/
<robtaylor> (or whatever its current name is)
<azeem> robtaylor: which fai?
<robtaylor> azeem: freindly arch interface
<azeem> ah
<robtaylor> azeem: yes, its changing its name.. again .. ;)
<robtaylor> suffering phoenix syndrome
<robtaylor> carlos: ooh, that sounds good (bazaar)
<robtaylor> carlos: so whats currently different between baz and tla?
<carlos> robtaylor: baz will be compatible 100% with tla
<carlos> robtaylor: but it will be user friendly
<robtaylor> carlos: but right now, there not much extra userfreindlyness implimented?
<carlos> robtaylor: it was started this week, so it has some things implemented but don't know if there will be a big difference at the moment
<robtaylor> ah :)
<seb128> pitti: here ?
<pitti> seb128: yes
<seb128> pitti: do you know if libxml2 2.6.15 fixes all the security issue you've adressed in your 2.6.11 patched version ?
* pitti looks
<seb128> it's in incoming
<seb128> thanks
<pitti> seb128: can't tell quickly; I download the orig.tar.gz and compare patches
<pitti> seb128: I assume you want to resync it?
<seb128> yes
<seb128> it's in my list of bugs
<seb128> there is no hurry, but if you have some time to do it .. :)
<pitti> seb128: I can as well do it now, before I forget it :-) What's the bug #?
<seb128> 2916   	
<seb128> I've added a comment about 2.6.15 and tagging it pending, but prefer to check since I'm not sure all it fixes all the issues patched in 2.6.11
<pitti> seb128: verified, I wrote a bug followup
<seb128> ok, thanks
<Kamion> mdz: no, because you guys haven't populated it properly yet :-)
<Kamion> mdz: it's only got proposed packages at the moment, germinate needs a bit more than that
<pitti> elmo: can you please sync vsftpd from Debian?
<lupus_> why is totem trying to write to a file it opens?
<lupus_> I have a vfat mounted ro and totem says an error acuired can not write to resource
<lupus_> occured I mean
<thom> elmo: please sync amd64-libs from debian
<fabbione> pitti: are you preparing the USN for apache?
<fabbione> elmo: can you sync all your money to my bank account?
<fabbione> :P
<pitti> fabbione: Everything is in place, but apache did not yet built on one platform before mdz went to bed
<fabbione> ok
<pitti> fabbione: mdz wasn't in a hurry with that because it's universe
<fabbione> pitti mind to send me the patch or upload for debian too?
<pitti> fabbione: our consensus was to do the upload, but don't send out an USN
<fabbione> debian unstable
<fabbione> pitti: whatever
<fabbione> i don't mind USN or not.. hounestly
<pitti> fabbione: interdiff is in #3011
<fabbione> we should probably just kill apache1.3 in hoary
<fabbione> pitti: ok cool
<pitti> fabbione: but I can upload it to sid if you wnat
<pitti> fabbione: I've got the ready package here
<fabbione> pitti: that would be very nice. don't make it an NMU, just add yourself to the uploaders
<pitti> fabbione: what about woody?
<fabbione> pitti: i have all the development of apache on a turned off machine
<fabbione> pitti: send the patch to Joey?
<pitti> for my sake
<fabbione> pitti: i simply don't have available power plugs for another computer atm
<pitti> fabbione: good idea
<fabbione> and i am without sid
<pitti> :-)
<rburton> [gasp] 
<pitti> ah right, I need to pdebuild the package
<fabbione> rburton: getting a new nuclear powerplant in the garden
<fabbione> but it's not ready yet :P
<fabbione> and i am with 2 plugs in the entire house
<fabbione> (old plant was like 35 years old)
<pitti> fabbione: don't need an extra heater in your house any more, do you?
<fabbione> nope :-)
<fabbione> the computer room is already 5 C > than the rest of the house
<fabbione> and i need to keep the window open
<fabbione> otherwise i would melt
<pitti> fabbione: OTOH, I think sid should get 1.3.33 right away
<fabbione> pitti: nah...
<fabbione> i will prepare 1.3.33 when i have the time
<fabbione> and the computer
<fabbione> and a new upstream release is a pain
<fabbione> trust me
<pitti> fabbione: 1.3.33 does not contain anything other than the patch, compared to 1.3.32
<fabbione> pitti: sid has 1.3.31
<Kamion>  /* The best bits of mii-diag and ethtool mixed into one big jelly roll. */
<fabbione> that's why
<pitti> fabbione: is 1.3.32 so bad?
<fabbione> pitti: the problem is not apache. It's to sync apache-perl, apache-ssl and mod_perl
<fabbione> they are really time consuming
<pitti> fabbione: okay. So I just upload the same version to sid for now.
<fabbione> + i have another bunch of patches to review too
<fabbione> yup
<fabbione> thanks
<pitti> fabbione: I think I take an NMU version and upload straigt away
<pitti> Hi Mithrandir!
<fabbione> pitti: nah. just upload without NMU
<fabbione> no point if you are allowed :-)
<pitti> fabbione: okay
<fabbione> is katie running?
<fabbione> ah fuck
<pitti> tsts - no cursing
<fabbione> thom: can you send me back the .diff.gz and .dsc for mdadm 1.7.0 ?
<fabbione> thom or elmo
<plovs_work> i am writing a howto on file-sharing with nfs/samba etc, to start with samba: any easy way to share a folder? (easy=newbie way,*not* editing samba.conf)
<rburton> plovs_work: at the moment,  no.  should be in G2.10 though, via webdav
<plovs_work> rburton, so the *only* way is editing samba.conf? so i write it correctly in the howto
<robtaylor> lamont: ping?
<rburton> plovs_work: as far as i know.
<plovs_work> we will not have "share this folder through samba"-rightclick in gnome?
<rburton> plovs_work: mandrake has a patch for that, but the current work to do sharing uses webdav
<plovs_work> rburton, thanks
* plovs_work off, typing a howto
<seb128> the share the folder with a right click from mandrake has been rewritten as a nautilus extension
<seb128> elmo: gnome-terminal 2.8.0 from experimental sync too please
<rburton> seb128: any idea how tied to mandrake's samba it is?
<seb128> nop
<amu> g'morning  
<plovs_work> seb128, rburton in case you find out feel free to add a link to: https://www.ubuntulinux.org/wiki/SharingFilesWithSamba
<seb128> the extension is in the mandrake cvs
<seb128> fcrozat did a blog entry about that
<rburton> personally, i feel that the webdav solution to quick per-user file sharing is superior
<seb128> that was like 2 weeks ago
<seb128> me too
<rburton> as then everybody can access it
<rburton> for "proper" shares, use NFS or SMB, but that is a different use case
<plovs_work> rburton, not be whining but i just want it all ... yesterday
* plovs_work ok, back to writing howto's
<rburton> the mandrake filesharing code is heavily tied to mandrake
<rburton> it's just a UI to DiskDrake
<Mithrandir> the usb-storage is on the live-cd initrd, isn't it?
<seb128> elmo: esound too ...
<seb128> elmo: and libxml2 2.6.15 (it's in incoming)
<mjg59> I need to sort out how to do user-level DAV properly
<mjg59> I got it working at home, but it's running as the webserver rather than me
<Kamion> fabbione: "di Debian" can safely become "di Ubuntu" in Italian, can't it?
<Kamion> or is it "d'Ubuntu"?
<fabbione> di Ubuntu is sane enough yes :-)
<Kamion> good
<rburton> mjg59: walters has a tool which run a per-user apache iirc
<fabbione> how has pcmcia slots handy?
<fabbione> thom: ?
<Mithrandir> mjg59: could nstx' README.Debian include the needed interfaces(5) fragment?  It would be useful for lazy bums like me.
<cenerentola> all: hey ppl who can suggest a nice unix programming book?
<cenerentola> all: what's best Linux Programming Unleashed or The Art of Unix Programming  
<pitti> cenerentola: www.tldp.org has some nice stuff
<cenerentola> i need one for the uni
<seb128> elmo: libxslt and gnome-common too and that should be ok, thanks :)
<rburton> poor elmo
<pitti> seb128: create an elmo proxy script which can do the sync stuff automatically :-)
<Kamion> cenerentola: neither; get one of W. Richard Stevens' Unix programming books
<Kamion> very dense, very detailed, but excellent
<seb128> rburton: poor elmo, poor elmo, apparently he's sleeping ... nothing to complain about :p
<cenerentola> Kamion:Advanced Programming in the UNIX Environmen
<Kamion> APUE is good, yes
<elmo> seb128: done except for libxml2 - I'll do that once it reaches a mirror
<seb128> elmo: ok thanks :)
<Kamion> obviously it depends what you're actually looking for, but ...
<seb128> (oups, he was not sleeping :p)
<Kamion> I'd rather that than e.g. a book by ESR :-)
<cenerentola> ESR?
<seb128> Kamion: do you know if we need to update the seed before getting new packages from debian ? ie: evolution-data-server has been splitted in a bunch of small binary packages for the different libs ...
<Kamion> seb128: we don't have hoary seeds yet ...
<seb128> ok, so nothing to worry, I was not sure
<seb128> thanks
<elmo> pitti, thom: also done
<cenerentola> kamion: modern operating systems, or Operating Systems: design & impl.?
<pitti> elmo: oh, thanks
<Kamion> cenerentola: haven't read either
<Kamion> cenerentola: (also, this isn't really the place ...)
<cenerentola> sth about hw?
<cenerentola> kamion: ohh cmon
<Kamion> no
<pitti> Kamion: can we at least rerun germinate? E. g. libhal-storage0 is currently in universe, but hal depends on it
<Kamion> pitti: against what? :-)
<cenerentola> kamion: just making some question to a friend...
<pitti> Kamion: well, I mean recalculating the main packages from the current seeds
<pitti> Kamion: isn't that possible?
<Kamion> pitti: that's up to elmo
<pitti> Kamion: okay, thanks
<elmo> I thought I fixed that yesterday
<pitti> elmo: hmm, can also be the lag of my mirror
<elmo> apparently not - fixed now
<pitti> thx :-)
<fabbione> pitti: your upload has been rejected
<Kamion> elmo: I'm assuming one of mdz and jdub is taking responsibility for doing new seeds; do you know?
<fabbione> pitti: you need to increase mod_perl version in debian/rules
<fabbione> pitti: also for warty/hoary
<pitti> fabbione: argh, I did not know that. That's what you get if you poke around in foreign packages...
<fabbione> pitti: noone will die for it
<fabbione> pitti: i also forget about it sometimes
<pitti> fabbione: just bump the version to the next one?
<elmo> Kamion: not afaik, no one's said anything about it other than to just copy warty's but I assume anyone can do that?
<pitti> fabbione: update APACHE_MINOR as well?
<fabbione> pitti: hold on a second only :-)
<pitti> fabbione: oh, the right time
<pitti> fabbione: I just ^C'ed the sid upload
<pitti> fabbione: but I found out that APACHE_MINOR is not actually used
<fabbione> pitti: it is
<fabbione> but the perl version is only in debian/rules at the end
<fabbione> it needs to be set manually
<fabbione> the VAR at the beginning is misleasding
<pitti> fabbione: I manually updated the libapache-mod-perl revision to -14
<pitti> fabbione: this worked fine so far; anything else?
<fabbione> pitti: ok. the APACHE_MINOR is used during debian/rules
<fabbione> even if it is empty
<pitti> martin@box79162:/tmp/apache-1.3.31$ grep -r APACHE_MINOR .
<pitti> ./debian/rules:APACHE_MINOR = 7
<pitti> ./debian/rules: debian/scripts/populate $(APACHE_MAJOR) $(APACHE_MINOR) $(PERL_MAJOR) $(DEBMAJOR)
<pitti> ./debian/rules:#        dh_gencontrol -v -plibapache-mod-perl -u-v$(PERL_MAJOR)$(DEBMAJOR)-$(APACHE_MINOR)
<fabbione> yes that should be more than correct
<fabbione> you might hit the same problem for hoary/warty...
<fabbione> (if you didn't change it before)
<pitti> fabbione: maybe, I already wondered why it did not built
<fabbione> it probably did build fine
<pitti> fabbione: argh, the populate script changes this again to APACHEMINOR
<fabbione> but the upload was rejected
<pitti> fabbione: but there is another one: ./debian/pkgtemplates/flavours.postinst:    if dpkg --compare-versions $2 eq @APACHEMAJOR@@DEBMAJOR@-@APACHEMINOR@; then
<fabbione> pitti: no no.. that's ok
<seb128> do we have some official "minimal hardware requirement" for the liveCD ?
<pitti> fabbione: anyway, for sid I updated it to 7 anyway
<seb128> just to reply to users who ask about this
<Keybuk> The following packages will be REMOVED:
<Keybuk>   python2.3-genetic
<fabbione> pitti: APACHE_MINOR set to 7 for sid is ok
<Keybuk> aww
<pitti> fabbione: for warty I probably need APACHE_MINOR=6.1
<fabbione> pitti: and -14 for libapache_mod_perl
<pitti> fabbione: yes
<fabbione> that's correct
<fabbione> pitti: don't care about the populate script
<fabbione> pitti: once it gets the proper values from debian/rules it does only a bunch of sed
<fabbione> pitti: so that's not important
<pitti> fabbione: okay, then I can actually upload the sid version as it is
<fabbione> i think so yes
<fabbione> hey
<fabbione> in the worst case Katie will say nO
<pitti> fabbione: argh, I need to remove the half-uploaded debs from the uplaod queue  before...
<fabbione> pitti: send the .commands :-)
<pitti> fabbione: right
<elmo> oi
<azeem> unstable's debootstrap does not support warty/hoary, right? What's the best way to install an Ubuntu chroot on Debian?
<fabbione> azeem: grab our debootstrap :-)
<elmo> azeem: install our debootstrap or steal the warty script
<elmo> pitti: what are you talking about uploading? 
<azeem> okie
<elmo> Keybuk: python-genetic contains it now
<pitti> elmo: fabbione asked me to upload a fixed apache version to sid
<fabbione> elmo: i did CC you on a bunch of packages that needs sync
<elmo> oh, sid, fine
<pitti> elmo: but I did not know that I had to bump a package version deeply hidden in debian/rules, so katie rejected it
<elmo> fabbione: yes, I know and I'd just like to say BUGZILLA SUCKS
<fabbione> elmo: yes.. don't worry.. he will have to fix it for hoary and warty too :-))
* fabbione ^5's elmo!
<elmo> well, that and maybe matt does too
<fabbione> matt does suck?
<elmo> I've got a bunch of mails from bugzilla and absolutely nothing tells me what freaking package their about
<elmo> so instead, of just reading my mail, I have to go click on 10 web links to find the packages to sync
<elmo> meh
* fabbione wants Xprint upstream's head on a silver plate
<chrisa> I use bugzilla at work, it's a good way to demoralize employees
<fabbione> + #  define PrintOnlyServer                   NO
<fabbione> according to documentation this means: "BUILD ONLY THE XPRINT SERVER"
<fabbione> why on earth it keeps building all the crap around it?
<fabbione> it's all fault of lixp6
<fabbione> i can't kill that library
<fabbione> or suddenly ubuntu and debian will FTBFS
<Keybuk> elmo: aahh
<fabbione> hmm
<fabbione> there is something wrong in my head
<fabbione> that should be a YES
* fabbione sighs and runs another hour build to verify
<Kamion> elmo: please resync parted with Debian
<elmo> fabbione: #2996 - I can only sync from proper repos, sid, whatever - I can't sync an unsigned source package into main - if you're happy with the package there, please sign and upload it
<elmo> Kamion: done
<Kamion> ta
<elmo> kamion: btw, what's up with 2814?
<fabbione> elmo: ok
<elmo> Kamion: jigdo seems to be using old d-i files..
<Kamion> elmo: yeah, I need to regen the jigdo files, will look once I emerge from under the merging pile
<elmo> ok, cool, just checking I didn't need to put the old d-i files back :>
<Kamion> I also need to figure out how to convince jigdo never to use daily-installer-* when building a release candidate, or something
<pitti> Hey amu, now officially on board? Welcome!
<Kamion> furthermore I need to have lunch ... :-)
<pitti> fabbione: uploaded updates to sid and warty; hoary will follow soon
<pitti> fabbione: the only odd thing is, why did hoary's katie did not reject the upload?
<fabbione> pitti: source only upload?
<fabbione> pitti: it will reject the binaries later
<pitti> fabbione: right
<fabbione> is the Debian -> Ubuntu bug sync working?
<pitti> fabbione: at least for me it tends to forget followups
<fabbione> i did open a RC bug on qt-x11-free more than 3 hours ago
<fabbione> and it is still not synced
<robtaylor> amu: the morphix hotplug bug is fixed
<pitti> fabbione: sid, warty, hoary uploaded *sigh* I hope it works this time :-)
<amu> robtaylor: thx, problem was hotplug itself ?  
<robtaylor> amu: chroot
<robtaylor> amu: morphix cvs noe pivot_roots as its last boot step
<robtaylor> amu: it used to only ever chroot, hence its brokenness
<amu> damed, well i'm working on the new sys, just with packages from the pool
<pitti> fabbione: just got Debian's ACK :-)
<fabbione> goody
<fabbione> pitti: btw.. congratulation for adopting apache
* fabbione grins evily
<pitti> fabbione: ah, was there something you should have told me before?
<fabbione> MUHA UHA UHA
<pitti> ARGH!
<pitti> There is an Indian slapping my back now!
* pitti runs away
<pitti> fabbione: my next upload will be a 10 kb arch-all package that automatically installs apache2
<fabbione> pitti: that's the plan after sarge release
<amu> robtaylor: asap, i got access, another live-test comes.   
<pitti> fabbione: or the PostScript webserver (maybe even better)
<pitti> lamont: here?
<fabbione> ehehe
<T-Bone> mako: ping?
<T-Bone> lamont: ping
<pitti> elmo: since apache is in universe, mdz and me agreed to upload the security-fixed package, but do not make an USN for it; he also agreed that you can amber it as soon as it is built
<robtaylor> amu: cool, that'll save me some work ;)
<Mithrandir> Keybuk: do you have a setup for running nstx on the same host as you have your name server?  I'm having a bit of difficulty getting it going..
<Keybuk> no, different hosts
<elmo> pitti: 1.3.31-6ubuntu0.2  <-- that
<pitti> elmo: right, if it already built?
<elmo> yeah, it did
<elmo> pitti: done
<pitti> elmo: thanks
<pitti> carlos: do you know whether there is a reasonable train between Girona and Mataro?
<carlos> I suppose it, let me check
<Keybuk> hmm, what the frell is ccwmap?
<amu> robtaylor: another good example why oss rocks ;) 
<robtaylor> amu: indeedydoody :)
<carlos> pitti: you have this english page, but seems to be broken under Linux :-(, I will check directly from the Spanish version
<carlos> pitti: http://horarios.renfe.es/hir/ingles.html
<Keybuk> ah, it's an S/390 thing
<pitti> carlos: well, I just looked at RyanAir, they have completely unreasonable flights anyway
<amu> pitti: could we test our voip connection today ? 
<pitti> amu: at Friday evening? Don't you have a gf that will kill you for that? :-)
<pitti> amu: but of course we can do another short test; however, I did not get any linux version to work
<pitti> amu: skype has its own protocol
<pitti> amu: so I guess I just take the MacOS thingy
<pitti> amu: BTW, did you already look for a flight?
<pitti> amu: so far, Lufthansa has the only reasonable flights; however, they are quite expensive
<robtaylor> amu: note that the changlogs in the cvs repo are out of date (alex forgot to check in). he just checked in, and obviously sf sucks so much it wont be checkoutable for 24 hrs :(#
<amu> pitti: hehe, well for me it's only imporatant which time it is, working 24/7 it's just normal  
<amu> pitti: flight for spain ? 
<pitti> amu: yes
<pitti> amu: I don't want to travel 4,5 h to Frankfurt and be there at 4am 
<carlos> pitti: seems like there is no train 
<pitti> carlos: okay
<pitti> carlos: well, Lufthansa has a good flight for about 300
<pitti> carlos: it's not cheap, though...
<amu> robtaylor: ;) i've still no access, maybe the next days ..   
<amu> pitti: letme check, i've a good hand for cheap flights   
<pitti> amu: would be great, I don't
<pitti> amu: although you and me are living in completely different corners of .de
<pitti> amu: where do you look?
<pitti> amu: i. e. which company?
<amu> http://www.aidu.de http://www.opodo.de http://www.expedia.de
<robtaylor> lamont: ping?
<Mithrandir> lamont: http://am.xs4all.nl/morphix/usb/linuxrc.patch.morphix could be very nice to have applied on the live cd, so booting from USB cdroms would work.
<thom> Mithrandir: dude, can you take #2855?
<lamont> robtaylor: ack
<robtaylor> lamont: hey :) hotplug bug fixed, do a cvs pull for your next livecd build
<robtaylor> of scripts-base
<Mithrandir> thom: done
<thom> Mithrandir: i'll swap you one if you want? :-)
<Mithrandir> thom: it's easy enough, I just have to drop my changes on bdale.
<robtaylor> lamont: well, fixed in theory, at least - havn't had chance to fully test it yet
<thom> fair enough
<robtaylor> lamont: i also wanted to ask do you have any local morphix changes that arent upstream yet?
<lamont> robtaylor: probably.  If it has a 'ubuntu' in the version number, then I probably haven't pushed it yet - my bad
<T-Bone> lamont: i'm up to building missing deps (and there's alot, which is scary). basically i have to go through the log files by hand, a cripple my stage1 archive with these bastardized deps, right?
<lamont> T-Bone: pretty much.
<T-Bone> sweet
<lamont> it means that you turn stage2 into stage1.5, or that there'll be a stage 3.  But it's 
<thom> elmo: please sync libapache2-mod-python from unstable
<lamont> "whatever it takes to get a working archive.  If cheating is involved, iterate another stage"
<T-Bone> got it
<lamont> T-Bone: at any point in there, if you have sufficient packages in your archive, you can start working on d-i.
<T-Bone> gonna try to scriptize a bit the missing deps building tho
<T-Bone> right
<Mithrandir> lamont: any comment on the patch I pointed to above?  A friend of mine would be _very_ happy to be a tester. :)
<lamont> Mithrandir: would have to go look at it, but I expect we could add it.
<RubenV> Anyone here from the laptop team?
<Mithrandir> lamont: goodie, if you could take a look and prod me when you have a test image, I would be most grateful.
<lamont> Mithrandir: wanna email it to me, or file it in the bts assigned to me - it's behind the hoary merge work, and I fear it'll fall through the cracks without something... (bts preferred, actually..)
<lamont> normal would be a good severity.. :)
<robtaylor> lamont: right. if you could push sometime betwen now and monday (or get some packages built with the new changes in), so i can build on monday, i'd be forever in your dept ;)
<thom> RubenV: sure, sup?
<Mithrandir> lamont: ok, filing a bug.
<lamont> thanks
<Mithrandir> seems like there's no component for the live cd, so UNKNOWN it was.
<Mithrandir> bug filed
<robtaylor> Mithrandir: i noticed that.. who's the bugzilla admin?
<Mithrandir> robtaylor: justdave
<Mithrandir> probably file a bug on websites, asking for a live-cd component for the bugzilla, assign it to him
<lamont> Mithrandir: LiveCD in the subject, assigned to whatever package it belongs to, has been what we've been doing...
<Mithrandir> lamont: I don't know what package is the right one, so I guess UNKNOWN is right, then
<justdave> robtaylor: I'll be remedying that this afternoon.
<robtaylor> justdave: ok i wont bother filing  bug then :)
<justdave> amu and I discussed how to do that last night, I'll be pushing it out today.
<robtaylor> brilliant 
<justdave> you could file, just mention it's for livecd in the summary and assign it to amu if you know his address
<robtaylor> justdave: i mean a bug for a livecd component in the bugzilla...
<justdave> oh, in that case, yeah, there's already a bug for that :)
<robtaylor> heh :)
<justdave> bug 2635
<Keybuk> gah, bloody hallo-fucking-een
<azeem> I got a free halloween straw from subway yesterday, because they were out of salad
<azeem> Keybuk: wanna have that one?
<Keybuk> can you kill small children with it?
<azeem> there's a small, whiteish ghost on it, but I doubt kids will die of horror because of that these days
<thom> Keybuk: i find a pumpaction shotgun to work quite well. it's a treat.
<Mithrandir> why not rather just not be home?
<Mithrandir> and that's what you get from importing US traditions.
<elmo> thom: done
<thom> elmo: grazi
<Micksa> quick question
<Micksa> maybe I'm too late but
<elmo> Out-of-date BUT modified: 103 (10.00%)
<elmo> getting there :)
<Micksa> did you guys switch to the new wiki partly because you wanted one from which you can generate docs of some format(s)?
* Kamion embarks on the PARTMAN MERGE OF DOOM
<Kamion> I'm not sure which direction is least bad for the partman-auto merge
<Keybuk> Mithrandir: hmm?  Trick-or-Treating is Irish in origin, iirc and predates the colonisation of Merkia
<Kamion> looking at the extent of the changes in both directions I suspect I might as well just redo all the changes by hand
<Keybuk> the tradition comes from the belief that evil spirits are abroad on Samhain, but can be fooled to leave you alone if you dress up like them
<Kamion> hm, mind you Keybuk's merge didn't do too bad a job on it
* Keybuk puts Brewers away <g>
<Mithrandir> Keybuk: hmkay, same difference, it's foreign. :P
* Keybuk clears a space between you and Colin
<Kamion> I'm torn between kicking his arse and not wanting to be associated with inventing trick-or-treating
* Mithrandir throws a few ice blocks at Keybuk 
<Kamion> p.s. next time I'm tempted to fork a file *and* change its name, somebody shoot me
* Keybuk catches them in his drink
<Mithrandir> Keybuk: ice blocks.  You know, not ice pebbles.
<Mithrandir> and you should never put ice in your beer
<Kyaneos> hi
<Kyaneos> what version of Gnome has Hoary??
<Mithrandir> it has 2.8 now, it will have 2.10
<pitti> lamont: here?
<Kyaneos> Mithrandir, 2.10 or 3.0
<Kyaneos> ?
<lamont> pitti: yo
<Mithrandir> Kyaneos: it's said to be called 2.10
<Kyaneos> ok
<Mithrandir> Kyaneos: I'm not a gnome person, so don't ask me what their next version will be numbered, but that's the number I've heard.
<Kyaneos> thank you very much
<lamont> Mithrandir: although jdub had a blog that wanted to call it '10'.
<pitti> lamont: I uploaded a security update of libxml2 yesterday, but it was not built on amd64 this morning. Can you please have a look at that?
<lamont> should be there now.
<pitti> lamont: oh, fine
<lamont> brain fart on my end
<Mithrandir> lamont: that was obvious trolling.
<pitti> so, no packaging error?
<lamont> pitti: none at all. It built fine...
<lamont> pitti: but you have to actually _upload_ stuff, you know?
<lamont> you == buildd here
<lamont> (missing crontab entry)
<pitti> lamont: hmm, that could really help
<lamont> yeah.  uploaded a whole boatload of packages for amd64...
<lamont> sorry Mithrandir. :-)
<thom> elmo: please sync exim4 from unstable
<lamont> thom: how well do you remember what you did to backuppc?  (And would you like 2857?)
<thom> lamont: sure
<thom> i probably just mad it depend on httpd rather than apache though
<lamont> thanks - looks like debian did _something_ addressing the same issue, but it'll take be a bit of digging to see what the diff is...
<T-Bone> mako: ping?
<lamont> +  * Use a2enmod rather than manually symlinking
<lamont> +  * Bin wwwconfig-common (Warty #848)
<mako> T-Bone: hey there
<lamont> it's the 2nd one that's the ugly part.
<thom> ah
<thom> yeah, i'll do it
<Micksa> uhm, can zwiki do images?
<Kamion> Micksa: I think part of the reason for the switch was to be able to integrate the wiki and the web site more closely
<mdz> seb128: we can adjust the seeds after it's uploaded
<mdz> Kamion: I was more curious about whether the new wiki actually provides the data in an easily accessible way, as the old one did
<mdz> I don't remember it having a 'just dump the raw page for me' feature
<Micksa> that could probably be added anyway
<bluefoxicy> The proactive security post to the ubuntu-devel mailing list was apparently ignored.  What else should I do to try to bring attention to the topic?
<thom> Kamion: d'you know if all our console-data changes went back upstream?
<Kamion> thom: not certain; I think that's on my list to merge-review ...
<thom> Kamion: ok, i'll assign the bug to you then :_)
<Kamion> bluefoxicy: start providing patches? :-) It seems to me that it would be useful to run a derivative distribution with the patches you want applied; we'll be making it pretty easy to start up derivative distributions of Ubuntu over the next few months or so
<Kamion> thom: oh, maybe it's not on my list, ok
<bluefoxicy> Kamion:  I do not want a derivative distribution.
<Kamion> I'm not saying it would stay that way forever
<Kamion> it's a useful way to demonstrate the utility and viability of a large wide-ranging patchset to lots of packages, though
<bluefoxicy> Kamion:  The changes are simple, and do not break binary compatibility.  They do not add excess administrative tasks, do not change the way the machine behaves for the user, and would quite probably be easy to maintain.
<bluefoxicy> also
<bluefoxicy> All of these things are in use right now on my machine; I'm running Gentoo Linux with a few bits from Hardened Gentoo, a subproject of Gentoo
<Kamion> if they're so simple, perhaps simply filing bugs with patches is the right thing to do.
<bluefoxicy> so such demonstration is already done
<bluefoxicy> I'm not a developer though :(  but I know someone who's working on it and may be willing to help
<mdz> bluefoxicy: we discussed this in the kickoff meeting
<mdz> I thought it was fairly clear
<bluefoxicy> mdz:  Hmm?
<bluefoxicy> kickoff meeting?
<pitti> Hi mdt!
<mdz> bluefoxicy: you were there, if I recall correctly
<pitti> Hi mdz!
<bluefoxicy> mdz:   The last discussion I remember was sending me here, which in turn sent me to the mailing list
<bluefoxicy> I was sent here from #ubuntu-meeting
<mdz> oh, I remember
<mdz> you asked during the community council meeting
<bluefoxicy> I don't think I paid much attention since then
<pitti> mdz: elmo ambered apache, libxml2 should be ready to go
<mdz> anyway, this was discussed during the Hoary kickoff meeting
<thom> Kamion: it's, um, on your list now :-) it looks like most of the change was a backport, but there's some translation magic needed
<bluefoxicy> ah
<Kamion> thom: yarrrr, more fun
<bluefoxicy> mdz:  i missed that one
<mdz> bluefoxicy: mako is working on a summary, and will publish a transcript as well
<mdz> I'll follow up to the mailing list when I have a chance
<bluefoxicy> Kamion:  I'm also not familiar with the Debian/Ubuntu developer's tools, and not familiar with Lorenzo's work (I don't pay much attention even though he tells me whenever he releases something), so I wouldn't be able to make intelligent bugs :)
<bluefoxicy> mdz:  Ah, ok
<bluefoxicy> I'll look for that
<Kamion> bluefoxicy: it doesn't have to be you, but *somebody* has to take responsibility for it!
<thom> Kamion: sadly, i don't even know what unfuzzying a translation is, let alone how one does it
<bluefoxicy> and try and figure a more structured way to go about this; I still haven't woken up, and I don't even know where to start even to argue for this stuff. . . geeze I'm like a 5 year old :P
<Kamion> bluefoxicy: the core team is already flat out, so we need help from the community if there are extra things that people in the community want
<bluefoxicy> . . .what was I talking about?
<Kamion> Keybuk: partman-basicfilesystems is a good example of where merging debian->warty *doesn't* work well
<bluefoxicy> mdz:  I'll be watching for the transcript where?
<bluefoxicy> and the summary?
<Keybuk> Kamion: oh, what did it do?
<mdz> bluefoxicy: probably -devel, or maybe -news, ask mako
<Kamion> Keybuk: the warty patch was a one-liner that didn't touch .po files or anything; the debian patch was enormous
<Kamion> Keybuk: it went around rewriting lots of .po files when it could have just ignored them, basically
<srbaker> hey.  jython is in debian main, but it's not in warty main or universe.  is there a reason why?
<mako> bluefoxicy: i'm posting things too all three at the moment but i'm going to start posting things to only news pretty soon
<bluefoxicy> mako:  uh huh
<bluefoxicy> mako:  And at the moment, there's a giant coffee cake downstairs
<bluefoxicy> you know what that means.
* bluefoxicy goes to make a giant coffee.
<bluefoxicy> I really have to not get on IRC when I've been awake for ~1 minute
<bluefoxicy> it's right by my bed
<bluefoxicy> it's like "uh?  where the hell am I?  *gets on IRC* Hey where the hell am. . .oh wait, I was dreaming that's right . . ."
* mako looks a little confused
<mdz> thom: how does firefox look?
<SuperL4g> bluefoxicy: do you also use Gentoo?
<srbaker> is rthere a place where i can download the blueish ubuntu background taht was used in the warty prerelease?
<SuperL4g> your name looks familiar
<srbaker> i'm not liking the shit brown.
<SuperL4g> srbaker: tell us how you _really_ feel :)
<srbaker> SuperL4g, sorry, i'm not good with subtlety
<srbaker> :P
<SuperL4g> No worries.  Nor am I.  I just think it's funny.
<srbaker> actually, i was being nice.  i usually call it diarrhea brown
<srbaker> ahh
<srbaker> looks like jython has incomplete build-deps
<bluefoxicy> SuperL4g:  yes
<bluefoxicy> SuperL4g: despite the flack it takes, Gentoo is an excellent developer's platform by nature, and various subprojects (including hardened) have benefited greatly from the ability to easily modify the system at will (easy does not mean it takes less than 2 days to rebuild, though)
<lamont> hrm.. patches back to debian... guess we're not using no-name-yet.com anymore, eh?
<mdz> lamont: people.ubuntu*
<lamont> yeah
* lamont sends a pwlib patch around the long way so he can close it in bugzilla as fixed-in-hoary
<lamont> thom?
<lamont> nm
<lamont> Keybuk: you re-run your scripts?
<Kamion> elmo: please revert console-data to the Debian version
<elmo> Kamion: done
<elmo> thom: done btw
<elmo> (exim4 ages ago, I think I forgot the ack)
<Keybuk> lamont: no?
<lamont> hrm... just wondering why libdc1394 disappeared.
<lamont> mind you, I'm done with it.
<Keybuk> did you look in merge/done ? :)
<lamont> ah, should i be moving things there?
<Keybuk> heh, you'd need +w for that
* Keybuk has been idly keeping track of hoary-changes :p
<Kamion> I do believe that that's everything synced/merged that's in the d-i initrds
<lamont> how often does our bugzilla sync debian bugs?
* lamont hates autocrap
<lamont> where do I put MAINTAINER_MODE again?
<Keybuk> AM_MAINTAINER_MODE in configure.{in,ac}
<Keybuk> somewhere near the top
<lamont> ok
* Kamion beats up discover1 to CHILL about version numbers
<Kamion> lamont: discover1/discover1-data build failures are both fixed now I think, if you're caring about hoary build failures at the moment
<lamont> Kamion: kinda half caring...
<lamont> I do look at them, but things are so flux-ful right now, that I haven't bothered to file any bugs about them.
* Kamion nods
<lamont> Kamion: miscfiles - you added a Depends: fileutils (..) | ...
<lamont> we still need that for hoary?
<Kamion> can I answer that later? :-) need to go out soon
<Keybuk> descent src% ./grepmap --usbmap 0x045e 0x001e 0x0121 0 0 0 3 1 2
<Keybuk> usbmouse
<Keybuk> usbhid
<Keybuk> \o/
<Keybuk> this is kinda fun <g>
<kylem> yargh, is there a divx package for ubuntu's totem, or whatnot.
<nasdaq4088> who here can download 3mb / sec ?
* amu 
<lamont> Kamion: np
<stratus> Is there a brazilian mirror? I need to download the live cd asap to show for a manager but the UK, Spain and other mirrors are really slow to me here.
* stratus thinking in setup one here.
<mdz> stratus: lists of mirrors can be found on the website and in the wiki
<stratus> mdz, i see that a brazilian mirror isn't listed there but anyone here can have one but it isn't published. thanks.
<pitti> mdz: have you got some minutes for libxml2? my gf will drag me out of the house in 10 minutes...
<mdz> pitti: yes
<pitti> mdz: sorry to bother you...
<pitti> mdz: but I'd like to get this out of the door; I'm at a Debian booth all the day tomorrow and are n/a
<mdz> elmo: debdiff on jackass, please?
<mdz> pitti: which advisory number?
<pitti> mdz: 10-1
<mdz> pitti: done
<pitti> mdz: got the template
<pitti> mdz: sent
<mdz> approved
<pitti> mdz: do you know of any changes of my web site login? I could add the advisory, but I cannot publish it
<pitti> mdz: the only option is to "mark obsolete"
<pitti> mdz: odd, now it works (the second time)
<pitti> mdz: however; thank you!
<pitti> night, everybody!
<cenerentola> hello...
<Kyaneos> hi
<amu> mdz: people reporting bug/requests thought my forum page, i forward it to bugzilla ?    
<mdz> amu: sure
<mdz> amu: wait
<mdz> amu: live CD bugs?
<mdz> or general bugs?
<amu> yap
<amu> liveCD 
<mdz> yes, fine
<amu> also such things like ITP's 
<amu> ;) 
<amu> ok, all kind of questions related to the liveCD ....
<Mithrandir> amu: if you can come up with a test image with the patch I mentioned in the "live cd and usb cdrom doesn't work" bug, a friend of mine is most interested in testing. :)
<amu> Mithrandir: sounds good, looks like we have some policy problems, at the buildsys.  
<amu> lamont: for faster process, please could you run a sync of the knoopix packages and a place inoffical-Mithrandir.iso to your testing tree ? 
<Mithrandir> amu: ugh, ok. what kind of policy problems?  The hotplug-runs-in-wrong-root problem?
<lamont> Mithrandir: other than the fact that the entire build process has to run as root in the real root, not much. :-)
<lamont> Mithrandir: and fixing that is a blocker for any liveCD build on a buildd now that warty is out the door, and we have repented of our sins.
<Mithrandir> yeah, I'm talking to amu now with ideas how to fix it.
* lamont goes to a fire call
#ubuntu-devel 2004-11-10
<adeleon> Someboy knows something about the XKB error a start P?????
<adeleon> Hellooooooooo
* lamont goes to fetch kids.  bbiab
<amu> lamont: did you start another test.iso ?  
<jdub> hey amu!
<jdub> nice, hoary announce was on LWN
<jdub> thom: around?
<mdz> jdub: too late for the weekly edition, though
<jdub> yeah
<jdub> nice though
<jdub> means jon probably likes it
<mdz> ubuntu gets lots of LWN love
<jdub> i was very happy to see ubuntu security updates in lwn
<jdub> it's like hearing your song on the radio or something ;)
<T-Bone> hehe
<jdub> $ ./universe
<jdub> libhowl0
<jdub> libreadline5
<jdub> ^ on hoary
<mdz> yeah, we have some seed changing to do
<jdub> what do you think we should do about mdnsresponder?
<mdz> cry
<jdub> heh
<mdz> it needs to listen by default, right?
<jdub> to be useful, yeah
<mdz> I think the best we could do without compromising safety would be to provide a knob to switch it on
<jdub> we need a sensible services editor
* jdub will propose a bounty to mark
<jdub> mdz: mdnsresponder == 5353 udp externally, 5335 tcp localhost
<jdub> hrm
<jdub> doesn't seem to use tcpwrappers
<mdz> written in C?
<jdub> but of course :)
<jdub> there are options to run it only on a particular interface or addr
<jdub> which is good
<mdz> but pointless if it needs to listen on an external interface in order to be useful
<jdub> yeah
<jdub> hrm
<jdub> i am an idiot
<jdub> libhowl0 should be libhowl1
<jdub> hrrrrmmm
<jdub> so if i have a package with two libraries
<jdub> hrm
* jdub does more fossicking
<mojo_> hi all
<mojo_> I'm working on somehack for Ubuntu About, I actually hacked the GNOME about, i'm wondering is it OK to do so? If so, I need a list of developers, and some info that Ubuntu want to put in
<jdub> mojo_: atm, we'd prefer to use a webpage for the 'about' information
<jdub> that icon should really be loading the on-disk page
<mojo_> i c, i just find it looks so simple, the icon in the applet is scaled up very blur, 
<mojo_> ok then
<jdub> the icon in the menu?
<jdub> depends which icon theme you're using ;)
<mojo_> the icon in the Main Menu is OK
<mojo_> but the icon in Add to Panel..(GApplet) is blur
<jdub> oh, the 'add to panel' thing?
<mojo_> yeah
<jdub> yeah, well, who wants to add that to their panel? :)
<mojo_> it used same icon
<jdub> those icons are only there due to a bug
<mojo_> true
<mojo_> hope artwork team fix it soon
<jdub> well
<jdub> it's not an artwork issue
<jdub> it's a panel issue
<mojo_> true
<jdub> those things shouldn't be available as applets
<mojo_> yeah
<mojo_> then y that applet existed there? lol
<jdub> if you have any suggestions of the on-disk page, let us know :)
<mojo_> ok
<mojo_> I will
<mojo_> oh yeah
<mojo_> about the Trash Applet
<mojo_> do u know who's responsible for it in Ubuntu team?
<jdub> well, Mitario is the upstream author
<jdub> but seb128 and jamesh did most of the hacking on it for warty
<mojo_> his nick is the same??
<mojo_> ok then
<mojo_> I will contact them
<herzi_lap> amu, ping
<mojo_> hey
<mojo_> herzi
<jdub> mojo_: where in vic are you?
<mojo_> I'm in Flemington rite now
<jdub> ahr
<mojo_> Derby day mate
<jdub> heh
<mojo_> u know Melb Cup rite?
<jdub> race that stops the nation
<jdub> :)
<mojo_> yeah
* jdub is in syd
<mojo_> my house is 100m away from Flemington RaceCourse
<jdub> ouch
<mojo_> next yr
<mojo_> I will travel to Syd
<mojo_> yawn...
<lamont> moo
<jdub> mdz: what were the problems with the user-mode-linux package?
<mdz> jdub: lots of bugs which just caused it to fail to boot in various situations
<mdz> 2.4 vs. 2.6 host kernels, skas vs. tt
<jdub> ahr
<jdub> it would be totally rad to have a uml package built from our default kernel
<jdub> when was that new version of skas due?
<sladen> it would be enourmously sane and fairly useful
<mdz> jdub: make-kpkg can build UML papckages now
<mdz> jdub: the new version of skas has never had a due date, and has been under development in secrecy for years now
<mdz> jdub: there has been talk on the UML list of creating a UML-oriented Linux distribution :-)
<mdz> would make a fantastic ubuntu derivative
<jdub> mmmmm!
<mojo_> hey jdub
<mojo_> do u know how to enable Java coloring syntax for vim?
<mojo_> I never used Vim with Java
<mdz> mojo_: same as enabling every other kind of syntax in vim
<mojo_> show me the syntax
<tseng> show me the google
<mdz> :syntax on
<tseng> :)
<mojo_> man,, too lazy,,any done it?
<tseng> ...
<srbaker> WHAT?!?!?
<mojo_> are there any good IDE for Java on Linux???
<srbaker> britis women don't give oral sex?!?
<srbaker> mojo_, emacs.  eclipse isn't bad
<mojo_> srbaker: cause they get bored with xxx, they can't moan any more!
<jdub> mojo_: (probably best for these questions in #ubuntu, #ubuntu-devel is for ubuntu development discussion)
<srbaker> whoops, british.
<srbaker> man.  i always wanted to travel to the UK.  not anymore!
<srbaker> mojo_, if you want an ide in the sense of a windows ide, try eclipse.  but emacs should be all you need
<srbaker> mojo_, hell, i'm an emacs bigot, and i'm even attracted to vim these days :P
<srbaker> mojo_, so either choice is good
<bluefoxicy> can someone give me a quick start guide to rebuilding ubuntu packages and the software involved?
<tseng> uh
<tseng> google debian new maint
<bluefoxicy> or do I actually have to do work and read docs, then try to pull the pieces I need out of them
<tseng> yes go read, its not immediately obvious
* bluefoxicy hates reading full documentation just to figure out how to do a single task
<tseng> its not a single task
<bluefoxicy> blah.
<tseng> its understanding the packaging format and several related tools
<bluefoxicy> tseng:  emerge -eB universe?  :)
* bluefoxicy is spoiled
<tseng> no?
<tseng> spoiled? i wouldnt say that
<bluefoxicy> megaverse?
<bluefoxicy> err, negaverse, megaverse, what the hell was it on sailor moon
<tseng> you get busted ass gcc and glibc-cvs-du-jour
<bluefoxicy> so?
<tseng> so, it sucks. ubuntu is solid
<tseng> so rtfm and join the fun :)
<bluefoxicy> I play well with gcc 3.4.2-alpha3-beta9-cvs200410nextweek
<bluefoxicy> gives me something to do
<tseng> meh.
<bluefoxicy> it'd be boring if it worked all the time; if I wanted everything to work, I'd be running stable :)
<bluefoxicy> that's what stable is for, having stuff that works.  :)
<bluefoxicy> wtf
<bluefoxicy> I just went to google.ow
<bluefoxicy> what a painful typo.
<bluefoxicy> tseng:  http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html
<bluefoxicy>        8  Package: gentoo  <
<bluefoxicy> ^-- There's a package that installs Gentoo?  wtf?
<lifeless> gentoo is a type of penguin
<bluefoxicy> yes
<lifeless> that documentation predates the 'Gentoo Linux' project.
<bluefoxicy> ah
<bluefoxicy> it's still funny; there's a program that converts another distro to debian, yes?
<tseng> gentoo is a file manager
<lifeless> yes, there is
<bluefoxicy> mmm.
<fabbione> morning guys
<fabbione> mdz: you around?
* lamont grumbles
<lamont> not all automated merges are created equally.
<lamont> 41 build failures in main right now...
<lamont> many of them thought they succeeded in the automerge..  well, that gives me something to work on next week..
<tuo2> hosaka: cafsoc?
<jdub> there was a phoenix.rpm a while bck
<jdub> that converted a red hat install to debian
<jdub> oh man
<jdub> there are even two herberts in bugzilla
<jdub> whoa!
<jdub> b0rkage in a hoary upgrade :)
<jdub> gnomemeeting uninstallable
<jdub> excitement!
<lamont> evolution-data-server-dev: Depends: libgnome2-dev but it is not going to be installed
<lamont> jdub: you want b0rkage??? "Get your b0rkage here!  just AU$5!!"
<lamont> hrm... maybe I'm getting a bit punchy.
<jdub> AU$5 is pretty cheap
<lamont> b0rkage is pretty easy to come by right now, that's all.....
<jdub> lamont: usual place for hoary build logs?
<jdub> http://people.ubuntulinux.org/~lamont/buildLogs/g/gnomemeeting/1.0.2-5/gnomemeeting_1.0.2-5_20041029-0057-i386-failed
<jdub> ahr
<jdub> After installing, the following source dependencies are still unsatisfied:
<jdub> libpt-dev(inst 1.6.5-3ubuntu1 ! >= wanted 1.6.6.4-1) libopenh323-dev(inst 1.13.4-3 ! >= wanted 1.13.5.4-1)
* jdub releases new u-a
<jdub> hmm, gotta plan for a new ubuntu-calendar :)
<lamont> yep
<lamont> ah, that explains something else.  hrm... to read, perchance to fix.
<pasc> woohoo
<pasc> jdub: I was going to stop at every pub on the way home, but then realised what that entailed
<lamont> jdub: thanks, I think I fixed the stupid auto-depwaiter :-(
<jdub> pasc: hahaha
<lamont> jdub: gnomemeeting building
<jdub> oh, rad!
<jdub> thanks :)
<lamont> the auto-depwaiter turned that failure into a d-w libpt-dev (>= 1.13.5.4-1), which would be, um, wrong.
<jdub> hrm
<jdub> bongy
<jdub> how are the buildds holding up?
<lamont> .+ instead of [^ ] +
<jdub> hope we get cricket graphs some time
<jdub> so we can watch the pain ;)
<lamont> kinda like this...
<lamont>  05:47:27 up 9 days, 13:52,  1 user,  load average: 0.00, 0.00, 0.00
<jdub> haha
<lamont> jdub: I need to roll out a new buildd that knows to only take N% of the needs-build packages, otherwise one buildd gets stingy
<lamont> code's done, just been waiting for both the buildd's and I to be idle at the same time.
<plovs_work> any wiki-dev here, site gives zope-errors logging in
<jdub> ahr
<jdub> plovs_work: use site-edit.ubuntulinux.org
<plovs_work> jdub, thanks
<plovs_work> jdub, same error Error Type: AttributeError Error Value: setProperties
<jdub> not sure then
<plovs_work> started 9 hours ago, at this site of the ocean :(
<plovs_work> jdub, Alt-e helped logging in, then it works (a bit) better
<jdub> hrm
<jdub> we should do a howto for reinstalling grub to the bootblock
<jdub> anyone know grub well>
<jdub> ?
* lamont goes to bed
<jdub> night lamont 
<fabbione> night
<tuo2> b/topic
<daniels> Kamion: do we support booting from a usb ms / ?
<sivang> Morning all.
<SuperLag> any of you guys dual boot Ubuntu with another Linux distro?
<jdub> SuperLag: best to ask user questions on #ubuntu
<sivang> SuperLag : Yes, with debian sid. But if you're interested in help, I believe that would be better served in #ubuntu
<mdz> fabbione: here now
<Kamion> elmo: please revert partman-md to Debian
<Kamion> daniels: "usb ms"?
<fabbione> mdz: does the bug sync from Debian work?
<fabbione> 278781 hasn't been synced
<fabbione> and i expect others too
<mdz> fabbione: I will check
<fabbione> mdz: i did check the rsync and it works fine
<fabbione> there were no updates in the queue since last run
<mdz> it's failing trying to download the germinate output
<fabbione> argh
<mdz> broke 3 days ago
<fabbione> ok
<fabbione> not too bad
<Kamion> from where is it trying to download the germinate output?
<mdz> Kamion: it was pointing at chinstrap/~scott/
<mdz> I redirected it to /~cjwatson/
<fabbione> with all this white dust i look like bdale :-)
<fabbione> (i was sandpapering walls ;))
<Kamion> mdz: you might want germinate-warty-output rather than germinate-output, too?
<mdz> Kamion: what is the difference?
<Kamion> mdz: the former is computed against sid
<jdub> hey dudes
<fabbione> hey lady
<mdz> Kamion: perhaps, now that we have a functional distribution, it should just point at Packages/Sources instead
* jdub spanks fabbione 
<Kamion> mdz: yeah, probably
<fabbione> YEAH SPANK ME SPANK ME! I LOVE THAT YEAHHH!
<fabbione> <g>
<Kamion> mdz: noting that you don't have all the seeds in there at the moment, either ...
* mdz rubs his eyes
<mdz> Kamion: I would be positively thrilled if you wanted to take responsibility for debzilla :-)
<Kamion> mdz: I wouldn't :-)
<jdub> fabbione: i don't think we should be doing this at the office
<Kamion> mdz: but, ok, ask me on Monday - I need to go into town now
<fabbione> jdub: no no... only in pvt :D
<Kamion> mother's birthday tomorrow, no present yet, WHOOPS
<fabbione> Kamion: better run
<mdz> 0800-SORRYMOM
* Kamion flees
<Keybuk> *sigh*  I wish there was a decent gnomeish IDE
<Mithrandir> fabbione: why have you marked 3032 as a duplicate of 3037 which in turn is a duplicate of 3032?
<jdub> Keybuk: tried anjuta? what do you think?
<mdz> anjuta of "I can't get anjuta to work" fame?
<mdz> Mithrandir: I think fabbione was rushing ahead of debzilla
<Mithrandir> mdz: debzilla marked it as a dupe twice.
<Mithrandir> once before, once after fabbione
<mdz>                 Marking 3037 as a duplicate of 3032
<mdz> that one was debzilla
<mdz> debzilla marked 3037 as a duplicate of 3032
<mdz> fabbione marked 3032 as a duplicate of 3037
<Mithrandir> yes, nine minutes later.
<mdz> debzilla can't read :-)
<mdz> reopening 3032
<Mithrandir> ok :)
<Keybuk> jdub: yeah, was just playing with it ... it's ok, but not great
<Keybuk> it lacks too many little features that I use all the time
<Keybuk> copy buffers and add-to-changelog being the top two
* mdz force-feeds emacs to Keybuk
<Keybuk> mdz: I use emacs now, but it'd be nice to have something a little more GUI :)
<Keybuk> something which I could use the mouse with, for example
<mdz> you can use the mouse with emacs
<mdz> it just punishes you for it
<Keybuk> can't when it's in a terminal
<Keybuk> the X variant is just terrible
<mdz> I don't find it to be so
<Keybuk> the font rendering is abysmal
<mdz> works fine for me
<mdz> and how could it possibly be worse than gnome-terminal anyway? :-P
<Keybuk> gnome-terminal's cute ... properly sized anti-aliased fonts
<Mithrandir> g-t is sloooow
<jdub> slooooooooow
<Keybuk> heh, I find that a *feature* ... I can do compiles and just about see what scrolls past
<mdz> it's like having a turbo button again
<jdub> haha
<jdub> man
<jdub> i have to lay the smack down on nalin
<Keybuk> nalin?
<jdub> vte "maintainer"
<Keybuk> heh
<moyogo> there has been some interesting discussion on why g-t is so slow lately, i hope it goes somewhere
<jdub> mmm, and i hope some of the patches go in
<Keybuk> any particular reason why we don't trial them?
<jdub> oh yeah
<jdub> dude
<jdub> we have a distro
<jdub> HAND ME THE BUG SPRAY!
<Keybuk> was that a "yeah there is a reason" or "omg! I forgot I have the power" ?
<jdub> the latter :)
<amu> jdub: ;) 
* mdz hands jdub the Sword of Power
<jdub> i was spun out earlier tonight
<jdub> there was an ad for HE-MAN figures and CASTLE GREYSKULL
* Micksa chuckles
<mdz> BY THE POWER OF GREYSKULL
<jdub> only, way modern
<mdz> FIX THAT UNIVERSE BUG
<jdub> haha
<Micksa> half of me was hoping you'd do a he-man rip-off just now
<Micksa> the other half of me was going to leave if you did
<mdz> who were the masters of the universe, anyway?  was he-man one of them?
<jdub> i think we're more galaxy quest than masters of the universe
<Keybuk> http://en.wikipedia.org/wiki/Masters_Of_The_Universe
<jdub> Keybuk: addict
<mdz> we're more Zork
<mdz> or Adventure
<mdz> you are in a maze of twisty packages, all alike
<jdub> mmm
<jdub> just wait until we in grumpy
<jdub> or perky
<Micksa> I'm imagining jdub doing the scene where captain whatsisname shows off his new crew
<jdub> warty at 12 months support
<jdub> hoary at 6 months support
<jdub> grumpy released
<jdub> perky in development
<Micksa> if every linux user gave $10 to a linux developer
<Micksa> how much would we each get?
<Micksa> (let's pretend I am one for a sec)
<martin_> ?
<mdz> martin_: !
<pitti> mdz: still awake?
<mdz> yes
<pitti> mdz: I just tried to use irssi the first time
<pitti> I'm at the Debian boot and these guys somehow block the IRC port, so I have to ssh to my server
<pitti> s/boot/booth/
<mdz> hello, booth
<jdub> GOOD MORNING FREEDOM LOVERS!
<jdub> ^ message for booth
<amu> hi pitti 
<pitti> jdub: thanks! This was necessary
<mdz> also counted among things which are necessary:
<mdz> sleep
<mdz> night, all
<pitti> mdz: night!
* Keybuk stares blankly at the kernel's USB code
<Keybuk> I swear, someone was having fun here
<Keybuk> descent linux-source-2.6.8.1% cat /sys/bus/usb/devices/1-2/version
<Keybuk>  1.10
<Keybuk> of course, that's 0x0110 ... *huh*?!
<Keybuk> return sprintf (buf, "%2x.%02x\n", udev->descriptor.bcdUSB >> 8,
<Keybuk>                 udev->descriptor.bcdUSB & 0xff);
<Keybuk> yeah, let's pull apart a BCD hex value and pretend it's a float, that'll confuse 'em
<Micksa> heh
<Micksa> is that something out of the USB spec maybe?
<Keybuk> probably
<Keybuk> BCD is actually a reasonably sensible way to do it; but it's still evil
<Keybuk> abusing hex to look like decimal
<Micksa> one of USB's major goals is that devices (and maybe hosts) could be made cheaply
<Micksa> it's slightly cheaper to throw BCD right at a numerical display than it is to put in decoding logic :)
<Keybuk> indeed
<Micksa> which is good if you ever have to make a USB device that needs to display its own dev ids :)
<Keybuk> http://searchvb.techtarget.com/originalContent/0,289142,sid8_gci1019210,00.html
<Keybuk> ^ ouch, you seen that one jdub?
<Keybuk> while not particularly anti-Mono, "Mono is an attempt by Novell to reverse engineer parts of Microsoft's .NET Framework." is a bit strong
<Micksa> *sigh*, every question is turned into a pretext to flog windows and bash linux
<Micksa> "multiple conflicting distributions with multiple infterfaces"... how about windows 3.1/95/98/me/nt/2000/xp
<Micksa> and all the fun developers have trying to make stuff that works on all of them
<Micksa> okay, I'm done
<Keybuk> heh, nah, MS have it even better
<Keybuk> they have multiple conflicting interfaces in each Windows release
<cenerentola> hey how can i install hoary?
<Keybuk> cenerentola: change warty in /etc/apt/sources.list to hoary and aptitude dist-upgrade -- but beware, in hoary be dragons at the moment
<cenerentola> keybuk: ill be there...
<jdub> Keybuk: yeah
<jdub> Keybuk: and the news about novell making it public that they're doing a patent review...
* jdub has some comments about that for his blog, if he ever writes one
<Micksa> sun sure are being dumbfucks lately
<Keybuk> why you say that?
<jdub> seb128: around?
<Micksa> not as such
<seb128> yes
<Micksa> grah, ww
<jdub> hey hey
<seb128> hello jdub :)
<jdub> seb128: i just did the tarballs due announec for 2.9.1
<seb128> I've got the mail yes
<jdub> seb128: so, um, you will be having fun early next week ;)
<seb128> he he, I know :)
<Micksa> Keybuk: bending over for kodak, mcnealy saying he'll attack redhat over java because he doesn't like them
<jdub> seb128: what do you think about making all the gnome packages create -dbg packages?
<Micksa> sputing crap about "the cost of free"
<seb128> jdub: even the applications ? 
<jdub> seb128: yeah, so when things go wrong, users can install -dbg packages and we can get good backtraces for us and upstream
<cenerentola> who's wearing the belt in here? who should i talk to for opening a ml & related thing [public relations] 
<jdub> cenerentola: what do you need?
<seb128> jdub: I don't really like the idea to have so many -dbg packages ...
<jdub> seb128: what do you think? is that a ton of packaging work, or is it pretty easy?
<seb128> packaging is not the problem, but that make huge packages
<Mitario> lo veryone!
<seb128> waste of mirror space, bandwidth, etc ...
<jdub> hey Mitario 
<jdub> seb128: hmm
<seb128> hi Mitario 
<cenerentola> jdub: wait a sec... mummy's calling
<jdub> seb128: pretty useful though
<jdub> seb128: kinda painful shipping 2.9 if we can't get good backtraces
<azeem> you could put the -dbg packages in a seperate, non-mirrored archive
<seb128> yes, but I would rather make a system to build packages with "nostrip noopt" somewhere
<azeem> or just automatically rebuild GNOME packages with DEB_BUILD_OPTIONS=nostrip and put them somewhere else for people to install
<jdub> if you guys want to come up with a cool way of doing it
<jdub> and ping lamont, mdz and i
<jdub> that would be sweet :)
<azeem> jdub: hey, it was *your* idea :)
<jdub> haha
<seb128> yes, we really need debugging packages
<cenerentola> jdub: im back...
<cenerentola> in black
<Micksa> jdub: do you have an alternative viewpoint on novell, so to speak? or do you just generally wanting to blog "novell are joining us! woo!"?
<seb128> jdub: the problem is ... what happen if we add -dbg for all the packages ? That's definitively not good for the debian side (too big, not really that useful), so we will definitively get out of sync for GNOME since we don't even have the same binary packages for a same source package
<azeem> I guess the CPU cycles for the buildds don't matter too much, so just building the package twice is acceptable? (as opposed to, say, hack debhelper/cdbs to spit out unstripped packages as well)
<jdub> Micksa: hard to explain
<jdub> seb128: hmm
<Micksa> jdub: how many blogs do you have? :)
<jdub> seb128: maybe lamont will have some clever ideas
<jdub> Micksa: one
<seb128> I'll take to lamont, the best option would be to get a "noopt nostrip" build for GNOME packages and a repository for these packages
<jdub> cool
<Mitario> anyone seen mvo_ around?
<cenerentola> jdub: here i am
<cenerentola> so let's talk
<cenerentola> 1) who should i ask to request an italian ml
<jdub> me
<cenerentola> so...
<jdub> mail jeff.waugh@canonical.com
<cenerentola> jdub: can you set up.. ahh
<cenerentola> can i query you?
<jdub> cenerentola: can you please mail me at the above address?
<jdub> Keybuk: http://bugzilla.gnome.org/show_bug.cgi?id=122656
<jdub> Keybuk: see elijah's comments at the end
<cenerentola> jdub: done
<Mitario> yay, runnin hoary now.. :)
<jdub> woo :)
<Mitario> ^^
<Keybuk> jdub: a nice collection of swats to apply there then
<Mitario> hmm, have to discuss with michael to get the upgrade-notifier and update-manager in :)
<Mitario> probably with mdz too
<Keybuk> jdub: Nalin's comments on all those bugs are the most interesting <g>
<jdub> mmm
<Keybuk> (through their lack :p)
<Micksa> is he alive?
<cenerentola> jdub: have got the mail?
<cenerentola> jdub: or better how long should i wait?
<Micksa> maybe he's using lynx in g-t
<jdub> cenerentola: i'll sort it out on monday :)
<Micksa> and he's going to get back to us eventually
<Micksa> ho ho ho
<Keybuk> Kamion: (catching up) there's a patch on #184635 to fix the Replaces bugs
<Keybuk> or, at least, so aj claims <g>
<Kamion> Keybuk: hah, awesome, I hadn't even got round to looking at the code yet
<cenerentola> jdub: next week ill be at the university and i wont be able to answer until.. friday
<Keybuk> I might stick that in 1.13~ and see what happens :p
<Keybuk> oh, and 1.10.24 is available for your consideration for sarge ... it's only been in unstable a few days, so you'll probably want to wait; but there's been no "aiieeee!" from it (and those usually show up *very* quickly :p)
<Kamion> Keybuk: ah, ok, can you remind me on Monday?
<Kamion> I'll push it through then
<Keybuk> yup, sure
<Kamion> ta
<Keybuk> unless my brain has melted from the stupidities of inputmap
<Mitario> Keybuk, did you draw that nice little update-config dialog some days ago?
<Kamion> elmo: please sync newt from Debian
<lamont> morning
<Keybuk> Mitario: yeah, http://people.ubuntu.com/~scott/software.png
<Keybuk> though it's not HIG-perfect  (a few spacings are wrong, and that line at the bottom shouldn't be there)
<trulux> hi
<trulux> hey bluefoxicy 
<trulux> has anybody get informed about the proactive security thread on ubuntu-devel list?
<trulux> i'm the head developer of Hardened Debian and bluefoxicy was commenting that maybe it would be a good idea to have me here explaining it, so, here i am
<Keybuk> I read that the other day ... my main concern is that I've never seen those types of changes work properly
<Keybuk> we've used one of them on our servers, and it just resulted in processes core dumping all the time
<trulux> Keybuk, it depends on how you know to do it
<trulux> and also on how you have been using it
<trulux> hardened debian has been severally tested on produciton environments (software-libre.org , ourproject.org , libre-projects.org)
<Keybuk> I guess the best way to demonstrate it's doable for Ubuntu is to do it, and demonstrate how well it works
<trulux> and that environments have an average of more than 50 users per hour in the minimal case
<trulux> Keybuk, what do you mean with that? letting ubuntu people to test it? sure
<Keybuk> I wasn't quite sure, personally, what the intent of John's mail was
<Keybuk> it kinda read as "I'd like to discuss doing this" ... but then never really raised anything to discuss *shrug*
<trulux> then let me to discuss about it ;-)
<trulux> i'm replying his email, but he has tested many implementations that i have already did
<trulux> the only thing lefts is the one related with performance and what one to choose
<trulux> the less painful, and the less harmful :)
<Keybuk> that's not really something you can decide by discussion, but by actually trying them out, isn't it?
<trulux> yes
<Keybuk> so it's not really anything anybody can take a technical decision on until there's working example
<Keybuk> stuff like that (and MAC too) is quite shiney though ... I know almost nothing about it all though
<nictuku> hi. is there a known bug about DMA being used on old cd-rom drives during installation?
<nictuku> I had problems with that. It errored with "cannot find install media". After burning another CD media, I tried disabling DMA in the CD-ROM drive, and it was fine.
<fabbione> mdz: why did you swap again 3037 and 3032?
<mdz> fabbione: they are merged in Debian, so debzilla marks the duplicate automatically
<elmo> Kamion: done
<Keybuk> heh, I appear to have discovered colin-separated arrays
<trulux> Keybuk, working examples are already did and also regresion tests
<trulux> Keybuk, https://sourceforge.net/project/showfiles.php?group_id=118309&package_id=132536&release_id=274754
<Keybuk> trulux-away: I'm slightly amused by the "Better performance" -> PIE line on that ...
<Keybuk> PIE is slower
<mvo_> Keybuk: is Mithario working on http://people.ubuntu.com/~scott/software.png? or was he just interessted in your mock-up?
<Keybuk> mvo_: unsure, you'd have to ask him
<mvo_> Keybuk: will do, thanks. 
* mvo_ joins at 1.11 and I would love to see something like this soon for ubuntu
<Keybuk> yeah, it'd be nice to have a source-selection UI that doesn't scare the crap out of people <g>
<mvo_> Keybuk: that's it! and I like the idea to integrate the "auto-update" feature into it
<mvo_> the button to control it that is
<Keybuk> I might improve that UI slightly once I've got this evil inputmap parser out of the way
<Keybuk> (whoever designed this stuff needs murdering)
<bluefoxicy> o.o
<bluefoxicy> <Keybuk> I read that the other day ... my main concern is that I've never seen those types of changes work properly <Keybuk> I guess the best way to demonstrate it's doable for Ubuntu is to do it, and demonstrate how well it works
<bluefoxicy> Keybuk:  Runs on Gentoo, I've used PaX/PIE/SSP for a while yet, though it takes some blood and sweat to get it working the first time.
<Keybuk> I'm not sure which elmo used on our servers, but it was causing things like Python, ls and tar to randomly segfault
<bluefoxicy> Keybuk:  The idea is that the distribution figures out what breaks, and handles that.  Once you've found what blows what apart, it pretty much works.
<bluefoxicy> This works because a minimal set of things break.
<bluefoxicy> Keybuk:  GrSecurity?
<Keybuk> PaX I *think* ... but don't quite me on it
<Keybuk> or quote me
<bluefoxicy> I've heard some people set up Gr improperly and have basic applications smack straight into their rate limit.
<bluefoxicy> err, resource limit . . rlimit, whatever that is.
<trulux> rlimit
<mdz> Keybuk: exec-shield
<Keybuk> ah, thankyou matt
<bluefoxicy> http://rafb.net/paste/results/jlO4K230.html
<bluefoxicy> :)
<bluefoxicy> on amd64; normally I'm using S (segmexec) instead of P (pageexec) on x86
<bluefoxicy> ET_DYN executables are executables built with -fPIE or -fPIC
<Keybuk> why would you build an executable -fPIC ?  other than as a dare
<bluefoxicy> so it can be quickly and safely loaded anywhere in memory.
<Keybuk> that's -fPIE ... not -fPIC
<Keybuk> PIC executables still have a fixed load-address
<bluefoxicy> -fPIE does not exist in gcc <3.4
<bluefoxicy> 3.3 uses -fPIC -pie
<Keybuk> indeed, but -fPIC doesn't have the same effect
<bluefoxicy> -pie is a linker flag.  :)
<bluefoxicy> http://lwn.net/Articles/106214/
<Keybuk> yeah, that'd make more sense
<Keybuk> just building PIC executables without making them PIE is a bit of an odd thing to do
<bluefoxicy> yeah
<Keybuk> "hey, let's make this executable slower for no reason <g>"
<bluefoxicy> even then they have a fixed load address though; but using PaX, PIE binaries will be loaded at random offsets automagically
<bluefoxicy> a normal system will still just jam them at an easily determined and repetable address
<Keybuk> well, it's not fixed in the sense that the application can't be loaded anywhere else
<Keybuk> the link-loader just doesn't load them anywhere else
<bluefoxicy> right.
<Keybuk> PIE is a bit security-through-obscenity though :p
<bluefoxicy> not really
<bluefoxicy> security through obscurity is the concept that a system has known flaws, but the attacker doesn't know what they are, and won't find out
<bluefoxicy> if the attacker finds out what said flaws are, he can easily exploit them.
<Keybuk> the basic security gain is that your application is loaded in a random place, so is harder to exploit
<Keybuk> which is up there with putting your PHP webserver on a random port :)
<bluefoxicy> In the absence of an information leak, the attacker may know that he can RET2LIBC, but he won't know where the heck LIBC is
<Keybuk> hmm... that's about 5 lines of assembler to find that out
<bluefoxicy> so even though he knows the system has a flaw, he can never guarantee that he can use that flaw
<bluefoxicy> and how do you find that out?
<bluefoxicy> remember that you can't execute code you've injected onto the stack.
<Keybuk> just look up a known libc symbol (open is a good one :p) in the GOT
<Keybuk> ah, no, see you can :)  unless you combine it with SSP/PaX or something aiui
<bluefoxicy> ah, no, you can't.
<bluefoxicy> the stack is made non-executable
<Keybuk> by what?
<bluefoxicy> by pax >:)
<Keybuk> <Keybuk> ah, no, see you can :)  unless you combine it with SSP/PaX or something aiui
<bluefoxicy> ah
<Keybuk>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<bluefoxicy> sorry, I just read SSP :)
<bluefoxicy> I just woke up
<bluefoxicy> anyway.
<Keybuk> heh :p
<bluefoxicy> PaX is what's doing the randomization, I'd figure you'd have it doing ESP too.
<Keybuk> but once you've made the stack non-executable, why do you need to have your applications playing musical chairs in memory?
<bluefoxicy> the stack may be nonexecutable, but the stack frame pointer and return address can eb fucked with
<bluefoxicy> and that can allow an attacker to set up a complex pipeline of attacks i.e. fopen()->fwrite()->fclose()->mmap()->some_newly_mapped_code()
<Keybuk> I guess
<Keybuk> PIE is slow as hell though :-(
<bluefoxicy> no it's not :)
<Keybuk> (unless you own an AMD64, anyway)
<bluefoxicy> I've seen a .99% slowdown on PIE on x86
<bluefoxicy> there's one caveat
<Keybuk> you have to do about 5 instructions instead of 1 for every jmp
<Keybuk> that's a pretty nasty slowdown
<Keybuk> though it doesn't hugely affect apps that rely on shared libs a lot
<bluefoxicy> if you use -fomit-frame-pointer without PIE, you gain about 5% performance; but if you use PIE (or pic) you don't get that performance boost, PLUS you lose the 1%
<bluefoxicy> so if you rely on -fomit-frame-pointer for a performance boost on x86, you lose ~6% total
<bluefoxicy> I used nbyte benchmark to do these tests
<Keybuk> heh, I always have a giggle when I see "-O2 -fomit-frame-pointer"
<bluefoxicy> and most apps basically live in shared libs.
<daniels> Kamion: mass storage
<bluefoxicy> -fomit-frame-pointer can do neat things I hear
<bluefoxicy> remember above I said you could fuck with the stack frame pointer
<bluefoxicy> well it's not there with -fomit
<Keybuk> bluefoxicy: sure, but doing that kind of thing in a link line just shows people don't really know what they're up to :)  (-O implies it)
<bluefoxicy> -O2 implies it on amd64, not on x86
<trulux> Keybuk, PIE does not provide obscurity as you said
<bluefoxicy> but again, most apps live in shared libs
<trulux> Keybuk, PIE provides a non agressive way to make the pax aslr working without so much brainstorming
<Keybuk> bluefoxicy: depends on whether you use -g or not, etc.
<mdz> Keybuk: that's only true for architectures which can debug without a frame pointer
<mdz> of which i386 is not one
<trulux> Keybuk, and also PIE is NOT slower at all
<Keybuk> trulux: of course it is
<mdz> it is on i386
<bluefoxicy> think xmms and beep (all those decoding and vis plugins); lame and oggenc (libogg, libvorbisfile, libmad); abiword (the entire set of filters are all plug-ins); anything doing compression (zlib bzip2lib etc)
<Keybuk> mdz: sure, I may be wrong, but I'm sure gcc only omits it if you use -g
<Keybuk> we don't all have the luxury of amd64 and their fancy-schmancy pic-in-processor addressing mode :o)
<bluefoxicy> doesn't gcc even use libraries to house the code doing most of the work during compilation?
<mdz> Keybuk: I don't think -O is that smart
<bluefoxicy> mdz, trulux:  PIC is slower than fixed position code; however, all libs are PIC, and a lot of shit hangs out in libs a lot, so PIE is not noticably slower
<Keybuk> mdz: dunno, I'd have to grep the source ... it's been a while since I last looked
<bluefoxicy> it IS a bit . . well
<bluefoxicy> let's say it has some overhead.
<bluefoxicy> as for slower, I touch 100% CPU when I'm compiling and encoding shit.
<mdz> #ifdef CAN_DEBUG_WITHOUT_FP
<mdz>       flag_omit_frame_pointer = 1;
<mdz> #endif
<Keybuk> ah, not that smart then :)
<bluefoxicy> you see 0 slowdown no matter what if you're not touching the ceiling of your CPU :)
<mdz> you'll always max the CPU out, at least for short periods
<bluefoxicy> yeah
<bluefoxicy> but for realtime tasks, nobody cares
<bluefoxicy> they have to get their job done in intervals of X time constituting Y work
<bluefoxicy> as long as they can do that, there's no problem.
<bluefoxicy> hrr, switch X and Y, and that's about what the CPU graph is:  work done over time
<mdz> I don't see your point
<mdz> in realtime scenarios, it's either fast enough, or it isn't.  If you make it slower, it will sometimes not be fast enough anymore :-)
* Keybuk has had a chuckling thought ... does prelinking defeat PIE or does PIE win?
<bluefoxicy> my point is that a 1% performance hit in some fraction of a program's run-time, probably the most lightweight fraction, is in most cases essentially nothing
<mdz> a valid point, but I don't think it applies to the issue at hand
<bluefoxicy> the issue at hand being. . . I seem to have been lost.
* bluefoxicy tries to wake up but his stomach hurts, no food in it.
<bluefoxicy> sorry I only talk about one thing at a time, and tend to not notice the rest of the world while i talk to myself
<bluefoxicy> ar, hey trulux did you see my post to the dh-hackers list
<trulux> none yet
<bluefoxicy> http://sourceforge.net/mailarchive/message.php?msg_id=9923072
<bluefoxicy> that was after a 30 second glance at some documentation
<bluefoxicy> so i don't know if it's relavent at all
<trulux> ok, i'm reading it
<bluefoxicy> that'll require modifying debian/rules in the source tree, but only for packages that break.  also I didn't cover anything to handle PaX markings on the package
<trulux> ok
<trulux> that should be did by an independant package
<bluefoxicy> heh
* bluefoxicy seeks breakfast
<Keybuk> why would packages break, out of interest?
<bluefoxicy> Keybuk:  They may expect various behavior which is no longer true under PaX; or they may be buggy and collide with SSP; or they may not be PIC-aware
<bluefoxicy> for example, JIT compilers and realtime machine emulators (Qemu) will not like PaX.  They will need either to be written to be aware of PaX and use mprotect() properly, plus have the mprotect() restrictions removed (paxctl -m); or they will need PaX disabled (paxctl -psem).  If they die from ASLR (java does this), that needs to be disabled for them (paxctl -rx)
<Keybuk> see, this is the bit about all of these things that worries me -- it's very in-your-face when it goes wrong
<bluefoxicy> JIT compilers can actually function under full PaX, if written properly-- http://www.kaffe.org/pipermail/kaffe/2004-October/099938.html
<bluefoxicy> Keybuk:  The distribution maintainers can handle marking the binaries; it's a 30 second job to figure out what breaks and why, and fix it.
<bluefoxicy> I know because I used to do it.
<Keybuk> yeah, but then you're disabling the security for a particular binary or more
<Keybuk> and at that point, you have a path of attack
<bluefoxicy> yes
<Keybuk> so you may as well not apply it to any binaries
<bluefoxicy> wrong
<bluefoxicy> maybe I disable the security for something like Java
<bluefoxicy> but not for Firefox
<Keybuk> so a Java Applet viewed in Firefox can exploit your machine?
<bluefoxicy> I can be exploited by a java applet that's written to damage my JIT, but I can't be exploited by malformed HTML
<bluefoxicy> nor by libpng exploits (which are umbrellad under the PaX proteciton; java runs in a separate binary)
<bluefoxicy> so I've narrowed down the potential exploit paths
<Keybuk> my attitude to security stuff is kinda like firewalls ... I'm entirely happy all the time it sits there, stops other people from using my machine; but the second it stops me from using it, it gets switched off completely
<bluefoxicy> yes
<bluefoxicy> that's the idea here.
<bluefoxicy> I want these things to work comfortably without the user or administrator having to care.
<Keybuk> and my worry with this stuff is that everything I've seen of it suggests to me that it's going to get in a user's way
<bluefoxicy> no
<bluefoxicy> it'll provide a small consideration to the maintainers, but not to the users
<bluefoxicy> you only have to handle this stuff once
<bluefoxicy> if some program overflows a buffer by itself in normal operation, and SSP kills it, then the program gets built without SSP.  The user doesn't have to worry about it, although he may see a note made in the description about it
<bluefoxicy> (or maybe you fix the program, although that's a job for the upstream maintainers)
<bluefoxicy> If it can't build PIE, then it's built ET_EXEC, or whatever prevents it from building PIE can be disabled.  Gimp for example won't build PIE with --enable-mmx; in general, pre-optimized assembly should be avoided.
<trulux> bluefoxicy, sorry , at the point of having the jit without protection i must explain the following scenario that will make the whle heck having sense:
* bluefoxicy ?
<trulux> by that way you should also say tha unprotected libraries loaded inside protected binaries will harm the binary as they can overrride the protections of the areas that they accomply to
<trulux> and that's false
<bluefoxicy> wha?
<trulux> so, running a jave applet, first takes care inside the java sandbox
<trulux> bluefoxicy, that the binary loading the sahred object which is unprotected will be affected by the object overrided protections
<bluefoxicy> if the java bytecode is malformed, and the JIT is buggy, the bytecode may damage the JIT's internal state and allow an attacker to inject malicious code.
<trulux> yes
<trulux> but inside the memory areas under the jit control
<Keybuk> hmm, a library isn't in a separate address space
<Keybuk> if a library can't work with ssp/pax then no application that linked with it could use it either
<trulux> false
<bluefoxicy> SSP yes it can.
<Keybuk> the java_vm is run as a separate process, so in a separate address space
<bluefoxicy> PaX no
<Keybuk> bluefoxicy: how?
<bluefoxicy> SSP checks are done inline
<Keybuk> ah, so the library code simply doesn't have ssp in it?
<trulux> it depends, PaX used with bind9 will need to have an un protected lib_*_dns
<bluefoxicy> the changes don't have a global affect; they're bits of code injected into the binary
<bluefoxicy> Keybuk:  exactly.
<Keybuk> so an ssp-less library could be used to exploit a binary which used ssp?
<trulux> not
<Keybuk> why not?
<Keybuk> the library lacks ssp, so that code isn't secure
<bluefoxicy> trulux:  if libraries in the same address space need different protections, then the relieved protections must be combined to find out everything that needs to be disabled.
<bluefoxicy> Keybuk:  Yes, and vice versa
<trulux> blueYEAH
<trulux> ops
<bluefoxicy> if Mozilla is SSP, and libpng is not, then libpng can be exploited via one of those nasty buffer overflows from 2 months ago (if you haven't upgraded yet)
<bluefoxicy> and this can happen via loading a malicious web page in mozilla
<trulux> yes
<Keybuk> bluefoxicy: thus code in libpng can write over all of Mozilla's address space
<bluefoxicy> On the other hand, if libpng has SSP, and Mozilla does not, then the libpng exploits are effectively useless
<bluefoxicy> Keybuk:  correct.
<bluefoxicy> Keybuk:  do not think of programs in terms of libraries and executables
<Keybuk> bluefoxicy: but they are :p
<bluefoxicy> that's as frivilous as thinking of a library in terms of the object files used to build it
<trulux> Keybuk, just btw, what version of glibc is ubuntu running on?
<bluefoxicy> once the program is in memory, all those libraries are effectively a part of the program
<Keybuk> trulux: same as Debian
<bluefoxicy> they might as well have been compiled straight in.
<Keybuk> bluefoxicy: they're actually not
<Keybuk> they're quite separate
<trulux> Keybuk, you mean the fscking old 2.3.2-ds1 ?
<Keybuk> trulux: yup
<bluefoxicy> Keybuk:  how?
<bluefoxicy> trulux:  uh oh :)
<bluefoxicy> Keybuk:  DO NOT enable PAGEEXEC in PaX, do NOT disable the vsyscall page :)
<Keybuk> bluefoxicy: the memory image of a shared library is shared ... it's just mapped in to each app's address space at some arbitrary point
<bluefoxicy> Keybuk:  Do you understand virtual memory?
<Keybuk> bluefoxicy: yes
<trulux> Keybuk, i pray for your ass then :) take a look on our glibc , you can find it useful for looking on how we implemented some things
<Keybuk> (at least, one would hope so <g>)
<trulux> bluefoxicy, where is pspax code? (i was out some time due to school , you know...:P)
<bluefoxicy> each application is run in what looks like its own machine.  Whether the code is in a library or in the executable, shared between VM spaces or not, it's run the same way.
<trulux> bluefoxicy, it was fixed, vsyscall now works without kissing our ass so on 
* trulux grins
<bluefoxicy> trulux:  yes, in ds14 IIRC
* bluefoxicy prods emerge trying to get it to find pax-utils
<trulux> ok
<bluefoxicy> http://pageexec.virtualave.net/pax-utils-0.0.4.tar.gz
<bluefoxicy> ack
<bluefoxicy> not found heh
<bluefoxicy> http://dev.gentoo.org/~solar/pax/
<bluefoxicy> there ya go
<bluefoxicy> trulux:  pax-utils-0.0.4.tar.gz in that folder
<Keybuk> trulux: upgrading glibc has been discussed, but we've nobody on team who really follows it
<Keybuk> also Debian's isn't really as old as it sounds, it's been heavily patched without the version being incremented
<trulux> ok, thanks
<trulux> Keybuk, yes
<trulux> Keybuk, i can do it
<Keybuk> there's also the issue of it being a heavy fork from Debian
<trulux> just give me up to it and i will work on it , as i have a ready glibc
<trulux> Keybuk, hardened debian?
<Keybuk> ordinary Debian
<Keybuk> do you know why Debian still runs an older version ?
<trulux> yes, for stability
<Keybuk> are later versions buggier?
<trulux> Keybuk, not
<Keybuk> then why do Debian stick?
<trulux> because they think that them do, i mean, they suppose that later versions are later problems
* trulux smiles
<Keybuk> most of our guys are upstream too, fwir ... so surely their concerns are justified
<trulux> that's nice
<trulux> Keybuk, do you want us collaborating together? collaboration for security maybe ;-) ?
<Keybuk> define "us" ?  Personally it's not really something that excites me
<azeem> as I said before, jbailey was working on updating glibc, and he told me at least gotom was doing it at some point, too
<trulux> so?
<trulux> Keybuk, us means hardened debian people and ubuntu developers
<trulux> i have wroten some documentation on that
<Keybuk> it's not really a group I can speak for
<Keybuk> from a personal pov. I'd like to see it working to play with, as I haven't yet
<trulux> what you haven't yet?
<Keybuk> seen a *working* system with any of the "hardened" toys on it -- including SELinux
<trulux> bluefoxicy, btw, can you submit a comment to the hardened-dev-tools issue and keep in in the tracker please?
<trulux> Keybuk, i have no available boxes, i mean, opened to anybody
<trulux> but i have one that could be open for that
<Keybuk> trulux: to be honest, I'd rather it were something I had on my machine
<trulux> ok
<trulux> then i will you in that way
<trulux> sorry , help missed in the msg :P
<trulux> first you need to get the last 2.6.7 sources from our repository
<trulux> make a kernel pkg and install it , it's easy
<trulux> i haven't time do it but i can try it now, jus give me 20 minutes
<Keybuk> isn't there an APT repository?
<Keybuk> and I thought you'd said that stuff had to be recompiled?
<trulux> Keybuk, yes, but not upgraded to the last revisions of sarge's gcc
<bluefoxicy> trulux: ?
<trulux> http://d-sbd.alioth.debian.org/apt/sarge/
<Keybuk> what about for Ubuntu ?
<trulux> which gcc uses it?
<bluefoxicy> what gcc does ubuntu use?
<bluefoxicy> you should use one to compile your whole distro, not two :)
<Keybuk> 4:3.3.4-1
<Keybuk> uh, that's gcc-defaults, heh
* bluefoxicy guesses 3.4 isn't ready for x86?
<Keybuk> 1:3.3.4-9ubuntu5
<trulux> Keybuk, http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/system-dh/x86/sarge/devel/gcc/3.3.4-6/
<trulux> get them, install them and try to recompile
<trulux> tell me if you get any error
* Keybuk ^Ds (I don't have time to play at the moment)
<trulux> Keybuk, then? install the already did pkgs , but it will make you downgrade to deb's 3.3.4-6
<trulux> i think i've already said that the heck is already done :P
<Keybuk> if the gain-to-impact ratio is good, they'd make nice grumpy goals I guess
<Keybuk> I don't think we've overloaded that yet <g>
<trulux> :)
<Keybuk> do you know much about MAC as well?
<trulux> not really, i'm 15 not so time to spend , just my effort
* bluefoxicy doesn't like the idea of implementing a real MAC system for standard installs
* trulux thinks so
<Keybuk> bluefoxicy: any particular reason?
<trulux> MAC systems can be agressive to implement transparently
<bluefoxicy> added layer of complexity
<trulux> that's the point
<Keybuk> heh, isn't that the same argument against ssp/pax/pie. etc? :p
<bluefoxicy> no
<bluefoxicy> ssp/pax/pie won't cause logins as root to be inable to do anything
<bluefoxicy> mac systems normally cause root to drop caps
<trulux> yeah
<Keybuk> sure, they drop the concept of a superuser entirely in favour of giving privilege where needed
<bluefoxicy> so to get sysadmin, it's normally something like log in as sysadmin-user, activate sysadmin-role, su root
<trulux> Keybuk, DH minds in usability
<trulux> transparently....etc
<Keybuk> bluefoxicy: that's actually a pretty good UI
<trulux> Keybuk, listen
<Keybuk> "activate sysadmin role"
<trulux> DH minds in providing the following:
<bluefoxicy> Keybuk:  it would change the way the system functions though; people expect root to be able to install programs without jumping through 2 or 3 hoops first.
<trulux> a soft system , the default: PaX+PIE+file system enhanced security+other patches such as tcp stealth, etc
<Keybuk> bluefoxicy: *shrug* we've pretty much buried root on Ubuntu
<trulux> a complete system: same but using rsbac and other mac implementations such as SELinux 
<bluefoxicy> s/and/or/
<trulux> bluefoxicy, and also thinking in what consists on ;-)
<trulux> yeah
<trulux> sorry :)
<bluefoxicy> implementing a proper MAC policy would also be a load on the maintainers ;)
<trulux> ;-) lol
<bluefoxicy> a serious load, not "Oh, X broke because of Y, let's not do that then"
* Keybuk looks fondly at Fedora
* bluefoxicy does not look fondly at fedora
* trulux looks at Fedora's holy shit errors, oops, etc etc etc :P
<Keybuk> SELinux in ... SELinux out ... SELinux in ... SELinux out ... shake it all about
<trulux> shake usability in the mix
<bluefoxicy> Microhat Fedora :)
<Keybuk> trulux: but that's exactly what I'm concerned about if added security-related patches
<trulux> same as putting tabasco on your coke
* trulux grins
<bluefoxicy> I've heard that at least some of Fedora's "Security" is smoke-and-mirrors that just does nothing
<bluefoxicy> but I don't know
<Keybuk> I'm admittedly entirely biased and tainted by a bad experience of exec-shield
<trulux> me too
<trulux> Keybuk, exec shield is not the whole heck AFAIK
<bluefoxicy> ES is crap
<trulux> there are many NOEXEC implementations, btw
<trulux> ES is deprecated
<trulux> http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/
<bluefoxicy> ES is immature and the author doesn't like giving people administrative control
<trulux> so, deprecated for use, obsolete by the moment
<bluefoxicy> Ingo Molnar thinks restricting mprotect() the way PaX does (which is btw an option, and disablable per-binary) is a bad idea :O
<bluefoxicy> besides, ES is from May, 2003; PaX came from October, 2000, and has been continuously actively developed since :)
<Keybuk> so if you PaX-enable everything, nothing fails and everything still runs?
<Keybuk> no strange core dumps/bus errors ?
<bluefoxicy> the developer knows his stuff, so it's pretty much mature
<bluefoxicy> Keybuk:  not everything
<bluefoxicy> but you can easily individually protect things
<Keybuk> now you see the source of my unease ... I think "why not?  something wrong there then"
<bluefoxicy> http://d-sbd.alioth.debian.org/www/pax/pax.conf
<bluefoxicy> Keybuk:  Remember PaX changes the behavior of the system, and applications may not expect that
<Keybuk> bluefoxicy: thus something that's supposed to be entirely hidden has now become in-your-face
<Keybuk> then I argue that it's broken the system
<bluefoxicy> the user doesn't need to see that.
<trulux> yeah
<Keybuk> sure they do, they install something and it breaks
<bluefoxicy> actually
<trulux> how they install something....does not root which must do that? :P
<bluefoxicy> it's possible to configure it so that third party apps can't break
<bluefoxicy> but it's less secure
<trulux> yep
<trulux> Keybuk, think that users must NOT write executable elfs on their homes
<bluefoxicy> and requires a few more lines in the developer script.  :)
<trulux> TPE...
<trulux> ;-)
<Keybuk> hmm?  most users download shit all the time and run it
<bluefoxicy> you'd have to paxctl -PSEMR everything by default
<Keybuk> cf. the proliferation of Ubuntu installs with mplayer on them
<bluefoxicy> Keybuk:  and?
<bluefoxicy> doesn't ubuntu supply mplayer?
<Keybuk> nope
<bluefoxicy> o.O
<bluefoxicy> anyway.
<Keybuk> it's a viable package for universe, but those are still unsupported
<Keybuk> so wouldn't get the love that main does
<bluefoxicy> to ensure no third party breakage, packages would have to {paxctl,chpax} -PSEMR everything they build, except for those which break; and set PaX into softmode.
<Keybuk> "packages" ?
<bluefoxicy> but third party binaries would get no protection by default
<bluefoxicy> whatever
<Keybuk> ah, sorry, I get you
<bluefoxicy> :)
<Keybuk> so now we're at a point where to stop the system being generally unstable, we only security-enable particular binaries
<Keybuk> which is pretty much the backpedal Fedora had to do with SELinux
<bluefoxicy> Keybuk:  another issue is that once the ball gets rolling, upstream should start supporting PaX and marking things in their own debs :)
<azeem> just have a trigger in dpkg which does it for all and then blacklist the failures =)
<bluefoxicy> Keybuk:  Different.
<Keybuk> azeem: was that you volunteering to write the code? <g>
<trulux> Keybuk, one resides on role-basis protections and the other on file-basis protections
<trulux> one is transparent
<trulux> the other not
<trulux> that's the diff
<bluefoxicy> Keybuk:  It's not "certain packages," it's that all of Ubuntu's standard distribution is handled with least privileges, and third party crap is just fully privileged
<Keybuk> but it's not transparent if it causes things to break
<trulux> bluefoxicy, quote that please :d
<Keybuk> on the first core dump, it goes from transparent to totally opaque
<trulux> Keybuk, I've wroten some stuff about that
<trulux> and believe me , it's known what it breaks
<trulux> and known how to solve it
<Keybuk> so why aren't those things fixed already?
<trulux> that's an upstream q
<trulux> make it to them
<Keybuk> have the patches been sent upstream ?
<trulux> i can't be responsible of why somebody decided to make use of odd mprotect and so on calls
<trulux> Keybuk, is that our task or ours is to test it, make it and work it?
<trulux> Keybuk, i call it collaboration -smile-
<Keybuk> sure, but you can't expect upstream to know what you've done to the system
<bluefoxicy> http://d-sbd.alioth.debian.org/www/secpaper.txt  down about 4/5 of the way you'll see "A.  Manual Control", try that
<bluefoxicy> Keybuk:  the changes are very defined :)
<Keybuk> bluefoxicy: but are they defined in a mail to the upstreams of what breaks?
<bluefoxicy> Keybuk:  I think upstream would notice what major distributions have done to their systems
<Keybuk> bluefoxicy: no, they'd only notice the change whatever distribution they run made
<bluefoxicy> even when the bug reports start coming in?  :>
<Keybuk> they're just ordinary developers, they can only test and fix the systems they have immediate access to
<Keybuk> sure
<Keybuk> I get bug reports all the time
<Keybuk> they're all tagged moreinfo or worksforme
<bluefoxicy> heh
<trulux> Keybuk, stop one moment, figure this:
<bluefoxicy> Keybuk:  Well you have to start somewhere
<bluefoxicy> PaX is 4 years old
<Keybuk> usually you start asking them for intimate details of their system, to send you example files, etc. and after a few days of tennis they loose interest in helping you fix the bug
<bluefoxicy> ssp is like 6
<bluefoxicy> and people still don't consider them
<trulux> Keybuk, i don't know how to make you figuring out what *we* want to say
<trulux> they key thing is that, the problems coming forwrd when using our stuff are minimal and only related with special scenarios
<trulux> specific errors related to upstream tasks
<Keybuk> I don't believe that
<Keybuk> as I said, I'm prejudiced by bad experience
<bluefoxicy> Keybuk:  The distribution can be managed so that things don't explode along the way; but it is a crucial first step that has to be taken by *someone* before the upstream devs will start chiming in.
<trulux> i mean , modifiyng the mprotect calls to something secure and reliable under restrictive environments
<Keybuk> sure, and you're taking those steps, no?
<bluefoxicy> I'm one person, I can't get any attention.
<bluefoxicy> people just roll their eyes at me
<Keybuk> stamp on them :)
<bluefoxicy> that's what I'm trying to do
<bluefoxicy> Often physics mimic eachother in different contexts
<bluefoxicy> The greater the mass, the greater the force needed to stop it
<bluefoxicy> A handfull of users on the side won't get any attention; a major distribution will.
<Keybuk> but to get a major distribution's attention, you need more than a handful of users :p
<bluefoxicy> Yes
<Keybuk> chicken, meet egg
<bluefoxicy> I actually tried that too
<bluefoxicy> did you see my article?
<Keybuk> possibly
<bluefoxicy> http://lwn.net/Articles/106214/
<Keybuk> ah yes, that was an interesting read
<bluefoxicy> Power play:  when the masses are ignorant, they're easily controlled; when they're informed, they begin to ask questions, and begin to control you
<bluefoxicy> It's easy for a few users to get ignored; but as you pointed out, more than a handful of users will get a major distro's attention :)
<Keybuk> sure, but there's one key point you've actually forgotten
<Keybuk> let's use Debian as an example here
<bluefoxicy> That the masses don't care
<bluefoxicy> :)
<Keybuk> why do you think Debian haven't started applying these patches?
<bluefoxicy> lethargy.
* trulux smiles
<Keybuk> whose lethargy?
<bluefoxicy> it means they'd rather sleep than get work done.
<Keybuk> no, I asked *whose* lethargy ... not what is it :p
<bluefoxicy> the maintainers'
<Keybuk> ah, so this is something the Debian maintainers should do?
<bluefoxicy> sure, why not?
<Keybuk> but they know nothing about it
<trulux> false! :P
<bluefoxicy> Trulux, solar, who was that other guy
<bluefoxicy> steve kemp?
<trulux> yes
<trulux> skx
<Keybuk> if they knew something about it, and believed in it, they'd do it
<Keybuk> to use a very bad, but simple example:
<trulux> bluefoxicy, steve is on a pub
<bluefoxicy> solar offered to be a cross-distro developer and help get this stuff in debian
<bluefoxicy> trulux:  an irish pub?
<Keybuk> mail debian-devel and ask them to package a piece of software
<trulux> bluefoxicy, lol, dunno
<Keybuk> generally, the answer (unless someone likes it) will be "do it yourself"
<bluefoxicy> heh
<Keybuk> Debian pretty much operates on the basis of people doing stuff because it gives them a woody
<azeem> I thought the generally the answer is just silence :)
<bluefoxicy> XD
<Keybuk> if they've not done something, it's not because they're asleep, it's just that they're limp about it
<Keybuk> azeem: that's because everyone's bored of saying "do it yourself" mostly :)
<Keybuk> personally I find shared libraries, compilation and build systems and package management rather interesting
<Keybuk> the packages I maintain reflects that pretty well
<bluefoxicy> no one even offered up mirror space :)
<bluefoxicy> how big is ubuntu's main distribution? (not universe)
<trulux> :)
<Keybuk> I find (e.g.) kernels a bit dull; sure, they're vaguely interesting and have to be there, but I don't get excited about it enough to contribute
<Keybuk> bluefoxicy: that's somewhat assuming people *had* mirror space
<Keybuk> bluefoxicy: not huge, the desktop set is designed to fit on a single CD ... the whole main set is probably no more than twice that size in total
<bluefoxicy> it comes from somewhere; debian has 13 binary distributions scattered on how many mirrors?  Are they all at max quota?
<Keybuk> bluefoxicy: Debian is always under-hardwared
<trulux> Keybuk, http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/HARDENING?rev=1.2&content-type=text/vnd.viewcvs-markup
<bluefoxicy> heh
<trulux> :)
<Keybuk> there's several machines down, the primary webserver is massively overloaded, the security mirror is out of disk space, etc.
<bluefoxicy> lol
<bluefoxicy> screw max quota
<Keybuk> trulux: what's that to show?
<bluefoxicy> the disk just can't take it anymore
<bluefoxicy> ye cannae change the laws of physics
<trulux> Keybuk, http://ecate.tuxedo-es.org/ runs a some-old stuff of hardened debian
<lamont> bluefoxicy: ubuntu main/restricted with source was around 4GB, I believe
<lamont> with hoary bits there, I'm stting at about 8GB
<lamont> but there's a bit of universe and multiverse on that mirror
<lamont> actually, just the pool is ~5GB
<Keybuk> if you're really interested in getting Debian to accept things, you simply do them
<trulux> Keybuk, talking to me?
<bluefoxicy> lamont: no source
<Keybuk> get the patches in as a kernel-patch-blah thing, join the kernel team and help get them integrated into the kernel; join the gcc/glibc team, etc.
<bluefoxicy> anything beyond talking and thinking and playing sonic the hedgehog is beyond my skills
<bluefoxicy> *cough*lazy*cough*
<lamont> bluefoxicy: the sum of the sizes for everything in warty/main (i386 only) is 1734353352 bytes
<bluefoxicy> 1.8G of debs o.o
<lamont> bluefoxicy: in warty/main.
<lamont> i386
<lamont> *~3 for all 3 architectures, of course.
<T-Bone> lamont: dude, stage 2.2 on the go :)
* Keybuk runs off to go bump in the night
<Keybuk> nite dudes
<lamont> T-Bone: I finally wrote a script called 'iterate'. :-)
* lamont continues his love-hate relationship with Arch: all
<T-Bone> lamont: sweet! Am i a valid beta-tester? :^)
<lamont> T-Bone: it's not much of a script, truthfully
<T-Bone> lol
<lamont> 17 lines...
<lamont> the arch-all pain is that you need them there once the arch-dep packages are there, but not before.
<grok> hello all, the usb drivers don't seem to work/get loaded on warty+ G4. any ideas how to get installation going?
<grok> (usb is kinda needed for keyboard :)
<grok> wakey wakey, eggs and bakey!
<grok> well, see you later then.
<T-Bone> mdz: ping?
<Mitario> hihi
<mdz> T-Bone: pong
#ubuntu-devel 2004-11-11
<mdz> cdrecord makes baby jesus cry
<tseng> indeed.
<daniels> mdz: yes
<srbaker> anyone know a good way to tell what format a video is in?  i can't get it to play under anything i can find for ubuntu *or* windows media
<mdz> srbaker: please use #ubuntu for support
<daniels> mdz: joerg doubly so
<srbaker> whoops
<daniels> http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html
<daniels> that was the logo that won the logo contest.
* mdz 's eyes bleed
<chrisa> If that won I don't want to know what lost
<mdz> jdub: did you realize that OpenBSD is on the same release schedule as Ubuntu and GNOME?
<mdz> jdub: stockholm just pointed this out
<jdub> seriously? april/october?
<jdub> "The current release is OpenBSD 3.6 which was released Oct 29, 2004."
<jdub> hrm, wonder where their release planning pages are
<jdub> 5.1 - OpenBSD's Flavors
<jdub> There are three "flavors" of OpenBSD:
<jdub>     * -release: The version of OpenBSD shipped every six months on CD.
<tseng> i ran into theo the other day
<jdub> The OpenBSD team makes a new release every six months, with target release dates of May 1 and November 1. More information on the development cycle can be found here.
<jdub> http://www.openbsd.org/faq/faq5.html#Flavors
<jdub> hrm, always annoying when real content is stuck in a FAQ
<tseng> he is hitting up everyone about getting the wifi fimrwares opened
<jdub> and giving linus stick about it, too
<tseng> good cause
<tseng> annoying methods
<tseng> some bsd'ers dont realize that freedom isnt everyones bag of tea
<tseng> not that there arent linux/gpl zealots
<mdz> jdub: http://www.openbsd.org/faq/faq1.html#Next
<mdz> ah, you found it already
<tseng> sigh @ "breakmyubuntu"
<tseng> id rather not have my work labeled as such
<tseng> daniels: dont forget libdbus-cil :P
<daniels> tseng: haven't forgotten dbus; after I've taken care of the merge, I'll be preparing packages of CVS D-BUS with Mono support
<tseng> daniels = the man.
* T-Bone calls it a night, bye all
<jdub> brazilian-conjugate - Brazilian Portuguese verb conjugator
<jdub> ^ heh
<lamont> moo
<jdub> hrm
<jdub> so
<jdub> attempting to do XDMCP query to 192.168.10.10
<jdub> gdm wants to connect back to the Xnest on 192.168.10.100
<jdub> however
<jdub> well, it should want to
<jdub> however,
<jdub> it's attempting to connect to 192.168.10.3
<jdub> which is the access point
<jdub> rather bizarre
<jdub> works fine if i don't go through the AP
<lamont> jdub: maybe it's a "smart" AP?
* lamont watches his mirror try to play catch-up
<pasc> judging from the last time I tried to get a wireless connection at jdub's place, it's probably the neighbours' AP ;-)
* lamont finishes getting util-linux up to date.
<lamont> assuming it builds, etc
<lamont> jdub: is there a reliable way to distinguish a hoary machine from a debian machine?
<lamont> mdz: please sync debian bug #269366 to hoary
<fabbione> morning guys
* lamont idly wishes that his debian mirror would finish, so he can build and upload the postfix that the hoary upload is based on... :-)
<fabbione> lamont: i have sid here, if you want, i can upload for you'
<lamont> doen
<lamont> just needed a couple files from krb5
<fabbione> ehhe
* lamont hugs his sid-full suite
<lamont> (that's a full set of packages files, without the .debs to back them up...)
<lamont> but means that just wget'ing the.deb fixes things up quite nicely. :-)
<fabbione> eheh
<lamont> the actual mirror (dists/sid) contains a leaner, meaner, Packages.gz
<fabbione> because you do partial mirroring?
<fabbione>  /dev/vgdata/debianorg 40G   34G  4.2G  89% /mirrors/debian.org
<fabbione> i still have some space to play with
<fabbione> but i think i will kill my debian mirror pretty soon
<lamont> 2552748 /org/debian/tree
<lamont> 7655432 /org/ubuntu/tree
<lamont> not much of a debian tree, I'll admit
<lamont> esp since it has sid:i386,ia64,hppa,alpha, sarge: i386,ia64,hppa, and woody: i386, with source for all.
<Gmail> something the devel shound know:
<Gmail>  B = Before
<Gmail> E = Engineers
<Gmail> T = Take
<Gmail> A = Action
<fabbione> lamont: i only have i386 and sources for woody/sarge/i386
<fabbione> ehm... sid
<lamont> fabbione: most of my mirror is either packages for machiens that don't have ubuntu support, or packages [and their (build-)depends]  that I maintain.
<fabbione> yes..
<lamont> hrm.. interesting drive-by defining.
<fabbione> i need a full mirror for the ipv6 stats
<fabbione> all the sources and binaries are parsed regularly every day
<lamont> oh - hey... wanna see if I broke ipv6 with 2.1.5-1ubuntu1?
<fabbione> at least the interdiff between day1 and dayx
<lamont> I don't _think_ I did...
<fabbione> lamont: i am not running ubuntu on my mail server (yet)
<lamont> s/ubuntu1//
<lamont> but that'll be in the archive tomorrow
<fabbione> if it is for debian sure
<fabbione> pass it here
<fabbione> is it in incoming?
<lamont> yeah
<fabbione> ok
<lamont> I do need to go get the current ipv6 patch and merge it in,
<fabbione> jeee
<fabbione> i need to buy a dvd burner ASAP
* lamont will be where he could buy and bring in december, if that makes life easier...
<fabbione> problem is that i can't delete anything
<fabbione> not that i don't know how to use rm
<fabbione> but it's just me that can't
<fabbione> so i keep filling up tons of harddisks for crap
<lamont> fabbione: disks are cheap
<fabbione> i don't have any more space for harddisks in the file server
<fabbione> Alloc PE / Size       157367 / 614.71 GB
<fabbione> there are already 8 disks in there
<fabbione> Alloc PE / Size       2493 / 9.74 GB
<fabbione> and the system vg
<fabbione> the first one is just data
<fabbione> btw.. why did you created a _multi.changes, uploading only i386?
<fabbione> telnet ::1 25
<fabbione> Connected to ::1.
<fabbione> 220 trider-g7.fabbione.net ESMTP Postfix (Debian/GNU)
<lamont> fabbione: cool
<fabbione> lamont: try to send me a mail please
<fabbione> this morning seems to be low traffic
<fabbione> ipv4 works fine
<fabbione> i didn't receive any mail via ipv6 yet
<fabbione> it seems to be ok
<lamont> fabbione: if it's not, I'm sure I'll hear about it.. :-)
<fabbione> ehehhe
<lamont> anyway, off to bed.
<fabbione> good night
<hornbeck> has anyone seen sivang?
<bluefoxicy> tseng:  i'm going to find out where you live one day
<Micksa> is it just me or is plone/zwiki/zope slow?
<lifeless> plone and zwiki are both zope2 -- dog slow
<Micksa> are you implying zope3 isn't?
<Micksa> trying to establish if zope is worth getting into :)
<lifeless> zope3 is good crack
<Micksa> so plone on zope3 will suck much less?
<Micksa> zwiki on its own seems reasonably zippy
<lifeless> zwiki might be zope3 in fact
<lifeless> and yes, if plone is migrated to zope3, it would be faster
<jdub> it would still be zwiki ;)
<Micksa> deciding on a wiki is hard
<Micksa> for a long-term project I mean
<Micksa> I'm guessing you guys chose it for sound reasons :)
<Micksa> I think half the reason it's slow is because of the wadload of Dynamic Content that's in there by default
<jdub> mdz: ping
<cenerentola> hello pplx
<mdz> jdub: pong
<mdz> lamont: what do you mean?
<cenerentola> one thing 
<lucas_> hi
<lucas_> where can I find the sources for ubuntu's fork of debian-installer ?
<jdub> lucas_: 'branch' :)
<jdub> lucas_: it's all on the archive -> archive.ubuntu.com
<lucas_> mmh, so this is outdated : http://wiki.debian.net/index.cgi?DebianInstallerBuild ?
<jdub> lucas_: i don't know, but that's nothing to do with ubuntu
<lucas_> is there a "how to build debian-installer to put it on a custom Ubuntu CD" howto ? :)
<jdub> no
<lucas_> well, where could I find relevant info ?
<cenerentola> jdub: after installing another warty on the laptop... the first warty's grub-entry disappeared... note that the second one has its own boot partition: what should i do?
<jdub> cenerentola: best to ask these kinds of questions in #ubuntu
<cenerentola> yes but no-one excetp iz seems to be good at this kind of things
<jdub> cenerentola: many of the developers are in #ubuntu
<jdub> that's where you should ask user questions
<lifeless> someone want to tak bug #3075 ?
<Gmail> hey anyone want to add the coolest!!! WYIWYG html editor to ubuntu hoary by making a binary its called nvu from nvu.com another sponsored by linspire project
<tuo2> gah.
<Gmail> ??
<Gmail> ??
<Gmail> ??
<Gmail> ??
<Gmail> ??
<sivang> Gmail : what seems to be the problem ?
<Gmail> <Gmail> hey anyone want to add the coolest!!! WYIWYG html editor to ubuntu hoary by making a binary its called nvu from nvu.com another sponsored by linspire project
<Gmail> 1hr ago
<sivang> Gmail : you can try and create a package if you like :)
<Gmail> sivang: i am
<jdub> lifeless: it's being rewritten upstream
<lifeless> jdub: its the category it was filed against I was more amused by.
<lifeless> someone filed it against bazaar.
<jdub> yeah
<jdub> weird
<jdub> just saw that
<jdub> https://bugzilla.ubuntu.com/show_bug.cgi?id=3075
<jdub> fixed
<lifeless> thanks!
<vinsci> the teams page doesn't mention a web team - is there one?
<Keybuk> morning Tollef
<lifeless> Keybuk: 'baz switch' implemented.
<uma> moind
<Mithrandir> hi Keybuk
<trulux> hey
<trulux> hey Keybuk 
<Gmail> I FUND THE BEST SOFTWARE EVER!!!!!!!!!!!!!!
<Gmail> http://www.molesoftware.com/www/index.php
<Gmail> it should be in ubuntu if ubuntu is going to be a server distro
<Gmail> it the coolest and OSS
<cenerentola> NO MORE STUPID QUESTION IM A NEW PERSO
<cenerentola> N
<bob2> erm, ok
<cenerentola> bob2: how r u doing?
<bob2> i am good thx
<zul> ah...okie dokie
<sivang> Anybody can shoot at me the directory under which the trash files reside?
<sivang> I have reason to believe that some files were not deleted from my system, although the trash:// applet seems empty
<plovs>  ~/.Trash/ ?
<plovs> anybody able to login to the wiki? seems authentication stopped working
<hornbeck> I cannot get in either
<Mithrandir> mdz: what's the procedure for bugs like 3032 which is now fixed in sid -- request sync or just close the bug?
<Keybuk> that one needs merging
<Keybuk> http://people.ubuntu.com/~scott/merge/review/qt-x11-free/
<Mithrandir> ok, and for for, who still isn't up-to-date wrt mail, that means I should do what?  Review the patches and upload manually or request sync?
<elmo> if there are outstanding ubuntu changes, merge them and upload - if there's none and the package should be reverted to sid, mail/irc me
<Keybuk> http://people.ubuntu.com/~scott/merge/README  explains what the .dropped and .patch files mean
<Keybuk> basically stuff in .dropped is Debian changes that couldn't be merged
<Mithrandir> ok, and we don't care about changelogs and such?
<Keybuk> yeah, try to fix the changelog -- otherwise next time we merge it's even harder
<Mithrandir> (so if the changes in code has been merged, no point in dragging the historical changelog patch along)
<Keybuk> no, really please put the changelog back together
<Keybuk> <debian pre-warty changes> <warty changes> <debian post-warty changes> <hoary changes>
<Keybuk> is the order we've used
<Mithrandir> ok
<Keybuk> other than that, it just looks like you need to fix debian/patches/00list
<Keybuk> and change that _warty.patch and _hoary.patch are roughly equivalent
<Mithrandir> ok, but I'm trying to understand the general concept here. :)
<lamont> mdz: ECONTEXT
<Keybuk> Mithrandir: we changed qt-x11-free ... we need to catch up with Debian and keep our changes
<Keybuk> basically
<Keybuk> the automagic merge script couldn't quite do that one by itself
<Mithrandir> ok
<T-Bone> lamont: got a few more "weird hangs" today in stage2.2 -> courrier
<Keybuk> how did I just get a "NEW" for a package LaMont filed a FTBFS on me for?
<Keybuk> automake1.9_1.9.2-1ubuntu1_source.changes is NEW
<Keybuk> vs. #3021
<fabbione> mdz: can we import http://freedesktop.org/bugzilla/show_bug.cgi?id=1744 ?
<fabbione> this is a possible show stopper to package X.org at the moment
<fabbione> it could break the hell out of ubuntu
<fabbione> (given that i am correct)
* fabbione goes off again
<mdz> lamont: <lamont> mdz: please sync debian bug #269366 to hoary
<mdz> fabbione: we have no means to import Bugzilla bugs at the moment
<mdz> you can file a bug with a hyperlink
<Keybuk> grepmap.c:136: warning: string length `679' is greater than the length `509' ISO C89 compilers are required to support
<Keybuk> boo
<Keybuk> hiss
<plovs> any www.ubuntulinux.org admins awake? wiki dows not allow logging in
<sivang> plovs : yes it doesn't :(
<plovs> sivang, btw thanks for the sambahowto windows domain stuff (in advance)
<sivang> plovs : no problem, I have a freind who is running an NYC IT Based consulting company, I will be using him for that :)
<plovs> sivang :)
<elmo> please try the wiki now?
<hornbeck> I just set up samba off that tutorial
<hornbeck> nice stuff worked right away
<sivang> hornbeck : samba is a way cool project :)
<hornbeck> yee, the wiki is back
<hornbeck> sivang: yes it is
<plovs> ok!
<hornbeck> back to work
<sivang> wiki is back? Yeeeha!
<hornbeck> anyone want to host the inotify kernel for me?
<hornbeck> It has killed my blog
<hornbeck> people are downloading the crap out of it
<hornbeck> plovs: great bootup howto
<plovs> :)
<plovs> hornbeck, ask tseng he has lots of mono stuff anyway
<hornbeck> ok, I have to find something
<hornbeck> as of right now it is down, for at least two days, and so is my blog
<plovs> hornbeck, how big is it?
<hornbeck> hmmm, don't know
<hornbeck> the size of the regular kernel
<plovs> hornbeck, too big to put it in the wiki then :(
<hornbeck> it is the same as the normal i386 kernel cept with inotify built in
<hornbeck> yes, to big
<plovs> ask for a folder on canonical
<plovs> like tseng and piti
<hornbeck> who would I ask?
<plovs> asdfl or mdz
<hornbeck> ok
<plovs> i suppose
<plovs> or ask louise on our list
<lamont> Keybuk: Either I grabbed source for debian, or the binaries weren't known to our katie. don't remember which
<lamont> cd debian/autodiff-new && aclocal
<lamont> /bin/bash: line 1: aclocal: command not found
* lamont giggles and points at emacs21
<Keybuk> missing build-depend ?
<lamont> prolly
<hornbeck> plovs: is there a way to get around the empty sections in ReST
<sivang> hornbeck : you created a package for the inotify built kernel?
<hornbeck> yeah
<plovs> hornbeck, make them unempty
<hornbeck> it is available on the beagle page
<hornbeck> plovs: I want two headers. One right after the other
<plovs> use different markup, just a sec...
<plovs> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#sections
<hornbeck> I fixed it
<hornbeck> https://www.ubuntulinux.org/wiki/LearningUbuntuChapterTwo
<hornbeck> look at that, is that a good starting point
<hornbeck> it is from the website
<hornbeck> plovs: where are you storing the pictures for the wiki
<plovs> just in the root
<lamont> Keybuk: linda is also pissed on i386.
<lamont> but only i386, which kinda points at arch:all stuff
<plovs> hornbeck, add new content
<hornbeck> ahhh
<hornbeck> ok
<Keybuk> lamont: *sigh* Debian and their allergy to correct build-depends
<lamont> Keybuk: I think it's more clue factor
<lamont> actually, I think linda may be arch all.
<mdz> linda is arch all
<mdz> (python)
<hornbeck> mdz: is there a way for me to get a folder to host files for ubuntu?
<mdz> hornbeck: large files or small files?
<hornbeck> about 30 megs or so
<hornbeck> a kernel image
<hornbeck> my host is dead because the kernel image has become popular
* mjg59 goes back to try one more thing on the Craptop
<Kosai> mjg59: No luck so far?
<hornbeck> mdz: the kernel image is 14M
<mdz> hornbeck: if it's just a one-time thing, I can put it up for you in my home directory
<hornbeck> mdz: I am not sure if I will need to make other files soon
<hornbeck> I will find something
<hornbeck> I am looking at building beagle packages
<mdz> hornbeck: is this for inotify?
<hornbeck> mdz: yes
<hornbeck> I have a link to the kernel on the beagle howto page and the kernel is getting downloaded a ton
<mdz> hornbeck: give me a URL and I can put it up someplace for you
<hornbeck> I only have it local now
<hornbeck> my host shut me off
<hornbeck> bastards took my blog down to
<mjg59> Kosai: Haha. No.
<Kosai> Aww.
<plovs> hornbeck, i try to save my pics as Pic... so it easier to find them later
<hornbeck> plovs: ok
<Keybuk> I swear, Lintian is on some serious crack today
<Keybuk> wartylog: grepmap source: changelog-should-mention-nmu
<Keybuk> wartylog: grepmap source: source-nmu-has-incorrect-version-number 0.1.0-1
<Mithrandir> Changelog maintainer != control file maintainer?
<Keybuk> nope, identical *shrug*
<Mithrandir> then it's on crack.
<Keybuk> ahh
<Keybuk> stray space on the end of the line in control
<Mithrandir> sounds like a bug -- whitespace is not important in rfc822 addresses
<Keybuk> right, dinner time
<mjg59> Gah. Fuck. Right, that makes no difference.
<mjg59> It must be something fundamentally wrong in the ACPI implementation, but I have no idea what.
<nictuku> hi
<nictuku> I dont understand. was #1608 fixed in Warty final?
<nictuku> I had problems with that.
<mdz> nictuku: it was fixed, and then unfortunately un-fixed
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=2773
<nictuku> :)
<mdz> hornbeck: the patch will go into hoary in the near future anyway
<Kyaneos> hi
<hornbeck> mdz: that is hoary though
<hornbeck> for people to use beagle now they need inotify
<enrico> Hello.  There's some interest in the doc group to try out some arch.  I still haven't clear how repositories work in arch, but would it be possible to have an arch playground we could use to practice a bit with it before we start doing community editing of big documents?
<hornbeck> arch would be good for the Learning Ubuntu book
<hornbeck> for the docbook part of it
<mdz> hornbeck: I don't follow
<mdz> hornbeck: what is hoary?
<hornbeck> mdz: you said that inotify was going into Hoary
<hornbeck> mdz: I was saying yes, but it was going in Hoary and not Warty
<hornbeck> mdz: I had that package so people could use beagle now with Warty
<mdz> hornbeck: your package is not going into warty, either
<hornbeck> mdz: I know, but I was hosting so people could use it
<hornbeck> hmm, I think something is missing here
<mdz> hornbeck: they could also use the hoary package, which we host
<hornbeck> mdz: ok
<hornbeck> mdz: I was just responding to your comment to me above :-)
<mdz> for now, at least. at some point in the future, the hoary kernel may no longer be installable on warty
<enrico> Ok.  No answer about my arch question.  Could someone please tell me where to ask instead?
<hornbeck> mdz: I was just trying to help people with using beagle
<mdz> enrico: the beauty of arch is that it's decentralized.  anyone who wants to try it out can set it up on their own
<enrico> mdz: yes, but how does it work when you want to put the results together?
<hornbeck> mdz: I get a ton of email everyday about the beagle howto and I know they all used the kernel I was hosting
<mdz> enrico: it works
<enrico> mdz: how?
<hornbeck> mdz: I was just looking for a new place to host it and I was told to as you
<mdz> enrico: http://www.gnu.org/software/gnu-arch/tutorial/arch.html
<mdz> enrico: http://mail.gnu.org/archive/html/gnu-arch-users/2003-09/msg00034.html
<enrico> mdz: I mean, do you need a central repository somewhere, or you do some peer-to-peer swap of patches, or 
<mdz> enrico: those are two good starting points fo rarch
<mdz> for arch
<enrico> mdz: ok.  Besides tutorials, you mean that if we want to have a playground somewhere we have to set it up in some machine of ours?
<mdz> enrico: an arch archive is just a directory tree, there is nothing to set up
<mdz> you just make it available via http
<enrico> And how do you write in it? DaV?
<mdz> that is one option, yes
<hornbeck> mdz: I think he was wanting something within the ubuntu servers
<mdz> enrico: to answer your question, #arch is the place to ask general questions about arch
<mdz> hornbeck: I know, and I am explaining that it is not necessary.  this is a fundamental difference between arch and (e.g.) CVS which is not obvious at first
<hornbeck> mdz: ok
<enrico> mdz: so, we don't need any central place to do group work on something 
<enrico> mdz: it's supposed to just work
<hornbeck> enrico: I am looking at hosting right now
<hornbeck> enrico: if need be I will set up a host for it all
<enrico> hornbeck: you mean, a private hosting for yourself?
<hornbeck> enrico: yes, but i could set up the central place for the doc team
<hornbeck> if it is needed
<enrico> According to the mail mdz just posted a link to, people pull changes from each other's trees
<enrico> Which would mean that people should have a tree available via http
<mdz> right
<mdz> you could decide that one of them is the "official" mainline
<hornbeck> I guess I will have to read on that
<hornbeck> mdz: would you not have to still have a web hosting than?
<mdz> and collect patches from everyone into that
<enrico> mdz: if people don't have a permanent http connection, I imagine people can have an official tree somewhere
<hornbeck> so others could get to it
<mdz> hornbeck: you need some means to transport the patches to others, yes
<hornbeck> ok
<mdz> if you expect to share them
<enrico> mdz: I mean, having a public web server could be quite a high requirement on people
<hornbeck> right
<hornbeck> enrico: I will host a central place for patches once i find hosting
<hornbeck> this crap is expensive :-)
<mdz> enrico: you have a long way to go with arch before you get to that point, and you could very well decide that it does not meet your needs
<mdz> enrico: the first step is to start using arch on your own, and then later, if it becomes a part of the way that you work, we can decide on a hosting arrangement if needed
<enrico> mdz: I see.
<hornbeck> mdz: what we are needing is a place for people to place files and be able to all work on them
<hornbeck> mdz: I guess like cvs
<moyogo> is there a way to switch locale without login out?
<moyogo> globally i mean
<hornbeck> there are a couple bigger files we have been emailing back and forth
<mdz> arch is very much overkill as a file sharing mechanism, even more so that CVS is
<mdz> moyogo: #ubuntu is the place for support
<moyogo> mdz: sorry, and thanks ;)
<hornbeck> mdz: we have directories of stuff to be worked through
<hornbeck> such as the gnome2-user-manual
<hornbeck> also the "Learning Ubuntu Linux" book that is being worked on
<enrico> mdz: well, I'll try and create an arch tree with some document, then I'll try and put the tree in some HTTP server for people to add something to it
<enrico> mdz: does it sound like a good approach for trying out some cooperative document writing?
<enrico> mdz: (where "add something" means pull the tree and add something locally)
<mdz> enrico: my honest opinion is that arch will not be suitable for you at this time
<enrico> mdz: you mean, we should stick to the wiki?
<mdz> enrico: where possible, yes  but obviously that won't work for things like the gnome2-user-manual
<enrico> mdz: so, what do you suggest for that instead of arch?
<hornbeck> mdz: we are going to start working on alot of bigger offline docs
<mdz> enrico: I don't know of anything which would be a very good solution
<hornbeck> cvs?
<mdz> when working on documentation, it is important for the barrier to entry to be low
<hornbeck> that is what gnome uses for those same docs
<mdz> are you going to require everyone who might work on documentation to learn CVS?
<enrico> mdz: subversion, then
<Clint> ugh
<enrico> mdz: we're talking about big documents, which can have a sligtly higher barrier.  Subversion is currently the VCS with the lowest barrier
<mdz> enrico: do you find subversion easier for non-technical users to learn than CVS?
<enrico> mdz: yes, so far
<Clint> How peculiar.
<mdz> I find it rather more complex
<mdz> but I haven't tried rapidsvn
<enrico> mdz: did you have different experiences?
* enrico doesn't want to start a flamewar
<hornbeck> cvs is not that hard
<mdz> it seems that what you want is like a whiteboard
<hornbeck> a small tutorial for how to make .diff's than send them to the -doc mailing list would not be hard for someone to learn
<mdz> where CVS is a filing cabinet
<mdz> subversion is a database
<enrico> Thing is, we were talking about doing group writing, and for big documents we put off both wiki and all version control systems.  Either someone has other suggestions, or I'm fine with the discussion
<mdz> and arch is a global satellite telecommunications network
<Clint> Other than lack of documentation, I don't see why Arch is more difficult to learn than CVS/Subversion
<Clint> especially for everyday tasks
* mdz gapes
<Clint> at least with tla
<mdz> arch brings experienced developers, familiar with revision control, to tears
<Clint> not for simple things like 'update', 'commit', 'add', 'rm'
<enrico> Ok, thanks for the help, we'll manage by ourselves.
* hornbeck will setup our own cvs server for us to work with
<Clint> and there's all kinds of wrapper programs and guis to simplify stuff for people
<mdz> even for simple things
<mdz> enrico: why not try something and see if it works?  I do not have a perfect solution prepared for you
<nictuku> what kind of "bugs" are supposed to go into the errata site section?
<Clint> mdz: if I give you instructions on how to check out the "HEAD" of a repo, make some changes, and generate a diff to send upstream, it's going to be basically the same few lines adjusted for the syntax of the three revision control systems being discussed
<mdz> nictuku: TBD
<enrico> mdz: I wasn't looking for the perfect solution.  However, I didn't really like the mood of a "there isn't anything out there for you".  But maybe today I'm not in a good mood.
<Clint> enrico: try Arch and see what problems you have with it
* enrico beats Clint with a 243 characters long commandline :)
<Clint> hush, that's what tab-completion's for
<lamont> Clint: shame shell tab comletion and arch don't agree on what to do with some of the special characters..
<nictuku> what is the Right Way to go and translate installer dialogs? Go translate upstream and wait ubuntu to get that fresh code, or what? I'd like to create a wiki page about this subject.
<Clint> lamont: what problems do you have?
<nictuku> closest information about that I found was http://lists.ubuntu.com/archives/ubuntu-translators/2004-October/000014.html
<lamont> Clint: use bash, and tab-complete an archive name
<lamont> @ really causes, um, issues
#ubuntu-devel 2004-11-12
<Clint> lamont: I would have thought that with bash you'd be used to all kinds of problems. :)
<lamont> Clint: feh
<Clint> but seriously, zsh doesn't have that problem
<lamont> no, it has it's own set.
<Clint> hmm
<lamont> on a different note...
<lamont> wifely one wants an address label management program...  what's a good one, preferably from main?
<jdub> lamont: glabels
<jdub> not in main
<lamont> jdub: thanks
* lamont watches ia64 chunk along
<lamont> jdub...  I want to give it an address book and print address labels from same...
<jdub> i think glabels does that
<lamont> very well may
<lup|strebe> an app in C or python using pygtk
<lup|strebe> does that make a big difference in the resources it will use
<lup|strebe> and the speed
<lamont> jdub: I can't seem to find a place to import an address book into glabels...
* lamont reads the docs, gets closer
<jdub> http://home.comcast.net/~plinius/fbui.html
<jdub> boggle
<lamont> jdub: thanks - figured it out... now to educate the wife...
<lamont> can I get evo to export an addressbook in csv?
<jdub> lamont: hrrmmm, dunno
<srbaker> jdub, that's sickening.  but somehow cool
<hornbeck> jdub, mdz: was a process ever decided about how to become a ubuntu maintainer?
<lamont> jdub: sick but, um, interesting.
<jdub> hornbeck: not yet, no
<hornbeck> jdub: ok, thanks
<jdub> 'coming soon'
<hornbeck> good deal, I am interested
<lup|strebe> jdub wouldn't it be a good idea to rewrite some of the default gnome apps in a higher programming language
<lup|strebe> for example gftp in python
<mjg59> Generally, rewriting software is a bad thing
<lup|strebe> not rewriting I mean replacing it
<lup|strebe> with a program that has the same functions
<jdub> that means rewriting :)
<mjg59> Would the application be any better as a result?
<jdub> only subtly different
<jdub> yeah, that's rewriting
<jdub> only subtly different :)
<lup|strebe> I think the code will be easier 
<jdub> lup|strebe: users won't care ;)
<mjg59> So you end up writing something that behaves slightly differently, and so cause people to have to learn how to use it again
<mjg59> In the process, you probably end up with about as many bugs as have already been fixed in the application you're reimplementing
<mjg59> Sometimes, this is worth it - Sawfish needed a replacement writing because nobody could maintain it
<mjg59> But there's no real shortage of people who understand C well enough to work on bugs in things like gftp
<lup|strebe> gftp misses a lot of features I would expect from a ftp client
<mjg59> That's an argument for improving gftp
<lup|strebe> plus when you can use the default python modules for ftp, ssh, kerberos and proxy
<mjg59> But, uh...
<lup|strebe> you have a lot of less code to maintain so it becomes easier to add new stuff and improve stuff
<lifeless> anyone here that knows dpkg pre-version number rules off-hand ?
<mdz> lifeless: the version number comparison rules are documented in the policy manual
<jdub> Intel 810 + AC97 Audio, version 1.01, 14:29:58 Oct 12 2004
<jdub> ACPI: PCI interrupt 0000:00:06.0[A]  -> GSI 20 (level, high) -> IRQ 193
<jdub> PCI: Setting latency timer of device 0000:00:06.0 to 64
<jdub> i810: NVIDIA nForce Audio found at IO 0xd800 and 0xd400, MEM 0x0000 and 0x0000, IRQ 193
<jdub> 
<jdub> does that ACPI line seem bong?
<jdub> 193:        116   IO-APIC-level  ehci_hcd, NVIDIA nForce Audio
* jdub is trying the oss module for fun
<jdub> given that the alsa ones stopped working
<justdave> mdz: assignment to amu on 3101 was a typo in the javascript dealing with the livecd stuff.  just fixed it
<justdave> had an = where it should have had an ==
<mdz> justdave: oh, thanks. I assumed the submitter had inadvertently typed something in the field
<jdub> justdave: can we get the component popup to go away when pressing enter?
<jdub> it is hard to enter 'linux' for example, given the number of linux... packages
<jdub> mdz: the discover initscript stays with that upgrade] 
<mdz> jdub: the init script stays, but the links go away
<mdz> jdub: it's a conffile and could have been customized; we can't throw it away
<jdub> ahr
<jdub> shouldn't matter on warty->hoary upgradew
<mdz> the script was there in warty too
<jdub> oh
<jdub> just no links?
<jdub> makes sense
<mdz> right, same story
<mdz> it's no longer part of the package in hoary
<mdz> maybe we can even get rid of the package for hoary
<mdz> fabbione: what do you say? :-)
<jdub> heh
<justdave> jdub: yeah, I can try
<jdub> thanks
<jdub> justdave: oh, status of advanced mail headers (like gnome's)?
<lifeless> mdz: yes they are, but I know that ~ is supported by dpkg, and policy didn't mention it last I looked.
<justdave> jdub: I thought you were talking about getting the product and component listed in the email (it does that now)
<justdave> unless that's what you meant.  did you want extra headers, too?
<jdub> justdave: gnome's bugzilla provides heaps more
<jdub> X-Bugzilla-Product: metacity
<jdub> X-Bugzilla-Component: general
<jdub> X-Bugzilla-Status: NEW
<jdub> X-Bugzilla-Priority: Normal
<jdub> X-Bugzilla-Severity: enhancement
<jdub> X-Bugzilla-Target-Milestone: future
<jdub> X-Bugzilla-Reason: CC
<jdub> X-Bugzilla-Version: unspecified
<jdub> 
<justdave> ok, product, component, and reason can go in now, with just config changes.
<justdave> the rest will take code (but not much)
<jdub> sweet!
<justdave> product/component are in.
<justdave> I'll get the others on the next update I push
<jdub> rocking, thanks
<jdub> what do you think about universe as a separate component?
<jdub> er
<jdub> product
<lifeless> mdz: and I just checked again. policy doesn't mention ~. lintian complains about ~, but dpkg knows about ~.
<jdub> careful typing ~. there ;)
<jdub> we should develop some spec that makes it very hard not to explain things starting with ~.
<lifeless> ~. could be a problem, yes :)
* jdub washes that arch developer right out of his hair!
<jdub> if tom didn't like openssh he would've done that by now ;)
<lifeless> lol
<pasc> lol
<lifeless> hey pasc.
<pasc> hey lifeless 
<lifeless> hows moi paperwork ?
<pasc> well I've just figured out something
<lifeless> tried baz yet ?
<justdave> universe as a product might be confusing...  since hoary could conceivably have stuff in main that's in universe in warty, etc.
<pasc> lifeless: I haven't looked at what it doesn't differently to tla, so no... haven't tried it
<pasc> however, in "http://lists.debian.org/debian-newmaint/2004/02/msg00010.html", tbm says elmo prints out reports to process them. I reckon that's the problem now. If you guys forced elmo to commute, he'd have time to read those reports again. ;-)
<jdub> justdave: oh
<jdub> justdave: good point
<lifeless> pasc: its not a problem for me... until he's got the report!!!!
<jdub> pasc: haha
* lamont looks hard at cyrus-sasl2, crys
<lamont> cries, even
<mdz> lifeless: that's exactly the state of ~ at the moment :-)
<lifeless> mdz: ah. does aptitude handle it ?
<mdz> lifeless: it's been implemented in the tools, but is not recognized by policy, and thus hasn't really been used or tested at all in the real world
<mdz> lifeless: aptitude uses libapt, so yes
<lifeless> cool. ok, I'm gonna use it :).
<lifeless> for the auto-builds of baz
<mdz> what if someone wants to package them for Debian? ;-)
<lifeless> then they will have a different number anyway.
<lifeless> (in point of fact, asuffield is already packaging baz)
<jdub> lifeless: INTERESTING
<lifeless> dunno if hes going to ITP and put it in the archive, but hes updating his build stuff, and was muttering about daily builds
<lifeless> /home/robertc/irclogs/irssi-2004-10-29:16:10 #arch: < asuffield> dpkg-deb: building package `bazaar' in `../bazaar_1.1-1~20041029-1.canonical_i386.deb'.
<mdz> lifeless: did you ask him why he hasn't updated tla in Debian?
<lifeless> mdz: whats the current version in debian ? 1.2 or 1.2.1 ?
<mdz> lifeless: 1.2
<mdz> you filed an Ubuntu bug saying it was too old
<lifeless> thats because 1.2.1 sucks in a couple of key ways, because tom /didn't release what jblack prepared/
<lifeless> 1.2.2 would have fixed that, but some process difficulties cropped up leading to it not every going gold, and tom is now working on 1.3, planning a beta in a week or so.
<lifeless> baz, right now, is >> tla 1.2.2 and >>>> tla 1.3
<lifeless> bug #3103 - another missassigned to bazaar
<lifeless> because I *care* about dell laptops
<fabbione> morning guys
<jdub> yo fabbione 
* lamont grumbles more at the gnutls1[01] -dev b0rkage
<lamont> (specifically that gnome build-depends on both :(
<jdub> heh
<fabbione> jo jdub
<fabbione> jdub: we might have a showstopper for X.org
<jdub> oh?
<fabbione> i already involved upstream
<fabbione> it's an API/ABI change in a library that has not been handled properly
<fabbione> quite a bunch of packages depends / build-dep on it
<jdub> xaw?
<fabbione> no xrender
<fabbione> xaw has a new version with new soname
<fabbione> so now we will ship xaw6 7 and 8
<fabbione> but Xrender is a bit of an issue
<jdub> yeah
<jdub> did it change in 6.8 or 6.8.1?
<fabbione> jdub: 6.8.1 afaict
<jdub> with lots of internal dependencies on the change?
<fabbione> jdub: no it's a new implemented function
<fabbione> but they didn't rename the lib
<fabbione> nor bumped the soname
<jdub> can we ignore that change?
<fabbione> no
<fabbione> X.org is a FTBFS without it
<jdub> yeah, so there is an internal dependency :)
<fabbione> jdub: X.org as monolithic tree has no problems.
<fabbione> the issue is the releation to this library
<fabbione> i hope that Keith P. will answer my bug asap
<jdub> ok, why is there an FTBFS without it?
<fabbione> jdub: it's complicate dependency to explain
<fabbione> basically xrender is shipped outside the monolithic tree
<fabbione> because Keith always released it outside
<jdub> mmm
<fabbione> the last release he did was 0.8.4
<fabbione> and in the monolithic tree
<fabbione> there is a differen 0.8.4
<jdub> bong
<jdub> bong bong bong
<fabbione> jdub: so the problem for us is to do a xrender transition in a sane way
<jdub> yeah
<jdub> and xorg doesn't like keith's xrender, right?
<fabbione> xrender is maintained by keithp, both inside and outside x.org
<jdub> i know
<fabbione> x.org doesn't like the external one
<jdub> yes
<jdub> ok
<fabbione> if keithp doesn't come back to me soon i will have to handle it together with OVerfiend/Debian
<fabbione> we can't break binary compatibility for these applications that use Xrender
<jdub> yeah
<jdub> have you checked how red hat's dealt with it in FC3?
<fabbione> jdub: no
<fabbione> because iirc they don't ship several packages
<lamont> night all
<fabbione> they have one big xorg rpm and that's it
<fabbione> night lamont
<jdub> fabbione: they still have the same problem
<fabbione> not necessarely
<fabbione> shipping the internal version and recompile *
<fabbione> is like fixing it
<fabbione> but not in the right way
<jdub> yeah, but acceptable in non-enterprise-don't-rely-on-this fedora
<jdub> grr ;)
<fabbione> yeah
<fabbione> today daniels should arrive too
<fabbione> i can press him to fix it upstream :-)
<jdub> ;)
<fabbione> he will be my direct upstream bitch^Wlink ;)
<fabbione> anyway other than this the situation looks good
<jdub> you have unnatural control
<fabbione> i know
<fabbione> in a range between 0 and 10 you can consider me as an 11
<fabbione> UHA UHA UHA
<fabbione> does anybody remember where the .shlibs file format is described in details?
<mdz> fabbione: isn't it in the policy manual?
<fabbione> oh yeah
* fabbione needs to drive gf to work
<fabbione> later
* jdub uploads to warty-updates instead... 8)
<hypa7ia> whoa someone awake
<hypa7ia> :-)
<jdub> there's almost always someone awake here
<hypa7ia> whoot
<hypa7ia> so i want to get involved in ubuntu, specifically with laptop support
<hypa7ia> what would be a good first step (beyond ridding my machine of the foul pestilence that is fedora, of course)
<jdub> identifying improvments that would help battery life
<hypa7ia> si
<jdub> turns out there's a bunch of patches to the kernel that help
<jdub> which paul drain (ultrafunk) has been looking at
<hypa7ia> kay, good to know
<jdub> and there's something on the system causing regular disk accesses
<jdub> which is not good for battery life
<jdub> (and it's not just ext3)
* hypa7ia nods
<jdub> hrm
<jdub> maybe look at the hoary feature goals wiki page to see what you can help with
<hypa7ia> coolcool
<jdub> can't think of anything else off-hand
<hypa7ia> reading the wiki page on warty laptop support ATM
<hypa7ia> would you recommend upping to hoary right away, or playing with warty for a bit first?
<jdub> depends on how familiar with debian you are
<hypa7ia> i've been running sarge one one machine for 2 months.  was a mac os x user for 2 years before that
<hypa7ia> so i'm a bit of a n00b
<hypa7ia> but a very committed one :-)
<jdub> hoary is going to be fairly rocky for a while
<hypa7ia> *nods*
<jdub> but it's pretty sane atm
<hypa7ia> whoot.
<hypa7ia> i think i'll wait a month then
<hypa7ia> just in case.  being a noob and all.
<hypa7ia> :-)
<hypa7ia> i have all sorts of fun unsupported or marginal hardware too :-)
<hypa7ia> and new stuff
<hypa7ia> it's all very exciting :-)
<jdub> elmo: ping
<jdub> elmo: whenever you get up, please take a peek at warty-updates -> would like to avoid fifty seven million questions about where the november package is. i'll do this when you're around next time. :-)
<doko> morning
<mvo_> hi doko 
<doko> hi
<netfighter> Quick question, do u guys know if the logo is licensed under the GFDL or GPL?
<jdub> netfighter: it's not
<jdub> netfighter: usage guidelines will be released soon
<netfighter> oh thanks
<pasc> jdub: and when are the t-shirts coming out?
<pasc> ;-)
<jdub> dunno, not sure why the competition hasn't been announced yet
<doko> lamont: around?
<pitti> Morning, guys!
<pitti> mvo_: Welcome to the team!!!
<mvo_> thanks pitti :-))
<mvo_> can we mark bugs as "hoary only" in bugzilla?
<pitti> mvo_: not really
<pitti> mvo_: but as long as they are not critical, they are not fixed for Warty anyway
<mvo_> pitti: thanks
<lifeless> who would liek this bug ?
<lifeless> https://bugzilla.ubuntu.com/show_bug.cgi?id=3103
<daniels> lifeless: RESOLVED/INVALID
<daniels> if your video card is that stupidly bong, not my fault
<lifeless> daniels: its on the wrong product dude.
<lifeless> its not a bazaar bug.
<daniels> i'll take it
<jdub> mvo_: target HoaryHedgehog
<jdub> mvo_: if that's appropriate
<mvo_> jdub: thanks
<jdub> mvo_: but there's no distro version setting
<thom> morning
<mvo_> hi thom 
<daniels> thom: morning sunshine
<Micksa> grah
<thom> daniels: if i throw rocks at heathrow, might I hit you? :-)
<Micksa> on what grounds was zwiki chosen as the site's wiki software?
<daniels> thom: if you aimed for t4, yah
* daniels waves in the general direction of Cockfosters.
<sparkes> hornbeck, are you around or is it past bedtime over there?
* daniels -> cph.
<jdub> #3117 -> eeek!
<sparkes> hornbeck, when you wake up drop me a line and I will sort out a new home for your blog
<mvo_> can someone sponsor a new synaptic upload? packages are at: http://people.debian.org/~mvo/synaptic/warty/0.55/
<thom> jdub: that's a fantastic bug
<tuo2> Cockfosters?
<Mithrandir> tuo2: the end station of one of the tram (or tube) lines in London.
<tuo2> really? And there I was thinking it was just another name for that godawful beer.
<tuo2> :
<tuo2> )
<Mithrandir> what beer?
<thom> tuo2: well, Fosters is Cock, definitely
<thom> but not the same thing :-)
<tuo2> heh
<tuo2> :)
<pitti> mvo_: just back from breakfast; your key is not in the upload keyring yet?
<mvo_> pitti: I don't think so, got no mail from elmo about it yet 
<pitti> mvo_: okay, I'll upload it 
<pitti> mvo_: your email address in the changelog is invalid
<mvo_> pitti: mvo@debian.org, sorry
<pitti> mvo_: did you already upload this into Debian?
<mvo_> pitti: not yet, I will soon
<pitti> mvo_: it has no Ubuntu specific version number, so it should rather be synced from Debian
<mvo_> what's the policy about the version in this case?
<pitti> mvo_: okay, please ask elmo to sync it when it is in sid
<mvo_> pitti: ok
<Keybuk> ubuntu-calendar (4.11) warty-updates; urgency=low
<Keybuk> hmm...  so the only people who'll get a calendar update is those that have psychically guessed they need to add a new line to their sources.list? :o)
* thom covers his eyes and screams at the very concept of webmin in main
<Keybuk> indeed, no.
<Kyaneos> hi
<Micksa> sho "official" develops zwiki? sm?
<Micksa> s/sho/who/
<Micksa> gah, my typing sucks today
<jdub> jamesh: gnome-font-viewer seems to work from the command line, but not from fonts:///
<jdub> jamesh: $ gnome-font-viewer "fonts:///Andale Mono"
<jdub> ^ works
<jdub> $ gnome-font-viewer "fonts:///Andale%20Mono"
<jdub> works
<jdub> $ gnome-font-viewer file:///home/jdub/.fonts/Andale_Mono.ttf
<jdub> works
<jdub> Couldn't display "fonts:///Andale%20Mono".
<jdub> There was an error launching the application.
<jdub> hrm
<jdub> no applications selected in the properties dialogue
<jdub> looks like we've missed a mime type
<jdub> yeah
<jamesh> I wonder if it was updated for the new mime stuff?
<Keybuk> nothing in its .desktop
<jdub> yeah
<jdub> where's the .desktop?
<jdub> which package?
<jdub> oh, capplets-data
<jdub> nono
<jdub> there is no .desktop file
<jdub> badness
<doko> pitti: should gnupg be built with capabilities enabled in Ubuntu?
<pitti> doko: no need for that any more
<pitti> doko: gnupg does not need to be suid root any more
<pitti> doko: kernel 2.6.8+ supports limited mlock() calls as user, which is sufficient for gnupg
<doko> so your patches 15_free_caps and 16_min_priviliges aren't needed anymoer?
<pitti> doko: not really.
<pitti> doko: but I think the package cannot be synced from sid
<pitti> doko: since sid still installs it as suid root
<pitti> doko: (I assume you are at syncing gnupg ATM)
<doko> yes, but that's the only patch I identified.
* jdub patches
<Kyaneos> hi
<Kamion> daniels: progress ping on syslinux merge? I need it before I can upload the merged debian-installer
<thom> Kamion: he's on a plane to .dk now i think
<Kamion> maybe I should grab it ...
<Kamion> ah well, still have a huge doc merge to do
<Keybuk> syndicate scott# /usr/bin/time /etc/init.d/hotplug start >/dev/null
<Keybuk> 12.47user 0.75system 0:14.34elapsed 92PU (0avgtext+0avgdata 0maxresident)k
<Keybuk> 0inputs+0outputs (0major+137328minor)pagefaults 0swaps
<Keybuk> syndicate scott# dpkg -i grepmap_0.1.0-1_i386.deb
<Keybuk> Selecting previously deselected package grepmap.
<Keybuk> (Reading database ... 140871 files and directories currently installed.)
<Keybuk> Unpacking grepmap (from grepmap_0.1.0-1_i386.deb) ...
<Keybuk> Setting up grepmap (0.1.0-1) ...
<Keybuk> syndicate scott# /usr/bin/time /etc/init.d/hotplug start >/dev/null
<Keybuk> 1.84user 0.56system 0:03.46elapsed 69PU (0avgtext+0avgdata 0maxresident)k
<Keybuk> 0inputs+0outputs (0major+143197minor)pagefaults 0swaps
<Keybuk> \o/
<doko> mithrandir: I have some updates for the ia32-libs/ia32-oppenoffice.org packages. should I do upload before you start updating the packages?
<Keybuk> 14.34s to 3.46s
<sabdfl> Keybuk: yowser, what's the trick?
<Keybuk> sabdfl: "grepmap" :)
<sabdfl> which is?
<Keybuk> wrote it over the weekend, C tool to parse the module map files
<sabdfl> cool, hoary?
<Keybuk> rather faster than doing it in shell
<Keybuk> yaeh
<sabdfl> rock
<Mithrandir> doko: what kind of updates?
<Keybuk> it's sitting in NEW at the moment, just testing some corner cases and I'll upload the patched hotplug that uses it
<doko> mithrandir: see #1996
<doko> any reason that glibc isn't synced from unstable and no merge report is open?
<Keybuk> doko: Colin just synced that one
<Keybuk> uh, Martin
<Mithrandir> doko: oh, that one.. the lib32* libs are in universe, right?
<doko> Mithrandir: yes. do you really need lib32stdc++5 ?
<Mithrandir> doko: isn't it used by openoffice?
<doko> then it should be included in ia32-libs/office-libs. I'll drop the biarch support from gcc-3.3.
<Mithrandir> but it'll still be in gcc-3.4?
<doko> sure, yes
<Mithrandir> does openoffice build with gcc-3.4?
<doko> kamion: grub needs to be compiled using gcc-3.4 on amd64. could you do this change with your resync upload?
<doko> Mithrandir: apparently not: see #279185
<Mithrandir> doko: ok, any ETA on a fix?
<Mithrandir> doko: hmm, no, forget what I said
<Mithrandir> doko: so, if ia32-libs-openoffice.org builds the libstdc++5, it should be fine?
<Mithrandir> what does it pull from gcc-3.4 today?
<doko> libgcc_s.so.1, which we will have be built from the gcc-3.4 sources
<Mithrandir> why isnt't that part of the regular ia32-libs?
<Mithrandir> or rather -- how are you proposing to solve this?
<doko> not needed until now. yes, ia32-libs seems to be appropriate
<daniels> Kamion: just sitting in the copenhagen baggage reclaim -- bear in mind I've been on a plane since god knows when :)
<daniels> Kamion: i'll get to it today after I've checked in today as a priority
<daniels> Kamion: sorry, it's just been a very long time since I've had real (read: non-nstx) access
<jdub> Keybuk: ooh. hope elmo gets up and flushes NEW soon. :-)
<Keybuk> heh. now to make the bloody alsa modules load faster :p
<jdub> "would it help if i got out and pushed?"
<Keybuk> I suspect it's just waiting for /sys to turn up so it can udev up
<thom> jdub: oh, so you get to be the princess today?
<pasc> does that mean we'll get the new desktop background?
<jdub> pasc: yeah
<jdub> pasc: and Keybuk's grepmap
<Mithrandir> more pr0n?
<jdub> Keybuk: why the new package, btw? (kind of generic name...)
* Mithrandir hides
<pasc> what does grepmap do?
<jdub> Mithrandir: pr0nnier pr0n, this time
<elmo> yeah, the name sucks
<Keybuk> jdub: well, it's arch-any and hotplug is arch-all
<Keybuk> and it's a little more generic, so really deserved a separate source package
<Keybuk> and then hotplug only needs to Recommend it, etc.
<Mithrandir> pasc: I think it greps a map, not maps a grep
<jdub> Keybuk: s/all/any/ in hotplug's control doesn't sound insane... :)
<jdub> elmo!
<Keybuk> jdub: minimum impact, dude
<jdub> won't upstream+debian want it?
<Keybuk> most likely
<Kamion> doko: sure
<Kamion> doko: just build-dep and CC?
* jdub makes weighing motions with his hands at Keybuk 
<Kamion> daniels: no problem, didn't realise you were travelling, feel free to punt it to me if things are too hectic
<Keybuk> jdub: turning hotplug into arch-any would mean changing the .orig to include the new source, possibly in a subdirectory, changing the rules to compile, link and install C, etc.
<Keybuk> kinda icky
<jdub> yeah.
<Keybuk> the only change is just an extra patch in debian/patches to use grepmap if it's installed
<doko> kamion: yes, sent you a debdiff
<Kamion> doko: ta
<doko> elmo: please sync python-defaults subversion foomatic-db from unstable, mailman 2.1.5-3 from incoming
<thom> elmo: please sync cpufreqd from unstable
<elmo> doko, thom: done for the unstable ones
<elmo> doko: you might need to remind me about mailman once it reaches a mirror
<thom> elmo: thanks
<elmo> jdub/keybuk: what's the verdict - shall i add grepmap as is ?
<jdub> seems like a very generic name to me
<jdub> but it might not survive very long in hoary if it is accepted upstream
<Keybuk> it greps map files ... I couldn't think of a better one :o)
<elmo> grepmodmap ? :P
<Keybuk> I googled and there weren't any clashes
<doko> elmo: thanks, will do.
<seb128> hello
<seb128> jdub: GRRRRRRR
<jdub> seb128: :-)
<seb128> jdub: dude, I'll never get the right to commit without maintainer approval to the control-center if everybody hijack my patches :p
<jdub> haha
<jdub> i will make sure jrb/jody know
<seb128> thanks :)
<seb128> BTW you've broken the string freeze
<jdub> cock
<jdub> cock cock cock
<seb128> the .desktop has some new translations
<jdub> i shouldn't have ptu them in POTFILES.in
<seb128> not for gnome-2-8
<jdub> oh man
<Kamion> elmo: what's the current way to get new packages into hoary? I need file-preseed and network-preseed at least
<elmo> Kamion: synced 
<elmo> I still haven't done the "sync new stuff, remove old stuff" for universe yet, meh
<elmo> so for now, if there's something new you need, just pester me
<thom> hmm, trying to build firefox and work on openoffice at the same time is way beyond painful
<elmo> thom: try building openoffice on your sparc box...
<thom> elmo: no thanks, the disks would cause earthquakes
<thom> :-)
<sivang> hahah
<sivang> thom : how old is it?
<Kamion> elmo: 'k, thanks
<thom> 98?
<thom> elmo: besides, i'm not sure i have enough space to build OO on the thing anyway ;/
<Mithrandir> NFS mount from a server on the moon?
<jdub> bandwidth to ISS is *rad*
<sivang> jdub : what's ISS ?
<Mithrandir> sivang: international space station
<Mithrandir> the secret headquarter where we're all bobbing around in our space suits.
<Mithrandir> oops, did I say that?
<elmo> thom: openoffice.org:      1580568k (1635344k lastest)
<thom>  /dev/sdb1             4.0G  2.2G  1.6G  58% /home
<thom> so, uh, that might be a little tight :/
<doko> elmo: please add/sync mpfr from unstable. the recent gmp in hoary depends on it.
<jdub> wtf
<elmo> I've just started syncing the 628 (!) new source packages
<jdub> someone just posted to warty changes
* jdub locks it down harder
<jdub> hrm
<jdub> hrrrm
<jdub> crap
<jdub> hey aes 
<aes> helloo
<aes> how goes?
<jdub> rockin', yourself?
<aes> very busy, but good :)
<lamont> doko: am now
<doko> lamont: which kernel do you have on the ia64 box with the failing gnat tests?
<lamont> 2.4.17-mckinley-smp
<lamont> another build will run sometime today on 2.4.25-hpe-9-mckinley-smp, will advise
<doko> hmm, merulo has 2.4.27 and I see the same behaviour. wondering which kernel the buildd runs.
<lamont> caballero 2.4.25-dsa-mckinley-smp
<robtaylor> lamont: hey, i'm just looking at the differneces between your ubuntu scripts-base and mainline..
<robtaylor> lamont: i've integrated the simple stuff into my tree, but theres a whole load of work in grub-nonemu-2.6 which i dont quite understand - whats all that doing?
<lamont> all the grub changes were changing splash screens
<robtaylor> ah, and the removal of scripts-base/etc?
<robtaylor> bla 
<robtaylor> scripts-base/etc/init.d/debian
<robtaylor> scripts-base/etc/modutils
<lamont> stuff removed/changed in the init.d scritps was because it broke things. :-)
<lamont> and ISTR adding something
<robtaylor> ISTR?
<lamont> I seem to recall\
<robtaylor> i seem to recall, ok ;)
<robtaylor> lol
<robtaylor> i think you moved modutils from etc to root, it seems
<robtaylor> and added autologin?
* lamont really doesn't remember - are you diffing the -NubuntuM versions, or somethign more than that?
<robtaylor> diffing morphix-base-scripts_0.5-19ubuntu1 and mainline
<lamont> 0.5-19, or something else?
<robtaylor> 0.5-19
<lamont> ok. that'd be my changes, then/
<robtaylor> (well, 0.5-20, but ignoring what i know are the differences between -20 and -19 ;))
<robtaylor> yep, i as as tehre seems to be a *lot* of work, and i'm trying to make sense of it all.. and you have very few changelog entries....
<lamont>   * chmod 644 /usr/lib/locale/locale-archive
<lamont>   * correct typo with homedir setup
<T-Bone> lamont: quick question: do i want to feed quinn-diff with -p and a packages list or with -s and a sources list?
<lamont> that's all I believe that I did.
<lamont> T-Bone: -p Packages -s Sources
<lamont> and then it does a diff.
<robtaylor> lamont: yep, that explains 2 lines of the 24000 line diff..
<T-Bone> lamont: i should pass it both? Cause you were only passing one file in the first place
<lamont> robtaylor: that's not to say there weren't other changes introduced because of whatever...
<lamont> T-Bone: the default is to grab both of them from ./
<T-Bone> lamont: ok i'll use both. I'm getting very close to the end of stage2, fwiw. I have the same problems than first time: gcc and perl wont build, as well as a couple other packages
<lamont> robtaylor: want me to send you my diff?
<lamont> diff -ur t/morphix-base-scripts-0.5/ morphix-base-scripts-0.5/| wc
<lamont>      56     258    2807
<lamont> -       rm -r $(CURDIR)/debian/morphix-base-conf/etc/pcmcia
<lamont> +       rm -rf $(CURDIR)/debian/morphix-base-conf/etc/pcmcia
<lamont> -       chroot /mnt/main locale-gen &
<lamont> +       chroot /mnt/main sh -c "locale-gen && chmod 644 /usr/lib/locale/locale-archive" &
<lamont> -    rmdir -f /mnt/main/home/$USERNAME
<lamont> +    rm -rf /mnt/main/home/$USERNAME
<doko> somebody has a hoary powerpc chroot available for testing?
<lamont> that's vs the version from www.morphix.org/debian
<robtaylor> hmm
<robtaylor> and that all you have?
<robtaylor> very odd.
<lamont> robtaylor: I thought it was a pretty comprehensive changelog... :-)
<robtaylor> well in which case the rest must be source deb building differences, *phew*
* lamont said 'dpkg-buildpackage -rfakeroot' ...
<mvo_> hi rburton 
* robtaylor thinks theres some very big differences beween the source packages on www.morphix.org/debian and cvs
<rburton> hi mvo_ 
<T-Bone> lamont: i don't get it. if i pass both packages and sources, it compares and checks what's missing, that's it?
<lamont> yes
<T-Bone> ok
<lamont> it says 'what sources are newer than the binaries I have'
<T-Bone> then i have only 147 packages left, among which i presume a whole bunch are "expected failures"
<lamont> and also remove ':partial' from the output, since those don't count either..
<lamont> T-Bone: cool.
<lamont> better than me, since it took me a while to figure out that cyrus-sasl2 is unbuildable right now.
<T-Bone> hehe
<T-Bone> suprisingly enough it wants me te rebuild glibc while i already have it built
<lamont> does it say ':partial' off to the right?
<T-Bone> lamont: i used:  quinn-diff -A ia64 -p build/chroot-warty/var/lib/apt/lists/envy_stage1_dists_warty_main_binary-ia64_Packages -s build/chroot-warty/var/lib/apt/lists/gandalf_dists_warty_main_source_Sources  | sed 's:^.*/\(.*\).dsc.*:\1:' > build_list_stage2.3
<robtaylor> lamont: not convinced thats the upstream -19 that your comparing too..
<T-Bone> greping partial in the resulting list gives no result
<T-Bone> lamont: am i doing something wrong?
<robtaylor> lamont: no i am convinced now =)
<robtaylor> i'm going to go poke alexx
<T-Bone> lamont: is that ok?
<lamont> T-Bone: did you correctly create the Packages and Sources files in the repository? and did you apt-get update?
<T-Bone> yes i did. Packages created using smashArchive, Sources created using your mirror script, version 1 :)
<lamont> and do you find libc6.1 in the Packages file?
<lamont> and is it the same version as the one that's going to get built?
<T-Bone> Package: libc6.1
<T-Bone> Source: glibc
<T-Bone> Version: 2.3.2.ds1-13ubuntu2
<T-Bone> and it wants to build: glibc_2.3.2.ds1-13ubuntu2
<thom> fear, i 'ave ze pangoised firefox love
<T-Bone> lamont: ain't that weird?
<lamont> very strange
<T-Bone> well i'll just remove glibc from the build list since it's one of the longest build
<T-Bone> and hope that these are only positive diffs (ie, quinn-diff is only adding unnecessary things, not missing ones)
<lamont> anything in sources that is missing binaries in packages goes in (some --> :partial)
<T-Bone> ah, got it
<T-Bone> removing the sed stuff: libs/glibc_2.3.2.ds1-13ubuntu2.dsc [required:partial] 
<T-Bone> you said partial should be ignored, why?
<robtaylor> lamont: is it ok with you if i upstream your changes?
<robtaylor> lamont: ah never mind, they're already upstream it seems
<lamont> robtaylor: all of those changes should get pushed upstream.  alex knows about them, may have pulled all of them, or may not.
<lamont> T-Bone: :partial means that some of the Binaries listed in the source package are missing.  duh.  we know that.  They won't get built if we do it over either...
<T-Bone> ok, got that
<lamont> :partial is the original reason that PaS was created
<T-Bone> PaS?
<lamont> Packages-arch-specific
<T-Bone> huh!
<lamont> the file that gets edited to tell the buildd's to not try a particular source package on a particular architecture.
<T-Bone> i'm fetching all.deb packages into my stage1 rep
<lamont> T-Bone: the reason I only had -p in what I gave you was because I fetched Sources and unziped in .
<T-Bone> gah
<T-Bone> ;-/
<T-Bone> wow
<T-Bone> grep -v partial and i'm down to 52 packages :)
<T-Bone> i'll have to find a way to clean my stage1/2 rep so that it only has stage2 bins in it at some point, too
<Micksa> hey, who knows zwiki well here? :)
<Micksa> I think sm is the only real zwiki developer
<Kamion> doko: um, grub in unstable already build-deps on gcc-3.4 on amd64?
<mvo_> hi Mitario 
<Mitario> hey everyone
<Mitario> mvo_, any idea on when to get the update stuff out for the public and upload it e.g. to hoary?
<mvo_> Mitario: this week?
<Mitario> fine by me
<mvo_> I added dbus support into upgrade notifier, so that it will recheck for upgrades on changes from apt
<Mitario> wow!
<Mitario> cool
<Mitario> apt is already dbussed?
<mvo_> no, but easy to do with the shell dbus-send
<Mitario> ah
<mvo_> for now I use it send a signal after synaptic ran (or to be precise the new upgrade-app script that will call the correct app :)
<Mitario> :)
<Mitario> it's great if we bring it out this week
* Mitario has lots of hacking time
<mvo_> that brings me to the upgrade-manager :) can we check it in somewhere?
<Mitario> i could use gnome.org cvs, but i don't think i'm allowed too
<Mitario> i could put it on cvs.luon.net, or my own server @ eyesopened.nl
<doko> ohh, yes Robert Milan recently added this.
<doko> kamion: ohh, yes Robert Milan recently added this.
<Mitario> mvo_, are you an ubuntu maintainer atm?
<Mitario> ah, yes ok, great :)
<mvo_> Mitario: yes, but my account is not yet created, so I can't upload :)
<Mitario> ah, ok bummer :p
<Mitario> we'll have to get us sponsored then, i guess
<mvo_> I think it will be ready in the next few days
<mvo_> I have a synaptic update ready too
<Mitario> ok, cool
* Mitario is going to fix some last bugs in update-manager, and find a place to put an upstream source at
<Kyaneos> hi
<Kyaneos> i have a problem with blender
<Kyaneos> can nobody help me?
<Kamion> elmo: I'm guessing file-preseed/network-preseed need NEWed?
<lamont> elmo: please sync memtest86+
<Kamion> elmo: please pull download-installer into hoary; it's from the net-retriever source
<mjg59> Do you all have macros so you can just do /sync package and get elmo: please sync package?
<mjg59> If not, why not?
<Keybuk> $ sync memtest86+
<Keybuk> opens a socket and sends PRIVMSG #ubuntu-devel :elmo: please sync memtest86+
<Keybuk> ? :)
<Keybuk> hmm, now I remembering discussions of an RPC-over-IRC protocol
<daniels> Keybuk: /ctcp elmo SYNC memtest86+
* <fabbione!~fabbione@port49.ds1-van.adsl.cybercity.dk>  requested unknown ctcp X.ORG!  from #ubuntu-devel
<tseng> hah nice.
<Mithrandir> fabbione: you evil person
* fabbione grins
<bob2> hahaha
<Kyaneos> i have a problem with blender
<Kyaneos> can nobody help me?
* X-Sprint-dk-Team is closed to complete the first X.org deb builds
<mjg59> fabbione: About time. Slacker.
<lamont> warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/html/footnote.xsl"
<lamont> hrm.. guess gtkmm2.0 shouldn't be trying to download pieces of itself during the build process, eh?
<lamont> yet another bug to file
<fabbione> mjg59: me? slaker? tsk :P
<fabbione> lamont: we might need your help pretty soon
<fabbione> lamont: we want to simulate an archive flush to rebuild hoary with x.org in place of xfree86
<fabbione> lamont: do you think you can assist us with something simple?
<fabbione> lamont: daniels already prepared from sbuild thingy
<lamont> prepared from sbuild thingy??
<fabbione> s/from/some
<daniels> lamont: we have a (sort of hackish but not terribly bad) sbuild+wanna-build+etc setup
<daniels> lamont: and want to simulate a scorched earth, but with xorg in place of xfree86
<lamont> then what do you need me for?
<fabbione> lamont: in case we get stocked somewhere?
<lamont> note that you can't do a full rebuild of hoary right now - cyrus-sasl2 (and hence ldap and..........) FTBFS
<fabbione> you are the buildd master here ;)
<lamont> can help, sure.
<fabbione> lamont: we can still start from warty
<fabbione> that is already a good shot
<lamont> yeah, pretty sure that warty can rebuild itself completely
* lamont wanders off for about 20 minutes or so - back then
<elmo> kamion: they did, but I did them before lunch?
<elmo> lamont: done
<elmo> hmm, where the hell did the binaries go
<daniels> lamont: is the wanna-build tree from cvs.linux-m68k.org the most current one?
<daniels> (or elmo, I suppose, since you're the nominal maintainer in debian/control :P)
<elmo> ah, someone broke katie
<elmo> daniels: no, db.debian.org/debian-admin
<elmo> kamion: done download-installer
<daniels> elmo: cheers
<daniels> elmo: you might want to update buildd.d.o at some stage (or whoever's responsible for that)
<daniels> elmo: er, db.d.o/d-a just gives the regular db.d.o page
<elmo> kamion: should prop through in ~10 mins
<daniels> elmo: (not on cvs or f-m either, afaict)
<elmo> daniels: grab a Packages or Sources and use exact URLs
<daniels> elmo: oh, deb and deb-src
<daniels> elmo: cheers
<Kamion> elmo: ta
<daniels> elmo: that source is missing wanna-build, fwiw (no w-b package for i386 in Packages.gz)
<elmo> daniels: there's w-b for other platforms and it's mostly arch: all *shrug* and there's source 
<daniels> elmo: yah, built it by hand
<lamont> elmo: you know gal2.2_2.2.3.orig.tar.gz is fail-to-fetch, yes?
<lamont> jbailey: stupid libc question for you...
<jbailey> lamont: Sure. =)
<lamont> why does the current hoary glibc hang on ia64 in threads tests? :-(
<jbailey> lamont: I haven't looked at hoary's glibc stuff at all - is it pretty much what we have in Debian sid?
<jbailey> (The difference being that I have seen a thread hang a couple of times, unreproducable with some hardcore tests in Debian sid's snapshot.  I've not seen them with recent glibc CVS snapshots)
<elmo> lamont: works for me ?
<lamont> elmo: and md5sum matches, etc?
* jbailey thinks.
* lamont will investigate more
<jbailey> Is your ia64 box on a 2.6 kernel?
<lamont> jbailey: atm, 2.3.2-13ubuntu3 - need to see how 2.3.2-18ubuntu1 does
<elmo> god damn it
<elmo> lamont: there's nothing I can do about that, we'll have to do a 2.2.3us1 or something
<lamont> ew!
<elmo> lamont: warty has a different .orig.tar.gz to hoary/sid
<elmo> we can't fix warty, so ...
<lamont> WTH!?
<enrico> Hello.   Are there any meeings scheduled in #ubuntu-meeting on thursday?  We'd like to make a docteam meeting and I'm checking so that we don't stomp on other people's toes
<jbailey> lamont: I wouldn't expect -13 to -18 to have much difference for thread hangs.
<lamont> jbailey: ah, ok. I'll track down exactly which test it is this time... amusingly enough, killing the test lets things finish...
<lamont> istr only one test
<lamont> otherwise, you timeout after 2.5 Hours
<daniels> mdz: ping
<jbailey> That sounds like the hang we used to have.  I haven't triggered it in a while, though.
<lamont> elmo: I'll upload a new gal2.2 then.
<lamont> jbailey: ok
<lamont> elmo: sync chicken please
<elmo> done
<lamont> and closed. :)
<Kamion> I think we need libelfg0 and libelfg0-dev in main
<Kamion> ltrace depends on the former and build-depends on the latter
* elmo cries at the hoary vs. seed diff
* daniels stares at autotools.
<daniels> just after Keybuk ran away, too.
<Kamion> daniels: so, syslinux, or shall I do it now?
* Kamion has debian-installer building for hoary on powerpc (which doesn't use syslinux) now, I think
<daniels> Kamion: i'll take it
<Kamion> lamont: hm, if I upload debian-installer before the last build-dep is ready, it won't cause extra work for you, will it?
<daniels> GNAR!
<daniels> lost the only version of my new thinkpad-x40-support package, which was by now rather generic.
* daniels talks to ext3 with an axe.
<lamont> Kamion: providing that it's not a virtual package that's missing, no, it shouldn't
<lamont> elmo: please sync imlib2_1.1.0-12.4
<lamont> (aka latest)
<elmo> lamont: done
<lamont> 2.2.3ubuntu1-1ubuntu1
<lamont> hrm.. something wierd about that version number...
<lamont> or should I call it 2.2.3ubuntu1-1?
<fabbione> dpkg-deb: building package `xlibs-pic' in `../xlibs-pic_6.8.1-0.0_all.deb'.
<fabbione> RAD
<lamont> elmo: uploading gal2.2_2.2.3ubuntu1-1ubuntu1 in a minute or two...
<pitti> lamont: WTF messed up _this_ version number?
<pitti> fabbione: does it finally work? Congrats!
<sivang> anybody knows what with the wiki?
<fabbione> pitti: no it doesn't yet
<lamont> pitti: 2.2.3 was uploaded to warty.  and later to debian.  and the orig.tar.gz's don't match.
<sivang> it's down again
<fabbione> pitti: we are just building the first set of debs
<lamont> so we get to be a different _upstream_ version number too.
<pitti> lamont: no chance to put the upstream changes into a debian diff?
<elmo> aiee, it's fabbione with daniels-speak
<sivang> http://www.ubuntulinux.org/ <=== DOWN also
<lamont> sivang: rookery is happy, though..
<elmo> sivang: no it's not?
<pitti> sivang: works fine for me
<sivang> elmo : oh, well maybe just for me.. strange..
<mdz> daniels: pong
<mdz> pitti: here?
<sivang> came back now
<pitti> mdz: yes, good morning!
<mdz> pitti: you have an update to release, yes?
<pitti> mdz: a couple of 'em :-)
<pitti> mdz: I prepared advisories for groff and for xpdf/cupsys/tetex-bin
<mdz> xpdf and tetex-bin are built
<pitti> mdz: I put the latter ones into one advisory because it has a common cause
<mdz> groff and cupsys are missing amd64
<mdz> lamont: ?
<pitti> hmm
<lamont> pitti: problem is that we want debian's orig.tar.gz, and changing to that would require that we change warty, which is a no-no
<lamont> mdz: yo
<pitti> lamont: I understand
<pitti> lamont: I uploaded some security updates today, but groff and cupsys did not build on amd64 yet
<lamont> pitti: my only indecision is whether to call it 2.2.3ubuntu1-1 or 2.2.3ubuntu1-1ubuntu1
<elmo> lamont: king isn't uploading right
<pitti> lamont: I'd favor the first :-)
<mdz> lamont: cupsys and groff security builds on amd64?
<pitti> mdz: BTW, is there any chance I could verify such things on my own? I. e. read access to the build queue?
<lamont> elmo: will check
<lamont> pitti: build results go to security@ for -security uploads
<pitti> mdz: BTW, https://chinstrap.warthogs.hbd.com/~pitti/ has the interdiffs and advisories
<pitti> lamont: odd, I thought I received security@...
<pitti> lamont: but obviously I don't
<pitti> lamont: security@ meaning security@ubuntulinux.org?
<pitti> mdz: did you get these mails to security@u.o? I don't
<lamont> elmo: cron restarted on king
<mdz> pitti: I have never received mail from an ubuntu security build, no
<pitti> lamont: ^
<lamont> you only get failure emails.  these were both successes
<lamont> cron wasn't launching johbs
<elmo> lamont: doh
<|trey|> quick q I thought I would ask here... bad to mix hoary universe + multiverse with warty main + restricted? (mainly saying cuz mplayer is in hoary multiverse)
<|trey|> (don't want to ask in help channel due to them getting the idea anyways...)
<lamont> |trey|: "bad" is a relative thing...
<Kamion> |trey|: may work sometimes, not likely to stay working
<lamont> I don't _think_ mplayer drags anything in right now, but who knows..
<Kamion> Uploading via ftp debian-installer_20041027ubuntu1_source.changes: done.
<lamont> gal uploaded
<|trey|> recommend in help for people that want to watch movies: yes/no?
<Kamion> unwise to recommend that they add the whole line to sources.list
<Kamion> retrieving individual .debs and installing with dpkg -i may work
<lamont> |trey|: or grab the hoary source and build it on warty...
<|trey|> Kamion, k... yeah, that sounds safest... like lamont said, its has no deps that I know of... so yeah  :)
<lamont> |trey|: known to build on warty, but that got done after the release, and doesn't meet criteria for warty-updates
<lamont> |trey|: so find a security bug in it, and we'll have an excuse to upload to warty-security. :)
<elmo> is anyone else having problems with a jabber.org account?
<lamont> elmo: yep
<sabdfl> elmo: check
<elmo> ok, cool
<lamont> elmo: that's why I'm bugging you _here_. :-)
<elmo> (well not.. but at least it's not just me, YKWIM)
<lamont> yeah
<lamont> gal2.2 uploaded
<lamont> Kamion: about miscfiles.......
<Kamion> lamont: what does the current version in unstable have?
* lamont looks
<Kamion> lamont: if it still has Depends: fileutils, the change needs to stay
<lamont> Depends: coreutils
<lamont> ah, was fileutils.  has changed in debian to coreutils.
<lamont> doh.
<lamont> elmo: please sync miscfiles
<pitti> lamont: are the amd64 packages in the queue now?
<lamont> pitti: uploaded
<pitti> lamont: thanks
<pitti> mdz: should be there now
<lamont> upload didn't happen was where the breakage was.
<mdz> pitti: yes, everything is there
<elmo> lamont: done
<T-Bone> gah, damned courrier, cursing my build
<mdz> elmo: do you have a moment to set up pitti with access and rights to run amber?
* lamont needs to wander out and do a couple things with his houseguest.
<elmo> mdz: meh, done
<pitti> mdz: could you give me the right to approve mails to u-s-a as well?
<T-Bone> lamont: seems that the culprit is emacs
<daniels> lamont: ping
<mdz> pitti: I think the list can have only one moderator, let me see
<lamont> daniels: yo
<mdz> elmo: do you have any written instructions for amber?
<lamont> T-Bone: culprit?
<lamont> dir.gz?
<T-Bone> no
<pitti> mdz: usually you have one administrator and several moderators
<T-Bone> stuck build
<T-Bone> on courrier test
<T-Bone> i can't figure out which package cause that
<lamont> kewl
<lamont> daniels: 60 second warning...
<daniels> lamont: can you please review the syslinux merge?
<pitti> mdz: oh, it seems that was not totally right; there can be several admins/moderators, but only one password, I think
<daniels> lamont: about to put it up on fooishbar
<elmo> mdz: err, beyond the obvious and --help?  no
<cenerentola> sorry i cant use the printer wizard...
<cenerentola> it doesnt recognize the printer: HP 710C
<T-Bone> lamont: yeah it's definitely emacs
<elmo> pitti: cd /srv/ftp.no-name-yet.com/queue/accepted/; amber 18-1 mawk_*.changes
<pitti> elmo: rookery?
<elmo> pitti: add '-n' to the end for no-action/dry run.. run 'helena' to get a (not ideal) list of what's waiting for you
<cenerentola> lamont: can you help?
<elmo> pitti: no, jackass
<mdz> pitti: if you need to make multiple uploads, make sure that you amber them all, even if they're erroneous
<mdz> pitti: this will cause the extra packages to be listed in the advisory template (unless elmo fixed that), but they shouldn't be left in the queue
<elmo> yeah, that too
<mdz> that was a bigger deal in Debian, where we had to worry about the .orig all the time
<mdz> there are actually a lot fewer gotchas in ubuntu, I guess
<pitti> okay, thanks
<pitti> elmo: when I run "helena", I get a python exception with "_pg.error: FATAL:  user "pitti" does not exist"
<daniels> ehm
<daniels> mdz: how do I version 2.11-0.1 for ubuntu?
<mdz> pitti: you're going to document all of this, right?
<elmo> pitti: meh, details
<mdz> daniels: 2.11-0ubuntu1
<elmo> pitti: fixed
<pitti> mdz: you mean in the advisory?
<mdz> pitti: I mean the procedures for security
<mdz> pitti: how to use the tools, etc. it should be documented
<daniels> mdz: which is > 2.11-0.2?
<pitti> mdz: Oh, I make notes :-)
<mdz> pitti: also, one caveat regarding the mailing list
<elmo> god I hate bash's history handling so much
<T-Bone> lamont: looks like i'll be ready to test stage2 chroot anytime soon, the remaining non-built package being less than necessary (abiword and co)
<pitti> elmo: you really mean amber 13-1 groff*.changes -n  (i. e. -n as the very last word)?
<pitti> elmo: or amber 13-1 -n groff*.changes?
<elmo> pitti: either works
<elmo> pitti: the important thing is that the advisory number is first - due to a bug, amber insists on that (even if '-n' is the first thing)
<Kamion> mdz: did you hear of a way to do ?action=raw in zwiki? I added it to WikiWishlist just in case ...
<mdz> Kamion: no, I haven't
<elmo> oh, wow, I'm so glad I didn't add that global redirect now..
<mdz> elmo: you need to put some zsh in your pipe and smoke it
<elmo> mdz: I use it at home, I just haven't gotten round to migrating my remote accounts
<mdz> elmo: speaking of which, can you set my preferred shell in userdir-ldap to zsh?
<fabbione> elmo: please i need rman installed on yellow and adare chroots
<fabbione> elmo: i need to do a test build for X.org
<elmo> eek, the buildd stuff doesn't prioritize it's builds 
<elmo> SUCKage
<elmo> fabbione: eh, adare doesn't even have a hoary chroot yet - or are you happy with warty?
<doko> elmo: yellow has i386-hoary only, not amd64
<fabbione> elmo: warty please
<fabbione> elmo: i don't need hoary yet
<fabbione> elmo: sorry i wasn't clear
<elmo> doko: oh, sweet.. I forgot yellow had an i386 base.  rock on
<elmo> doko: btw, has mdz talked to you about de-kdelib-ing gcc-3.4
<elmo> fabbione: done - just freshening the chroots while I'm herte
<mdz> I don't think I have, but now is as good a time as any
<mdz> doko: you have a merge to do with gcc-3.4 anyway; you could do that at the same time
<fabbione> elmo: thanks a lot!
<elmo> aiee
<mdz> pitti: I have added you as a moderator for u-s-a
<mdz> pitti: one thing you need to be aware of
<mdz> pitti: there are many broken mailers in the world
<mdz> pitti: something which happens constantly is that copies of the advisory get fed back to the list itself
<mdz> pitti: so be careful to only approve the one that you sent, and discard the rest
<doko> mdz: do what with kdelib? it's built with 3.4?
<elmo> doko: not build-depend on it :)
<mdz> doko: remove the build-dependency on kdelibs
<pitti> mdz: I already cursed at the millions of autoamted replies I got...
<doko> ok
<mdz> pitti: yes, I have a blacklist for that if you want it ;-)
<pitti> mdz: nice :-) procmail based?
<doko> could I have access to a powerpc hoary box for a gcc test build?
<mdz> pitti: yes
<mdz> over the years I have collected them from bogus bugtraq bounces
<pitti> mdz: I would kill for it :-)
<pitti> mdz: well, at least I would say "thank you" :-)
<elmo> fabbione: all done
<elmo> doko: I'll create a hoary chroot on adare
<elmo> this one will actually be hoary too ;-)
<fabbione> elmo: thanks!
<doko> elmo: thanks
<daniels> lamont: http://fooishbar.org/daniel/syslinux/ -- it was reasonably complex and stuff has changed, so review would be nice
<daniels> Kamion: ^^
<elmo> lamont: buildd will take 10 packages, 9 universe one main, and not build the main one first - if you get a chance, and it's easy, might be nice to fix that
<Kamion> daniels: 0.1ubuntu1 would be a better version number
<Kamion> daniels: that way it isn't greater than any -0.2 that might happen to be uploaded to Debian
<daniels> Kamion: *shrug* ask mdz
<mdz> 0.1ubuntu1, 0ubuntu1, whatever
<mdz> it's all hypothetical in the extreme
<daniels> changed
<pitti> mdz, elmo: ambering worked fine, thanks for the introduction and setup
<pitti> mdz: I think we need to agree on an ML admin password, right?
<Kamion> mdz: hypothetical?
<pitti> mdz: I sent oht the advisories, but I have to approve them
<Kamion> -0.2 for syslinux is quite likely
<Kamion> given that the maintainer's fairly inactive
<elmo> # UNCONFIGURED FSTAB FOR BASE SYSTEM
<mdz> pitti: I am just extremely paranoid about amber because there were a lot of things to worry about in Debian, but it's much simpler here
<elmo> always an encouraging thing to find at the top of an /etc/fstab of a production machine
<Kamion> elmo: somebody just ran debootstrap and didn't finish the job, it seems ...
<elmo> kamion: that's the root fs
<pitti> mdz: the only gotcha that I found was that the presence or absence of '-n' does not really seem to make a difference
<lamont> elmo: part of the whole 3 unequal but together suites mess I need to address.  But thanks - hadn't gotten that one yet.
<elmo> pitti: ??
<pitti> mdz, elmo: I used -n for groff, but the packages were installed anyway and I also got the template mail
<mdz> pitti: I meant primarily with the uploads themselves.  in Debian, security was an entirely separate katie instance, so you had to remember to handle the .orig correctly, and there were no safeguards to ensure the version numbers were sane
<elmo> dude, that's like so not possible
<mdz> (relative to the main archive)
* lamont really runs off for about an hour or so.
<mdz> pitti: cut and paste the command line?
<T-Bone> lamont: see ya
<pitti> mdz: oh, right. As far as I can see, security.u.o and archive.u.o are more or less the same, right?
<Kamion> daniels: in fact, 0ubuntu1 < 0.1, so definitely wrong :)
<Kamion> daniels: with version 2.11-0.1ubuntu1, the diff looks otherwise fine to me
<elmo> pitti: no, archive.u.c is one machine, security.u.o is two
<elmo> they should appear the same tho, so the fact that you think they are is good ;-)
<pitti> mdz, elmo: oh, I looked again in bash history, I typed the groff command twice, second one without -n. Alright then, sorry.
<daniels> Kamion: cheers
<pitti> mdz: can you send me an encrypted mail with the u-s-a moderator password?
<mdz> pitti: is it possible to set a moderator password separate from the administrator password?
<mdz> I think what I have is the admin password
<pitti> mdz: I only found the list of admin/mod email addresses
<pitti> mdz: when I go to .../admindb/u-s-a, it only asks for a password, and not for a kind of login
<pitti> mdz: I already tried the password for ubuntu-de
<pitti> @ALL: ANY MAILMAN GURU HERE?
<pitti> mdz: I found it
<pitti> mdz: on the main admin page, second menu point is "Passwords"
<pitti> mdz: there you can set a moderator password
<mdz> pitti: ok, send a signed&encrypted email with the password you would like
<pitti> mdz: it's still only one password for all moderators, but better than nothing
<mdz> pitti: or I can make a random one and send it to you
<pitti> mdz: I'll mail you
<pitti> mdz: sent; we really need to sign our keys at es-conf
<mdz> mvo_: welcome aboard! :-)
<mvo_> thanks mdz  :)
<mvo_> I already have a bunch of questions for you :)
<mdz> elmo: can you take care of mvo as far as accounts and keys?
<mvo_> mdz: elmo did already, I got my account today
<mvo_> but I haven't tried to log-in yet :)
<mdz> ah, great
<elmo> mdz: :-P
* mdz hugs elmo
<mdz> pitti: moderator password set
<pitti> mdz: works,thanks
<Kamion> sorry, circuit breaker tripped
* Kamion needs a UPS
<doko> mdz, elmo: I'm lost. which kdelibs version has a gcc-3.4 build-dep?
<Kamion> You don't have permission to access /~lamont/buildLogs/byDate/today.html on this server.
<elmo> doko: nono, gcc-3.4 b-ds on kdelibs
<elmo> or, more precisely, kdebindings
<daniels> elmo: ?!?!?!
<Kamion> lamont: ^--
<Kamion> for AWT presumably
<elmo> err.. hang on
<elmo> apparently my germinate output parsing powers have waned
<elmo> doko: sorry, it's not your problem at all
<elmo> it's actually.. ?! debconf which is pulling in kdelibs
<elmo> libqt-perl                                 | libqt-perl                       | debconf (Build-Depend)            
<elmo> libsmokeqt-dev                                    | kdebindings                  | libqt-perl (Build-Depend)   
<doko> ok, I didn't any dependency there as well. good to know I'm not halluscianting
<elmo> kdelibs4-dev                               | kdelibs                          | kdebindings (Build-Depend)     
<mdz> ICK
<Keybuk> "Guns don't kill people, Germinate does" ?
<daniels> elmo: yeah, that makes sense
<elmo> not for us :P
<elmo> shall I file a bug on debconf ?
<daniels> yah, asking to disable the qt frontend
<mdz> why does it build-dep on it anyway?
<mdz> it only Suggests it at runtime
<mdz> elmo: yes, please
<elmo> mdz: eh? it still has to b-d on it, to be able to suggest it
<elmo> or at least build with it to suggest it
<mdz> elmo: wha? it's perl
<mdz> seb128: are you fixing this libgroupwise/e-d-s conflict?
<Kamion> mdz: moc/uic
<Kamion> mdz: the Qt interface is generated at build-time
<Kamion> puic, rather
<elmo> mdz: with a .so ?
* mdz weeps
<elmo> in fact, a proper shared library even
<seb128> mdz: there is a conflict ?
<mdz> seb128: dpkg: error processing /var/cache/apt/archives/libecal6_1.0.2-2ubuntu1_i386.deb (--unpack):
<mdz>  trying to overwrite `/usr/lib/libecal.so.6.2.1', which is also in package evolution-data-server
<seb128> hum, ok
<mdz> seb128: several of them
<mdz> dpkg: error processing /var/cache/apt/archives/libegroupwise6_1.0.2-2ubuntu1_i386.deb (--unpack):
<mdz>  trying to overwrite `/usr/lib/libegroupwise.so.6.0.0', which is also in package evolution-data-server
<mdz> evolution-data-server conflicts with about 5 packages now
<mdz> er
<mdz> someone just sent a problem report to warty-changes
<elmo> mdz: jdub saw it and tightened the list down
<pitti> elmo: what's a working and prefered email for the Ubuntu security team? security@u.org or team@security.u.org?
<elmo> pitti: the former, the latter no longer exists
<pitti> elmo: thanks; the latter could be nice for Debian compatibility, though
<elmo> (s@ul.o or s@u.c, bother work)
<elmo> pitti: mdz
<elmo> mdz: pitti
<elmo> ;)
<mdz> pitti: security@ is used by everyone else in the world :-)
<pitti> right
<mdz> amu, lamont : so we can build live CDs in a chroot now?
<amu> mdz: no, just workng on it, you follow my daily reports ? 
<mdz> amu: yes, I inferred that from your report
<amu> mdz: guess some more day's and i get it working 
<mdz> * run serval tests building the iso in a chroot
<mdz> amu: that seemed to indicate that it was working
<amu> mdz: he problem is, the mmaker/isomaker has 0 debug option  
<amu> s/he/the
<amu> i got it now on this, i have all modules unter /tmp ... i dont know why, some packages arnt installed, rewiting code now that every fucking comannd is beeing logged :)  
<amu> mdz: the bootspash isnt added to the miniroot, and at the final iso-tree grub+themes are missing. i cannot find it out why, so I need debug options on the code.   
<fabbione> lamont: at what time do the buildd's pick up stuff from the archive?
<Kamion> jdub: 19:00 < joeyh> Kamion: give jdub some props from me, FWIW he correctly decided about whether preseeding was safe for warty..
<Kosai> Kamion: Hiya.  Power cut?  :)
<Kamion> Kosai: kinda, circuit breaker tripped apparently due to the radio being plugged in in the kitchen (!)
<Kosai> Huh.
<pitti> mdz, doko: I fleshed out http://www.ubuntulinux.org/wiki/SecurityUpdateProcedures. I would appreciate some proofreading :-)
<lamont> Kamion: you want to write the livecd vs install CD blurb, or shall I?
<Kamion> don't mind really. if you're at a loose end ... :)
* lamont has about 16 things on his plate.
<lamont> one more either way doesn't much matter...
<Kamion> heh
<Kamion> ok, I'll put it on my todo
* lamont needs to really make a list and verify that he has his priorities straight.
<daniels> Kamion: if you want to take syslinux and upload it, that would be nice
<daniels> Kamion: waiting for my shiny new ssh key to propagate (sigh)
<daniels> Kamion: otoh, if it's not a blocker for your work, i'll take care of it (probably on the other side of sleep by the time the key's out though, i'm crashing raipidly)
<lamont> Kamion/vorlon: fwiw, taking postgresql-dev into sarge makes cyrus-sasl2 unbuildable. :-(   See 279158
<daniels> lamont: could you please give back xrender 0.9.0-0ubuntu1 when render 0.9-0ubuntu1 is in?
<daniels> lamont: (forgot to tighten up b-ds)
* daniels -> hotel
<mdz> pitti: I made some adjustments, looks pretty good
<mdz> pitti: we will need a separate process for coordinated disclosure
<pitti> mdz: so far I do not know much about this anyway
<desp> cough
<desp> mdz: :)
<mdz> ?
<desp> mdz: I have ubuntu working on my oldworld
<mdz> desp: great, do you have some patches for us?
<mdz> what was the cause of the problem?
<pitti> mdz: did you made any serious changes (apart from typos)? I can't spot them :-)
<mdz> pitti: shift+reload, it's probably cached
<mdz> pitti: you can also read the history
<desp> the cause of the problem was that the generated initrd was left on the ext3 partition, and the BootX bootloader used on oldworld needed it on the Mac OS HFS partition
<desp> so this is really not an issue, because the most difficult thing to do is getting the actual initrd file across the ext3/hfs barrier
<desp> this is actually pretty hard, since there is no support for ext3 on Mac OS 9, and having booted from the ubuntu install CD, one can't mount a hfs partition.
<pitti> mdz: a "debdiff" is a different thing for me than an "interdiff". debdiff checking is good, but it does not really help to concisely see code changes; I prefer an interdiff for this
<mdz> it should be possible to use the live CD
<mdz> pitti: er..have you used debdiff? :-)
<pitti> mdz: yes
<mdz> pitti: it does what interdiff does, plus more
<pitti> mdz: so far I only used it with deb packages, though
<mdz> pitti: you can run debdiff on two .dsc files
<lamont> daniels: it does that sort of give-back automatically... (it's called 'dep-wait'...)
* lamont ducks
<pitti> mdz: ah, I did not know that, thanks. I always used interdiff for this.
<mdz> pitti: maybe it is worth more explanation in the wiki page, then
<pitti> mdz: I add the "two .dsc files"
<mdz> mvo_: will you be uploading a new synaptic today?
<pitti> mdz: BTW, doko prepared an update for libarchive-zip-perl, did you see this?
<mdz> pitti: he sent the email to me, CCing you
<pitti> mdz: shall I check and handle this?
<desp> I'll be going, then. see ya
<T-Bone> lamont: i have a few remaining FTBS packages that fail for stupid reasons, such as subversion dying because it doesn't like the current locale during install :P
<T-Bone> i'm left with 47 packages, tho
<lamont> T-Bone: sounds like you're ready to move on to d-i then, ey?
<T-Bone> lamont: sounds like, yeah :)
<sjoerd> seb128, pitti: the new debian g-v-m should fix the crash on dbus restart, that people have been seeing
<pitti> sjoerd: nice, thanks
<T-Bone> lamont: if you wanna give a look at the remaining failures: http://envy.esiee.fr/~varenet/not_successful
<pitti> sjoerd: I'll do an upload soon
<T-Bone> lamont: i'll have to find a way to purge the chroot from pre-stage2 binaries too
<pitti> doko: there is no CVE/CAN number for the perl zip vulnerability?
<seb128> sjoerd: ok, cool
<Kamion> daniels: ok, may have a look after karate tonight
<doko> no, haven't seen one, only the references found at http://lwn.net/Articles/108926/
<pitti> doko: I don't have access to yellow, is the package on chinstrap still valid?
<doko> did I write yellow? I meant chinstrap.
<pitti> mdz: do you agree to upload this libarchive-zip-perl update?
<Kamion> T-Bone: guess I should upload linux-kernel-di-ia64-2.6 soon
<T-Bone> Kamion: that'd be cool :)
<Kamion> not that hoary's installer is working for any other architecture quite yet ...
<T-Bone> hehe
<lamont> elmo: please sync kdelibs
<elmo> lamont: done
<elmo> doko: adare now has a hoary chroot and you have an account
* lamont closes his last merge bug.
* Kamion has one more to go, but can't face base-config today
<doko> elmo: cool
<elmo> Out-of-date BUT modified:  68 (6.59%)
<elmo> Out-of-date BUT modified:  76 (0.97%)
<doko> have to be there before fabbione starts the X builds ;)
<elmo> main, universe
<lamont> Kamion: mooning it won't help, but it might make you feel better....  And it avoids facing it! :-)
<Kamion> *groan*
<lamont> elmo: does that stat automatically pick up new sid  uploads?
<elmo> lamont: yeah
<elmo> I need to start filing bugs I guess for new ones
<lamont> prolly
<lamont> elmo: once the buildd's get caught up, I'll drop in the latest, which has max_build_percentage (then I'll make max_build=30, max_build_percent=25, and we'll handle both large and small influxes in a more distributed manner)
<lamont> s/latest/latest buildd/
<lamont> elmo: any chance that the universe-before-main included a main package that was 'unknown'?
<elmo> it was d-i, so I doubt it
<elmo> I saw it on whatever built the powerpc upload
<Kamion> universe-before-main?
<elmo> buildd ordering stuff
<elmo> the buildd took 10 packages, 9 universe, 1 main (d-i) and built d-i last.. which is a bug
<lamont> elmo: ok.  I'll stare at it a little bit - could be a trivial tweak
<lamont> elmo: you mean this one?
<elmo> lamont: it's not a big deal, the really critical stuff is warty-security, and I know that works (i.e. is built first), so don't go to any effort
<lamont> Nov  1 17:19:12 buildd: Starting build (dist=hoary) of:
<lamont> Nov  1 17:19:12 buildd: imlib2_1.1.0-12.4 gal2.2_2.2.3ubuntu1-1ubuntu1 dvd+rw-tools_5.21.4.10.8-1ubuntu1 debian-installer_20041027ubuntu1 ocaml-mad_0.1.2-2 ocaml-shout_0.1.1-2 ocaml-vorbis_0.1.1-2 simage_1.6.0-2 swt-gtk_3.0-6 swt-motif_3.0-4
<elmo> blink
<lamont> because that looks right...
<elmo> lamont: blah, sorry, yes, it's fine.  god damn, i just suck at parsing simple things today
* lamont makes a note to buy elmo a beer and give him some sympathy in spain.
<lamont> elmo: is the lene output fetchable (for each architecture, of course...)
<lamont> ?
<elmo> lamont: no, I could probably make it fetchable - LAN only tho, I'm afraid
<elmo> (you're free to wget it on rookery, and dump it in your ~/public_html if you want tho)
<elmo> I just can't expose jackass' apache
* lamont meant to the buildd's.
<lamont> although it might not be a bad thing to wget to rookery
<elmo> lamont: why do the buildds want it?
<fabbione> daniels: i uploaded xrender ubuntu2 to fix the build-dep
<fabbione> elmo: when you have time (= no rush) i will need access to the hoary chroots on yellow and adare
<lamont> elmo: _I_ want it.
<fabbione> elmo: do you want a mail for it?
<fabbione> X.org can't build on warty anymore
<lamont> so that I can do givebacks as needed to deal with the 90%-working auto-depwaiter.
<mdz> pitti_: I have not reviewed the package; what is your analysis?
* lamont grabs his _11_ running SyncTest.exe's and looks around for doko./
<lamont> elmo: so s/buildd/in-dc-lan/
<lamont> elmo: automake1.9 needs some NEW love.
<elmo> automake1.9 is what broke katie earlier - I'm looking at it
<lamont> elmo: ah, ok.
<doko> lamont: that's hppa only, doesn't count. I'll add some love^H^H^H^H killing to the tests
<lamont> doko: heh.  thanks
<lamont> doko: but don't do a special upload for that fix. :-)
<lamont> doko: lt-gij as well, it appears
<doko> gcc-3.3 only, or 3.4 and -snapshot as well?
<fabbione> ah damn
<fabbione> i misread the version
<elmo> GAR stupid X
<mako> wiki question
<mako> i am going to start and then advertise a wiki page for non-canonical people that want to come to the conference.. where should i put it?
<fabbione> xorg_6.8.1-0.0_i386.changes                                     100%   21KB  21.3KB/s   00:00    
<fabbione> Successfully uploaded packages.
<fabbione> Not running dinstall.
<fabbione> well
<fabbione> looks good
<mjg59> ZORG
<fabbione> dput -u -f ubuntu-local xorg_6.8.1-0.0_i386.changes
<fabbione> tsk :-)
<elmo> lamont: jackass/lene/
<lamont> tnx
<hornbeck> did the fonts change for Hoary?
<mdz> elmo: are you synching unmodified packages on an ongoing basis yet?
<mdz> hornbeck: not that I know of
<mdz> they look the same to me, anyway
<hornbeck> they look different on the box I just updated
<hornbeck> maybe just my eys
<hornbeck> eyes
<elmo> mdz: have been for ages
<mdz> elmo: ok. how frequently? daily?
<elmo> mdz: yes
<mdz> elmo: what time of day?
<elmo> debian only updates that frequently?
<mdz> elmo: so I have a bug which is fixed in the current Debian version.  At what time should I set a reminder to close the bug?
<elmo> 3:17 local to jackass
<mdz> thanks
<elmo> (GMT atm)
<mdz> justdave: can we have an 'automatically resolve in 24 hours' status in bugzilla? :-)
* maswan prods elmo regarding max connections
<maswan> @ERROR: max connections (25) reached - try again later
<mako> can someone give me some advice on the wiki question above?
<maswan> or is it the other one?
<mdz> mako: ?
<justdave> mdz: funny you should ask... mozilla.org wants that, too. :)
<maswan> or another ftpmaster, does archive.ubuntu.com limit to 25 rsync connections for the public modules, and if so can I as a mirror admin get access to a non-public, unlimited version?
<justdave> Gerv was working on it, last I heard, but he's gone to Asia for a month as of yesterday
<lamont> elmo: how often do the lene outputs run?
<mako> mdz: i am going to start and then advertise a wiki page for non-canonical people that want to come to the conference.. where should i put it?
<jdub> elmo, mdz: actually, i didn't tighten the list down
<jdub> because all the mails are posted as the uploader
<jdub> makes it hard
<jdub> Kamion: heh
<pitti_> mdz: back; re libarchive-zip-perl: the patch is from upstream and looks reasonable; however, I do not really consider a potential fooling of virus scanners as truly critical
<pitti_> mdz: that's why I'm unsure whether to upload it
<pitti_> mdz: there are probably a million ways to hide viruses from scanners anyway
<pitti_> mdz: I think it's safe to upload, though
<seb128> jdub: do we want hoary really usuable or that's a really a devel tree ? The new metacity (2.9.0) has switched the focus stealing prevention on again, but since some apps are still bugged that's a bit annoying to use ...
* lamont giggles as he notices things accidentally get fixed in warty. :-(
<seb128> arg, can't build yelp
<doko> mdz, pitti: For debian unstable I need the patch for mailscanner, that's why I noticed it. libarchive-zip-perl is in main, so I prepared the patch for warty. do we want to have something like volatile?
<seb128> some GNOME stuff use libgcrypt7-dev, libxslt1-dev wants libgcrypt11-dev
<seb128> time to transition to gnutls11 I guess
<pitti> doko, mdz: if warty-updates would work, I would prefer putting the package there
<pitti> doko: I do not feel that this is really critical for warty, that's why I still hesitate to upload it
<pitti> doko: BTW, is it already fixed in Hoary?
<doko> pitti: agreed, even gentoo marked it as low urgency
<doko> yes, hoary has 1.14
<lamont> seb128: transition to gcrypt11 is on my list if you don't get there first...  (or was that gnutls11...?)
<seb128> both gnutls/gcrypt
<lamont> seb128: heh. that was it, then. :-)
<jdub> seb128: we're dogfooding!
<Mitario> HI!
* Mitario is happy
<lamont> jdub: you are? really? wow!
<jdub> that's what it's all about!
<lamont> jdub: I thought that was the hokey-pokey
<mdz> seb128: I still got file overlaps with the latest packages
<seb128> hum, I've updated all the Replaces and it installed fine here
<seb128> let me check
<jdub> with the evo packages?
* lamont gets asked if openafs-* can make it into main for hoary.
<jdub> i had some problems too
<jdub> apt-get -f install worked though
<jdub> lamont: eeek
<lamont> mdz: can't remember if openafs makes baby jesus cry or not.
<mdz> jdub: "worked"
<seb128> jdub: yes, this was with the debian version, should be fixed with the new upload ...
<mdz> lamont: yes
<mdz> lamont: it doesn't even work with 2.6 yet
<seb128> mdz: which packages/files conflicts ?
<mdz> seb128: sent you email
<jdub> lamont: head spinning, green goo flying, etc.
<seb128> ok
<mdz> seb128: libedataserver3 has conflicts/replaces e-d-s << 1.0
<lamont> mdz: fixed upstream in 1.3.37
<mdz> seb128: but it conflicts with later versions than that still
<seb128> mdz: I've updated the conflicts to 1.0.2, 1.0.0 was good for debian but we splitted later
<mdz> hm, maybe it isn't built yet
<mdz> but that was hours ago, wasn't it?
<seb128> yes
<mdz> the version being unpacked was 1.0.2-2ubuntu2
<seb128> about 15min after you pinged me with the conflict
<seb128> that's the fixed one
<mdz> mizar:[~]  apt-cache show libedataserver3 | grep-dctrl -sVersion,Replaces,Conflicts ''
<mdz> Version: 1.0.2-2ubuntu2
<mdz> Replaces: evolution-data-server (<< 1.0.0)
<mdz> Conflicts: evolution-data-server (<< 1.0.0)
<mdz> looks exactly the same as the previous version
<seb128> Conflicts: evolution-data-server (<< 1.0.2-1)
<seb128> Replaces: evolution-data-server (<< 1.0.2-1)
<seb128> in my debian/control
<mdz> seb128: what version?
<mdz> I thought 1.0.2-2ubuntu2 was the fixed one
<mdz> according to the changelog
<seb128> should be, I'm updating
<mdz> seb128: control.in has 1.0.2, but control has 1.0.0
<seb128> mdz: oups, -2ubuntu3 on its way ...
<mdz> thanks
* lamont wanders off for a couple hours to do things with the houseguest.  back on later tonight
<seb128> ok, eds doesn't update the control during the clean target, that's why ...
<mdz> jdub: did you fix the problem with the calendar package where the entries aren't added to the list of backgrounds?
<jdub> mdz: that only seemed to happen for you
<jdub> mdz: perhaps killing nautilus would help
<mdz> I find that very hard to believe
<mdz> jdub: I have logged out and logged back in
<jdub> who else has upgraded to -calendar-november?
<mdz> I think this is the same breakage that scott and I kept running into when messing with the backgorund stuff
<mdz> sometimes it just decides not to update ~/.gnome2/backgrounds.xml
<jdub> mdz: that'll be out of scope for u-c releases then
<mdz> jdub: it's in scope for hoary
<jdub> hrm, i should do hoary releases of those, too
<srbaker_> anyone here done any packaging of mono apps?
<mdz> srbaker: tseng
<srbaker_> tseng, around?
<pitti> mdz: can you please review #3131 (patch and advisory text)? TIA
<srbaker_> mdz, apparently mono apps like to install in /usr/lib/<prog> and they're supposed to go in /usr/share/dotnet/<prog>/
<jdub> mdz: probably best to file a bug and provide a strace or something; i'm not going to be able to fix it
<mdz> pitti: how is $TMPLIB generated?
<pitti> mdz: the usual insanity with $$
<mdz> pitti: ok, as long as it isn't static, otherwise it's an easy DoS
<mdz> pitti: patch looks fine
<pitti> mdz: but since it is a directory, checking that mkdir is successful should be safe
<pitti> mdz: I thought about using mktemp -d, but it is not portable
<mdz> pitti: on the text, s/allowed/could allow/
<pitti> mdz: otherwise okay?
<mdz> pitti: yes
* jdub cheers on seb128 
<seb128> ?
<seb128> for what ? :)
<jdub> hoary uploads :)
<seb128> oh
<jdub> should i work on a few 2.9 upgrades while you're asleep?
<jdub> looks like evo's on its way in atm
<seb128> if you want, but I can manage them tomorrow
<seb128> I just don't want to break evo before going to sleep so I'm doing them tonight
<jdub> cool
<seb128> s/I'm doing/I'm *not* doing/
<jdub> heh
<seb128> BTW yelp has been accepted but gnome-doc-utils is probably stucked in NEW
<seb128> elmo: ? :)
<jdub> elmo, mdz: would it be better to sync u-c uploads from warty-updates to hoary, or upload new ones?
<seb128> jdub: so we really want metacity 2.9.0 ? :)
<seb128> I've it ready to upload, but I fear some people will not be happy, little focus problems are very annoying sometime :)
<jdub> seb128: sooner people use it, the sooner it'll get fixed :)
<seb128> right
<seb128> GO GO GO
<jdub> ;)
<seb128> I don't fear the bug reports :)
<jdub> we'll just mark them all UPSTREAM ;)
<seb128> ah ah, true :p
<seb128> BTW do you have this gstreamer crash ?
<seb128> supposed to be ubuntu specific, but no problem here and the packages have no significant changes ...
<jdub> seb128: haven't seen it :|
<seb128> ok
<seb128> that's not really and evo is out
<seb128> let's go with the evo stack NOW
<seb128> I'll sleep a bit later tomorrow :p
<seb128> (doh, today was a supposed to be not working day here :p)
<jdub> heh
<carlos> seb128: that's the problem with us, we are too work addicts :-P
<seb128> carlos: to be honest I can't wait to get all the cool stuff in 2.9 :)
<jdub> me too :-)
<carlos> seb128: are there so many changes with 2.9.1?
<seb128> a bunch of good ones yes
<seb128> the new mountapplet in GNOME applets
<seb128> metacity as focus stealing prevention back
<jdub> gtk+ 2.5
<seb128> that too
<seb128> I like the extensions chooser in epiphany too :)
<seb128> you can turn on/off the extensions you want to use in the UI
<jdub> cool
<carlos> jdub: when is the GNOME feature freeze?
<jdub> carlos: jan 10th
<jdub> perfect timing for the ubuntu conference ;)
<carlos> so hoary will have the freeze before GNOME?
<jdub> hoary will have upstream version freeze, yeah
<jdub> but that's independent of GNOME in hoary
<carlos> yes, I know, I was talking about "global system freeze"
<mdz> seb128: don't worry about breaking evo; it seems broken already (for new users) ;-)
<seb128> mdz: oh yes, I've some mails about evo freezing but no idea of the problem for the moment 
<mdz> seb128: I am able to reproduce it easily here
<mdz> it spins
<jdub> carlos: our UpstreamVersionFreeze is before GNOME's feature freeze (but doesn't effect GNOME), our FeatureFreeze is one month after GNOME's
<seb128> I'll work on this tomorrow so (if 2.1.0 doesn't fix that)
<jdub> mdz: good solution from Niall Sheridan re: ipv6
#ubuntu-devel 2004-11-13
<jdub> pitti: steaming along with the USNs :)
<pitti> jdub: I do not manage to do anything else apart from security bugs right now :-(
<seb128> everybody else has his trash applet broken in hoary ?
<Mitario> jup
<seb128> oh, Mitario !
<jdub> yo Mitario 
<Mitario> hi dudes :)
<Mitario> seb128, going to investigate soon, probably some drag event which doesn't work
<seb128> yeah
<pitti> mdz: BTW, is there anybody else on your list who wanted to join the security team to reinforce me? 
<seb128> I've a really weird behaviour
<seb128> I DND something in the applet
<seb128> and like 2-3 min after I get the animation on the screen
<Mitario> well, weird that it doesn't work in gtk 2.5 but does in 2.4.x
<Mitario> seb128, yeah, drag_timeout
<seb128> ok
<seb128> good luck with that :)
<Mitario> ty :)
<jdub> Mitario: what do you think about having a bigger icon pop up when you drag over the trash applet?
<Mitario> jdub, jep was already hacking/thinking it out :D
<mdz> pitti: fabio, but he is busy with X.org
<Mitario> we need some animation which gives the user the idea that it's on top of the icon and the file has actually been 'dropped' in the icon
<jdub> Mitario: mmm
<Mitario> jdub, or isn't that what you meant?
<jdub> Mitario: that's exactly what i meant ;)
<Mitario> :d
<seb128> jdub: are you going to upload polypaudio to debian too ?
<jdub> azeem didn't want to just yet
<seb128> why ?
<jdub> i'm waiting a bit for lennart's next release anyway
<jdub> rpath oddness in the modules, etc.
<seb128> #272596 -> rename that to an ITP at least
<pitti> night, guys!
<Mitario> nn pitti
<srbaker__> yaye
<srbaker__> i ahve a tomboy package for ubuntu if anyone's interested
<jdub> srbaker__: there's one in tseng's repo
<srbaker__> jdub, oh, cool.  i wanted to do this anyways for educational value
<srbaker__> god damnit.  balsa is being a pain in the ass
<tseng> boo
<elmo> jdub: dude, filter the lists on the X-Katie header
<jdub> elmo: ahar
<jdub> hrm
<elmo> maswan: zoiks
<elmo> poor little auckland - there must be steam coming off it
<Mitario> nn all, hacktime tomorrow
<jdub> elmo: hrm, see, can't.
<jdub> hrm.
<elmo> jdub: doh, oh well
<jdub> mdz: so, Keybuk tells me that warty-updates is not in the default sources.list
<jdub> lamont: http://people.ubuntulinux.org/~lamont/buildLogs/t/tomcat4/4.1.30-6/tomcat4_4.1.30-6_20041101-2106-i386-failed
<jdub> lamont: is this fixable in any sane way?
<mdz> jdub: yep
<jdub> mdz: this is much the suck
<jdub> mdz: i'm going to mail ubuntu-users about it
<jdub> mdz: but... hrm.
<mdz> jdub: sabdfl has decreed that it shall be forced into warty-security
<jdub> oh
<jdub> yuck
* jdub goes for shower+lunch-combo
<mdz> jdub: baby jesus may not be crying, but he's definitely making a face
<lamont> jdub: looking
<lamont> jdub: sure: simply provide a blackdown-j2sdk1.4 package where the buildd's can fetch it (even if we don't allow machines outside the LAN to fetch it), and lots of stuff will suddenly build
<lamont> and get baby jesus some candy or something...
<jdub> heh
<jdub> mdz: so should i upload to warty-security, or are we going to push the packages over?
<mdz> jdub: that'd be an elmo question
<jdub> hrm
<jdub> elmo: still awake?
<elmo> unfortunately
<mdz> jdub: I've updated the HoaryGoals wiki page with the rest of the stuff discussed at the kickoff meeting
<jdub> HELLO ELMO!
<jdub> mdz: rock
<mdz> jdub: but I realized that my notes don't contain information about which bounties you had candidates for and which were open
<mdz> jdub: if you could make a pass over the page and note where you already have a candidate, we can start to actively point folks to the remainder
<jdub> mdz: i was thinking of bugzillizing them, and making a nice tree
* mdz gags
<jdub> good for tracking
<mdz> I really don't want to fill bugzilla with enhancement requests
<mdz> certain users are already trying, and my current feeling is that they should all be moved elsewhere
<jdub> these are features goals, there's a difference :)
<elmo> jdub: done
<mdz> but they aren't, they're potential goals which may or may not happen
<jdub> yeah
<mdz> targets of opportunity, mostly
<jdub> elmo: oh, you moved them?
<mdz> fine with opening a bug once there's someone to assign it to
<mdz> but I'd rather not create a bunch of bugs with no home
<srbaker_> grrrrrrrr
<jdub> mdz: yeah, only want a tree of assigned tracking bugs
<elmo> jdub: yeah - didn't you want me to?
<jdub> elmo: was asking what we should do
<elmo> oh, duh.  well.  hasn't sabdfl spoken?
<jdub> never mind
<elmo> ?
* jdub was asking "should i upload, or do you want to push them over?"
<jdub> mdz: checked out libuser yet?
<lamont> ah, jabber seems happy again
<mdz> jdub: no
<mdz> jdub: ok, so for the ones where there's an assignee, feel free to create a bug and link it from the wiki
<mdz> jdub: will you do that?
<jdub> ok
<mdz> great, thanks
* lamont calls an early night
<vinsci> "security" needs to be a top-level item on the web site
<vinsci> rather than hidden under support|documentation|security notices
<mdz> vinsci: agreed
<mdz> it needs to be more prominent
<mdz> vinsci: filed bug #3145 about it
<fabbione> morning guys
<fabbione> lamont: are you still around?
<fabbione> buildd's did pickup xrender ubuntu3
<fabbione> mdz: libreadline5 needs to move from universe to main
<fabbione> quite a bunch of packages depends on it
<fabbione> and it blocks pure warty -> hoary updates
<fabbione> UHA
<fabbione> i am running XORG!
<fabbione> i am running XORG!
* fabbione feels terribly alone
<tseng> fabbione: you rock ++
<fabbione> :-)
<fabbione> the upgrade seems to be pretty smooth
<fabbione> there are a few tons of things that needs checking tho
<hornbeck> fabbione: yes you do rock++ I can't wait to play myself
<daniels> fabbione: i've been running xorg for months (although back to xfree86 now), get with the program :P
<fabbione> daniels: but you suck :P
<fabbione> hornbeck: it won't take too long
<fabbione> daniels: the upgrade looks pretty good
<fabbione> there is not much that needs modification
<fabbione> daniels: specially because we kept the same name schema
<daniels> fabbione: cool :)
<fabbione> guys... daniels has is portion of credits too
<fabbione> s/is/his/
<daniels> fabbione: just eating my free croissants, then I'll head off and go over to your place and we can set up buildd and stuff there
<fabbione> daniels: setting up an upgrade bitch machine to torture
<fabbione> daniels: sure.. take the time you need
<daniels> fabbione: btw, the wireless here is really weird; none of the access points were active until 7am, and they were all off when I got back
<fabbione> daniels: do you remember how to come here?
<fabbione> daniels: hmmm i would give a kismet shot to the area..
<fabbione> i am sure there are more :-)
<daniels> GNAR
<daniels> would it be possible to limit hoary-changes to *only* messages from katie?
<daniels> fabbione: yah, catch the C line train to Islev
<daniels> fabbione: still got the sheet of paper
<fabbione> cool
<fabbione> daniels: for some reasons katie accepted xresprobe ubuntu3
<fabbione> but it has not been built
<fabbione> or better.. it did never hit the buildd
<fabbione> (fixing the build-dep)
<daniels> fabbione: eh, it'll get there in time
<fabbione> well.. i uploaded it yesterday evening
<fabbione> other packages after it have been already built
<fabbione> it's not a big deal
<fabbione> X.org installs fine without
<fabbione> but it doesn't build without ;)
<daniels> heh :)
<fabbione> daniels: remember that you need to stamp the ticket!
<fabbione> there are some red machines at the train station
<fabbione> if they catch you without the stamp is like 500DKK
<daniels> ahr
<daniels> holy crap, that's expensive
<daniels> like AUD160
<fabbione> if in doubts just ask to people
<fabbione> they are friendly with turists
<fabbione> ;)
<pasc> fabbione: with a face like this: http://fooishbar.org/gallery/syd-jul2004/acc
<pasc> ?
<daniels> fabbione: ok, heading off now
<fabbione> daniels: ok
<fabbione> pasc: ehehe
<fabbione> ok all lib* maint script revisited
<mdz> fabbione: morning
<mdz> fabbione: yes, there are several packages which need to move into main when the dust settles
<fabbione> mdz: ok. do you know what happened to the buildd yesterday?
<mdz> fabbione: I don't know what you mean
<fabbione> i uploaded xrender ubuntu3
<fabbione> accepted by katie
<fabbione> never built
<fabbione> other packages upload after have been built
<fabbione> there are no signs of build logs
<mdz> no idea, lots of other stuff has built fine
<fabbione> mdz: do you have access to check or do we have to wait for elmo/lamont?
* Mithrandir waves
<mdz> fabbione: I do not
<fabbione> ok
<fabbione> hey Mithrandir 
<Mithrandir> hiya fabio, how's .dk today?
* sid77 hello!
<daniels> Mithrandir: denmark is nice today
<Mithrandir> daniels: gotten any chocolate yet?
<daniels> not yet
<fabbione> Mithrandir: nice sunshine... amazing.. probably daniels took a slice of summer with him :-)
<Mithrandir> sounds nice
<mvo_> hi seb128 
<seb128> morning
<seb128> good morning mvo_ :)
<seb128> jdub: around ?
<vinsci> thanks, mdz
<bob2> thom: your dbus cvs packages ftbfs :)
<mvo_> anyone familar with discover1 out there?
<fabbione> mvo_: daniels is.. 
<daniels> sup?
<mvo_> daniels: is there a way to tell discover to load a module with certain parameters?
<daniels> not without hacking the code
<daniels> file an enhancement and assign it to me and I'll get it done
<mvo_> arggs :/
<daniels> is it urgent?
<daniels> i still have merge stuff to complete as well as x.org
<mvo_> not urgent, it's for #3154
<daniels> cool
<mvo_> there may be other ways to deal with the problem of the parameters
<daniels> well if you just want to file another one and mark it as blocking 3154, that'll probably be easiest
<mvo_> thanks. I'll first have a look if there is another (easier) way to solve the problem
<bob2> thom: and your Sources.gz is out-of-date wrt wireless-tools
<seb128> fabbione: "to 2004-01-01" ? You're restarting the same year again ? :)
<fabbione> ops
<fabbione> it was meant to be 2004-11-01
<carlos> seb128: 2004 is being a good year :-P
<seb128> :)
<robtaylor> hey all!
<robtaylor> hey, carlos! hows accessd going? i saw the post to the dbus list..
<Mitario> hi all
<Mitario> why aint I proud to be a dutchie :S
<maswan> elmo: well, we didn't seem to get too many mails tonight. we have dropped the partial cd mirror though, since we ran out of space hard yesterday.
<elmo> maswan: doh
<maswan> elmo: we're at 10 gigs free out of 400 now.
<Kamion> where were you mirroring CD images from?
<maswan> (well, strictly, 20 gigs out of 800, but all data counts twice since we do full replication)
<maswan> Kamion: same place, the releases directory
<Kamion> right
<maswan> # rsync --delete --delete-after --hard-links -aq rsync://archive.ubuntu.com/cdimage/releases /export/ftp/mirror/ubuntu-cdimage/releases
<maswan> elmo: but still, official mirorrs should probably have a private authorized module with a high enough max client count
<maswan> that way, hitting the max client count on the anon part doesn't hurt that much
<elmo> maswan: yeah, they will
<elmo> does anyone know why fakeroot's shared lib is u+s ?
<elmo> maswan: I've just been a bit crap about setting up proper mirror infrastructure so far
<maswan> elmo: ah, ok. let me know if you want a helping hand, assuming I'm not out travelling or so.
<Kamion> maswan: oh, don't use that one, use rsync://releases.ubuntu.com/releases
<Kamion> maswan: archive.u.c/cdimage/releases/ has a fair amount of junk in it, and we'll hopefully be able to get rid of it at some point
<maswan> Kamion: ah, ok. thanks. I'll change that for the still commented out ubuntu-cdimage part then.
* maswan discretely hits on how a couple of scsi disks would add a fast cdimage mirror over here. ;)
* Kamion glares at the apt-setup merge and wonders if Joey's preseeding changes will allow him to throw away some of the diff from warty
<elmo> Dear World, please stop finding security bugs in packages that are installed on any Linux machine.  kthxbye
<pitti> fabbione, daniels: did you see Matt's message with the libxpm patch?
<pitti> fabbione, daniels: do you think it is security relevant and must be fixed for Warty?
<pitti> elmo: +1
<pitti> fabbione: since an X build would probably last until tomorrow on my machine, can I ask you to prepare and test an updated package? In exchange I would fix this new security bug in apache...
* pitti likes trading cows
<fabbione> Kamion: what is the status of the installer for hoary?
<Kamion> fabbione: working on it :-)
<Kamion> fabbione: nearly there, but not quite yet
<fabbione> Kamion: cool.. do you have any ETA for when we can attempt the first clean hoary installs?
<fabbione> Kamion: i will have to test X.org on fresh installs pretty soon
<elmo> Kamion: dude - what's the easiest way to use a different kernel with warty installer?  I need a G5 friendly kernel
<Kamion> elmo: wget it, chroot /target dpkg -i before rebooting?
<Kamion> elmo: or do you need it in the installer too?
<Kamion> fabbione: later this week, at a guess. I'm buried in the base-config merge now
<elmo> need it in the installer - the existing kernel is unpatched, so won't boot AIUI
<elmo> I'll check tho
<fabbione> Kamion: cool
<Kamion> elmo: modules don't need to change, do they?
<elmo> kamion: nope, just your patch needs applying
<Kamion> elmo: if not, knock up a kernel-image .udeb with the new vmlinux and the same control information as the existing one, and drop it in place of the existing one on the CD
<elmo> netboot's an option, if that's easier
<Kamion> uh, I'm on crack, excuse me, kernel-image is irrelevant
<Kamion> elmo: either put the new vmlinux in /install/powerpc/ on the CD, or just replace the warty d-i netboot kernel with your custom one
<elmo> kamion: cool, thanks will try that
<elmo> the latter that is
<lamont> morning
<fabbione> hey lamont 
<lamont> morning fabbione
<lamont> hoary.all.amd64:libs/xrender_0.9.0-0ubuntu3: Installed [optional:out-of-date] 
<lamont> hoary.all.i386:libs/xrender_0.9.0-0ubuntu3: Installed [optional:out-of-date] 
<lamont> hoary.all.powerpc:libs/xrender_0.9.0-0ubuntu3: Installed [optional:out-of-date] 
<lamont> fabbione: or what was the issue?
<seb128> hi lamont 
<fabbione> lamont: elmo fixed it. thanks
<fabbione> lamont: ubuntu2 went in dep-wait
<fabbione> i fixed the deps in ubuntu3
<fabbione> but it was not unlocked automatically
<Kamion> daniels: you still looking for that syslinux upload? I didn't make it back to a screen last night
<daniels> Kamion: um yeah, if you could, that would be cool, thanks
<daniels> adelie has been radiating hate
<lamont> fabbione: ah, ok
* lamont takes kids to school
<geoff__> just installed to partition with xp. Looking good so far
<pitti> elmo: when you put my key into the upload keyring, you asked me which email address I wanted to use. Now that I have a @canonical address, this might be better suited. Do you have to change anything for that?
<elmo> pitti: no, *@canonical.com Just Works
<pitti> elmo: okay, thanks
<fabbione> elmo: when can i swap my gpgkeys?
<Kamion> did anyone make a decision on libelfg0/libelfg0-dev in main?
<Kamion> it's blocking debootstrap
<elmo> migrated
<Kamion> hm, libreadline5 too
<Kamion> not sure what we're doing about that
<Kamion> python wants it so it probably has to move to main though
<elmo> gar fuck
<elmo> libelf is one of the same version in warty/hoary things
<geoff__> how do I "uncomment" lines in /etc/apt/sources.list  to be able to download universe packages. Newbie
<thom> geoff__: you really want to be in #ubuntu for user support questions, this is the developemnet channel
<geoff__> Ok, sorry thom and thanks
<mjg59> Where's Mark at the moment? Still out of the country?
<elmo> yeah - he's reading email tho
<fabbione> mjg59: yes
<daniels> mjg59: in sidd iffrika
<mjg59> mark@canonical.com ?
<daniels> mark@hbd.com is his main one iirc, though he probably also gets mark@canonical
<elmo> yeah, either works
<Kamion> elmo: want a dummy libelf upload or something? :)
<elmo> no, there's a bunch of packages this affects, we can't fork them all just to move them between components
<elmo> I'm working on it - it just means making DB changes and stuff, meh
<Kamion> ok, I'll hack around it for now
<elmo> actually, no it doesn't.. I'll just brute force it
<daniels> it's a race to see who can hack the fastest
<Kamion> I'd've won already if my NET CONNECTION WEREN'T SO SLOW
<Kamion> of course this might have something to do with debmirror currently trying to suck down all of hoary/main+restricted
<mjg59> Kamion: Are you doing anything this evening?
<Kamion> not a lot
<mjg59> Fancy meeting to chat about the POST thing?
<daniels> Kamion: and it was only the other day you were saying something baout making my dialup explode :P
<Kamion> mjg59: yeah, that sounds like a plan
<winkle> Any reason for leaving jabberd2 out?
<daniels> winkle: no-one proposed it?
<winkle> Ok.
<plovs_work> who is admins@admins.warthogs... Thom or James?
<daniels> plovs_work: both
<plovs_work> daniels, thanks
<mvo_> ping doko
<Kamion> plovs_work: you need to know? :)
<Keybuk> Kamion: probably a matter of language ... elmo you ask nicely, thom you say "do this, bitch" <g>
<plovs_work> Kamion, need to sent a mail about the wiki and got two possible names
<thom> and people wonder why i ignore mail from scott
<thom> :P
<Kamion> plovs_work: if you need to send a mail, why not just use the role address?
<daniels> Keybuk: no, to elmo, you say 'dude! account! now!', and to thom you just smile sweetly
<mjg59> Kamion: Do you have pjc50's mobile number?
<Keybuk> interesting, and how long did it take you to get an account again?
<Kamion> yes
<mjg59> Could you /msg it?
<daniels> Keybuk: ehm, about three minutes after I asked thom :)
<enrico> elmo?  thom?
<daniels> Keybuk: that's how you get accounts created -- if you have any idea on how to get thom to Fabric, let me know :P
* thom -> lunch, belatedly
<daniels> gah, it would be truly useful if dput had substitution in the post_command_hook
<daniels> something like ssh trider-g7.int.fabbione.net wanna-build --needs-build %p, hypothetically
<Kamion> root@cairhien:/# base-config new
<Kamion> Terminated
<Kamion> I can see this is going well
<plovs> Kamion: thanks
<elmo> AAAAAAAAAAAAIEEEEEEE
<daniels> Keybuk: if you're drinking, put the glass down and swallow
<elmo> ocaml-native-compilers                     | ocaml                            | cdbs (Build-Depend) 
<elmo> what CRACK is that?
<daniels> elmo: ...
<fabbione> elmo: pure shit :-)
<fabbione> of the best quality
<mdz> morning
<Keybuk> mdz: what are you doing online?!  get out there and vote as many times as possible! :D
<mdz> Keybuk: hopped out of bed after realizing that my UTC offset had changed since the last tech board meeting :-)
<Keybuk> is there an agenda for this one?
<daniels> mdz: when is the next one?
<mdz> I think it's empty at the moment
<mdz> hmm, no, I seem to recall adding something to it
<mdz> daniels: every second week
<mdz> tuesday
<fabbione> elmo: i need a few packages on hoary chroots on both adare and yellow...
<Keybuk> http://wiki.ubuntu.com/TechnicalBoardAgenda  still thinks we're having the next one two weeks ago
<daniels> Keybuk: that's because it's the old wiki, foo'
<fabbione> elmo: adare: Unmet build dependencies: groff libpam0g-dev | libpam-dev rman lynx libpng12-dev | libpng-dev libxcursor-dev dbs libxrender-dev (>= 0.9.0)
<mdz> http://wiki.ubuntu.com/.* is dead
<elmo> fabbione: the yellow chroot isn't a real amd64 chroot btw
<fabbione> elmo: yellow: Unmet build dependencies: libglide2-dev (>> 2001.01.26) libxrender-dev (>= 0.9.0)
<mdz> http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda
<fabbione> elmo: hmmmm.. i think it will do..
<mdz> Keybuk: we're going to talk about how you're going to work the merge magic on an ongoing basis for hoary :-)
<fabbione> elmo: isn't that chroot created from warty -> hoary upgrade?
<Keybuk> are we?  that's nice :o)
<Keybuk> hmm, changing timezones plays hell with Evolution's ongoing calendar
<fabbione> elmo: btw.. (hoary-chroot)fabbione@adare <- good | fabbione@yellow <- no good
<elmo> fabbione: no, I did a new one, 'cos I'm stupid.. I'll redo it in asec
<fabbione> elmo: ok.. let me logout
<fabbione> elmo: done.. it's all free (my side)
<elmo> Kamion: fyi, I did almost all the outstanding syncage, you should be good now
<elmo> ohh... which means, the testing output just became usable again..
<elmo> hmm, except it's all on crack.. anyway blah
<elmo> fabbione: done adare
<mdz> tech board meeting in #ubuntu-meeting
<daniels> elmo: please sync xfsprogs_2.6.20-1
<Keybuk> elmo, mako, anyone else: #ubuntu-meeting
<mdz> Kamion, fabbione, thom, anyone
<daniels> fabbione is moving a washing machine at the moment, sort of
<elmo> umount: /srv/chroots/warty-chroot/proc/: device is busy
<daniels> he'll be there
<thom> already there :-)
<elmo> daniels: done
<daniels> elmo: thanks
<elmo> anyone know how to trace down _why_ it's busy?  lsof is unhelpful
<elmo> there's nothing else bind mounting that directory or anything silly - other /proc chroot mounts umounted successfully
<daniels> elmo: quilt 0.35-1.1 kthx
<elmo> daniels: done
<daniels> ta
<fabbione> elmo: thanks
<fabbione> dchroot -c hoary
<fabbione> Executing shell in 'hoary' chroot.
<fabbione> No directory, logging in with HOME=/
<fabbione> fabbione@yellow:/ $ 
<daniels> elmo: re2c 0.9.1-6 plz
<fabbione> elmo: are you rebuilding yellow too?
<elmo> fabbione: see above about proc
<mvo_> mdz: upgrade-notifier is ready for first upload. can I just upload it? 
<mdz> mvo_: sure
<mdz> long live horay
<mdz> hoary
<mvo_> mdz: it contains a cron-job that will do a daily "apt-get update" and is dbus-ified so updates/package manager runs will result in recalculation of the cache
<mdz> mvo_: hmm
<mdz> I had thought that the cron job would be part of apt
<fabbione> elmo: fuser ?
<mvo_> mdz: we can of course do that as well, but my reasoning was that it should be easy for the user to disable this notification stuff. in that case he only has to uninstall the upgrade-notifier and no more cron and icon. 
<mdz> mvo_: but there are other reasons to update the lists from cron, without upgrade-notifier
<thom> elmo: please can you sync mozilla-firefox from unstable?
<fabbione> elmo: i can see several files open in the warty-chroot
<elmo> SKIP (too new)
<elmo> Rejected: syslinux_2.11-0.1ubuntu1.dsc refers to syslinux_2.11.orig.tar.gz, but I can't find it in the queue or in the pool.
<elmo> someone
* fabbione hands elmo chroots/<whatever>/usr/sbin/policy-rc.d 
<fabbione> #!/bin/sh
<fabbione> exit 101
<mdz> mvo_: I suppose we need to provide some way to enable/disable it, though
<mdz> I'm a bit nervous about having apt run the cron job by default, too
<mdz> though it's something that I do practically everywhere
<mvo_> same here :)
<thom> elmo: backuppc also
<elmo> thom: both done
<Kamion> elmo: arse, ok, will fix
<Kamion> I've uploaded the base-config merge; however, I expect it to break, because I haven't been able to test it fully and it was very complicated. I figure nobody will notice because the rest of the installer doesn't work yet :-)
<thom> danke
<fabbione> Kamion: cool :-)
<fabbione> Kamion 
<fabbione> if you want i can upload X now.. so nothing will work.. full stop
<fabbione> we can share the blames :-)
<Kamion> if you like :-)
<fabbione> Kamion: don't temp us.. we are almost ready :-)
<daniels> gnah
<fabbione> (... to break world ;))
<daniels> Kamion: sorry, my bad
<Kamion> daniels: no, my fault for not building with -sa
<Kamion> elmo: I've re-uploaded the .orig.tar.gz and the .changes; is that enough, or do I need another full upload?
<elmo> no, it's not, but I've fudged it
<daniels> Kamion: thanks for the sponsoring
<daniels> Kamion: feels just like the KDE-maintaining days ;)
<Kamion> :-)
<Kamion> elmo: thanks
<Kamion> you'd think I'd know the gotchas by now
* Riddell would happily take over the KDE-maintaining
<zul> bleah..
<daniels> Riddell: it's yours! take it! please!
<daniels> Riddell: (the reference was when I was running around #debian-devel, harassing everyone I knew to sponsor my KDE uploads)
* bluefoxicy is away: Voting for the president. . . go bush
<Riddell> unfortunatly I'm not a debian developer, and I don't have time to do KDE for Ubuntu (unless they pay me)
<daniels> Kamion: is the right fix for 1685 to hardcode to another location, or is leaving it to $PATH secure enough?
<daniels> Riddell: i wasn't a DD when I maintained KDE ...
<Kamion> daniels: can't use $PATH
<Kamion>         if (!options.xauth_location ||
<Kamion>             (stat(options.xauth_location, &st) == -1)) {
<Kamion>                 debug("No xauth program.");
<Kamion> it'll have to be hardcoded to /usr/bin/X11/xauth, if that's the right fix
<daniels> the violent apoplectic spasms of rage /usr/bin/X11/xauth induces in me aren't much less violent than /usr/X11R6, I'm afriad
<daniels> i'd like to cycle through /usr/bin/xauth, /usr/bin/X11/xauth, and /usr/X11R6/bin/xauth
<daniels> ideally
<Kamion> meh
<Kamion> I'd rather fix it to look on $PATH than do that, I think
<Kamion> assuming $PATH is sensible at the start of the session
<elmo> Keybuk: universe is in needs-merged.txt now too
<Keybuk> cool
<Kamion> daniels: it's kind of awkward since you could get an x11-req message before login processing happens
<pitti> mdz: Hi! if you have a minute, can you please review #3126?
<pitti> mdz: again, s/if/when/
<mdz> pitti: I do not think there is a vulnerability there
<mdz> joeyh opened the same bug, and I closed it
<mdz> the script runs with set -C
<Kamion> I have C path-searching code in man-db that I could use, but it's a bit bulky; giving it a list for xauth_location might be less intrusive :-/
<daniels> Kamion: ah
<Kamion> daniels: when do you need this fixed by?
<daniels> Kamion: ehm, grumpy
<daniels> since it was decided that we weren't doing the whole modular thing for hoary
<Kamion> oh :)
<pitti> mdz: hmm, so this is a mere DoS problem then
<Kamion> ok, well, I'll try not to forget anyway
<mdz> pitti: I do not think there is even a significant DoS
<pitti> mdz: the DoS part does not scare me
<pitti> mdz: I just thought that the scripts were unsafe when runned in /tmp/
<daniels> Kamion: so, tell me, is reformatting the entire sis section in discover1-data total crack?
<daniels> Kamion: i'm thinking that the magic 8-ball says 'bongsipper' to retabbing the whole thing
<lamont> bbiab
<Kamion> daniels: tabs are significant there; what exactly do you mean?
<daniels> Kamion: tabbing it all out to be a consistent width
<Kamion> daniels: actually, I *think* only the first four tab characters are significant, but I'd still be inclined to leave it alone
<daniels> Kamion: 'kay
<thom> what are .gmo files, and can i treat them with the contempt they seem due and blow them away in a clean target?
<Kamion>   if(line[0]  == '\t'){
<Kamion>     sscanf(line, "%08lx\t%12s\t%32s\t%256[^\n] \n",
<Kamion> thom: compiled .po files; you can blow them away
<elmo> thom: I do
<thom> thanks
<daniels> hoary has firefox 1.0RC?
<thom> mozilla-firefox | 0.99+1.0RC1-2 |         hoary | source, i386
<fabbione> elmo: thanks for fixing yellow :-)
<elmo> fabbione: libglide2-dev doesn't exist?
<mdz> thom: yay
<elmo> thom: err, didn't that, like trash all our branding?
<mdz> libglide2-dev | 2002.04.10-8ubuntu1 | http://archive.ubuntu.com hoary/main Packages
<elmo> mdz: for amd64 :P
<elmo> actually, fabbione probably ran dpkg-checkbuilddeps in the old (i386) chroot, which would explain it, so nm
<mdz> Filename: pool/main/g/glide/libglide2-dev_2002.04.10-8ubuntu1_i386.deb
<thom> elmo: yes. there is method to my madness tho
<thom> don't worry :-)
<fabbione> elmo: it's ok..
<elmo> okay, that needs-merged.txt is updated whenever new packages are installed now too
<fabbione> elmo: no i used dpkg-buildpackage in the chroot
<elmo> fabbione: dpkg-buildpackage calls dpkg-checkbuilddeps ..
<fabbione> anyway.. dpkg-buildpackage was happy with what you did :-)
<elmo> k
* bluefoxicy is back (gone 00:37:06)
<Kamion> cjwatson@rookery:~/public_html/seeds$ tla register-archive https://chinstrap.warthogs.hbd.com/~cjwatson/ubuntu-devel@lists.ubuntu.com
<Kamion> unable to access URL: /~cjwatson/ubuntu-devel@lists.ubuntu.com/.listing
<Kamion> I'm confused, that shouldn't be a 302
<Kamion> webdav error: 302 Found
<daniels> elmo: lolz syck 0.42-5 tia
<daniels> Kamion: it shouldn't be going for a .listing unless webdav is broken
<Kamion> bleh, it isn't doing https properly
<Kamion> how'm I supposed to cron this?
<Kamion> I'm not giving rookery unfettered access to chinstrap, and I don't want the public copy to be behind a passworded apache
<Kamion> daniels: I deliberately set up a .listing just in case, that's not really the problem
<thom> bleh, you should probably use baz
<Kamion> happy to, but it's not on rookery
<daniels> elmo: xosd 2.2.11-3
<thom> i don't think we ever fixed the tla in warty to talk https
<Kamion> nor chinstrap, for that matter
<daniels> elmo: (please)
<Kamion> fuck it, I'll rsync the archive to rookery using a restricted ssh key
<daniels> Kamion: oh, I know why it might be
<Mitario> hey everyone
<mvo_> hi Mitario 
<mvo_> I uploaded the upgrade-notifier in the archive today :)
<Mitario> cool! :)
<Kamion> daniels: it's ignoring https: and trying to talk to port 80, so it gets a redirect
<Mitario> with cronjob?
<mvo_> without, mdz suggest to put it into the apt package itself
<Mitario> yeah, good point
<mvo_> but we'll have to make it a configurable item first
<mvo_> not everyone wants a cronjob
<mvo_> I need to do some shoping, will be back in ~30min-1h
<Mitario> ok
<pitti> mdz: can you please review #2771 at some time? TIA
<daniels> Kamion: ah
<Mitario> brb, food
<mdz> pitti: so many bugs :-(
<pitti> mdz: in fact we only need to fix a few of the original list of the trustix patch
<mdz> pitti: is there no official patch upstream yet?
<mdz> pitti: it might be worthwhile to mail bod or upstream
<pitti> mdz: I just looked into the "cvs" (they have a slightly different thing there)
<pitti> mdz: apparently they fixed stuff, but they rewrote half of the code
* mdz hugs upstream
<pitti> mdz: and upstream uses a very odd method to generate a valid tmpname, and there is still a race condition
<mdz> pitti: I see no problems with your patch; I assume you ran the test suite to test it?
<pitti> mdz: of course
<pitti> mdz: it is automatically done during the build, BTW
<pitti> mdz: I also ran the affected programs manually
<mdz> pitti: none of the code is installed, correct?
<mdz> it is only tests?
<pitti> mdz: the *.t files are not installed
<mdz> oh, some of it is
<mdz> ExtUtils and Devel
<pitti> mdz: but the other files are
<Kamion> elmo/thom: could I have gpg on rookery?
<pitti> mdz: that's why I rewrote PPPort.pm
<Kamion> (for archive signature checks on the tla get I'm about to do)
<pitti> mdz: there, a simple tmp$$ in the current directory is inappropriate
<pitti> mdz: instmodsh is also installed, but it got a proper tmpfile handling, too
<pitti> mdz: okay, I uploaded the thing and will process it when it built
<daniels> elmo: can you please sync gnutls10 1.0.4-8?
<Kamion> ok: tla register-archive sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com
<Kamion> tla get ubuntu-devel@lists.ubuntu.com/seeds--hoary--0
<Kamion> it's a signed archive, so before committing to it please make sure you have 'gpg --clearsign' or similar in ~/.arch-params/signing/=default
<Kamion> updates mirrored to http://people.ubuntu.com/~cjwatson/seeds/ with a maximum lag of about 17 minutes
<mdz> Kamion: thanks
<zul> anyone working on a sparc port? :)
<Kamion> I'll mail that stuff to the list once germinate works on it
<mdz> zul: some people have expressed interest, including fabbione I believe
<fabbione> yes
<fabbione> i am still waiting to get my sparc back
<zul> cool..what does one have to do to get started?
<fabbione> i am seriously fedup
<fabbione> zul: mail lamont :-)
<fabbione> ;)
<zul> heh
<Kamion> elmo: you're not running germinate against sid any more, are you?
<Kamion> actually, never mind, will do it a different way
<elmo> daniels: done
<elmo> Kamion: done
<daniels> elmo: thanks dude
<Kamion> ta
<elmo> pitti: your perl upload has a bogus version number
<pitti> elmo: argh; I'll fix it
<pitti> elmo: can the packages be removed from the queue?
<Kamion> what was that CONFIG_PCI_MSI change purported to fix?
<elmo> pitti: ugh - yes, with a lot of manual hacking
<pitti> elmo: I'm sorry for that
<pitti> elmo: it isn't sufficient to remove the package from accepted/?
<pitti> elmo: problem is, that 2ubuntu0.1 is smaller than 2.1
<pitti> elmo: I can also call the next upload -2.1ubuntu0.1; also ugly, but maybe easier
<elmo> pitti: doesn't matter, I've done it now
<pitti> elmo: thanks a lot!
<Kamion> germinate mainline now has a -s/--seed-dist option that you can use to pick a different seed
<Kamion> you'll likely want to use -s hoary -d hoary (i.e. get both seeds and Packages/Sources files from hoary)
<elmo> Out-of-date BUT modified:  54 (5.16%)
<elmo> Out-of-date BUT modified: 131 (1.48%) <-- main+universe ^--- just main
<mdz> hmm
<mdz> only 18 bugs remaining, I guess there have been quite a few debian changes
<Kamion> fabbione: may be incoming call for you/daniels from sabdfl about some weird X configuration thing he's battling with
<Keybuk> isn't he supposed to be on a plane at the moment?
<Kamion> fabbione: do we still need germinate support for your IPv6 dump thing? I'm thinking that if it's still needed it might be better to split it out into a separate tool
<Kamion> Keybuk: didn't sound like it when he called me a few minutes ago while doing an installation :)
<Kamion> unless he's got the ultra-first-class plane seat with lots of computers scattered around him
<fabbione> Kamion: i am on the phone with him right now
<fabbione> Kamion: thanks :-)
<Kamion> daniels: ugh, syslinux/amd64 failed, guess I'll have to poke at that here
<Mithrandir> failed to merge, failed to build or failed to work?
<Kamion> build
<Kamion> bugger, I'm late
* Kamion flees
<Mithrandir> argh, my dsl is either dead or on a different IP.
<thom> suckage either way
<Mithrandir> thom: could I get nasm and netpbm in the hoary chroot on yellow?
<thom> amd64 or i386, or both?
<Mithrandir> it only has hoary-amd64
<thom> ah, right
<thom> easy answer then ;-)
<carlos> could anyone suggest me a warty/hoary package with .po files to translate the debian package templates?
<thom> apache
<Mithrandir> mailman
<carlos> ok, thanks
<mdz> seb128: where do these eggdesktop messages come from?
<seb128> which ones ?
<mdz> seb128: the ones seen during postinst with some packages in hoary
<seb128> oh, update-desktop-database
<mdz> seb128: have you looked for the cause?
<seb128> probably the mplayer .desktop, I don't have it installed but according to some users it has 4 [Desktop Entry]  entries
<mdz> ah
<mdz> yeah, just looked at strace
<mdz> removing mplayer.desktop fixes it
<seb128> ok, that's it
<mdz> it also complains about gftp, but in a much nicer way :-)
<mdz> Could not parse file '/usr/share/applications/gftp.desktop': desktop entry contain line 'Desktop Entry] ' which is not an entry, group, or comment
<seb128> I'll take care of the gftp problem
<seb128> anybody has planned a mplayer update and want to fix this one ? :)
<mdz> seb128: is it simply malformed?
<thom> Mithrandir: done
<seb128> I've not looked on the source, so not sure if it's generated or fix
<seb128> but basically it should get only one [Desktop Entry]  
<mdz> so it should be split into several .desktop files?
<seb128> yes
<seb128> I'm downloading the source
<seb128> just to be sure
<Mithrandir> Kamion: weird, builds fine now.
<mdz> seb128: actually I have no idea what it is doing
<mdz> seb128: it seems to have several copies of exactly the same [Desktop Entry] 
<Mithrandir> thom: uhm, please run apt-get update in the chroot as well?
<seb128> mplayer is crap, that's not new :p
<seb128> (still downloading
<mdz> true
<seb128> )
<seb128> hum, ./etc/mplayer.desktop is fine, ./debian/mplayer.desktop is fucked
<seb128> I blame Marillat
<thom> Mithrandir: i did
<Mithrandir> thom: you did indeed, thanks.
<Mithrandir> thom: but you ran that after installing the build-deps, I think, as mingw32 is missing
<thom> nope
<Mithrandir> : tfheen@yellow(hoary-chroot) ~/syslinux/syslinux-2.11 $ dpkg-checkbuilddeps 
<Mithrandir> dpkg-checkbuilddeps: Unmet build dependencies: mingw32
<thom> uh, you just asked for nasm and netpbm, dude
<thom> i've now got the build-deps installed ;-)
<seb128> mdz: dunno why Marillat duplicated the same stuff several time. I'm going to upload a package with only one entry that should be fine
<mdz> seb128: sounds good
<Mithrandir> thom: ok, I'm silly then.  Please, mingw32 as well, with sugar, sans chocolate, with tea on top?
<thom> heh :-) done already
<Mithrandir> thanks :)
<Mithrandir> why do we need syslinux, btw?  Is it used for the cds?
<mdz> Mithrandir: yes, for isolinux
<mdz> though perhaps we should consider moving to grub
<Mithrandir> we should just use grub, at least on amd64
* Mithrandir kicks syslinux's makefiles
<mdz> grub wouldn't boot the morphix CD on my old laptop
<mdz> but it booted a Debian CD with isolinux fine
<Mithrandir> was that an amd64 box? :)
<mdz> no, i386
* mdz ponders an "old" amd64 laptop :-)
<Mithrandir> yeah, i386 is full of quirks, amd64 should be a lot better, so I was suggesting just to change for amd64, not i386.
<winkle> seb128: missing python-gtk2-doc, any plans to include it?
<Mithrandir> and memdisk doesn't compile and there's _no_ way it could be compiled on i386 either.
<seb128> python-gtk2-doc:
<seb128>   Installs: (aucun)
<seb128>   Candidat: 2.4.10-2ubuntu1
<seb128>  Table de version:
<seb128>      2.4.10-2ubuntu1 0
<seb128>         500 http://archive.ubuntu.com hoary/multiverse Packages
<seb128> winkle: not missing
<winkle> sorry, lacked multiverse
<seb128> np
<seb128> but dunno why it's here
<seb128> it should be in main
<winkle> yeah
<seb128> I've added it to the seed before the warty release IIRC
<jdub> "Ubuntu is great only thing missing is encrypted IM."
<jdub> only thing missing, dudes
<jdub> we have our hoary work cut out
<seb128> jdub: !!
<jdub> hey seb128 
<seb128> jdub: evo 2.1.0 will take a few days
<seb128> they changed all the libs names in e-d-s, so we have to renamed all the binary packages
<jdub> oof
<jdub> for us, that'll be two transitions in a week or so ;)
<seb128> and  it would be better to have the same name in debian/ubuntu ... so I've mailed kitame with a summary of the renaming
<seb128> I'm waiting to know if he's ok with that
<thom> holy crap. someone just used KDE and simplicity in the same sentence
<Mithrandir> two points to whoever sees what's wrong:
<Mithrandir>         $(LD) -nostdlib $(LDFLAGS) $(CFLAGS_ARCHDEP) -Wl,-Ttext,0 -o $@ $^
<Kamion> Mithrandir: hm, I don't see CFLAGS_ARCHDEP and ASFLAGS_ARCHDEP actually being passed from debian/rules to the Makefile
<Mithrandir> Kamion: they're not, but this sticks a fair bit deeper than that.
<Kamion> I don't think so?
<Mithrandir> the debian package builds, though, but clean is FUBAR.
<Kamion> -               $(MAKE) CFLAGS="$(CFLAGS)" CFLAGS_ARCHDEP="$(CFLAGS_ARCHDEP)" ASFLAGS_ARCHDEP="$(ASFLAGS_ARCHDEP)" LDFLAGS="$(LDFLAGS)" VERSION="$(VERSION)" DATE="(Debian, $(DATE))"
<Mithrandir> remember, we've broken gcc-3.3's 32 bit support
<Kamion> +###            $(MAKE) CFLAGS="$(CFLAGS)" CFLAGS_ARCHDEP="$(CFLAGS_ARCHDEP)" ASFLAGS_ARCHDEP="$(ASFLAGS_ARCHDEP)" LDFLAGS="$(LDFLAGS)" VERSION="$(VERSION)" DATE="(Debian, $(DATE))"
<Kamion> +               $(MAKE) VERSION="$(VERSION)" DATE="(Debian, $(DATE))"
<Kamion> that's from the syslinux 2.04-2ubuntu1 -> 2.11-0.1ubuntu1 diff
* Riddell looks at thom through narrowed eyes
<mvo_> ping doko
<Kamion> elmo: might want to pull mingw32 and deps in from universe for syslinux?
<Mithrandir> Kamion: are you whacking the package or should I?
* lamont returns from a fire call.
<Kamion> Mithrandir: is it more than just adding CFLAGS_ARCHDEP and ASFLAGS_ARCHDEP? I can do that now, just pulling in build-deps
<sivang> lamont : are you a fireman ?
<Kamion> Mithrandir: ... on the other hand I have a thumping headache. Go ahead.
<lamont> sivang: yes
<Mithrandir> Kamion: I'll do it, it's a bit more, since the version in Debian is borken atm.
<lamont> sivang: although this time, all we did was stand around with 3-dozen or so law enforcement types until they were done..
<lamont> 1 dead, 3 in custody, or something like that
<Kamion> Mithrandir: mkay, thanks
<Kamion> well, it *builds* for me with those two additions anyway, I'll leave making it work up to you
<Mithrandir> Kamion: on amd64?
<Kamion> yep
<Kamion> you're working off the merged version in hoary?
<Mithrandir> yes
<Kamion> -               $(MAKE) VERSION="$(VERSION)" DATE="(Debian, $(DATE))"
<Kamion> +               $(MAKE) CFLAGS_ARCHDEP="$(CFLAGS_ARCHDEP)" ASFLAGS_ARCHDEP="$(ASFLAGS_ARCHDEP)" VERSION="$(VERSION)" DATE="(Debian, $(DATE))"
<Kamion> that's all I did
<Mithrandir> ok
<Mithrandir> Kamion: hm, it builds now, yes.  I need to test it at home, though.
<Mitario> nite all
<sivang> night
<mdz> seb128: hmm, dist-upgrade in hoary removes trashapplet? was it merged into gnome-applets or something?
<Craigory> Hello, I just read the Ubuntu review here: http://www.osnews.com/story.php?news_id=8754
<Craigory> One complaint they had was with the difficulty in editing the gnome applications menu.
<seb128> mdz: yes, gnome-applets 2.9.1 conflitcs/provides/replaces it
<mdz> seb128: ah, neat
<Craigory> I think it might be a good idea to add an entry in applications:/// called "Edit Menu" or some such.  That's what I have done on my installation.
<Craigory> Or perhaps in the "Computer" menu.
<jdub> Craigory: menu editing is largely broken, so keeping it out of the public eye is healthy for the time being
* lamont wanders for a bit
<mdz> jdub: everything should be syncing from sid automagically unless it's modified
<jdub> hrm, maybe it hasn't got past NEW in debian yet
<seb128> it was in incoming today
<seb128> you're speaking agout gst-python, right ?
<jdub> yeah
<seb128> http://ftp.debian.org/debian/pool/main/g/gst-python/
<seb128> it's here
<jdub> rad
<seb128> are we going to sync openoffice 1.1.3 from experimental ?
<seb128> the new package has the gnomevfs support :)
<jdub> rad
<jdub> filechooser?
<seb128> not tested yet, but:
<seb128>    * New major patches:
<seb128>      - vfs-*: GNOME VFS Support [MM] 
<seb128>        [ This means we now have integrated all of the major Ximian
<seb128>          patches and thefore this closes: #201494 ] 
<seb128> so probably
<seb128> hum
<seb128>   * New packages: [RE] 
<seb128>      - openoffice.org-gtk-gnome: Gtk UI Plugin and GNOME File Picker for
<seb128>                                  OpenOffice.org
<seb128>      - openoffice.org-gnomevfs: GNOME VFS support for OpenOffice.org
<seb128>      - openoffice.org-evolution: Evolution Adressbook support for
<seb128>        OpenOffice.org
<seb128> 
<seb128> nice nice nice :)
<jdub> elite
<jdub> mdz: linux-source you just upped to hoary -> worth a warty-update?
<jdub> seb128: hahaha, dude
<jdub> seb128: the 'install samba' and 'install ntp' buttons ROCK
<seb128> yeah :)
<jdub> seb128: although the time/date thingy doesn't really handle ntp being installed underneath it very well ;)
<seb128> yeah, need some improvements :/
<jdub> but it is cool!
<jdub> uh oh
<jdub> oh
<jdub> never mind
<jdub> seb128: i think s/SMB/Windows Networking/ in the dialogue would make sense
<lamont> jbailey: glibc build this time (2.3.2-18ubuntu1)
<jbailey> lamont: Still seing the failure?
<seb128> jdub: hum, probably yes
<seb128> hey jbailey !
<lamont> jbailey: not with this one
<jbailey> Heya sb!
<jdub> seb128: heh, all the g-s-t tools crash on close for me - same there?
<jdub> yo jbailey!
<jbailey> lamont: Hmm.  Strange.  It was never consistant for me, but I haven't seen it in a while.  There shouldn't be anything between -13 and -18 to change that though.
<jbailey> jdub: Namesake!
<seb128> jdub: yes, and also in the bugzilla
<jdub> seb128: rock
* lamont remembered to go to the poles and vote against the candidate that scares him more.
<lamont> seb128: are you working through the gnutls1[01]  change?
<seb128> lamont: that's on my list yes
<lamont> ok
<seb128> but doing the evolution 2.1.0 stack for the moment :)
<elmo> kamion: gar.  we really have to pull in mingw32?
<mojo_> hi all ppl
<Kamion> elmo: dunno the rationale
<Kamion> Mithrandir: ^-- ?
<mojo_> can someone look at the /etcS.d/S50hwclock.sh please?
<mojo_> it found some weird syntax error there
<mojo_> /etc/rcS.d/S50hwclock.sh please?
<mojo_> /etc/rcS.d/S50hwclock.sh: line 118: syntax error near unexpected token `('
<mojo_> /etc/rcS.d/S50hwclock.sh: line 118: `           log_success_msg "start sets kernel (system) clock from hardware (RTC) clock" >&2'
<Kamion> ok, will do
<pitti> mojo_: indeed...
<pitti> mojo_: the error is on line 96, an unterminated string
<pitti> aaaaaaargh!
<Kamion> pitti: you on it already, or shall I fix?
<pitti> mojo_: thanks for this! 
<pitti> Kamion: I just fixed it inline in my system, but I don't yet have the package
<pitti> so go ahead if you have it
<pitti> Kamion: I guess the pretty and quiet init scripts don't only have advantages...
<mojo_> so u fix it pitti?
<mojo_> and upload it
<Kamion> mojo_: I'm doing it now
<Kamion> (unless lamont beats me to it, since he's more the maintainer than I am :))
<mojo_> hehe
<Kamion> uploaded
<mojo_> cool
<mojo_> things get buggy these day heh?
<mojo_> but I love buggy stuff
<Kamion> merges are like that sometimes, they're a very complex business and quite error-prone
<jdub> o/~ that's what hoary's for... in good times, and bad times, i'll be filing bugs for evermore... that's what hoary's for... o/~
<mojo_> hehe
<mojo_> coding is a bit spiky like Hedgehog
<lamont> Kamion: just hoary, or is it a debian bug too?
<Kamion> just hoary
<Kamion> I checked :)
<lamont> cool
<Kamion> it's in the pretty-init-script stuff
<Kamion> sorry to preempt, seemed urgent
<Kamion> then again, I always did like preemptive bridge bids :)
<mojo_> lamont, kamion: closed this bug on bugzilla too
<lamont> Kamion: np
<mojo_> who is the maintainer of evolution?
<mojo_> bob2?
<mdz> Kamion: if you fixed hwclock, there's a bug in bugzilla open about it which should be closed, if you haven't already
<seb128> mojo_: I'm doing the evolution uploads, why ?
<Kamion> mdz: done
<mojo_> seb128: something wrong with the 2.02
<seb128> what ?
<mdz> Kamion: another one just came in (#3179)
<mojo_> seb128: run it, it works,
<seb128> ?
<Kamion> mojo_: this sort of thing tends to be better done through the BTS than by finding the maintainer on IRC ...
<mojo_> seb128: then it breaks whole my apt/source.list
<mdz> lamont: what happened with that bug?
<mojo_> seb128: I dun have such prob with Debian 'sid'
<seb128> mojo_: evolution breaks your sources.list ?
<seb128> are you sure that's evolution ?
<mojo_> seb128: yeah, so weird!!!
<mojo_> seb128: yeah, I tested many times but can't find the answer, I think u put something wrong in the package
<seb128> why do you say that's evolution ?
<lamont> mdz: ECONTEXT?
<Kamion> mojo_: don't file random bugs against base-config in future, though, please :-)
<seb128> mojo_: the current package is the debian one
<mojo_> seb128: cause whenever I run it, it breaks
<mojo_> seb128: weird!!
<mdz> lamont: hwclock syntax error, came in Sunday
<lamont> mdz: I think that's the one that kamion just uploaded the fix for
<seb128> mojo_: what is changed in the sources.list ?
<mdz> lamont: yes, it is
<mojo_> seb128: maybe I was wrong, but I am sure that evolution stops and freezes sometimes at wizard choosing time zone
<lamont> mdz: and the question is how did it get there?
<mojo_> seb128: all the text been deleted
<lamont> merge screwup, I expect.
<mdz> lamont: no, the question was why it didn't get the trivial fix sooner
<mojo_> seb128: btw, I leave this for u, hope u find some answer for it
<lamont> mdz: good question - was dealing with merges of other packages yesterday, and it got lost in the pile of bugs, I expect.
<seb128> mojo_: yes, the freeze bug has been reported 
<mojo_> are ppl reconsidering to have a deb for Helix Player in Hoary?
<lamont> mdz: house guest this week is also messing a bit with productivity, to be followed next 2 weeks with me being elsewhere and able to focus better.
<Kamion> mdz: so, anything obvious that I should be adding to the hoary seeds straight away?
* Kamion wants to get debootstrap germinate-generated ASAP
<elmo> kamion: the stuff you had me add
<elmo> preseed
<Kamion> elmo: most of that was dependencies?
<Kamion> oh, ok
<elmo> grepmap
<mdz> libglide
<mdz> fam->gamin
<mdz> esd->polypaudio
<mdz> lm-sensors
<mdz> bluetooth
<mdz> that's what I have on my list
<mdz> some of those need elaboration and discussion, though
<elmo>    o upgrade-notifier
<seb128> jdub: running evo 2.1.0 now :) I'll try to get a reply from Kitame tomorrow and then upload the new evo stack :)
<mdz> jdub: are we clear for fam->gamin and esd->polypaudio?
<jdub> mdz: clear for gamin, not clear for polypaudio
<jdub> seb128: rawk :)
<mdz> Kamion: go ahead with s/fam/gamin/ if you're editing; that's been discussed already
<seb128> big fight for polypaudio
<elmo> seb128: can you fix evo1.5 while you're there; as in kill it?
<elmo> kamion: download-installer too
<mdz> fabbione: which libglide package do we want in desktop?
<elmo> kamion: and ssh
<seb128> elmo: the 1.5 have been removed with the merges, haven't they ?
* lamont must go fetch children
<elmo> seb128: hmm, yeah, it ought to have been killed as cruft, it's not built from source - sorry
<mdz> elmo: do you remember the outcome of the archive key management discussion we had a while back?
<seb128> elmo: ok, np
<lamont> mdz: fwiw, 3105 showed up on my doorstep this morning about 10 AM
<mdz> having that stuff straightened out is the only prerequisite for getting apt 0.6 into hoary
<elmo> mdz: which one - we've had at least 3 or 4 :/
<mdz> lamont: it came in before 0400 2004-11-01, so 10-31 your time
<Kamion> file-preseed, network-preseed, download-installer added; s/fam/gamin/ done
<mdz> lamont: mail problems?
<seb128> jdub: good time to switch epiphany from mozilla to firefox I guess ? :)
<thom> seb128: you so should do that now
<lamont> mdz: sorry - wrong mail message.
<Kamion> s/openssh-server/ssh/ done
<seb128> thom: ok, let's go for it :)
<thom> you need anything from firefox?
<lamont> original report arrived monday 08:09 AM
* jdub gets out the riot suits and rubber bullets.
<elmo> thom: this is the method? :P
<lamont> anyway, back in a biut
<Kamion> mdz: where do lm-sensors and bluetooth need to go?
<thom> elmo: eh? 
<elmo> in your madness...
<thom> oh, right
<thom> heh
<seb128> thom: no, that's fine, just need to switch a build flag for epiphany
<thom> multi-hour comments don't work too well for me right now, too tired :/
<jdub> thom: how'd ff theme and stuff go?
<elmo> gar, I wish sh had a -x flag that showed redirections too
<thom> jdub: still working on it; forms worked no problems, themes need more love
<Kamion> does -v help?
<Kamion> might need to use -vx which is super-noisy
<jdub> thom: cool, hard to get additional theme into the package and set as default, or...?
#ubuntu-devel 2004-11-14
<Kamion> how do I make commit mails happen with arch?
<thom> just struggling to work out the magic to let firefox know it's a theme
<thom> it's shipped and all without problem, and i know how to make it the default
<pitti> Kamion: ~/.arch-params/hook
<pitti> Kamion: it gets called with $1 == action (e. g. "commit") and some environment variables which show the archive and revision and so on
<pitti> Kamion: http://www.gnu.org/software/gnu-arch/tutorial/using-hooks.html
<Kamion> ~/.arch-params/hook isn't acceptable here, this is a shared archive
<Kamion> looks like I'll need a cron job on chinstrap or something
<Kamion> mdz,jdub: what do you think of a seed-changes list?
<jdub> thom: heh, bong.
<jdub> Kamion: mailing list?
<Kamion> yeah
<jdub> Kamion: BONG!
<Kamion> I'll take that as a no, shall I? :)
<jdub> ;-)
<elmo> I could make teri send notifications
<jdub> seems like overkill
<jdub> Kamion: maybe daily updates to -devel?
<elmo> mdz's been asking me to make lorraine do that for a good 6 months now
<Kamion> diffs between yesterday and today, something like that?
<thom> he, we could get some hot rss love, too
<Kamion> cdimage actually sends me something like that already, although that's post-germinate
<mdz> Kamion: now that it's in arch, that's easily automatable, right?
<Kamion> it diffs debian-cd/tasks/warty-{base,desktop,ship,supported} with the new version
<Kamion> mdz: yep
<mdz> Kamion: yeah, I think the existing hoary-changes would be a good destination
<Kamion> hoary-changes? guess that makes sense
<jdub> mmm
<mdz> elmo's sync notifications, etc. I've been nagging about should go there too
<Kamion> what're the posting restrictions there?
<pitti> Kamion: right, this does not work in an archive, you have to install the hook on every machine you do commits on
<jdub> Kamion: um, none, atm. :)
<Kamion> not strict enough, judging by the person who randomly mailed it earlier today :)
<pitti> Kamion: CVS supports this because it uses its own protocol, but http does not allow to put executable hooks into an archive
<jdub> elmo: would it be crack to get katie to send mails from a particular From: instead of from the uploader?
<carlos> Kamion: Do we have a manual about the Ubuntu installation?
<Kamion> pitti: right
<mdz> jdub, Kamion: I think we're to blame for putting it in the hoary announcement mail
<pitti> Kamion: however,  there is a hackish workaround
<Kamion> carlos: http://archive.ubuntulinux.org/ubuntu/dists/warty/main/installer-i386/release/doc/manual/en/
<carlos> my cousin is asking me about it to learn to handle manual partitions
<carlos> ok
<elmo> jdub: I think so yes, we'd be losing IMO useful information because mailman sucks and can't filter worth jack
<pitti> Kamion: you can put the hook into the arch archive and only have a general hook which checks this out and executes it
<carlos> Kamion: thanks
<Kamion> jdub: that kind of sucks, because my mailer wouldn't show the right thing any more
<jdub> Kamion: right thing? oh, so you can reply to the person?
<Kamion> pitti: thanks, but I think I've considered hooks and rejected them - they just won't work for this use case
<Kamion> jdub: right
<jdub> mmm
<Kamion> plus the name in the left-hand column
<jdub> well, i can basically only filter on sender
<jdub> so atm anyone can post
<jdub> which sucks the big one
<pasc> stick some procmail in front of it
<jdub> i could start making it a moderated list
<Kamion> katie could set reply-to, I suppose, but ugh
<jdub> and add senders
<jdub> Kamion: from (something standard), reply-to (uploader)?
<elmo> jdub: dude, that's really all mailman can offer in terms of filtering?
<elmo> jdub: debian-devel-changes has a reply-to debian-devel; we could do the same or -user
<Kamion> I think I'd go with pasc here
<Kamion> if mailman sucks too much we should put something in front of it
<jdub> elmo: it currently sets reply-to
<Kamion> or torture Mithrandir until he fixes it
<elmo> ah, k
<jdub> i would like to dodge the exim crap to put procmail in front of one list, however :)
<jdub> elmo: seriously, this is whack. you admin exim. i admin lists. you don't have access. i do.
<jdub> I WANT A REFUND
<pasc> jdub: you might as well put procmail in front of all lists
<mdz> elmo: these guys aren't replying, they're just posting random stuff to the -changes lists
<mdz> no clue how they got there other than the link to the hoary-changes mailman page in the hoary announcement
<pitti> Good night guys! Happy President voting to our U.S.A. folks! :-)
<amu> Kermit 4 President!
<carlos> pitti: night
* netjoined: irc.freenode.net -> sendak.freenode.net
<mdz> Kamion: I suppose I should update ubuntu-meta
<Kamion> you noticed the debootstrap upload then?
<mdz> is there an easy way to tla get something without the register-archive madness?
<mdz> Kamion: yes
<Kamion> mdz: don't believe so
<mdz> tla register-archive seems like a nasty thing for a script to do
<mdz> lifeless: ?
<Kamion> so register-archive once per machine?
<elmo> *cough*
<mdz> I really thought it could do this
<Kamion> you can always HTTP-get the checkout
<Kamion> on rookery
<mdz> that'll do
<lifeless> mdz: not really.
<elmo> elmo-paraphrase(tm): "<mdz> no, no tla is fine, quit yer whining" ... "<mdz> tla sucks for this"
<Kamion> I'm trying a test debootstrap now; it'll be better than before, but I don't know if it'll quite work yet
<lifeless> register-archive is non invasive. and if you just want a deb, grab the deb source, or even the binary
<Kamion> lifeless: I imagine he's talking about ubuntu-devel@lists.ubuntu.com/seeds--hoary--0, not a package
<mdz> lifeless: ubuntu-meta contains a script which the package builder can run in order to sync it with the published seed lists
<Kamion> s/package/Debian package/
<mdz> lifeless: the seed lists are now in an arch archive
* mdz pummels xchat
<lifeless> register-archive is fine to do from a script.
<jdub> obviously we need debian packages for the seeds
<thom> mdz: ctrl+w again? :/
<lifeless> if its already registered, its a noop.
<mdz> lifeless: package builds should not mess with the user's home directory.
<Kamion> you don't run this script automatically, though, do you?
<mdz> no
<jdub> lifeless: the man has a point
<mdz> but the principle still applies
<lifeless> jdub: svn, cvs both will futz with ~ 
<Kamion> I'd consider it OK then ... alternatively, just say "you need to tla register-archive this first"
<lifeless> so I think its a moot point.
<jdub> lifeless: but optionally don't
<lifeless> jdub: ha. thats called HOME=...
<mdz> lifeless: cvs *so* doesn't
<mdz> do a cvs checkout, ls -altr ~
<lifeless> .cvspass
<mdz> zero modifications
<elmo> cvs login does dude
<Kamion> you only need cvs login for pserver though
<mdz> I don't run cvs login
<mdz> and you don't need cvs login for anonymous pserver
<Kamion> indeed
<mdz> this is so not an unreasonable thing to want to do
<jdub> fix baz!
<jdub> el fixo!
<jdub> el fixio del scorchio!
<mdz> Kamion: considered converting away from wiki markup for the seeds?
<elmo> can we pleeeeeeeeeeeeease add commentary, and not just in the revision history
<elmo> s/commentary/rationale/ if you like
<Kamion> mdz: no objection in principle, but that involves germinate changes
<elmo> at least for new ones
<Kamion> elmo: ok, will try to remember
<jdub> "added elmosplatter for obvious reasons"
<mdz> Kamion: sure, trivial ones, though
<Kamion>             if not line.startswith(" * "):
<Kamion>                 continue
<Kamion> mdz: right, it just wasn't top of the list :)
<mdz> another day, perhaps
<Kamion> I'm more interested in having a variable substitution mechanism so I can simplify the installer seed, personally
<Kamion> I've tried to add that a few times now and given up, though
<Kamion> I think it must have exceeded the 15 minutes of free time when I thought "hey, let's hack on germinate"
<elmo> restricted seed would be good at some stage too
<mdz> Kamion: what differences should I expect to see?
<elmo> the current seed syncage stuff has a 'lala lala you said restricted, I'm not listening lala lala'
<elmo> +policy
<mdz> Kamion: currently it only sees the addition of ttf-arabeyes
<mdz> Kamion: the stuff we just talked about doesn't seem to be in the public checkout yet
<Kamion> are you running against hoary (-s hoary -d hoary)?
<elmo> kamion: is that not the default? :)
<mdz> Kamion: I'm running ubuntu-meta's update script
<mdz> Kamion: and then when trying to explain the results, I looked at http://people.ubuntulinux.org/~cjwatson/seeds/hoary/desktop
<mdz> Kamion: which still has fam, e.g.
<mdz> jdub: so what's going to break if I upload ubuntu-desktop to hoary, pulling in gamin for everyone?
<Kamion> mdz: bleh, I forgot a step in the cron job, fixed
<jdub> mdz: not a heck of a lot
<jdub> mdz: little notification quirks
<Kamion> elmo: probably should be, which is why I asked earlier if you were still running germinate against warty
<elmo> Kamion: no, I'm not
<Kamion> elmo: if you are, I don't want to break your stuff
<Kamion> ok
<mdz> jdub: should we tell everyone to remove fam?
<Kamion> elmo: or sid?
<jdub> hell yeah
<jdub> and portmap
<jdub> fuck them right off
<elmo> Kamion: I run it with custom Packages files, so don't worry about me
<Kamion> ok
<Kamion> 2004-11-03 00:21:32 GMT Colin Watson <cjwatson@canonical.com>   patch-10
<Kamion>     Summary:
<Kamion>       default everything to hoary
<jdub> mdz: conflicts in u-d would be nasty, but good :)
<mdz> elmo: gamin needs to move into main
<Kamion> elmo: restricted doesn't seem to make much sense as a seed
<mdz> before I can upload this
<elmo> gar, you mean I have to actually upgrade to this new germinate rather than whine about it?
<Kamion> elmo: it's partly a subset of base, partly desktop, partly ship, partly supported, partly installer ...
<Kamion> that'd be a nightmare to implement
<Kamion> elmo: oh, I've been meaning to make germinate able to download and concatenate multiple Packages files, which might help you ... may actually get round to that soon
<elmo> mdz: done
<Kamion> d'oh, I meant to go to bed like an hour ago
<Kamion> night all
<Kamion> ooh: I: Base system installed successfully.
<jdub> heh
<jdub> night Kamion 
<elmo> mdz: ok to pull in mingw32 btw?
<Mithrandir> Kamion: I think it's for syslinux.exe
<Mithrandir> which we really shouldn't need to build
<Mithrandir> somebody should whack syslinux' build system
<elmo> oh, well, that answers that :)
<elmo> Mithrandir: oh.. do we ship it tho?
<Mithrandir> elmo: the .exe?  No idea.
<elmo> if we ship it, we should build it.. if we don't
<Mithrandir> we build it, but I don't know if we ship it.
<Mithrandir> and I really don't see any reason to ship it?
<jdub> would this be a useful addition to cdrecord or something?
<jdub> http://vu1tur.eu.org/tools/
<mdz> voting, back in a bit
<amu> ;)
<mdz> lamont: ping?
<lamont_r> moo
<mdz> lamont_r: voted?
<lamont_r> yep
<lamont_r> that was like 14 hours ago. :-)
<lamont_r> before the day went to hell in a hand basket
<fabbione> morning guys
<Micksa> is there any reason why I shouldn't be able to make a bootable netinst CD out of the kernel image and initrd for the pxe boot stuff?
<fabbione> Micksa: because you don't need it?
<fabbione> there is the same kernel and initrd on the install cd
<fabbione> you can just change the line at syslinux to start that kernel
<Micksa> I want a CC-size netinst CD
<Micksa> okay, I'll look
<Micksa> I haven't actually tried yet :)
<Micksa> just curious
<fabbione> iirc it is planned...
<fabbione> but i don't want to lie :-)
* lamont_r heads home
<fabbione> mdz: you around?
<tsblack> Hello all
<tsblack> Thomas here - in SA with Mark for Ubuntu SA launch
<fabbione> hey tsblack 
<tsblack> Hey fabbione, just the man I wanted to see!
<tsblack> How do I get Warty installed on an ide / sata syste,?
<tsblack> system
<fabbione> uh?
<fabbione> i am the X man ;)
<fabbione> let me see.. there should be a howto somewhere
<tsblack> Ok, on the X side, I'm busy downloading the nvidia-glx stuff
<tsblack> it doesn't seem to ship standard on cd?
<jamesh> it installed to an SATA disk without problem for me
<tsblack> On some systems you can force the sata into legacy mode where it recognises the sata as a typical hdx, not on this intel server..
<tsblack> Depending on bios settings, it either recognises ide cdrom or sata hd, not both.
<tsblack> fabbione: remember that fuzzy display mark was talking about yesterday?
<fabbione> tsblack: yes i do
<tsblack> Only happens at max res of 1200x800, all other modes fine.
<fabbione> tsblack: i think all the SATA discussion was on the user mailing list but i don't have it handy
<fabbione> tsblack: can you describe me the problem in details? i could really understand much on the phonr
<fabbione> the line was very distrurbed
<fabbione> and full of noise
<jdub> yo tsblack 
<tsblack> The display looks noisy, ie pixels not quite in their place
<fabbione> ehm i couldn't
<tsblack> hi jdub
<fabbione> tsblack: ok.. that must be a driver bug... if you have the opportunity, please set the resolution to that level again and send me /var/log/XFree86.0.log of both the working and non-working setup
<fabbione> tsblack: and if possible a picture of the broken display
<tsblack> mmm, will try...
<tsblack> going to give nvidia-glx a bash.
<fabbione> ok
<tsblack> Any idea why the colour depth on nv is so bad?
<fabbione> tsblack: it should be 24 bits as default
<fabbione> no problems here
<fabbione> (i have almost only nv cards)
<tsblack> brb, need to test display..
<pitti> Morning!
<daniels> elmo: please sync shorewall 2.0.10-1
<ChrisH> Hi, developers. :) I've been contributing to Debian for 1.5 years. Now I'd like to join the Ubuntu development team to contribute packages directly to Ubuntu. Is the "MaintainerCandidates" page in the Wiki the right place to get signed up?
<sivang> ChrisH : hi!
<Keybuk> jdub: http://www.osnews.com/story.php?news_id=8754
<smurfix> Any ubuntuwiki-savvy person here? I can't edit my own page. :-/
<smurfix> Ah, just saw the front page. Duh.  ;-)
<sivang> smurfix : have you logged in?
<smurfix> Yep. I just saw on the frontpage that the wiki's going to be switched over to Something Else, so I assume that the pages are locked because of that. ?
<sivang> smurfix : what URL have you been using?
<Mitario> lo everyone
<smurfix> sivang: *Sigh*. Apparently, the old one. wiki.ubuntulinux.org. The new wiki doesn't know me yet; is that intentional?
<smurfix> sivang: The MaintainerCandidates page on the new wiki has a few URLs that still point ot the old wiiki; I'll fix that as soon as I log in there.
<smurfix> sivang: https://www.ubuntulinux.org/forgottenpassword => "A system error occurred".
<smurfix> ... in other words, no login for me at the moment.
<daniels> from the forums -- ubuntu box set artwork: http://www.deviantart.com/deviation/11944873/
<pitti> Hi sivang!
<sivang> hey pitti! how are you?
<pitti> sivang: fine, thanks! Just read the latest news on cnn.com. The famous first/last/only words of the Petunia Bowl in "Hitchhiker's Guide to the Galaxy" come to my mind...
<elmo> daniels: done
<daniels> elmo: thanks
<fabbione> morning elmo
<fabbione> elmo: btw.. you rock :-)
<elmo_away> fabbione: err, morning.. I do ?
<daniels> aye
<daniels> elmo_away: that's the last of my sync merge bugs
<fabbione> hey azeem 
<azeem> ciao fabbione 
<sivang> smurfix : you can try and create a new account on the new wiki
<sivang> smurfix : can continue from there
<smurfix> sivang: I'd like to do that with my old email address if at all possible.
<pitti> fabbione: Did you see Joey's latest reply to the last apache fix? There's another patch (and this time it's already public :-) )
<sivang> smurfix : ok, I suggest you sine up for ubuntu-doc@ , and mail the list - I bet Lulu would get back to you and reset your account or help you with this.
<pitti> fabbione: do you or do I?
<smurfix> sivang: OK, will do, thanks.
<fabbione> pitti: ENOTIME
<pitti> fabbione: okay, I can make the fix for sid, if you want
<pitti> fabbione: I think we use the same procedure for Warty: fix, but don't officially announce
<smurfix> *sigh*, ubuntu-doc isn't on gmane yet. I'll ping them.
<fabbione> pitti: fine for me
<sivang> smurfix : gmane?
<smurfix> sivang: it's a rather large mail-to-usenet gateway.
<fabbione> pitti: for the next 2 weeks whatever is not X related = ENOTIME
<Kamion> elmo_away: we seem to be missing Task: ubuntu-desktop for hoary
<sivang> smurfix : ah usenet, bring in old memories from my time as a BBS operator :)
<pitti> fabbione: okay. BTW, as a new maintainer I thought about packaging the apache X11 plugin :-)
<fabbione> pitti: we are having the X-Sprint here in dk
<fabbione> pitti: go ahead :-)))
<smurfix> sivang: ;-)  It's rather nice, I read most of my mailing lists through them.
<fabbione> pitti: together with my removal from the uploaders ;)
<pitti> fabbione: oh, it's already running? I wish you all the best for it
<sivang> smurfix : are you using one?
<smurfix> sivang: ? One of what?
<fabbione> pitti: we already have packages :-)
<pitti> fabbione: daniels is with you in .dk right now?
<pitti> GO X-TEAM, GO!
<fabbione> pitti: we are testin Xfree86 -> X.org upgrades 
<fabbione> and build situation
<fabbione> dpkg-deb: building package `xlibmesa-dri-dbg' in `../xlibmesa-dri-dbg_6.8.1-0.0_i386.deb'.
<pitti> fabbione: a PITA, or does it reasonably work?
<fabbione> see...
<sivang> smurfix : bulletine board system..
<fabbione> pitti: 50/50%
* pitti waves to daniels in dk
<smurfix> sivang: I wrote one myself. 25 years ago. Compiled BASIC on a Commodore C-64, obliterated my parents' phone line, and all that. But these days? NFW.
<daniels> pitti: hello there
<daniels> pitti: live from casa del fabbione!
<sivang> smurfix  : haha that's cool , I did a RemoteAccess clone in pascal, way long long ago :)
<fabbione> OK OK.. this is RADIO UBUNTU live from DK today!
<fabbione> DJ GIMME SOMME MUSIC
<sivang> fabbione : DJ, do you accept requests?
<pitti> fabbione: the "X-Files" soundtrack?
<daniels> fabbione: do you really want me to start playing Aussie hip-hop?
<fabbione> eheh
<fabbione> daniels: no.. you are not allowed to put hip hop in my house
* azeem requests some Eros Ramazotti for fabbione 
* fabbione cross burns azeem 
<daniels> fabbione: how about dnb?
<fabbione> yeah
<fabbione> UHAAAAA
<fabbione> almost the first upgrade without glitches :-)
<fabbione> WE ORCK
<fabbione> and ROCK
<fabbione> sometimes even HIP HOP
<azeem> fo 'shizzle
<Mithrandir> fabbione: yeah, you rock, but you knew that already.
<Mitario> back!
<Mitario> lo everyone
<Mitario> mvo_, here?
<mvo_> Mitario: yes
<Mitario> got answer from the kerneljanitors?
<mvo_> not yet, they life on brasil time, I expect them to be around in 2-3h :)
<mvo_> are there changes in the code since the last version you send me?
<Mitario> not really
<Mitario> no vital changes
<Mitario> maybe a diff of 2 lines :)
<Mitario> so doesn't matter i'll retype that code
<Mitario> mostly debug code anyways
<mvo_> Mitario: oh, ok
* sid77 hello
<ChrisH> Anyone here in charge of the server that sends wiki passwords out? Looks like it has no valid reverse DNS resolution (PTR) so my mail server blocked it in the first place.
* ChrisH wonders if the new maintainers approval process in Ubuntu is easier than the two-year-waiting-hassle in Debian... ;)
<Mithrandir> ChrisH: I don't think the process has really started yet, but I think that's a definitive goal, yes.
<ChrisH> Mithrandir: Are there any number of how many maintainers there are already? I know these questions may sound stupid but these came to my mind when comparing debian and ubuntu.
<Mithrandir> ChrisH: I think we're about 15-20 people.
<ChrisH> Mithrandir: When I saw the new maintainer process guidelines of Ubuntu I thought "oh, no, not the same beaurocracy as in debian".
<ChrisH> Mithrandir: So I assume there are more people doing QA on debian packages that are included in Ubuntu than people that directly contribute packages to Ubuntu?
<Mithrandir> ChrisH: we contribute stuff back and try to stay in sync with Debian -- I'm not sure if there are any real packages in Ubuntu which aren't in Debian.
<Mithrandir> (some artwork and meta-packages, but I'm not sure about anything else)
<smurfix> ChrisH: I didn't have to wait two years. 
<smurfix> ChrisH: ... though I do agree that the process could be handled somewhat better.
<thom> please lets not have a discussion of NM here :-)
<smurfix> thom: Debian-NM, no. Ubuntu-NM ..?
* tseng mummbles something about NM
<ChrisH> Why not? :) I don't mean to bash anyone/anything. But I'm not quite happy with some aspects of Debian. And I'm trying to start a mental decision task if there's a way to use the great Debian technial background without some obvious hassles.
<fabbione> RIDE THE SPLIT!
<fabbione> YEAH MORE!!!!
<mjg59> iwlist scan shows them
<thom> mjg59: current ubuntu
<fabbione> WELCOME TO FEE NODE
<sid77> net split!
<mjg59> thom: Right. I'm wondering whether 2.6.9 has changed something.
<Mithrandir> daniels: I imagine xorg will hit sid post-sarge?
<daniels> thom: oh, I only just caught scrollback
<daniels> thom: networkmanager is horrific for me
<daniels> thom: this is just with the gnome wifi applet
<daniels> Mithrandir: yes, I've been instructed not to change it pre-sarge
<mjg59> I get strength for the current connection with stuff, but I don't get strength for other connections
<tseng> i get strength bars in netapplet/wifiapplet
<daniels> thom: it showers me with hate, saying that it couldn't connect to the wired network, and new dialogs spawn as soon as I kill the old
<sid77> YOOOOHOHOHOH
<mjg59> thom: What does your iwlist scan output look like?
<tseng> it uses a different method im presy sure
* sid77 does some tricks on the split
<sid77> (like a heelflip ;)
<tseng> pretty?
<thom> daniels: what version - sounds like something i fixed in -2
<daniels> thom: -1
<daniels> let me try -2
<thom> mjg59: um, you want the lot? or just the fact that it looks to be giving me correct quality/signal/noise
* daniels holds his breath as he upgrades to xorg.
<Mithrandir> daniels: where can we get that crack?
<mjg59> thom: If you could stick the lot somewhere (assuming there's no personal information in it) that would be great
<mjg59> My suspicion is that 2.6.9 reports stuff slightly differently
<thom> http://people.debian.org/~thom/iwlist-output
<daniels> Mithrandir: http://trider-g7/ubuntu-local/
<ChrisH> tseng: In what way are the goals different? I probably missed a line due to the netsplit.
<tseng> ChrisH: the goal of ubuntu is to make a polished release with 6 month cycles, and provide commercial support on top
<tseng> you know what debian is up to
<Mithrandir> daniels: I'll be happy to be your guinea pig with my home system. :)
<daniels> Mithrandir: isn't that amd64?
<tseng> struggling to make a release once in a blue moon, and support is up to you
<Mithrandir> daniels: it is.
<ChrisH> tseng: I know which direction Debian is heading to. But I don't know what they are up to.
<daniels> Mithrandir: we're still beating out some issues, anyway
<Mithrandir> daniels: I'm not at home either, so. :)
<daniels> Mithrandir: ahr, no amd64 binaries as yet, but it should build and work OK
<Mithrandir> daniels: and trider isn't available outside fabbione's lan, is it?
<daniels> Mithrandir: that was sort of the point :)
<ChrisH> tseng: Ubuntu sounds like the founders tried to improve the Debian release cycles, failed in that, and out of frustration started their own distribution. It would be no problem to offer commercial support for Debian. So the argument left is the long release cycle.
<Mithrandir> fabbione: you're evil and bad, giving trider-g7 link-local addresses in DNS.
<Mithrandir> ChrisH: and the fact that we don't support the whole of debian.
<Mithrandir> ChrisH: and that we're able to make things act in certain ways -- gnome is your desktop, if you want kde, you're on your own.
<ChrisH> Mithrandir: I just read that the release criteria are more relaxed than in Debian (which often delayed the Sarge release).
<Mithrandir> removing choices means it becomes simpler for the user, in a lot of cases.
<thom> ChrisH: nothing about a time based release is relaxed :-)
<ChrisH> thom: Nah. I meant the "we can't release Sarge because the libfoobar could possibly violate a patent of Microsoft that we heard rumors about at the bus station".
<Mithrandir> daniels: actually, I get permission denied. :P
<ChrisH> So Ubuntu was created out of the need for fast releas cycles for end-users rather than getting rid of Debian-political problems?
<smurfix> thom: ... except for the fact that Ubuntu has a few people that get told "fix it", while Debian ... well, that rant would be somewhat off-topic here.
<Mithrandir> ChrisH: the biggest problem with Debian's release cycle is not that it's slow, it's that it's so freaking unpredictable.
<daniels> Mithrandir: shame!
<daniels> :P
<Mithrandir> I waaant myyy craaack
<mjg59> thom: Yeah. My output looks nothing like that.
<mjg59> thom: http://tyrosine.codon.org.uk/~mjg59/scan
<thom> woah
<thom> ok, so that's changed rather dramatically
<mjg59> That's with an ipw2100
<mjg59> So I need to fix up netapplet. Sigh.
<thom> fun
<mjg59> It's either kernel or wireless-tools
<thom> wonder if NM will cope with that
<thom> mjg59: i'm on sid's wireless-tools
<mjg59> Ah. Probably kernel, then.
<mjg59> Unless mine have come from experimental, somehow
<mjg59> Hmm. No, I'm actually behind sid it seems
* mjg59 likes finally having a local mirror
<daniels> local mirrors are sweet
<ChrisH> Mithrandir: Isn't the Debian release manager working for Ubuntu, too? ;)
<daniels> ChrisH: no
<Mithrandir> ChrisH: the Debian Release Manager is a team consisting of three people (iirc), one of which is working on Ubuntu.
<daniels> well, the RM (who just resigned) does not; one of the release team members does, the other does not
<Mithrandir> daniels: I thought aba was a RA now as well?
<ChrisH> When I first read "release manager *team*" I thought: thank god!
<daniels> Mithrandir: oh?  well yeah, then that would be 1/3.
<ChrisH> Having single persons do such an important job alone is probably the biggest flaw in debian.
<smurfix> ChrisH: Quite a few Debian jobs share that problem.
<daniels> this is #debian material, dudes
* sid77 goodbye all!
<ChrisH> I'm just trying to find out if I could help contribute to Ubuntu while staying mentally sane.
<thom> we'd like to think we're mostly sane... besides fabio
<fabbione> thom: true :-)
<fabbione> I AM NOT SANE
<fabbione> :P
<daniels> ChrisH: here's a tip -- don't maintain X ;)
<fabbione> ChrisH: what would you like to do beside X?
<daniels> or firefox
<daniels> i hear the firefox maintainer is totally insane
<fabbione> or mozilla
<fabbione> or thunderbird
<fabbione> that btw keeps crashing once in a while...
<ChrisH> fabbione: I had prepared a page about myself: http://workaround.org/ubuntu/
<fabbione> ChrisH: checking
<thom> fabbione: thunderbird sucks, kthxbye :-)
<daniels> ChrisH: we can't decide for you ;)
<ChrisH> fabbione: I couldn't decide yet whether to put the page up on the MaintainerCandidates page.
<ChrisH> daniels: But I can abuse you to help me make up my mind. :)
<fabbione> ChrisH: well there is a lot you can do.. but you need to find your own path
<fabbione> doing what you feel more comfortable with
<daniels> find something you enjoy
<carlos> seb128: do we have any GNOME package in hoary/warty that uses cdbs and adds new strings to the orig.tar.gz? 
<ChrisH> So there is not the classical way to first maintain packages (as there are hardly any ubuntu-specific packages) and the look further...
<seb128> carlos: add new strings ? gnome-panel ?
<carlos> seb128: only gnome-panel?
<carlos> seb128: does it uses cdbs?
<seb128> probably yes
<seb128> yes, cdbs
<carlos> ok, thanks
<seb128> np
<fabbione> ChrisH: if you like to maintain packages you can do that
<fabbione> ChrisH: it's all up to you
<mojo> hi all ppl
<mojo> does anyone here encounter a problem with wheeling mouse scroll on Ubuntu Bugzilla?
<fabbione> mojo: yes
<ChrisH> fabbione: I'm just used to just maintain packages. Everything else needed discussions on mailing lists I rather not read to keep my blood-pressure low. So "freedom of choice" for developers/contributors/maintainers is a new concept to me. :)
<mojo> You can wheel scroll for around 10 lines then I stuck
<ross> mojo: if the cursor is over a text area it will scroll that instead
<fabbione> ross: it does indipendently from where you scroll
<fabbione> i did check several combination
<mojo> yeah
<mojo> I think it's a bug of Ubuntu Bugzilla
<ross> interesting, not seen that
<mojo> I tried to test with other website
<mojo> it only happens with Ubuntu Bugzilla
<seb128> yes, I've this problem too
<fabbione> ChrisH: well.. some topics will have to be discussed here too :-)
<thom> mojo: it's a firefox bug
<thom> mojo: and it's already filed
<thom> both upstream and in ubuntu
<fabbione> thom: also in mozilla
<thom> fabbione: same odds
<fabbione> :-)
<daniels> thom: have you fixed it yet? :)
<thom> daniels: nope
<seb128> thom: I need a "firefox-gtkmozembed" to build epiphany with firefox, where do you hide this file ?
<seb128> thom: same for firefox-xpcom
<daniels> thom: Package: mozilla-firefox Subject: have to restart it when you upgrade it Severity: blocker Assignee: thom@canonical.com
<seb128> thoooooom
<thom> seb128: looking
<daniels> seb128: (i think we broke our tourguide)
<thom> guess they're not installed
<thom> daniels: bite me
<seb128> thom: we need a mozilla-firefox-dev
* fabbione upgrades to hoary and X.org
<thom> seb128: yeah
<thom> looking at how much work this will be
<seb128> thom: do you need a bugzilla entry as a reminder ?
<thom> seb128: please
<Mithrandir> I dreamt up an idea for transitioning to dependency-based init tonight
<Mithrandir> what we know today is that the ordering is correct, so we know that services starting at step 20 might need anything loaded before.
<Mithrandir> so we already have a worst-case ordering-graph today.
<daniels> bear in mind gdm will be moving today or tomorrow
<daniels> just to throw you all into confusion
<Mithrandir> a service could then add some meta information about what other services it needs to have running, and there wouldn't be any need for a full transition.
<Mithrandir> legacy applications would still use the ordering system, and everybody would be happy.
<seb128> thom: done
<fabbione> 700 upgraded, 33 newly installed, 7 to remove and 0 not upgraded.
<fabbione> Need to get 0B/492MB of archives.
<fabbione> After unpacking 59.2MB of additional disk space will be used.
<thom> seb128: danke
<fabbione> warty to hoary+x.org
<seb128> np
<bob2> hm, last I tried gnome-devel wasn't installable in hoary
<lamont> bob2: I think that's the gnutls 10->11 transition thang
<seb128> it works here 
<bob2> lamont: hm, generally, if something in hoary is uninstallable, it's a bug, right?
<seb128> bob2: which part is blocking ?
<bob2> seb128: maybe ppc is lagging?
<bob2> hrm, one sec, I'll check
<seb128> perhaps
<seb128> need more details to be sure
<lamont> bob2: generally speaking, hoary should be installable (or it's a bug), although many things are transient...
<lamont> so you might try a second time an hour or so later before filing the bug.
<bob2> lamont: ok, will do
<seb128> just paste the error here to start
<bob2> gnome-devel because of gnome-core-devel because of libxslt1-dev
<bob2> I'm using aptitude
<seb128> dpkg -l libxslt1-dev ?
<bob2> ii  libxslt1-dev   1.1.7-1ubuntu2 XSLT processing library - development kit
<bob2> all this is installed, it's just blocking the upgrade to hoary
<seb128> what happens if you try to upgrade it ?
<bob2>   libxslt1-dev: Depends: libgcrypt11-dev but it is not going to be installed
<bob2> ah, so what lamont said
<seb128> and if you install libgcrypt11-dev
<sivang> I was wondering, what is going on with the new maintainer process? anybody?
<bob2> seb128: it will install, but wants to remove a ton of gnome -dev package
<seb128> libgnomevfs2-dev ?
<bob2> that is one of them, yes
<seb128> ok, so that's the major problem
<seb128> looking why my new package uploaded 2 days ago doesn't fix that
<seb128> weird
<seb128> 2.8.3-0ubuntu2 has built and depends on gnutls11
<seb128> it should not try removing it ...
<bob2> I haven't update'd today
<sivang> Was interested to know if the MaintainersCandidate page is worth for anything :)
<bob2> oh well, lifeless is asleep, he won't notice me using his bandwidth
<bob2> hm, no, after an update, libxslt1-dev is still unupgradable
<mojo> bob2: have u played around with the image resize in trash applet??
<bob2> mojo: I've only ever used the trash applet once, and that's only because I noticed a weird new icon on the panel ;)
<mojo> hehe, new service config tool is added to system setting menu, nice
<mojo> darn, can someone check the Boot's Help in System Config? It doesnt fire up help browser
<lamont> seb128: you know gcalctool is ftbfs,yes?
<seb128> no
<seb128> I'll look on it, thanks
<lamont> checking for yywrap in -ll... no
<lamont> configure: error: flex is required to create the gcalctool scanners
<lamont> missing build-dep flex
<daniels> heh.  i set up the buildd here for the full archive rebuild, and seeded the Sources list with stuff from hoary
<seb128> lamont: ok, thanks
<daniels> went about putting xorg into there before I realised that I actually had the buildd *working*; it had already done db3 and was part of the way through glibc before I killed it
<lamont> seb128: and libgnome is FTBFS: conflicting build-deps (10->11 thang)
<daniels> intltool-debian m4 gettext file html2text texi2html gettext-base debhelper debconf-utils po-debconf libmagic1 libbz2-1.0 bzip2 gawk texinfo autoconf
<daniels> (sorry)
<Mithrandir> anybody have any experience with DVI KVM switches (which ones are good, for instance?)
<mojo> stupid bug buddy doesnt compile with cpp3.4, can someone help?
<seb128> lamont: the libgnome one is probably fixed with the new libgnomevfs ... any change to retry the build ?
<lamont> sure
<seb128> thanks
<lamont> checking for gtk+-2.0 libgnomeui-2.0 libglade-2.0 dbus-glib-1... Package
<lamont> +dbus-glib-1 was not found in the pkg-config search path.
* lamont kicks update-notifier
<lamont> upgrade notifier,eeven
<lamont> doko?
<daniels> someone's missing a b-d
<lamont> doko: 3.4.2-2ubuntu1 ICE at people.ubuntu.com/~lamont/buildLogs/g/ghdl/0.14-2/ghdl_0.14-2_20041101-1427-amd64-failed 
* daniels watches xorg spin round sbuild.
<mojo> lamont: do u know the bug with initscript about 'not found ext3 on specfic hdd'? final 4.10 fixed it but then now it appears, it'd be the problem of the merging system?
<lamont> mojo: new upstream and a merge there...
<mojo> bug #2100
<lamont> if you're up to it, you might see if the debian package also fails.
<bob2> daniels: is xorg's build system any less shit yet?
<fabbione> bob2: no
<daniels> bob2: HA HA
<daniels> no.
<fabbione> it builds more
* fabbione is with hoary AND x.org
<daniels> the modular build system is a lot more rad
<bob2> lordy
<mojo> darn, hopes all mates working hard to migrate all cpp3.3 compiled programs to cpp3.4 so I can get rid of cpp3.3 on my system
* lamont wonders if gcc-3.4 will be the default for hoary, or not.
<lamont> dpkg-shlibdeps: warning: format of libxpcom.so not recognized
<Mithrandir> lamont: any reason not to, really?
<lamont> lets all kick firefox about.
<lamont> Mithrandir: dunno
<lamont> hence the wondering
<lamont> how much more stuff did they decide to turn from warnings into errors, and how much stuff does that break?
<daniels> lamont: ehm, you don't need to worry about that, IIRC it's a module
<mojo> lamont: I find it weird to hack the firefox about, just leave it as original is better
<bob2> Mithrandir: abi change before debian does it?
<Mithrandir> lamont: amd64 has a gcc-3.4-archive
<lamont> daniels: the segv from dpkg-shlibdeps shortly thereafter, OTOH, I do...
<Mithrandir> bob2: you can change without bumping the ABI, AIUI.
<daniels> lamont: ... wow
<mojo> fabbione: dude, have u up X.org yet? I want to get hand on it 2
<bob2> Mithrandir: oooh
<daniels> mojo: it's not up, still highly experimental, but rest assured we will announce it widely when it is
<Mithrandir> bob2: else, we'll have to hire neuro so we can get him to fix the autobuilder problems for Debian so sarge can release so we can move to gcc-3.4 for both Debian and Ubuntu. :)
<mojo> daniels: hope new X.org won't break whole my system which is the only thing I get to IRC here
<bob2> Mithrandir: hahaha
<mojo> bob2: yeah, a pure gcc3.4 for Hoary must be so nice] 
<fabbione> mojo: that's the reason why it's not up yet
<fabbione> mojo: so be patience liike all the others
<lamont> daniels: people.ubuntu.com/~lamont/buildLogs/s/syslinux/2.11-0.1ubuntu1/syslinux_2.11-0.1ubuntu1_20041102-1708-amd64-failed
<fabbione> mojo: nobody will get anything until it is considered good enough for public
<lamont> and why 0.1ubuntu1 instead of 0ubuntu1?
<fabbione> also
<fabbione> X.org is slower than Xfree86
<seb128> because debian version was 0.1 ?
<fabbione> so i don't really see the point in all this rush
<lamont> seb128: that would be a good reason, yes.
<mojo> fabbione: heh? slower?? how come?? u mean u not optimize it for Ubuntu rite?
<lamont> make[4] : Entering directory `/build/buildd/zsh-4.2.1/obj/Src/Modules'
<lamont> Makefile:406: cap.rules: No such file or directory
<lamont> Makefile:1327: pcre.rules: No such file or directory
<lamont> bummer
<seb128> fabbione: people don't rush for the speed but for the new extensions
<mojo> fabbione: with FC3, X.org rocks faster than Xfree86
<seb128> lamont: libgnome built fine this time, thanks :)
<fabbione> seb128: the new extensions make it slower :-))
<lamont> :-)
<daniels> mojo: no, this is optimised for Ubuntu also
<mojo> daniels: alright then, I wait
<fabbione> mojo: please provide either detailed numbers of your arguments or please avoiid certain topics in here
<lamont> seb128: gnome-media, OTOH....
<fabbione> mojo:
<lamont> Perhaps you should add the directory containing `libnautilus-burn.pc'
<lamont> to the PKG_CONFIG_PATH environment variable
<seb128> outch
<seb128> totally forgotten this
<fabbione> i don't like this kind of arguments without proper information
<lamont> fabbione: it's frequently a subjective "faster" for many such comparisons...
<daniels> lamont: i'd need to dredge out the logs for 2.04 -- the warty version
<mojo> fabbione: alright then, I will do some benchmark, I could post it to OSnews, probably
<lamont> hence the need for ABX bakeoffs sometimes.
<daniels> lamont: any chance of that happening?
<fabbione> lamont: i know.. that's why i am asking for numbers :-)
<daniels> mojo: osnews?
<lamont> daniels: they can be had, yes.
<mojo> fabbione: don't u know OSnews.com??
* lamont goes digging
<fabbione> mojo: yes i know OSnews, but why you ask me if i know it?
<mojo> fabbione: u misunderstand me, I say I probably write an aritcle on comparing X.org and Xfree86 and maybe post it up to OSnews.com, so I can prove it to u that X.org runs faster
<daniels> thanks uncle lamont :)
<daniels> mojo: um, what numbers will you use to prove it?
<fabbione> mojo: i understood perfectly...
<daniels> mojo: at this point, 'faster' is almost entirely subjective
<Mithrandir> mojo: please, could you use "you" instead of "u" and so on? :)
<fabbione> mojo: i would like to see these numbers too
<daniels> (and it's almost impossible to measure it, because fb writes, which you'd need to do, likely, are AMAZINGLY slow)
<mojo> fabbione: ofcourse I will do testing on game like UT2k4, running some render, doing dual monitor test, remote acess, misc
<daniels> that is not a good benchmark.
<daniels> how many fps you get in ut2k4 has absolutely nothing to do with interactive performance
<daniels> at which point it's actually about latency rather than throughput (hence why x11perf is useless unless you're hacking the fb layer to optimise it or somesuch)
<mojo> ...
<mojo> maybe ..
<daniels> trust me
<daniels> the 2D and 3D subsystems are completely different
* fabbione reminds mojo that daniels is one X.org upstream..
<daniels> fabio was reporting slower based on the fact that the 2D stuff appeared to be far more latent in X.Org than XFree86
<daniels> which is almost impossible to measure, and has nothing to do with throughput/how fast your 3D core can deal with complicated textures/etc
<mojo> oopss, maybe I was wrong, I'm not in X.org upstream so I can't argue much against u
<fabbione> but the 2D performance different is pretty clear and visible
<mojo> ic
<Mithrandir> fabbione: but we want transparent windows! :)
<daniels> Mithrandir: do you also want a reasonably responsive desktop? :P
<mojo> isn't there hacked Sawfish to do it?
<lamont> daniels: .../s/syslinux/2.04-2ubuntu1/syslinux_2.04-2ubuntu1_20040818-0236-amd64-successful
<fabbione> Mithrandir: u c'n mov' u'r ass here in dk a'd gimme l337 p4tch35
<daniels> mojo: not properly
<daniels> lamont: thanks uncle
* lamont contemplates just populating the whole damn tree in.
<Mithrandir> daniels: responsiveness is overrated, I want transparent clocks! :P
<daniels> Mithrandir: KAN FAB HV DA PCHS PLZ KTHXBYE
<mojo> me too, new transparent X.org clock is nice stuff
* Mithrandir wonders if daniels was trying to write Danish.
<fabbione> AHAH
<daniels> Mithrandir: kn fb hv da pchs plz kthxby
<mojo> seems to me daniels write srilankan
<daniels> ('can fabbione have the patches please kthxbye')
<mojo> lol
<bob2> fabbione: don't let daniels on IRC when he's been drinking, please
<Mithrandir> yeah, yeah, I'll patch fabbione in Spain.  Patch him with beer and wine.
<daniels> bob2: heh
<fabbione> Mithrandir: ahahaha
<fabbione> bob2: he only had a cup of coffee.. probably too
<bob2> yeah, I've heard all about that "Danish coffee"
<daniels> heh
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion and support on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE, long live Hoary | http://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000005.html | If you want X.org packages please send 2 X-Men uniform to fabbione and daniels
<Mithrandir> fabbione: you know, somebody could be crazy enough to send them to you.
<fabbione> Mithrandir: i would love that... but i don't think they will find my size :-)
* bob2 looks for his Visa
<lamont> fabbione: they're not _that_ hard to find...
<mojo> fabbione: I do, I got one here, Wolfverine uniform with new redesigned X sign
<fabbione> lamont: i don't want the moon :-)
* lamont moons fabbione :-P
<Mithrandir> fabbione: my gf knows how to thread a needle.. ;)
* fabbione takes a pic of goatse^wlamont
<fabbione> :P
<fabbione> Mithrandir: ahaha
<Mithrandir> she might be coming to spain, a bit depending on money
<fabbione> i need to teach that to my gf.. see. i am better than her with needle ;)
<fabbione> today she learned the first command: "female: coffee!"
<fabbione> it took only 20 minutes to get it tho
<fabbione> and without too much complain
<Mithrandir> ooh, you're starting well, then.
<fabbione> only a few flying fingers
<daniels> it was good coffee, too
<daniels> better than fabbione's stuff ... these italians don't know how to make coffee, it seems :P
<fabbione> (middle) fingers ;)
<bob2> haha
<bob2> you guys remind me entirely too much of cheech and chong for some reason
<mojo> bob2: isn't it weird that gaim 1.02 has not up yet (since 1.02 been released for weeks)
<lamont> net/gaim_1:1.0.2-1ubuntu1: Building by buildd+macaroni [optional:out-of-date] 
<lamont> hrm.
<bob2> it's in sid on all arches at least
<lamont> may build this time
<mojo> k
* lamont wanders off for a bit
<Mithrandir> daniels: uhm, you kinda need to bump the version number.
<daniels> Mithrandir: i will when I upload, yah
<carlos> seb128: a dist-upgrade in hoary asks me to remove trashapplet, is that correct?
<seb128> carlos: yes, it has been merged in gnome-applet 2.9
<Mithrandir> daniels: it doesn't work, don't pass CFLAGS
<Mithrandir> daniels: and don't pass LDFLAGS
<Mithrandir> daniels: just the _ARCHDEP flags, then it should build fine.
<Mithrandir> I can test it once you've fixed that.
<carlos> seb128: ok, I thought that but I don't see it in the Replaces or Conflicts from gnome-applets so I was not sure
<carlos> thanks
<seb128> ?
<seb128> carlos: 
<seb128> Replaces: gnome-panel-data (<= 2.2.2.2-2), trashapplet
<seb128> Provides: trashapplet
<seb128> carlos: which version of gnome-applets do you have ?
<daniels> Mithrandir: try ubuntu2, same place
<carlos> seb128: yes, is there, just ignore me I'm a blind person...
<carlos> sight
<seb128> :p
<Mithrandir> daniels: it looks good, I'll test-compile it as well.
<daniels> Mithrandir: phat, thanks
<seb128> carlos: should I bring you some glasses for the conf ? :)
<carlos> seb128: I think so :-)
<carlos> perhaps it's better a new brain
<carlos> so I could implement SMP so I work better :-)
<seb128> ah ah
<mojo> hey
<mojo> new theme for FireFox
<mojo> Ubuntu should have this
<mojo> http://gnomefx.mozdev.org/screenshots.html
* sid77 hello!
<carlos> is the november calendar out?
<seb128> carlos: for some days yes
<carlos> seb128: but it's not in hoary, right?
<carlos> because I don't see it O:-)
<mojo> carlos: I do see it, check it again!
<carlos> my ubuntu-calendar only has a dependency on october one
<carlos> and dist-upgrade does not shows me anything about ubuntu-calendar
<carlos> anything pending
<carlos> carlos@frodo /tmp/rosetta $ apt-cache search ubuntu-calendar
<carlos> ubuntu-calendar - The Ubuntu Calendar features monthly updated artwork and themes
<carlos> ubuntu-calendar-october - Ubuntu calendar artwork for October
<carlos> nothing more
<Mithrandir> daniels: builds fine on amd64 at least.
<mojo> carlos: it's a bacground, check /usr/share/backgrounds
<seb128> carlos:  ubuntu-calendar-november (4.11) warty-updates; urgency=low
<carlos> seb128: I'm talking about hoary
<seb128> <carlos> is the november calendar out?
<seb128> you were asking that :p
<seb128> dunno why it's not in hoary though
<carlos> mojo: the package is not installed so it's not there, but thanks
<seb128> that's a question for jdub :)
<carlos> <carlos> seb128: but it's not in hoary, right?
<seb128> yeah, right, sorry
<carlos> :-)
<carlos> seb128: no problem, I will ask jdub when wakes up
<lamont> Mithrandir: that's daniels' new syslinux?
<Mithrandir> lamont: ack
<lamont> cool
<lamont> daniels: may as well upload, eh?
<Mithrandir> as I'm at the uni, I haven't tested it.
<lamont> Mithrandir: ah, there is that...
<T-Bone> mdz ping?
<mojo> it's 6am here, I need to get some rest,
<mojo> so long ppl
<mojo> nice dream!
<pitti> g'night mojo
<Mithrandir> T-Bone: he's probably be up in about 1.5-2 hours.
<T-Bone> Mithrandir: ok thx
<Mithrandir> lamont: breaking amd64 install cds now wouldn't be too bad, and that's the only place it's used on amd64.
<daniels> rad
<daniels> lamont: yeah, will do, ta
<mdz> T-Gone: pong
<lamont> morning mdz
<lamont> mdz: re 2113... I guess that one starts with a seed change request to move the needed package into supported?
<lamont> which is already tehre.
* sid77 bye!
* lamont looks at libselinux, and decides that warty was broken... :-(
<lamont> since when do -dev symlinks get delivered in /lib and not /usr/lib???
<lamont> elmo: please sync libselinux_1.16-8
<T-Bone> mdz: ping again? :)
<lamont> T-Bone: he sent mail about 30 minutes ago that he'd be offline for about 2 hurs
<lamont> hours, even
<T-Bone> damn
<mojo> I'm back, wake up b'c can't sleep
<mojo> gaim 1.02 is up
<mojo> thx god
<bluefoxicy> OK
* netjoined: irc.freenode.net -> sendak.freenode.net
<bluefoxicy> Ubuntu Warty 4.10, i386, in the installer, custom install, fdisk sees my partitions, the partitioner in the installer sees my partitions, the kernel has no devices in /dev/ide/host0/bus0/target0/lun0/ aside from disc and part1 (there are 9 partitions)
<bluefoxicy> and using mknod to make a device to access various partitions just gets me devices that the kernel says aren't there when i try to read from them.
<bluefoxicy> what's the problemL
<bluefoxicy> Anyone know about partitioning problems?
<bluefoxicy> i.e. kernel can't figure out htf to read the partition table, even though fdisk and the partitioner in the installer can read it just fine, and 2 other OSes (Debian Sarge and GEntoo) boot fine
<bluefoxicy> Normal install, expert install, custom install, and custom-expert on http://releases.ubuntu.com/warty/warty-release-install-i386.iso all terminally broken?
<T-Bone> mdz: ping?
<mvo_> has anyone actually tried to use dpkg --status-fd with apt?
<T-Bone> mako: ping?
<daniels> fabbione: xorg-common maintainer script is broken, looks like it doesn't work from a fresh install
<daniels> Setting up xorg-common (6.8.1-0.0) ...
<daniels> mv: when moving multiple files, last argument must be a directory
<daniels> Try `mv --help' for more information.
<daniels> dpkg: error processing xorg-common (--configure):
<daniels>  subprocess post-installation script returned error exit status 1
<daniels> fabbione: if you want to reproduce, su to me on trider-g7 and run sbuild -A -d hoary -v xorg-driver-synaptics_0.13.6-0ubuntu1
<daniels> fabbione: so obviously we can't go much further, and I'm in an internet cafe in a part of town where all there are is sex shops and topless bars
<daniels> so I think I'm going to head back to the hotel and crash, heh
<daniels> fabbione: (the street behind vesterbrogade -- iskengade or such)
<daniels> fabbione: but yeah, we can't build anything until the xorg-common maintainer script is fixed.  i'll take a look at it when I get back to my room.
<daniels> mdz: fwiw, I did the php4 merge earlier, despite fooish being down.
<mako> T-Bone: hey there
<mako> T-Bone: whats up?
<mdz> mako: did you get to that summary?
<mdz> mvo_: no, not to my knowledge. what are you thinking about?
<mvo_> mdz: I was thinking about a way to hide the dpkg output from the normal user
<mvo_> the --status-fd seemed like a option, but I suspect that apt closes all filedescriptiors when it forks of dpkg
<mdz> hm, yes, it would
<mdz> except stdin/stdout/stderr
<mvo_> ok, so this is not a option. I actually liked the idea :/
<mvo_> btw, how long does it usually take for a new package to enter the archive?
<mdz> mvo_: a NEW package, or just a new version?
<mvo_> a NEW package :)
<mdz> mvo_: that time is measured in elmo units :-)
<mvo_> ohhhh :P
<mdz> mvo_: upgrade-notifier?
<mvo_> the advantage of the the --status-fd would be that it is available now and could be easily extended to provide additonal information (like unpack-progress). but reading ExecFork() I noticed that it will close all FDs
<mvo_> mdz: yes
<elmo> eh, I did upgrade-notifier within minutes
<elmo> it just didn't build :P
<mvo_> hehe 
* mvo_ blushes
<amu> btw. mvo_ welcome ;) 
<mvo_> amu: thanks!
<mvo_> elmo: where can I check the build log?
<mvo_> oh, I think I spotted the problem already with the build-depends (stupid me)
<elmo> mvo: people.ubuntu.com/~lamont somewhere
<mvo_> elmo: thanks!
<mvo_> ping lamont 
<lupus_> can someone fix the gftp package in hoary? :) http://bugzilla.gnome.org/show_bug.cgi?id=157288
<lupus_> it is easy to fix
<seb128> lupus_: ok, I'll do it now
<lupus_> k thx
<lamont> mvo_: yo
<lupus_> I seem to have 2 files hwclock.sh and hwclockfirst.sh
<lupus_> is this normal?
<mvo_> lamont: where can I view the buildd logs?
<lamont> people.ubuntulinux.org/~lamont/buildLogs/...
<lamont> lupus_: yes
<lupus_> lupus@lupus /etc/init.d $ sudo ./hwclock.sh stop
<lupus_> ./hwclock.sh: line 118: syntax error near unexpected token `('
<lupus_> ./hwclock.sh: line 118: `               log_success_msg "       start sets kernel (system) clock from hardware (RTC) clock" >&2'
<lupus_> hoary release
<lamont> lupus_: already fixed.
<lamont> 2.12h-2ubuntu2 or later
<lupus_> weird I have updated to latest
<lamont> dpkg -l util-linux
<lupus_> still get this error
<lupus_> 2.12h-2ubuntu1
<lamont> lupus_: bug present in that version
<mdz> thom: what's the latest on firefox?
<lupus_> hmm k seems to be my mistake sorry :)
<lamont> mjg59: you around?
<mdz> thom: people are starting to notice that the Ubuntu-specific patches are missing :-)
<mjg59> lamont: Hi
<mjg59> http://kerneltrap.org/node/view/4118 - OpenBSD have a Free implementation of the Atheros HAL. Someone ought to look into mating that with the Madwifi driver.
<jdub> ooh
<mjg59> It's not fully-featured yet, but it's the sort of thing that should be encouraged
<jdub> mjg59: worth a bug
<mjg59> Keybuk: <mjg59> http://kerneltrap.org/node/view/4118 - OpenBSD have a Free implementation of the Atheros HAL. Someone ought to look into mating that with the Madwifi driver.
<Keybuk> is that even legal?
<mdz> mjg59: neat. reverse-engineered?
<mjg59> mdz: Yeah
<Keybuk> the only reason the Atheros HAL is closed-source is the FCC are evil
<mjg59> Producing an open implementation of stuff isn't illegal
<mjg59> Shipping it in the US might be...
#ubuntu-devel 2005-11-14
<dseomn> http://bugzilla.ubuntu.com/show_bug.cgi?id=19404 is really easy to fix for anybody with access to the overides files and might cause a problem if somebody's offended
<elmo> dseomn: overrides don't work for package descriptions
<dseomn> oh, ok
<daniels> in that case, the override is called an upload
<Keybuk> syndicate udev-0.074%
<Keybuk> syndicate udev-0.074% dpkg-deb -c ../udev-udeb_0.074-1_i386.udeb
<Keybuk> drwxr-xr-x root/root         0 2005-11-08 18:04:50 ./
<Keybuk> syndicate udev-0.074%
<Keybuk> \o/
<Keybuk> SMALLEST UDEB EVER!
<Kamion> Keybuk: dude, that's practically normal
<Kamion> plenty of udebs only have maintainer scripts and nothing else
<Keybuk> this doesn't have those either :p
<Keybuk> typing "udev" and "udeb" on the same line is *hard*
* Keybuk installed all the files to debian/udeb-udev
<jordi> lifeless: yes, carlos has a contract somewhere
<sabdfl> sivang: ping
<elmo> does someone want to do deal with gimp-print vs. gutenprint?
<elmo> pretty pls
<daniels> elmo: define 'deal with'
<elmo> gimp-print wants to be removed, gutenprint replaces it
<elmo> gimp-print has ubuntu mods
<elmo> our changes need either merged into gutenprint, or some needs to tell me to PUSH THE BUTTON and force-sync gutenprint
<daniels> s/guten/gimp-/2 ?
<elmo> daniels: err, I'm confused, if you mean in the line "has ubuntu mods", then no
<daniels> i meant the last word of the third line
<elmo> ok, still no.  gimp-print no longer exists in debian, it's been removed in favour of gutenprint
<elmo> sorry, I'm obviously being exceedingly unclear
<elmo> I blame cvd
<\sh> elmo: hmmm..jul 02 debian-devel : gimp-print (renamed to gutenprint) means we have to merge it
<\sh> elmo: and no...i don't have any clue about printing...I like the paperless office
<\sh> and I wonder what our nameserver (running on hoary) is doing now
<\sh> socket.c:1119: unexpected error:
<\sh> The Severity is 5
<Keybuk> right, just set off a "d" run of mom now
<\sh> Keybuk: was it purpose the 0.1breezy1 or just a demonstration?
<\sh> ?)
<Keybuk> \sh: ??
<\sh> breezy-changes
<\sh> oh mdz was it
<\sh> Keybuk: anyways...give me a small hint..if MoM removes something from the changelog entry...it means it's wrong http://people.ubuntu.com/~scott/ongoing-merge/ace/ace_merged.debdiff
<Keybuk> just means it went a bit screwy
<\sh> ok...manual interaction is needed
<\sh> I hope it's only the changelog
<Keybuk> right, nda seems to be running now too
<robertj> anyone care to discuss the GnomeUserInterface for Ubuntu Express's Computer Name screen?
<robertj> The RFC 1178 is err...interesting
<\sh> damn...the first upload .. and forgot the -v for debuild gnarf 
* tsume can't wait for the kubuntu shipit cds
<tsume> yi pyip yip :)
<minghua> hmm, Keybuk uses a Chinese quit message
<cevizoglu> which means " is absurd" 
<Toma-> how do you request a package to be submitted to multiverse?
<daniels>  is probably the chinese  glyph for dpkg or something ;)
<cevizoglu> hehe
<\sh> elmo: time for syncs...or better mail to u ?
<elmo> \sh: whichever
<\sh> I'll mail it...there are a lot to come this night
<minghua> no,  is something like "ridiculous enough"
<minghua>  is an adverb
<minghua> daniels: Chinese doesn't have a glyph for dpkg (yet) :-)
<PukingGeko> does anyone know if ieee80211 wireless modems work out of the box with the 2.6.14 kernel?
<mpt> d'oh
* mpt missed robertj
<\sh> hehehe...merges and MOTU hopefuls...I feel like I'm an old fart
<tseng> \sh: you are!
<\sh> tseng: oh damn...u r right :)
<wasabi_> darnit. evms is breaking on breezy. =(
<pitti> Kamion, elmo: still here?
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti> Hey hey jdub
<pitti> jdub: back to home or BBB?
<pitti> jdub: s/to/at/
<whiprush> jdub: "ryan" is ubuntu-geek right?
<daniels> yeah
<whiprush> thanks
<jdub>   binfmt-support: Depends: lsb-base (>= 3.0-6) but 3.0-1ubuntu8 is to be installed
<jdub> ^ dapper
<Kamion> jdub: yes, I'll sort it out when I merge lsb, in the meantime tough :P
<Kamion> I'm not diverging binfmt-support just for that - the changes are minor
<mvo> elmo: please sync python-apt from debian/incoming (override our changes is ok)
<daniels> urgh.  i much preferred montral's weather.
<daniels> luckily it appears a ton of rain is on the way.
<Mithrandir> elmo: please sync xmltex 1.9-11 from unstable into dapper.
<mvo> Mithrandir: hi! do you also battle jetlag right now :) ?
<daniels> mvo: yes ;)
<Mithrandir> mvo: yes. :-)
<mvo> daniels: hello! did you had a good trip back? 
<Mithrandir> I tend not to be in the office at 0530 on most days.
<mvo> we should rename it to #ubuntu-jetlag
<daniels> mvo: long but largely hassle-free
<mvo> daniels: same for me (except not as long as yours :)
<daniels> mvo: ah, cool.  you just got back lyesterday?
<mvo> daniels: yes, I was at home around mid-day, but felt *so* sleepy for the rest of the day
<daniels> heh
<mvo> Mithrandir: when did you plane leave in montreal?
<mvo> daniels: yeah, the trip was quite good because I was traveling with seb128, ogra and dholbach
<Mithrandir> mvo: plane left at 1755, got home at ~1100 yesterday, spent most of the day trying not to fall asleep
<daniels> mvo: oh, cool!
<mvo> Kamion: do we use the aptitude patch for "--allow-unauthenticated" in the installer?
<minghua> elmo: please sync libmath++ 0.0.4-2 from debian, all previous ubuntu changes should be dropped
<wasabi> Um. Trying to redo mbr from rescue mode. grub complains about no tty.
<freeflying_> anyone know smurf
<Burgundavia> small blue man, happy, last seen being bombed in unicef commercial
<zakame> buwahahaha
<Burgundavia> freeflying, honestly, he lives in Europe and thus is likely to be asleep right now
<freeflying_> Burgundavia: Who is in charge of LocalTeam besides him ?
<Burgundavia> freeflying, no idea, sorry
<freeflying_> Burgundavia: thanks
<minghua> freeflying_: are you hinting that there is going to be some activities from ubuntu-zh team? :-)
<freeflying_> minghua: your help is very important to us 
<freeflying_> minghua: so we need advice from you 
<poningru> I had a question
<poningru> are we still looking for testing process?
<poningru> has anyone looked into litmus?
<poningru> deved by mofo?
<poningru> err -?
<poningru> http://litmus.mozilla.org/run_tests.cgi
<poningru> http://ws314.juntadeandalucia.es/guadalinex2005/live_installer/default/
<poningru> err
<poningru> http://wiki.mozilla.org/Litmus
<pef> hello
<pef> elmo: hello, can you confirm me my upload of "mixxx" package to archive is successfull ? (exists in Debian, new in Ubuntu)
<pef> elmo: thank you :)
<siretart> elmo: I'm very sorry, I botched an upload to debian :( - won't happen again, promised
<HiddenWolf> siretart, just fix it. ;)
<siretart> HiddenWolf: no, it shouldn't go there at all, it is now in the incoming queue of debian :(
<HiddenWolf> siretart, so find an ftp-master and have it killed.
<Mithrandir> elmo: please sync pkg-config from unstable into dapper.  Ok to override Ubuntu changes.
<siretart> elmo: please sync 3ddesktop and aalib from unstable into dapper, overriding ubuntu changes
<Mithrandir> elmo: please sync norwegian from unstable.  Ok to override Ubuntu changes.
<siretart> elmo: please sync lxdoom from unstable, Ok to override Ubuntu changes
<janimo> why the sync requests? isn't this automatic (for universe at least) as at the beginning of breezy ?
<Lathiat> janimo: If we have changes, the sync does not happen automatically
<janimo> so MOM is not happening?
<Lathiat> janimo: Obviously we don't want to tread on top of the local changes
<janimo> then why the need to specify 'ok to override' ?
<Nafallo> janimo: mom is happening and we want to remove our changes
<Nafallo> janimo: (override *ubuntu*)
<janimo> aha so sync already happened, and stuck in MOM and you want a resync?
<janimo> just like with breezy then, I get it now
<Nafallo> sync didn't happen, cause we had *ubuntu* for the package.
<Nafallo> then mom got it and we want to have a sync dropping our *ubuntu*
<janimo> hmm I understand a different thing by sync then :)
<janimo> sync = bring from debian to MOM
<janimo> aka step 1
<Nafallo> nope
<Nafallo> sync is bring from debian into archive :-)
<janimo> I thought of sync as a best effort thing :)
<janimo> nothing guarranteed
<janimo> ok it's clear now thanks
<Nafallo> no problemo :-)
<siretart> elmo: please sync mail-notification from unstable, Ok to override Ubuntu changes
<zyga> hello
<Lathiat> ermm
<Lathiat> we are still using bugzilla
<Lathiat> for main stuff
<Lathiat> right?
<siretart> Lathiat: for now, yes
<poningru> when will migration occur?
<poningru> to launchpad that is
<siretart> poningru: there are still some features missing in malone, like NEEDINFO and some others. It will be done as soon as it is possible and feasible
<poningru> ok
<dholbach> siretart: we do have needinfo now
<siretart> dholbach: oh. whats missing then in malone?
<dholbach> various filters
<siretart> ah, okay
<dholbach> like the equivalent of bugzilla's "filter only upstream bugs", although jamesh just wrote something about it
<dholbach> might be implemented too
<slomo> elmo: please move everything of ffmpeg back to universe ;)
<HiddenWolf> slomo, is it multiverse now?
<slomo> HiddenWolf: no... libpostproc-dev is in multiverse for no good reason now, everything else in universe
<Mithrandir> elmo: please sync xrestop from Debian unstable, ok to override Ubuntu changes.
<Mithrandir> elmo: please sync siege from Debian unstable.  Ok to override Ubuntu changes.
<\sh> elmo: please sync alleyoop form Debian unstable, Ok to override Ubuntu changes
<Mithrandir> elmo: please sync debtags from Debian unstable.  Overriding Ubuntu changes is ok.
<HiddenWolf> Mithrandir, you're on a roll, aren't you? ;)
<Mithrandir> HiddenWolf: I'm almost falling asleep so it's better to do a bit of brainless work.
<Treenaks> wanking!
<dholbach> elmo: could you please sync atk1.0 from sid? ok to override ubuntu changes
<mvo> elmo: please sync w3m from debian (override ok)
<seb128> Mithrandir: any opinion on https://bugzilla.ubuntu.com/show_bug.cgi?id=18819 ?
<HiddenWolf> guys, that expired certificate on bugzilla is bugging me. :P
<mvo> elmo: please sync nmap (override ok)
<dholbach> elmo: could you please sync dia from sid, ok to override changes
<rob^^^> dholbach: btw, do you know of any reason not to default dia to anti-aliased?
<dholbach> rob^^^: no idea
<dholbach> elmo please sync at-spi from sid, ok to override
<jsgotangco> hi
<Keybuk> BeeeeeeeeeeeeeeeeeeeeeeeeeeeeeenC!
<siretart> hi Keybuk 
<Keybuk> siretart: hey
<the--dud> isnt benc that dvd-rw taiwan manufacturer?
<the--dud> or something like that
<siretart> elmo: thanks for the syncs. by chance, did you find some time to get my key added?
<mvo> can someone please double-check that we can sync emacs21 (ubuntu #19169)? it looks all our changes are in debian now
<jbailey> Riddell: Question for you, is there a kubuntu-artwork package of some sort?
<Riddell> jbailey: no, it's all in kubuntu-default-settings
<jbailey> Riddell: So from a branding POV, if someone wnated to make a Kubuntu derivative, is that and kubuntu-docs the two packages they would have to frob?
<Riddell> yep
<jbailey> Riddell: Thanks.
<Riddell> I'd recommend they make a foo-default-settings and change /etc/kderc to point to their directory too so they are just overriding kubuntu's settings for the stuff they want
<jbailey> But those are sysadming settings.  For someone producing a derivative and shipping it, that looks like it would be the wrong place to touch things.
<jbailey> You don't want it to give annoying conffile warnings on each upgrade of the package.
<Riddell> well the alternative is to throw out kubuntu-default-settings and not get all my great KDE tweaks (also kdm depends on kubuntu-default-settings unfortunatly)
<jbailey> Right, but that's the same with ubuntu-artwork.
<jbailey> If they touch that, they'd lose the Human theme, the sounds, etc.
<jbailey> I think so far we assume that anyone doing a derivative is competant enough to know that.
<jbailey> And it localises the changes they need to do to one package easily.
<Simira> Mithrandir : you promised to get home early today!
* siretart senses upcoming crisis
<siretart> huhu Simira :)
<Simira> haha
<Simira> siretart : we're still kind of on canadian time, so he left for job pretty early today. 
<jbailey> "Canadian time"? =)
<jbailey> You know we have 5.5 timezones here, right? =)
* magnon woke up montreal time today too :(
* desrt eyes jbailey suspiciously
<Simira> jbailey :p Well, we've only been to one of them
<desrt> i think that number is a little bit low
<siretart> jbailey: I see that you create daily .debs of bzr in http://people.ubuntu.com/~jbailey/snapshot/bzr/, would you object to have the latest release of bzr in dapper?
<siretart> jbailey: that means, If you don't object, I'd like to upload bzr 0.6 to dapper, based on your packaging work
<pitti> Mithrandir: ping
<Mithrandir> pitti: pong
<pitti> Mithrandir: wrt cfengine, shall we throw cfengine-doc out of the seeds? or promote cfengine?
<Mithrandir> pitti: I think promoting cfengine2 would be a good thing, and throw cf1 out.
<pitti> Mithrandir: can you write a main inclusion report for cf2 then?
* siretart strongly agrees
* Simira pings Mithrandir in the head
<Mithrandir> boooing
<Mithrandir> pitti: I'm going home now, but yes, I'll do that.  Mail me, please?
<Simira> (pretty empty sound, eh?)
<pitti> Mithrandir: k
<Simira> Mithrandir : buy dinner!
<siretart> magnon: did you notice, pitti has uploaded a the new jackd to dapper, so we can start that transition
<magnon> yes I did :)
<magnon> he told me
<siretart> great :)
<magnon> I will look at it when I get back tonight I guess
<magnon> but now, time for board meeting in the party
<siretart> oh. have fun there! 
<magnon> thxbye. :)
<sivang> Mithrandir: you know anything about the Zope3 Packages?
<Mithrandir> no
<sivang> Mithrandir: ok
<rob^^^> https://wiki.ubuntu.com/UbuntuExpress/GnomeUserInterface <- any thoughts on that suggestionf or combining steps?
<ogra> elmo, ping
<elmo> ogra: ?
<ogra> elmo, something weird seems to have happened to sdl-mixer, could you kick it to trigger a build ? 
<elmo> ogra: no, talk to infinity or lamont, they handle the buildds
<ogra> ok
<ogra> infinity, ping ? 
<infinity> Pong!
<infinity> sdl-mixer?
<infinity> Looking.
<ogra> infinity, greta, thanks
<ogra> seems there was a race with smpeg at build time
<seb128> infinity: please kick sound-juicer build
<seb128> infinity: it failed because of gnome-media beeing not installable which is fixed
<jbailey> siretart: 0.6 doesn't work.
<infinity> seb128 : I think I'm going to do a mass-give-back soon anyway, since half the GNOME build-dep chain was uninstallable until yesterday.
<jbailey> siretart: mpool gave me an 0.6.1 last night to try intead, haven't done it yet.
<infinity> seb128 : I can't be bothered to track down what failed because of it.
<siretart> jbailey: okay, so I assume you are at it. thanks
<jbailey> siretart: Slowly, but yeah. =)
<mvo> elmo: can you please sync python-apt from debian incoming (override ok)? 
<ogra> infinity, hmm... actually it seems i'm still to jetlagged and did read the buildlogs wrong, no race there... but sdl-mixer isnt in dapper 
<seb128> infinity: half of GNOME, I've looked some days ago on it and it was like 5 packages
<mvo> any emacs-lover here who wants to have a second look on it before I request a sync?
<ogra> sdl-mixer1.2 to be precise
<siretart> mvo: I'm on xemacs ;)
* mvo waves to siretart 
<sbalneav> ogra: whenever you get un-jetlagged, let me know, and we can talk about what mods need to be added to ltspfs to tie in with the spec.
<mvo> siretart: did you had a good trip back?
* siretart waves back
<wasabi_> jbailey: howdy
<ogra> sbalneav, give me 1-2 days to sort my stuff here ... i also have to get it approved first
<siretart> mvo: yes, the jetlag is still a bit annoying, but I'm fine. could sleep a bit in the plane. How was your trip back?
<jbailey> wasabi_: Heyhey!  You pinged me yesterday for something /me looks
<wasabi_> yeah
<jbailey> Right!
<jbailey> evms.
<wasabi_> Yeah!
<wasabi_> Any thoughts?
<jbailey> evms is love, I agree.  Except that it ate my ppc partition table once and integrates poorly with the installer. =)
<wasabi_> Ah hah.
<sbalneav> ogra: no sweat.  From now on I'll be idling on both #ltsp and #ubuntu-devel, so you'll know where to find me.
<Robot101> hahahaha gaim are using linphone libraries to implement googlt talk
<wasabi_> What about using EVMS purely for activation of LVM and MD?
<wasabi_> vs using mdadm and evms and lvm
<ogra> sbalneav, oki... :)
<wasabi_> Other wise, if evms is enabled, it should proactively disable lvm and md.
<mvo> siretart: mostly good, the flight itself was a bit bumpy for 30min, but otherwise it was fine (but I feel still pretty jetlaged)
<wasabi_> And include the md evms plugin in the initrd.
<Kinnison> I thought device-mapper was meant to be integrating everything?
<jbailey> wasabi_: Hmm.  The biggest problem there is that I don't think evms puts the nodes in /dev/mapper
<wasabi_> device mapper is the kernel portion, but a user space utility has to set it up
<jbailey> wasabi_: So that may break existing setups and require people to transition again.
<wasabi_> hmmm
<wasabi_> i thought it did
<wasabi_> mine are in here.
<jbailey> wasabi_: Feel free to tell me I'm wrong. =)
<dholbach> see you
<jbailey> g'n Daniel
<jbailey> infinity: *poke*
<jbailey> infinity: This involves you more than me now. =)
<siretart> evms annoyed me a lot because it insisted on taking control over the partition table on devices handled by evms. lvm does not have such a restriction :/
<wasabi_> Hmmm. You might be thinking about the older evms.
<jbailey> siretart: Right.  With evms you have a choice of whether the partition is a pure evms partition (with crazy magic on it), or whether evms is just being nice and doing lvmish things for you.
<wasabi_> evms2 is non kernel based.
<wasabi_> It's just a user space library now that maps everything thru d-m
<jbailey> The power of evms really comes when it can add its signatures to the partitions so that it can map them reliably.
<wasabi_> Yeah, but it doesn't HAVE to do that.
<jbailey> But otherwise it'll cheerfully just assemble other devices as it sees fit.
<jbailey> Right. =)
<jbailey> Keybuk: Hey.  It occurs to me that evms has the partition reading code already in userspace.
<wasabi_> It will scan physical disks for md metadata, activate them
<wasabi_> then scan everything for lvm metadata, activate them.
<jbailey> Keybuk: Forcing evms for a scan might be a way of getting the partition table reading code out of the kernel.
<wasabi_> and then scan everything else for evms metadata and activate those.
<wasabi_> but it doesn't require evms metadata anywhere.
<siretart> well, the last time I used it, I found it very confusing and annoying. I didn't find a rescue cd that time, to reassemble broken software raid setups, so I run away
<wasabi_> I know that evms1 was pretty bad.
<wasabi_> Which is why linus wouldn't accept it.
<wasabi_> So they rewrote it in user space.
<jbailey> siretart: Yeah, it's much better this time.
<wasabi_> Now it's just a nice library/ui to manage all these different pieces: md, lvm
<jbailey> wasabi_: I suspect that forcing evms is a bit much for dapper, really.
<jbailey> It would make a good dapper+1 target.
<wasabi_> Yeah... well, you see my specific case yesterday anyways.
<wasabi_> If I do choose to use evms, they all step on each other.
<jbailey> wasabi_: Right.  In this case I run each set of stuff based on looking at the ROOT= bit and guessng.
<wasabi_> So maybe they should at least be mutually exclusive.
<wasabi_> Yeah.
<wasabi_> If ROOT#/dev/evms, disable md and lvm.
<wasabi_> and do include the md evms plugin in the initrd.
<jbailey> Well.  It only activates evms is the ROOT= is set to /dev/evms/FOO IIRC
<wasabi_> Yeah, but evms depends on lvm
<wasabi_> and lvm depends on md
<jbailey> Only in the sense that the scripts have to be ordered.
<jbailey> If evms gets to them first, lvm and md can't do their jobs.
<jbailey> and md has to come before lvm in case the volume is spread across more than one disk.
<wasabi_> and vica versa.
<jbailey> I do agree that it would be nice to have sexier handling than can be gracefully provided in shell. =)
<wasabi_> Was the evms md plugin left out for a reason?
<jbailey> I WILL NOT STOP UNTIL I HAVE A SCHEME INTERPRETOR WRITTEN IN SHELL IN THE INITRAMFS!
<jbailey> err.
<jbailey> dontmindme
<wasabi_> heh.
<jbailey> wasabi_: Yes.  It's huge and we already have mdadm
<wasabi_> But you might not be using mdadm with evms.
<jbailey> wasabi_: It was the fight to try and get the size seriously reduced.
* Kinnison hands jbailey a statically linked lua interpreter
<sladen> not sure about scheme.  But forth in the initramfs would absolutely rock
<wasabi_> Well, I need to examine this system.
<jbailey> Kinnison: Nah, I figure doing a read loop to split the string, then feeding it to a case stamement might just work enough. =)
<wasabi_> What I know is that evms did not work until I added evms md plugin to the initrd and removed mdadm
<jbailey> wasabi_: ah right, the other thing that came up was that mdrun assembles devices differently than mdadm --auto did.
<jbailey> I suspect that md.o would preserve the behaviour off mdadm (which is certainly the correct one)
<wasabi_> Yeah, sometimes does it in a different order.
<wasabi_> so if you have two md's, they switch from md0 to md1
<wasabi_> Which, metadata wise, is fine.
<jbailey> But that shouldn't change for Dapper at all.
<wasabi_> mdadm however has hard coded names in /etc/mdadm or whatever
<jbailey> No.
<jbailey> mdadm is able to detect them automatically no.
<jbailey> +w
<wasabi_> DEVICE partitions
<wasabi_> ARRAY /dev/md0 level=raid0 num-devices=2 UUID=6b8b4567:327b23c6:643c9869:663348$   devices=/dev/sdb3,/dev/sda3
<Kinnison> Hmm, a fully static lua50 interpreter with all the libs is 553k
<wasabi_> That looks hard set to /dev/md0 to me
* Kinnison imagines most of that is libc
<jbailey> There's metadata in there that suggests the MD number to set.
<Kinnison> 112k without libc
<Kinnison> and you could halve that without the libraries you don't need
<infinity> Keyword: suggests.  It doesn't have to listen to you.
<infinity> sladen : I will not put forth in initramfs, for purely religious reasons.
<Keybuk> Kinnison: libc is generally "useful"
<Kinnison> Keybuk: I assume initramfs has klibc though, so I don't have to -static
<Keybuk> I suspect we'll drop klibc as a failed experiment
<infinity> initramfs has both klibc and glibc currently, actually. :/
<Kinnison> oh dear
<ogra> ugh
<Keybuk> as soon as you have one application you need in initramfs that won't compile against klibc, you've not only lost all of the benefit of klibc but actually made things worse by having two libcs
<infinity> <nod>
<jbailey> Kinnison: Possibly.  glibc pulls in all the i18n machinery if you include a single output statement.
<Keybuk> and as you get those apps to compile against klibc, the size of klibc approaches glibc
<Keybuk> it might be better to build a minimal glibc without all that locale crap
<jdub> yeah man, locales are for girls
<infinity> mini-glibc?
<infinity> I'd sign up for that as a solution.
<Keybuk> girls and cheese-eating surrender monkeys
<jbailey> In my spare time I can see if glibc still builds with the i18n machinery disabled.  I doubt it would, but it might be anicer hack than klibc.
<sivang> lol
<Keybuk> we could have a mini-Ulrich to go with it, who only rants a little bit
<infinity> <laugh>
<infinity> I'll register a mini-LJ account right now.
<Robot101> rofl
<jbailey> That's not fair.  Ulrich doesn't rant that much.  Mostly he ignores emails.  You have to be special to actually get ranted at.
<HiddenWolf> Bij de epidemie op de Bible-belt raakten ook zwangere vrouwen besmet. Intussen zijn zeven van hen bevallen. Drie kinderen zijn geboren met een ernstig handicap, een ander kind is doof. En kind is overleden. 
<HiddenWolf> whoops
<HiddenWolf> middle-click sucks
<HiddenWolf> sorry guys
* HiddenWolf has an unfortunate tendency to highlight what he's reading with his mouse
<azeem> that, and a twitching middle finger == suck
<HiddenWolf> It happened to me in a couple of rushjob university assignments. :P
<madduck|msg_me> dilinger: vistaprint.co.uk makes free business cards, in case you want to cut your losses. sorry for the adv, no affiliation.
<davyd> can someone check my dpkg-divert syntax? dpkg-divert --divert /usr/share/icons/.../distributor-logo.png.no-ubuntu-logo --rename --add /usr/share/icons/.../distributor.logo
<madduck|msg_me> does it work?
<madduck|msg_me> looks good.
<davyd> according to me, that moves the icon to /u/s/i/h/4/a/distributor-logo.png.no-ubuntu-logo
<davyd> which is seems to
<davyd> but somehow
<davyd> panel keeps finding it
<davyd> it works on one machine, but not the other
<madduck|msg_me> is this in postinst?
<madduck|msg_me> dpkg-divert is weird. it's not a renamer...
<madduck|msg_me> it's a renaming rule.
<davyd> this is just something I ran, to make that icon go away
<davyd> but to allow dpkg to still find the file
<madduck|msg_me> here, this is the section from my book: http://rafb.net/paste/results/Wsh3Aa69.txt
<madduck|msg_me> specifically:
<madduck|msg_me> \footnote{The exact behaviour is that if
<madduck|msg_me> a package \package{foo} diverts a file \package{bar}, \programme{dpkg} will
<madduck|msg_me> only allow \package{foo} to write to the location of the original \file{bar}
<madduck|msg_me> file. If any other package writes to the file, the access is diverted.}.
<Simira> madduck|msg_me!
<madduck|msg_me> Simira!
<davyd> aah, it seems that I had a icon cache file
<ogra> infinity, can you give back gcompris please, seems all build-deps are fulfilled (they weren't at sync time) ...
<infinity> ogra : It already has been given back, unless you mean it's failed in the last hour..
<ogra> infinity, ooohhh, thanks ...
<infinity> Hrm, oh, it has failed in the last hour. :)
<infinity> In fact, it failed 7 minutes ago.
<infinity> sdl-mixer/smpeg.  I guess I'll have to manually intervene there in a bit,
<ogra> strange
<ogra> my pbuilder builds it fine over here
<infinity> I hate to sound like a broken record, but do you have universe in your sources.list?
<ogra> yes ...
<ogra> ah... smpge has only the dev parts in main iirc ...
<ogra> *smpeg
<infinity> Bingo.
<ogra> hehe... silly me
<infinity> Is this a newly-introduced build-dep, or did smpeg change?
<infinity> If the former, evaluate if you need it, if the latter, get the archive sorted. :)
<ogra> gcompris needs it
<infinity> I assume nothing actually needs to be seeded, anastasia probably just needs to be run.
<infinity> elmo : Does anastasia have anything to say about smpeg?
<ogra> i have no idea why it went to universe ...
<elmo> infinity: promotoed
<elmo> ogra: because things go to universe by default
<infinity> elmo : Ta.
<ogra> elmo, sdl-image1.2 build-depends on libsmpeg-dev, which in turn depends on libsmpeg ...
<ogra> elmo, so i would think its pulled in through this
<infinity> ogra : Yes, and anastasia picks that up (thanks to germinate), and elmo promotes it manually.
<infinity> ogra : When NEW packages are uploaded, they go to universe, until someone manually intervenes.
<ogra> ah, i see... i thought it was promoted in dapper, since gcompris built fine there
<infinity> ogra : To prevent, say, you syncing something from Debian with crazy added biuld-deps, and having the world auto-promoted without anyone noticing.
<ogra> this is no new build-dep... 
<elmo> like, say, abiword, MICHAEL
<ogra> it was there before
<infinity> ogra : SONAME bump in the library would be mhy assumption in this case (hence, a new package name)
<elmo> ogra: dude, no it wasn't, stop arguing
<ogra> elmo, i'm not arguing, i'm wondering ...
<pitti> elmo: is/was the changelog scanning on rookery down? It's missing some recent updates
<elmo> pitti: I've no idea, mvo runs it
<pitti> mvo: ^
<mvo> pitti: I can have a look
<pitti> mvo: e. g. http://changelogs.ubuntu.com/changelogs/pool/main/libu/libungif4/libungif4_4.1.3-1ubuntu0.1/changelog
<pitti> elmo: can you please sync adduser aspell-bn aspell-pt aspell-sv awstats cpio cvs grep-dctrl linux-wlan-ng pcre3 ?
<\sh> elmo: please sync alsamixergui from debian unstable, override ubuntu changes ok
<\sh> elmo: please sync alexandria from debian unstable, override ubuntu changes ok
<slomo_> elmo: please sync aatv from debian/unstable... ubuntu changes can be dropped
<slomo_> elmo: and please sync avahi from debian/experimental... thanks :)
<slomo_> jdub: ping?
<Amaranth> that rick guy is kinda clueless...
<slomo_> infinity, lamont-away: please remove fox1.4 from dep-wait... it's fixed with the latest upload
<bradb_> seb128: I just sent you an email directly telling you that Nov 11th is a holiday in Canada too. Enjoy!
* bradb_ stumbles over a web-based email interface
<seb128> bradb_: thanks ;)
<bradb_> :P
<seb128> bradb_: quick malone question, is there a "unknown" package for it?
<bradb_> seb128: nope, just empty
<bradb_> seb128: is there a reason to create an explicit "unknown" package, rather than just leave it empty?
<seb128> bradb_: somebody assigned a bug to gnome-games because the corresponding package is not known by malone (probably launchpad)
<seb128> bradb_: no, I just didn't figured how/where to reassign, I've tried to set "unknow" as package as we do with bugzilla
<bradb_> you could just unset the package field
<seb128> then "Ubuntu" since I thought I showed you a bug assigned to "Ubuntu" some day ago
<seb128> and then I just closed the window figuring I'm not malone expert to do this :p
<seb128> k, thanks
<seb128> I'll do it and remember for next time :)
<seb128> s/to do/enough to do/
<jdub> slomo_, pong
<slomo_> jdub: i've updated the gnome-user-share package to new upstream... with avahi instead of howl now... do you still want to be set as maintainer?
<slomo_> jdub: i ask as the package was removed for breezy and maybe you don't care about it anymore
<Chipzz> .win 28
<jdub> slomo_, happy for it to be taken over
<\sh> elmo: please sync alexandria from debian unstable, override ubuntu changes ok
<slomo_> jdub: ok... so you don't want it anymore? i'll upload it then tomorrow... is there something that needs to be done to get it uploaded again (maybe elmo needs to remove it from some list)?
<seb128> slomo_: oh, you are updating shared-admin?
* seb128 unmarks it of his list of packages to update
<seb128> s/shared-admin/gnome-user/share/
<slomo_> seb128: yes... dholbach asked me this morning ;)
<seb128> slomo_: cool, thanks
<slomo_> seb128: np :)
<seb128> elmo: libgnomecups sync please
<seb128> elmo: gtksourceview too
<daniels> great, discover1 is utterly broken
<seb128> pitti: are you going to make a promotion page for gtkmathview ?
<pitti> seb128: because of abiword?
<pitti> seb128: seems like an easy case
<seb128> pitti: yeah
<seb128> abiword FTBFS due to it atm
<seb128> fmtutil-sys: /var/lib/texmf/web2c/pdflatex.fmt installed.
<seb128> Error: `tex -ini  -jobname=xmltex -progname=xmltex &latex xmltex.ini' failed
* seb128 hates latex
<janimo> daniels, wan't discover1 meant to be deprecated? IIRC even during hoary there were talks about that
<daniels> janimo: xserver-xorg still uses it
<seb128> evil xorg
<janimo> I know, I meant there was some talk about unifying xorg hw detection with the rest of the world
<daniels> heh, yeah
<janimo> daniels, unrelated: do you think fixing the X600/700 ati sigills is too risky for breezy-updates? (#17421)
<slomo_> elmo: please sync avahi from debian experimental
<seb128> slomo_: are you interested in avahi?
<slomo_> seb128: sure... why do you ask? :)
<daniels> janimo: tbh I'm not *entirely* sure how
<daniels> janimo: but trust me, it's very much on my radar
<janimo> isn't the patch attached enough?is it more complicated?
<seb128> slomo_: because there is a spec about it and it will require some work before beeing accepted for dapper
<seb128> slomo_: so if you want to contribute you are welcome :)
<slomo_> seb128: yes i know the spec ;) i already told Lathiat some months ago that i can help with some stuff if he needs help on that spec...
<daniels> janimo: oh, hmm
<daniels> janimo: if that disables acceleration, then something is *seriously* wrong
<seb128> slomo_: I've worked on the draft of the spec during UBZ, but Keybuk was not quite happy with it so it has been bounced back to draft
<janimo> I think it is just the revert of what went into -75
<janimo> so it is accelerated and working as in hoary
<daniels> janimo: err, unless I'm very much mistaken, it's disabling acceleration that fixed it, and enabling it that breaks it
<daniels> -    if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, FALSE)) {
<daniels> +    if (!xf86ReturnOptValBool(info->Options, OPTION_NOACCEL, info->NoAccel)) {
<daniels> that's original -> current
<daniels> so if NoAccel is FALSE, then we're going with standard behaviour, i.e. enable acceleration
<daniels> if it's TRUE, then we're disabling acceleration
<janimo> lemme look again, double negations make my head spin
<daniels> yeah
<daniels> or triple, in this case
<daniels> (negation of the function, NoAccel, then negation of that if you use FALSE)
<slomo_> seb128: i'll think about solutions for the issues that are mentioned on the page... is someone already working on zeroconf (the application?) and what issues are with it?
<janimo> all i know that NoAccel shoul be set TRUE for the X300 chips but not for X600 ones
<daniels> hrm
<seb128> slomo_: no
<daniels> the feedback I was getting was that setting NoAccel fixed everything
<janimo> so I wrote the NoAccel = FALSE just to replace the TRUE and keep the patch non-fuzzy, otherwise that if is not needed
<daniels> right
<daniels> but yeah, looking at the logs, if it segfaults in XAA setup, then surely we're walking the acceleration path
<janimo> yes, NoAccel worked around the crash but made it slow
<janimo> then the real fix was reverting the -75 change
<janimo> I proposed the noaccel as a stopgap in the first day
<janimo> s it should be acceled and it works that way on this chip as confirmed by a X700 owner too IIRC
<daniels> hrm
<daniels> which -75 change; just patch #025?
<janimo> daniels, yes
<daniels> janimo: hrm
<janimo> I suppose I did not find the wholl 75 change
<janimo> is there a place I can see the diffs between 75 and 76
<janimo> actually -76 change the one blacklisting X300
<janimo> but which also blackliste X600
<janimo> I just assumed it was all confined to #025 as mucking with that fixes it
<daniels> yeah, it's weird
<daniels> i'm just looking at the diff now
<janimo> btw why SIGILL? I understand it happened on some P2-s but doesn;t P-M include all instructions of previous CPUs?
<daniels> so I'm wondering whether building it unoptimised (during the build, cd programs/Xserver/hw/xfree86/drivers/ati, edit the Makefile, remove all -O2 and replace with -O0) won't help
<janimo> but changing the optimization flags will still leave X600 with NoAccel true  I assume?
<janimo> so it will run but be slow
<daniels> i'm just trying to narrow it down to something that crashes and something that doesn't
<daniels> so if leaving that patch in (the one from -76) and having an optimised build breaks, and leaving the patch in and not having an optimised build works, then we've found our problem
<janimo> by works you mean accelerated?
<janimo> or just does not crash
<daniels> not crash
<daniels> not having accel sucks, but it's not fatal; crashing on start is, so I'm trying to work out what's causing that first
<janimo> but that will still be a regressiojn from hoary
<daniels> sure, but a less crap one.  one issue at a time; the bug is already confused enough as is.
<janimo> I agree that my patch just avoids this card trigerring a deeper bug
<daniels> one other thing to try I guess is changing the definition of NoAccel in radeon.h from Bool to int
<janimo> so should I try the -O2 trick and then the Bool->Int one?
<janimo> It's midnight here, I may try now, if not tomorrow morning, and update bugzilla
<daniels> janimo: try Bool to int first, then -O2
<daniels> janimo: okay, thanks
<janimo> ok
<janimo> You mean this in radeon_driver.c ? { OPTION_NOACCEL,        "NoAccel",          OPTV_BOOLEAN, {0}, FALSE },
<janimo> I see no NoAccel in radeon.h
<daniels> in #025
<janimo> aha
<mjg59> daniels: Of course, my X300 stopped crashing shortly before the end of the Breezy cycle
<mjg59> I need to test it with Breezy final, but -3 days it seemed to work and be fast
<mvo> elmo: please sync emacs21 from debian (override ok)
<seb128> elmo: please sync gnome-common gnome-keyring
<pitti> mvo, seb128: I just finished the sudo patch for testing a command
<pitti> unfortunately upstream's patch did not work
<seb128> why ?
<pitti> seb128: too far away from the stable release
<pitti> seb128: and it was huuuge
<pitti> seb128: now I added a -t option and simply just exit with the test result instead of executing the command
<pitti> seb128: small patch
<mvo> pitti: nice
<Amaranth> i thought you could just see if the user was in a certain group
* mvo needs sleep
<Amaranth> all sudo users are in the admin group, aren't they?
<pitti> Amaranth: no, that's not general enough
<pitti> Amaranth: no
<seb128> Amaranth: no
<pitti> Amaranth: you can give certain users only certain restricted privs
<seb128> Amaranth: where is your new menu editor?
<seb128> pitti: cool
<Amaranth> seb128: I currently have no computer to finish the package on, for complicated reasons
<Amaranth> none of them hardware releated
<Amaranth> err, related
<seb128> hum
<seb128> you pointed a package when I was at UBZ
<seb128> and you have destroyed this one now?
<Amaranth> and you didn't like it
<Amaranth> no
<Amaranth> bob2 was working on an ITP for debian, i think
<seb128> I've not said I didn't like it
<seb128> there is like 2 points to change
<seb128> if I get the tarball I can update smeg to it in 5 min
<Amaranth> tarball?
<Amaranth> you mean the orig and diff?
<seb128> you know, what upstream ship
<seb128> sources
<Amaranth> ah
<seb128> no, if you have no package I don't really care
<Amaranth> brb
<seb128> updating from the current smeg package takes like 5 min
<seb128> just point a tarball of the sources
<seb128> bob2_: are you packaging smeg for deb?
<Amaranth> http://dev.realistanew.com/alacarte/releases/0.8/alacarte-0.8.tar.gz
<seb128> Amaranth: thanks
<Keybuk> http://www.netsplit.com/2005/bootchart-dapper-20051109-1.png
<Keybuk> ^ shiny
<Amaranth> shiny but not good
<Amaranth> over 1 minute?
<seb128> Amaranth: there is a deb-src, do you want to get your package sponsored?
<Amaranth> that's the one that needed the changes
<Amaranth> if you want to do those real quick and upload it, sure
<seb128> I don't have the comments I made on this box
<seb128> but that was like 2 minor points
<seb128> sure I can do the changes and upload tomorrow
<seb128> (I'm going to bed soon for today)
<Amaranth> it was removing the symlinks and the mv in rules and putting the smeg changelog back in
<seb128> but you can as well fix that if you have noted them :)
<Amaranth> I have no way of testing, I hate doing things without being able to make sure they work
<seb128> k, I don't really care about the changelog
<seb128> but I'll do an upload based on your version
<seb128> just fixing the naming stuff
<seb128> ok ?
<Amaranth> ok
<seb128> cool
<daniels> why the hell does emacs need patching to support ppc64?
<Amaranth> because emacs sucks?
<pitti> I bet it has an integrated assembler :-)
<\sh> elmo: please sync apt-move from debian unstable, override ubuntu changes ok
<daniels> Keybuk: klibc> heh
<Keybuk> brb
<Keybuk> x.org is teh suck
<Keybuk> it should cope better with me rmmod'ing mouse modules from under it
<daniels> patches happily accepted
* ..[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
<pitti> you know, with a topic of 4353245342 chars, I can never remember what you actually *changed*
<Amaranth> i was just about to ask
<Keybuk> pitti: http://www.netsplit.com/software/topicdiff
<daniels> probably removal of #ubz?
<pitti> Keybuk: thanks, cute
<pitti> Keybuk: you have a script for *everything*, don't you? :-)
<Keybuk> almost
<jbailey> Keybuk: He keeps threatening to replace me with a shell script, but if he did he wouldn't have anyone to show his initramfs-tools hacks to ;)
<jbailey> err.
<jbailey> pitti: ^^
<daniels> Keybuk: xchat is the SUCK
<Keybuk> daniels: someone (pasc?) wrote one for irssi too
<pitti> jbailey: I figured
<Keybuk> my initramfs hack is love
<carstenh> pitti: do you use xchat? if not, i have one for irssi :)
<Keybuk> it even lets the initramfs get cleaned up, because it's chrooted into a different tmpfs and has its own mount of /proc
* pitti follows the dogfood approach in this regard
<pitti> (I use xchat)
<carstenh> ah, ok
<daniels> carstenh: url for irssi plskthx
<Keybuk> http://www.redellipse.net/code/topic-diff
<carstenh> daniels: just a minute
<carstenh> daniels: http://svn.df7cb.de/dotfiles/cb/.irssi/scripts/topic-diff.pl 
<daniels> 'sokay, I've grabbed pascalito's
#ubuntu-devel 2005-11-15
<azeem> dude, you lived without topic-diff.pl until now?
<Riddell> is there an ubuntu art IRC channel?
<ogra> Riddell, #ubuntu-artwork
* \sh needs a beer
<Riddell> ogra: thanks, I'd tried all other possible combinations
<ogra> heh
<womble> How do I get added as a maintainer of a package, so I can see all of my bugs in launchpad?  Or does somebody With Authority have to mark me as maintainer?  (Neither the Launchpad nor Ubuntu wikis are giving me any love)
<daniels> womble: With Authority, AIUI
<womble> daniels: Any idea who I might make my request to?
<daniels> no clue, sorry
<\sh> womble: are u upstream?
(womble/#ubuntu-devel) \sh: Define "upstream".  I'm Debian maint for about a dozen things, and Ultimate Upstream for one or two.
(womble/#ubuntu-devel) Is there a way I can subscribe to bugs on a package?
<\sh> womble: ok...to be ultimate upstream, for this ask on #launchpad 
<\sh> womble: regarding packages...well...yes...this is a real problem, without maintainership in ubuntu :)
<womble> \sh: I'm not pro Maintainer Death Grip, but there is always going to be some collection of packages I'm more interested in over the average.
<\sh> womble: do u know if your packages are in main or in universe? if universe please check here for bugs on your packages https://launchpad.net/people/motu/+assignedbugs
<\sh> womble: or check here: https://launchpad.net/products/+all
<\sh> womble: but this is all launchpad...so i think this is more #launchpad 
<womble> \sh: Uhm, +assignedbugs isn't useful to me -- waaaaaaaay too much noise.
<womble> \sh: I'll go and ask over there.  Thanks.
<\sh> womble: this is only for universe packages
<womble> \sh: "Only" universe is still a big list of packages -- 99.9% of which I have no interest, experience, or knowledge of.
<\sh> womble: welcome to the real world of the MOTUs :)
<ogra> womble, you need a launchpad account, then you can just subscribe to the bug... regarding that launchpads malone also will track upstream bugs or debian bugs, you could even use it for all your bugtracking
<ogra> its quite capable to centralize this stuff :)
<bob2_> Amaranth: yes, still working on it
<bob2_> Amaranth: seb128 uploaded pyxdg 0.15 yesterday or so
<womble> ogra: I've got a launchpad account.  Before I can subscribe to the bug, though, I need to know it exists.  And launchpad needs a couple of dozen major features before I think about switching away from the Debian BTS as my primary bug tracker for Debian packages.
<ogra> womble, whats missing ? file whishlist bugs on malone :)
<womble> ogra: https://wiki.launchpad.canonical.com/PackageSubscriptions, for one
<womble> Far better e-mail based bug management, for another.
<ogra> search for products via https://launchpad.net/products
<womble> (Which I think there's a spec somewhere for, too)
<ogra> womble, did you try the email management yet ? 
<tseng> PackageSubscriptions is a must for everyone since a long time
<tseng> hopefully it will land RSN
<ogra> tseng, !
<womble> ogra: docs?
<tseng> ogra: !
<tseng> hiya
<ogra> tseng, my f-spot died :/
<ogra> with todays upgrade...
<tseng> ...the dbus rebuild?
<ogra> seems i cant get a mono-mcs to build the source myself ... i havent tracked it further yet
<tseng> ok, what is the symptom?
<ogra> s/to/package to/
<tseng> and why the hell do i have screenshots of ancient rhythmbox mockups in my ~
<ogra> lol
<tseng> hm they are in rb cvs
<tseng> ogra: do you get a "backtrace" spit out
<ogra> tseng, nope, it just hardlocks
<tseng> hm
<ogra> during scrolling through the images or the timebar
<\sh> pitti: when are u uploading libjack0.100.0?
<pitti> \sh: a day ago
<\sh> pitti: grmpf.
<janimo> daniels, how to rebuild just the ati driver in the x tree?
<pitti> \sh: jack-audio-connection-kit |  0.100.0-4 | http://archive.ubuntu.com dapper/universe Sources
<janimo> I issue make in build-tree
<pitti> \sh: magnon wanted me to do that fast, since he wanted it for the transition in universe (for syncs, etc.)
<\sh> pitti: yeah
<janimo> and then copy ati_drv.o to /usr/x/lib/modules?
<\sh> well...so he should do the transition 
<janimo> debuild binary rebuilds the whole tree
<\sh> pitti: so..when are u fixing jack-audio-connection-kit? ,)
<pitti> ?
<daniels> janimo: start debuild -us -uc, then ^C it when it starts actually running gcc on things
<daniels> janimo: then cd programs/Xserver/hw/xfree86/drivers/ati and make
<\sh> pitti: E: Package type-handling has no installation candidate
<pitti> \sh: that's already fixed
<pitti> \sh: the package has moved to universe and could be uncrippled
<janimo> daniels, and the resulting ati_drv.o is good to go?
<daniels> janimo: right
<janimo> I'll try
<ogra> tseng, i'd look myself, but there seem to be only mono-gmcs and mono-common to be in the archive
<daniels> janimo: well, you'll need radeon_drv.o rather than ati_drv.o
<daniels> janimo: but yeah
<\sh> pitti: hmmm...because right now we don't have anything which looks like libjack
<\sh> pitti: install-ish
<tseng> ogra: id say that is false, since slomo_ and i built everything before upload
<pitti> \sh: libjack0.100.0-0 |  0.100.0-4 | dapper/universe | amd64, i386, powerpc
<tseng> ogra: and the buildd had no such trouble either
<tseng> pool/main/m/mono/mono-mcs_1.1.9.2-1ubuntu1_all.deb
<ogra> very strange
<\sh> pitti: strange updated dapper pbuilder is complaining...moment
<ogra> tseng, sorry... i looked at universe ....
<pitti> elmo: please sync ruby1.8
<\sh> generating dapper dchroot 
<\sh> pitti: looks like our jack needs a little give-back
<pitti> \sh: we can't give back packages that successfully built
<\sh> pitti: hmm...strange..I don't see it on the buildd logs 
<pitti> \sh: http://archive.ubuntu.com/ubuntu/pool/universe/j/jack-audio-connection-kit/
<tseng> jdub returns!
<pitti> \sh: http://people.ubuntu.com/~lamont/buildLogs/j/jack-audio-connection-kit/0.100.0-4/
<pitti> \sh: it took a while until it was demoted to universe, thus the many FTBFS
<\sh> pitti: ok....could be there is a glitch in the matrix....
<pitti> \sh: out of date mirror?
<\sh> pitti: archive.ubuntu.com?
<pitti> that one's fine
<\sh> pitti: u see...why i'm confused
* pitti blames the jetlag
<\sh> haha
<\sh> yeah....I'm still not clean
<\sh> but anyways..building a clean chroot 
<sistpoty> ' \sh a clean dapper chroot or updated from breezy?
<\sh> updated from breezy...if this is not helping...I'll have to install new debootstrap
<sistpoty> I tried a new dapper (not updated) some hours ago... didn't finish :(
<sistpoty> but maybe it was my fault ;)
<janimo> daniels, crashes with NoAccel bool/int and -O2/-O0 all combinations
<janimo> only NoAccel FALSE saves
<daniels> janimo: gnar
<janimo> any debugging hints?
<janimo> I tries sudo gdb X
<LaserJock> I was able to make a clean dapper chroot last week or so but haven't tried recently
<janimo> but that made the screen blank had to reboot
<daniels> janimo: gdb'ing from the same machine is a no-no
<daniels> janimo: the server gets a signal, so gdb stops it in-place -> your video card is screwed
<daniels> you need to do it remotely
<daniels> my best thought at the moment would be to remove info->NoAccel and just do a test in radeon_driver.c a la -75, but that's a nasty hack
<janimo> you want to find the reason it crashes not just fix it for X600/X700 right?
<daniels> yeah
<\sh> ok...something is really wrong
<janimo> since noaccel is true when it crashes is it in XAA as you said earlier?
<janimo> does XAA handle the non acceled path too?
<daniels> if noaccel is true, xaa shouldn't be called at all
<janimo> but you said you thin it crashed in XAA
<janimo> that would be weird in this case
<daniels> very
<janimo> should I build the -dbg version for gdb-ing?
<janimo> I see there's an xc-dbg dir created
<daniels> nah, the radeon_drv.o in your build tree is unstripped
<janimo> isn;t it possible that it crashes outside radeon?
<Riddell> op needed in #ubuntu
<Riddell> poke seb128, bob2, fabbione, lamont, thom, Keybuk, fooishbar, jdub, mdz, Amaranth, tritium ajmich, crimsun, ogra, CarlK, Seveas, Burgundavia, apokryphos, thoreauputic, and Nalioth
<janimo> I'll try remote gdb tomorrow.is that gdb through a ssh login, or gdb-server and such sofistication?
<daniels> janimo: just gdb through ssh is fine
<janimo> ok, I'll let you know what I find
<daniels> thanks a lot dude, appreciate it
<janimo> np, thank you too
<Keybuk> Riddell: wouldn't they run out of poking steam half way through that list
<Keybuk> mdz: does lrm-manager /deliberately/ remove the volatile tmpfs after an upgrade?
<Keybuk> or is that just somebody failing to check "$1" = remove/purge
<Keybuk> Rejected: ardour_0.99-3ubuntu1.dsc refers to ardour_0.99.orig.tar.gz, but I can't find it in the queue or in the pool.
<Keybuk> ^ who wants to own up? :)
<\sh> Keybuk: thx to launchpad discussion
<\sh> Keybuk: my fault...sorry
<\sh> i just banged my head against the wall for it
<mdz> Keybuk: dunno
<Keybuk> it could be useful to keep it if KVER=@@KVERSION@@ ... otherwise I guess it makes no difference
<sistpoty> elmo: please sync gvr (1.3.4-1) override ok
<tritium> Is the Ubuntu "engineer" certification program in place?  The IBM DB2 announcement refers to "Ubuntu engineers"...
<\sh> elmo: please sync armagetron from debian unstable, override ubuntu changes ok
<jdong_> hey guys, would it be at all possible for me to get (1) Fridge (2) people.ubuntu.com/~jdong accounts?
<bob2> people accounts require login access to rookery
<bob2> and I'm pretty sure only employees have tat
<jdong_> ah, ok... darn...
<jdong_> what about the fridge?
<bob2> talk to jdub or whipruh, I suppose
<ogra> you need to be a member i think
<daniels> i believe rookery (and thus chinstrap) accounts are canonical-only at this point in time
<daniels> but fridge's independent of that, so yeah, talk to jdub or whiprush
<lifeless> chinstrap as bastion will be fixed soonish I hear
<lifeless> which *may* make having non employee people doable.
<daniels> heh.  according to getent passwd, dsilvers got his account before I did.
<bob2> haha
<whiprush> jdong_: jdub is the guy to talk to about fridge stuff, he has (wisely) kept my account mostly powerless. :)
<jdong_> alright, I'll ring jdub later tommorrow
<jdong_> thanks everyone
<whiprush> in the meantime feel free to ping me on irc if you need anything fridge-wise.
<jdong_> whiprush: absolutely :)
<jdong_> ** time to bug MOTU :)
<jdong_> yay
<Kamion> hah, early 'getent passwd' is so not in employment order
<daniels> Kamion: yeah
<daniels> also, jane's account on chinstrap is ... interesting
<pitti> heh
<mvo> Kamion: is elmo somewhere near you?
<Keybuk> yes
<Keybuk> he's a little busy currently though
<mvo> Keybuk: ok, I will send a mail to rt@admin then. it looks like there is something wrong with archive.u.c and the Release file for breezy
<Keybuk> uhhhh
<mvo> yes :/
<wasabi> Odd.
<wasabi> Monodevelop is somehow not in dapper.
<Keybuk> hmm?
<Keybuk> gpg: Good signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>"
<Keybuk> wasabi: uninstallable
<Keybuk> mvo: what do you think is wrong with the Release file?
<elmo> mvo: one of archive.u.c was broken earlier
<elmo> and apt gets horribly confused
<elmo> point at a nother mirror, run update, point back, should fix
<elmo> kthx
<mvo> elmo: I know how to fix the problem, but I think there will be others who don't. it seems to me like it might be enough to just make sure that apts I-M-S request gets something else than a "not modified" to fix the problem
* tseng wonders why the evolution team insists on major breakage every cycle for seemingly little improvement
<mvo> Keybuk: yeah, seems to happen only for people who updated in the timeframe that the release file changed and got it from the particular server
<Keybuk> mvo: yeah, we know why it happened :p
<Keybuk> I'll let elmo tell the world though
<elmo> the problem is the broken server was in rotation, if apt in stable is broken, this is going to be super unpleasant
<mvo> elmo: I don't think it's apt that is broken, it requests the Release file with a I-M-S header and gets a 304. so it uses its local copy that is different than the server version and the Relesae.gpg file does not match
<elmo> mvo: ok, so I'm too tired to argue, but I think apt has to deal with this case
<elmo> but in any event we need to regen breezy for other reasons
<elmo> so this should only be a transient problem
<mvo> elmo: ok, thanks (I'm happy to talk to you about how apt can be fixed here once you are more awake)
<mpt> desrt, ping
<Keybuk> pitti: ping
<pitti> Hi Keybuk 
<Keybuk> linux-wlan-ng ... does that do depmod in its postinst and postrm?
<pitti> Keybuk: apparently not
<pitti> Keybuk: but it calls update-modules
<Keybuk> pitti: it'll need to now
<Keybuk> heh, that's 2.4 shit dude :p  RELEASE THE MODUTILS DEP
<pitti> Keybuk: that's added by debhelper
<pitti> Keybuk: dh_installmodules or so
<pitti> Keybuk: if that's wrong, we should fix debhelper instead
<Keybuk> hand me a hammer :)
* pitti gives Keybuk a horribly large sledgehammer
<Keybuk> but yes, it'll need to run depmod -a -q -F /boot/System.map-$KERNEL_VER $KERNEL_VER now
<Keybuk> after install and removal
<pitti> *shudder*
<pitti> that should really be in a wrapper script
<pitti> update-modules sounds conveniently generic
<crimsun> hmm didn't module-init-tools deprecate that?
<Keybuk> update-modules will be gone RSN
<pitti> Keybuk: it seems that we should fix dh_installmodule then and just rebuild the affected packages?
<pitti> to keep the delta small
<Keybuk> KERNEL_VER is the kernel version for the modules you're installing, not the kernel version running on the system
<Keybuk> anyhoo, it'll just mean your linux-wlan-ng things won't work right now unless you manually run depmod after booting
<Keybuk> or boot now :)
<Keybuk> (btw, I have no problem with patching dh_installmodules to run depmod)
<desrt> mpt; pong
<mpt> desrt, you're the assignee for https://launchpad.net/distros/ubuntu/+spec/power-management-configuration
<mpt> UBZ finishes tomorrow
<mpt> I put a bunch of outstanding issues at the bottom of https://wiki.ubuntu.com/PowerManagementConfiguration
<mpt> Is it ok if I incorporate those points into the design and try to get it approved tomorrow?
<desrt> mpt; uhm.  OK.
<desrt> mpt; generally speaking, the final thought that we came to was that we would attempt to get richard to address the bullet points under 'backend' upstream
<desrt> mpt; so i've written him an email on this subject and am awaiting a reply just now
<desrt> mpt; if you have UI suggestions that need merging, those are OK
<mpt> ok, great
<desrt>  "Remaining percentage" doesn't really make sense when the battery is charging. <- not true
<mpt> no?
<desrt> agree with ... on prefs
<desrt> yes.  the alert dialog box is scary.
<desrt> slider for turning off the screen is good.  also perhaps one for dimming it
<mpt> ok
<desrt> we decided that automatic shutdown on mains power was not something that we should address (but i'm willing to hear an argument to oppose that)
<desrt> when "suspend on lid close" is turned off it's obvious that just nothing happens
<desrt> (although, in reality, the screen will be turned off)
<mpt> right
<desrt> the lock-on-suspend thing *is* tricky (perhaps impossible) if the normal screensaver doesn't require a password
<desrt> i overlooked that in the BOF
<desrt> the "issue warning" text is awful
<desrt> should read something like "issue warning when remaining time falls to:"
<desrt> and then it becomes obvious what the issued warning will be, even if not explicitly stated
<mpt> ah, so if the screensaver is set to not require a password, waking up has nothing to ask to do the authentication UI?
<desrt> bingo.
<mpt> ok
<desrt> i lie
<desrt> gnome screensaver is smarter than me :)
<desrt> if you call gss-cmd --lock even when lock-on-blank is diabled it still locks
<desrt> so we're OK on this point
<mpt> great
<desrt> are you editing now?
<mpt> not right now, in theory I'm asleep
<desrt> ok
<desrt> i'll hack it a bit, then
<mpt> ok, and I'll draw some nice pictures tomorrow
<mpt> er, today
<desrt> sweet
<mpt> past midnight already, I should sleep
<mpt> thanks desrt 
<desrt> np.
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti> jdub!
<Keybuk> http://www.netsplit.com/2005/bootchart-dapper-20051109-2.png
<Keybuk> ^ that's a _little_ better (10s quicker)
<desrt> i love bootchart :)
<desrt> mpt; more or less done now (if you're still awake and want to give a look)
<mpt> thanks desrt 
<desrt> is ok?
<desrt> you were right about the power dialog... switchuser/logout don't belong on it :p
<mpt> jdub, https://wiki.ubuntu.com/BrowserDefaults is (probably) ready for your approval 
<Keybuk> desrt: do you notice what's a little unusual about that one? :)
<Keybuk> I hacked it to start in the initramfs, and live in its own little filesystem throughout the boot process
<desrt> Keybuk; no.  i just look at the pretty graphics without actually absorbing info :p
<mpt> Keybuk, what's that between 25s and 35s?
<mpt> or 26 and 36, rather
* pitti falls into bed now -- cu tomorrow
<Keybuk> readahead being very badly optimised with a stupid list someone pulled out of their arse
<Keybuk> that should be a 3s blip of full IO, not a ski-slope
<infinity> Hey, the list was correct a year ago. :P
<infinity> (or more)
<mpt> heh
<Keybuk> infinity: that list was _NEVER_ correct
<Keybuk> /var/log/cups/error_log
<infinity> Hah. :)
<Keybuk> yes... that needs reading int o memory
<infinity> Special.
<Keybuk> /var/log/Xorg.0.log
<Keybuk> OBVIOUSLY we need that one
<mpt> jdub, it may need a little decantankerization, your call :-)
<infinity> I assume it was base don files touched during boot, and not much tweaking. :)
<infinity> Achwell.  Easy enough to clean up.
<infinity> And not cleaning it up in breezy means that dapper will seem THAT MUCH FASTER. :)
<infinity> Keybuk : The new lrm didn't seem to blow up for me.  Okay for you?
<Keybuk> yup, seemed ok for me
<Keybuk> it did a depmod when it installed
<Keybuk> and didn't seem to mind one not happening on boot
<infinity> Yeahp, I checked that.
<infinity> \lo/
<infinity> s/l//
<HrdwrBoB> yeah I always wondered why on earth I was doing a depmod every boot
<infinity> Cause it's FUN.
<Keybuk> ok, so we're depmod'ing modules that we then throw away
<Keybuk> and the modules that you have on that volatile tmpfs aren't the modules that are referred to in the lists
<Keybuk> but that's ok
<Keybuk> because they LOOK A LOT LIKE THEM
<infinity> Keybuk : Yeah, it feels horribly evil, but the reasoning is sound.
<mpt> desrt, would adding sleep/shutdown options for mains power, parallel to those for battery power, be much extra work?
<infinity> Keybuk : Now, if you can convince jbailey (as I've been trying to do) that fragmented/chained initramfs images are utter crack and something we won't support, then we can kill the depmod in initramfs.
<HrdwrBoB> haha
<Keybuk> he seems to think it's a good idea
<Keybuk> otoh, that depmod is run in an initramfs, reading modules in the same initramfs
<Keybuk> which can be defined as "reading memory"
<Keybuk> it's so fast, it defeats time
<infinity> Keybuk : Yes, but it's still painfully slow for some users, for reasons unknown.
<Keybuk> I think they're lieing
<desrt> mpt; no.  but it's extra pref for something that almost nobody will want
<Keybuk> and it's really the "Loading modules" that's slow
<desrt> mpt; talk to corey :)
<Keybuk> some of those do block a bit
<Burgundavia> desrt, talk to me about what?
<mpt> desrt, so you don't like my "gone for the holidays" use case? :-)
<desrt> Burgundavia; if we have preference for dim/poweroff-screen/sleep when on mains
<infinity> Keybuk : If you package up the bootchart crack, we can find out once and for all, by asking the problematic users to install it. :)
<desrt> mpt; no.  it's definitely bogus :)
<Keybuk> infinity: yes
<Keybuk> I should try and find a better way of building the pretty charts than java
<desrt> mpt; you'd be much better to come up with a way to make sure the coffee pot is turned off :)
<infinity> Does gcj not compile it?
* mpt has a desktop computer, but no coffee pot
<mpt> desrt, Windows has had such options since 98, afaik, and similar for Mac OS
<desrt> cry
<desrt> ok.  how about this
<mpt> that doesn't necessarily mean they're a good idea, I'm just saying
<desrt> if you want to modify the spec i won't stop you
<desrt> -but-
<desrt> if we're adding this many items then we'll probably need to reintroduce tabs
<desrt> and i want you to think long and hard about it before you go and do that
<desrt> each additional preference knob comes at the cost of confusign the user a little bit more
<mpt> absolutely
<Keybuk> infinity: dunno yet, I should find out
<infinity> Keybuk : Well, if it compiles it first try, that seems the path of least resistance.
<mpt> I don't think *that* would need tabs, though, desrt
<desrt> ok
<Burgundavia> mpt, there really isn't much usecase for dim/poweroff-screen/sleep when on mains
<desrt> just keep in mind.... 7 sliders in a pref dialog looks intimidating
<Keybuk> infinity: then I'd have no excuse not to write a rules file and stuff :)  I was almost tempted to just build a _all.deb by hand <g>
<mpt> Where's your environmental conscience, Burgundavia 
<infinity> Keybuk : Hah.
<infinity> Keybuk : The dpkg maintainer should remind himself how to build source packages from time to time anyway. :P
<Burgundavia> mpt, sleep is really only a laptop thing currently
<desrt> mpt; he don't care about pollution
<mpt> desrt, basically turn the word "batteries" into an option menu
<desrt> mpt; he's an air-conditioned gypsy
<mpt> so flipping the menu changes which options are shown
<desrt> mpt; watch the police and the taxman miss him
<mpt> that's one way to do it if you don't like 6 sliders at once
<Keybuk> infinity: bah
<Keybuk> I'LL PUT JAVA IN THE INITRAMFS!
* infinity radiates hate.
<desrt> so like
<mpt> ("They put coffee in the initrfamfs, in Brazil")
<desrt> When running on [ Battery       | v ] 
<desrt>                 | AC Power           ] 
<mpt> yah
<desrt> and then under that have the sliders that change depending on what pulldown item you select
<desrt> vaguely undiscoverable but not too bad
<desrt> better than having all 7 at once, i think
<mpt> desrt, if you have a copy of the Mozilla suite hanging around, have a look at its font prefs
<mpt> I used a similar idea there
<desrt> mpt; THAT DIALOG HAS NEEDED TO DIE FOR TEN YEARS
<desrt> holy shit i hate the mozilla font dialog
<mpt> Mozilla's font prefs are crack, but I'm talking about the layout :-)
<Keybuk> that's crack too
* mpt blames the W3C
<desrt> welcome to the 21st century
<desrt> we have this thing called unicode
<desrt> it means that every character set on earth doesn't require its own font
<mpt> yah
<desrt> 21st century meet mozilla.... mozilla, MEET THE FREAKIN' 21st CENTURY!
<Keybuk> mozilla is the american version of a browser on a diet
<Keybuk> big mac, large fries, chicken nuggets but a DIET COKE!
<desrt> atkins?
<jsgotangco> yum
<Keybuk> so it's still fat, but can just squeeze through doors if shoved hard enough
<mpt> Keybuk, where Netscape 6 is the one with the normal Coke?
<desrt> it
<desrt> 's a shame that firefox is so intensely popular
<Keybuk> mpt: SUPER SIZED
<mpt> and Netscape 7 is the one with extra cheese
<desrt> since ephy is a better product
<Burgundavia> desrt, indeed
<desrt> but it's worth shipping firefox with ubuntu just because of its popularity
<desrt> everyone knows how to use it and everyone likes it
<mpt> rename it to Ephyfox and give it an icon of some sort of animal burning up on re-entering Earth's atmosphere
<desrt> and certainly, everyone has at least _heard of_ it
<desrt> Ephyrfox
<mpt> Epyrephox
<Burgundavia> ZephyrFox
<Burgundavia> ZephyFox
<dilinger> CrashyFox
<desrt> isn't zephyr some weird IM service?
<mpt> my Toshiba's called zephyr, because it's running Breezy
<desrt> one of my servers at school is called breezy because it's running breezy
<neuralis_> desrt: zephyr is the old-school internal MIT IM system.
<desrt> i want to register 6 hostnames at mcmaster... and they're all available except for 1
<desrt> available: up, down, truth, beauty, charm
<desrt> taken: strange
<desrt> that was just the rain on my parade :(
<freeflying_> smurf: hi
<jdub> hmm, 2.6.15 is sounding good'
<dilinger> just read the lwn article too, eh?
* Burgundavia laughs at http://www.linux.org/dist/reviews/openlab4.html
<Burgundavia> "living in Ubuntus shadow"
<jdub> yay ubuntu tree in lwn kernel page! BenC :-)
<Burgundavia> desrt, you had a chance to chat with richard yet?
* Burgundavia wonders what to do about the feedback we are getting on MenusRevisited
<Burgundavia> salut magnon 
<magnon> hey corey
<Burgundavia> where you in the MenusRevisited stuff?
<magnon> I think so
<rob^> does this chan have a log somewhere?
<Burgundavia> rob^, yes, same place as all the rest
<magnon> yeah, I did attend menus revisited
<rob^> Burgundavia, thanks
<Burgundavia> salut marilize 
<marilize> Burgundavia: mr burger, how are you???
<jsgotangco> hey hey
<Burgundavia> marilize, tired and I should be going to sleep
<jsgotangco> Burgundavia, started working again?
<marilize> yes, just wanted to ask, what are you still doing up.....
<beppo> Hi #ubuntu-devel
<Burgundavia> jsgotangco, I went back to work on monday
<Treenaks> marilize: "still"?
<marilize> slept the whole day yesterday, two days of traveling, not fun
* Treenaks slept for 14 hours
<Treenaks> and is STILL tired
<zakame> whoa
<marilize> treebaks! hi
<marilize> treenaks
<marilize> hi everybody!
<beppo> is there ia list to report problems or bugs in order to help? 
<highvoltage> hi marilize 
<Treenaks> beppo: http://launchpad.net/
<beppo> thanks Treenaks 
<beppo> there is probably a problem with bogofilter on the CD of Ubuntu 5.10
<highvoltage> marilize: back in .za?
<beppo> libdb4.3-dev  needs to be installed
<marilize> highvoltage: yes, got back wed. morning
<Treenaks> marilize: oh you were on the same plane as JaneW?
<marilize> Treenaks: no, she left a day after me, but i went via London with a 12 hour layover
<Treenaks> marilize: ouch
<Treenaks> we had to run to catch our plane to Amsterdam in Heathrow
<Treenaks> (almost)
<magnon> Hm. I just asked my mother on msn if she could tell me something very positive about me that I could put on my CV for now
<magnon> and then... she logs out instantly
<magnon> :(
<Treenaks> magnon: http://www.albinoblacksheep.com/flash/blockedme.php
<Treenaks> (flash)
<magnon> I don't have flash
<magnon> ppc
<Treenaks> oh yeah, you're one of THOSE people :)
<magnon> which reminds me, I'm supposed to ubuntify a bunch of machines here
<Treenaks> magnon: uh.. you can resolve weird problems with Chinese/Canadian hotel staff
<magnon> can't be liberal youth office without ubuntu machines, can it
<Kamion> keyboardMash: http://people.ubuntu.com/~fabbione/irclogs/
<Treenaks> magnon: isn't that a CV-able skill?
<magnon> Treenaks: Oh, guess so
<magnon> thanks :p
<keyboardMash> Kamion, thanks, found it 
<magnon> ugh, I need fake references :P
<magnon> I have... ten different trusted positions of voluntary work, and led a bunch of (still voluntary) IT-projects and teached computer security for youth
<magnon> but I just have high school and my only work reference is my own business :P
<magnon> oh, in fact I didn't complete high school totally, I miss two subjects. Even better.
<Treenaks> magnon: I have that, I just got hired by .nl's coolest ISP (xs4all) :)
<zakame> magnon: aww
<magnon> zakame: ah well, people often question my responsibility, but I usually just say I had two years of leadership of a cultural event in Oslo which had a budget for about 20,000 which I was personally responsible for. It helps. :P
<zakame> magnon: good for you... at least you still get to take such a lead :)
<magnon> zakame: I could do such a thing again, but my wallet is dusty
<zakame> magnon: here in .ph, 'tis very hard to get a good job without a college degree :(
<magnon> same here
<zakame> but what really bakes the noodle is that getting a good education is even harder :(
<magnon> oh, we get that for free :p
<Treenaks> magnon: if you marry me, you could become a Dutch citizen. If you're <28, you can get it for free :)
* magnon is <20 anyway
<Treenaks> magnon: oh.. kick your parents into paying then
<magnon> paying for education? it's free, I said :P
<Treenaks> say you'll pay it back when you have a decent job -- which the education will provide
<Treenaks> "See it as an investment"
<Treenaks> magnon: oh.. I read "not for free"
<magnon> I stay away from my parents
* Treenaks blames timezones
<zakame> haha
<jsgotangco> zakame, it's not really that bad as you think it is
<Treenaks> jsgotangco: what? timezones?
<jsgotangco> Treenaks, no the education i mean
<jsgotangco> sorry
<jsgotangco> Timezones are bad
<jsgotangco> really bad
<jsgotangco> it would have been nice if the world was flat
<zakame> jsgotangco: well, yeah, otoh the quality is very good
<zakame> at least for some schools
<magnon> hello Jane!
<Orborde> I was going to suggest that the default sshd settings not permit root login at all. Where would I file this suggestion?
<Orborde> Should I file a bug or what?
<_native_> Thats what i would guess.
<Orborde> Thanks
<sivang> morning all
<marilize> sivang: morning
<sivang> marilize: hey :) are you not sleeping ? 
<marilize> hi, no, slept whole day yesterday :)
<sivang> hmm
<sivang> W: GPG error: http://archive.ubuntu.com breezy Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<Mithrandir> is the bug importing script not running again?
<sivang> Mithrandir: importing bugs from bugzilla to malone?
<Mithrandir> yup
<sivang> Mithrandir: do you have any idea what happens to specs that do not appear on https://launchpad.net/distros/ubuntu/dapper/+specstable ? are they deffered from dapper?
<Mithrandir> sivang: they might not be attached to dapper, for some reason?
<sivang> Mithrandir: k
<koke> https://wiki.ubuntu.com/MenusRevisited/Comments?action=diff <-- is my last comment correct?
<highvoltage> I asked in #ubuntu, and got no reply, i hope it's not too intrusive asking here, on https://launchpad.net/distros/ubuntu/dapper/+specstable it mentions amd64, arm, hppa, i386 powerpc and sparc. does this mean that 6.04 will support all these architectures?
<highvoltage> or is it mentioned for upstream purposes?
<Mithrandir> elmo: please sync ttf2pt1 from unstable to dapper.  Ok to override Ubuntu changes.
<Mithrandir> highvoltage: dapper will exist for all of them.  Some of them will be more official than others, AIUI.
<highvoltage> cool :)
<sivang> dholbach: morning daniel
<dholbach> hi sivan
<dholbach> http://www.heise.de/newsticker/meldung/65966 - "Ubuntu for the data centre" :)
<sivang> dholbach:  :)
<Mithrandir> dholbach: you requested a sync for atk yesterday, didn't you?
<dholbach> Mithrandir: yes
<Mithrandir> dholbach: would you mind grabbing the merge bug for stuff you request syncs for?  Just as an advisory lock?
<dholbach> Mithrandir: oh, reassign it to me? that makes sense, will do next time
<Mithrandir> dholbach: yes, juts assigning it to you.  Anyway, if it's synced, please close the bug. :-)
<Mithrandir> 19120
<dholbach> merci
<Mithrandir> is upload.ubuntu.com down right ?
<Mithrandir> s/right/& now/
<Mithrandir> I get ECONNREFUSED
<dholbach> i had hiccups of it before... never knew what actually was wrong
<Nafallo> was just slow on my upload of apt-proxy a while ago
<seb128> why nobody mention the Ubuntu changes when merging?
<seb128> we drop any information on what we changed
<Mithrandir> I uploaded stuff ten minutes ago which worked fine, but it seems to refuse my connections now.  Maybe it thinks I'm DoS-ing it?
<Mithrandir> seb128: no, don't drop the changelog chunks.
<Mithrandir> Znarl: ^^ ?  upload.ubuntu.com broken?
<seb128> "* Resynchronise with Debian."
<seb128> adding a 
<seb128> - ... Build-Depends updated
<seb128> - this change
<seb128> is easy to do and make easy to know what we change for the package
<Lathiat> seb128: so what didnt keybuk like about the zc spec
<Mithrandir> seb128: compared to the previous Ubuntu version or compared to the last Debian version, you mean?
<seb128> Mithrandir: compared to the Debian version
<Mithrandir> seb128: that's already in the changelog for the Ubuntu versions.
<seb128> Mithrandir: so we know what the Ubuntu changes on the package are and why we can't ask a sync
<seb128> Mithrandir: changelog than we drop when we resynchronise
<Nafallo> I like pitti's changelogs in that regard :-)
<Nafallo> Only changes left:
<dholbach> Mithrandir: i agree with seb, it makes perfect sense, to list just what's left of changes to debian in a aggregated way
<Mithrandir> seb128: yes, and when we sync any changes are no longer important, hence sync.  If it's a merge, the changes from the Ubuntu version still holds.
<seb128> Mithrandir: I've to grep the distro-changes box to find the informations
<Mithrandir> *shrug*; either way works.
<slomo_> infinity, lamont-away: please give-back mono-tools... the ftbfs is seemed to be a temporary error as it builds fine here in pbuilder
<seb128> Mithrandir: hum. What we do, is: 
<seb128> - take the current Debian version
<seb128> - add a changelog entry saying we resynchronize with deb
<seb128> - apply the ubuntu changes
<seb128> so we drop the ubuntu changelog
<seb128> and we don't mention those ubuntu changes
<Mithrandir> that's not a merge, no.
<Mithrandir> what we do there is take the Ubuntu package, apply the debian changes to the Ubuntu package, ... profit.
* Nafallo agrees with Mithrandir we should actually merge the changelog when we merge
<Mithrandir> MOM merges the changelog, there's a reason for that.
<Mithrandir> if you do byhand merges, merge the changelog, yes.
<seb128> I do what I've described
<Mithrandir> you don't use MOM?
<Lathiat> isnt MOM b0rked anyway?
<seb128> I'm not the only one probably by looking at some of the pitti's changes
<seb128> Mithrandir: is mom running again?
<seb128> Mithrandir: I thought it was b0rked due to snapshot.debian.org issues
* Lathiat too
<Mithrandir> seb128: it has merged stuff which went into Debian three days ago, for instance.
<Mithrandir> seb128: for some packages, it's borked, for a lot, it's not.
<seb128> hum, k, so maybe I should use it :)
<Lathiat> might be good to make it indicate when ti can't find the comparison package
<Lathiat> and probably need to do some kind of manual lifting
<seb128_> re
<seb128_> Lathiat, Nafallo: was that one of you who had a screem package update ?
<Nafallo> seb128: yepp, me :-).
<viviersf> where can i get the source for the ubuntu installer ?
<slomo_> seb128: gnome-user-share is in NEW :)
<seb128_> Nafallo: is it based on the Debian 0.15.1 ?
<seb128_> slomo_: cool
<Nafallo> seb128: yepp. but fixed in various places where Tollef told me he wasn't happy :-).
<seb128_> cool
<seb128_> is your package online? Is Tollef going to upload it?
<viviersf> or whats collins nick ?
<sivang> viviersf: which colin?
<Nafallo> yes, and hopefully. http://www.magicalforest.se/~nafallo/packages :-)
<dholbach> viviersf: Colin Watson's nick is Kamion
<viviersf> thx
<sivang> ah, that one :)
<viviersf> sivang, i need ubuntu installer source and i know collin has it :)
<Nafallo> viviersf: it's in the archive :-). in millions of sources.
<seb128_> Nafallo: dholbach has just worked on the sync from Debian 0.15.1 but you should probably take your 0.16 if he's happy with that. Let we know if you need an uploader. If Mithrandir already commented on it he'll probably upload though
<Nafallo> seb128: oki thanx :-).
<seb128_> np
<Nafallo> dholbach: you saw the URL? :-)
<dholbach> Nafallo: url?
<dholbach> ah yes
<Nafallo> dholbach: if you wanted to check screem 0.16.0 out :-)
<viviersf> its weird
<viviersf> i just need the debian installer to see what modules it loads
<viviersf> :/
* sivang is rebooting to dapper
<viviersf> gl
<Diziet> seb128_: You reassigned malone 3203 to firefox but I'm not sure I follow.  Does epiphany use embeddable gecko from the firefox package ?
<Diziet> Because I thought the embeddable gecko in the firefox package was half-broken.
<tseng> i have several packages using it since warty, and I have yet to see a major gtkmozembed related issue
<tseng> fwiw
<seb128> Diziet: we build epiphany/galeon/yelp/... with firefox yep
<Diziet> tseng: OK.  I just remember a bug report or two about missing metadata of some kind.  (I should mention that I don't really know how the embeddable mozilla works.)
<Diziet> seb128: So can 3203 be reproduced with firefox ?
<Diziet> If no-one has tried then fine, I can try it myself.
<seb128> Diziet: I'm not sure. The bugs of gtkmozembed are not always present with firefox
<seb128> I've not tried with firefox no
<Diziet> OK.
<seb128> Diziet: epiphany's upstream has pointed than http://cvs.fedora.redhat.com/viewcvs/rpms/firefox/FC-4/firefox-1.0-uriloader.patch?rev=1.3&view=auto may fix the issue, I'm trying a build with it
<tseng> seb128: i can "confirm" it in firefox
<seb128> cool
<tseng> it opens a new tab and goes nowhere from there
<tseng> commenting
<zyga> hello
<seb128> Diziet: the FC4 patch pointed fixes the issue for me
<seb128> Diziet: I've commented on the bug saying so
<Diziet> seb128: Good, thanks.
<seb128> you're welcome
<Diziet> I'm working on the 1.5beta merge now; when I've done that this'll be on the list to revisit.
<Diziet> If we don't end up switching to Malone then you might have to remind me.
<viviersf> does any here know , the modules that gets loaded in the debian installer
<viviersf> where can i get a list of them
<viviersf> cos they are a set list
<viviersf> hardware scanning is done even before the debian installer is ran
<seb128> Diziet: noted
<dholbach> Nafallo: want to assign 10890 to yourself?
<Nafallo> dholbach: sure
<Nafallo> dholbach: if I could, that is :-P
<dholbach> Nafallo: ask ogra, kiko or mdz for "editbugs" rights :)
* Nafallo pings kiko ;-)
<dholbach> Nafallo: you should have them anyway to get into the bug squashers team ;)
<Nafallo> hehe :-)
<pitti> Dear mvo: please fix changelogs.u.c to unbreak ubuntu-cve. Love, pittii
<pitti> mvo: :)
<\sh> any ppc gurus there who have time to have a look on this http://people.ubuntu.com/~lamont/buildLogs/libv/libvisual/0.2.0-2ubuntu1/libvisual_0.2.0-2ubuntu1_20051104-1514-powerpc-failed.gz and tell me how I can fix it
<orborde-remote> How do I refile a bug as a duplicate in Bugzilla?
<dholbach> orborde-remote: what do you want to do?
<dholbach> elmo: please sync gnome-mag from sid, ok to override.
<orborde-remote> dholbach: bug 19437 is a duplicate of 18064
<dholbach> orborde-remote: it has a text box where you can enter that information. "mark it as a duplicate of"
<dholbach> orborde-remote: be sure to close the one with less information :)
<Mithrandir> elmo: please sync tagcoll from Debian unstable.  Ok to override Ubuntu changes.
<orborde-remote> dholbach: Thanks
<dholbach> orborde-remote: thank you for taking care of bugs
<Mithrandir> elmo: please sync tcpdump from Debian unstable.  Overriding Ubuntu changes is ok.
<orborde-remote> dholbach: I don't think I have the powers to move bugs around like that :(
<dholbach> orborde-remote: you seem to need editbugs rights for that... if you want to help out with bug triage and had a look at http://wiki.ubuntu.com/HelpingWithBugs mdz, kiko or ogra can give you those
<orborde-remote> Not to be too stupid, but how do I list the people in a channel on IRSSI?
<orborde-remote> Oh, never mind.
<orborde-remote> dholbach: Could you mark that duplicate for me?
<dholbach> will do
<orborde-remote> dholbach: I don't have the amazing powers and knowledge required to actually enact changes, so it'd be kind of pointless for me to, say, mark the bug as resolved or whatever
<Nafallo> dholbach: you left 4 mins ago ;-)
<dholbach> Nafallo: i know :)
<dholbach> orborde-remote: you seem to need editbugs rights for that... if you want to help out with bug triage and had a look at http://wiki.ubuntu.com/HelpingWithBugs mdz, kiko or ogra can give you those :)))
* Nafallo was about to paste tha ;-)
<desrt> hmm
<Nafallo> that
<dholbach> haha :)
<desrt> this is bad
<desrt> dholbach; i just got an email reply from richard hughes
<desrt> the gist of it:
<desrt> "you're basically asking me to completely rearchitect g-p-m (he's right) and i don't want to"
<Robot101> "will you accept a patch?"
<orborde-remote> dholbach: Thanks. I'll figure out getting editty powers later, seeing as I'm in class ATM :)
<dholbach> orborde-remote: right... thanks again
<dholbach> desrt: *cry desperately*
<desrt> Robot101; he's said that a lot of people have requested this change on the lists in the past and he's refused all of them
<Nafallo> what change?
<highvoltage> rewrite gpm, call it ugpm :)
<Robot101> fork :)
<desrt> "desperately"
<Robot101> upm :)
<desrt> you've spent too much time around kinnison :)
<orborde-remote> dholbach: You might notice that I posted a solution, too, FYI, if there's a status change that should be done
<dholbach> desrt: i can cry desperately on my own :)
<highvoltage> while you're at it, rewrite the whole way virtual terminals work too ;)
* orborde-remote = dev n00b ^ max
<desrt> we don't have time for a g-p-m fork in breezy timeframe :p
<desrt> if i wasn't currently an undergraduate student then we might
<Amaranth> dapper
<dholbach> desrt: and not even in the dapper timeframe
<desrt> but i am
<desrt> erp.  s/breezy/dapper/
<desrt> anyway... richard had a few questions in his reply... so i've answered them, explaining our position a little better
<sivang> desrt: maybe have just some of the changes for dapper?
<desrt> he seemed annoyed by pitti's security policy
* orborde-remote goes idle
<desrt> woh
<desrt> that's creepy
<desrt> i say "pitti" and he appears
<pitti> Hi mvo!
<pitti> summoning powers :)
<jsgotangco> he sees all
<pitti> MUHAHA
<desrt> pitti; i have a letter from richard.  he says "run hal as root, sissy"
<jsgotangco> he's your security genie in a bottle
<mvo> hey pitti 
<pitti> desrt: over my cold dead body
<desrt> heh :)
<desrt> that's the spirit!
* Nafallo agrees :-)
<pitti> mvo: did you find the reason for the changelogs.u.c. breakage?
<desrt> pitti; essentially, richard refuses to introduce our requested changes into g-p-m
<pitti> desrt: I didn't go through the "Killallroots, killallroots" hack rave to throw everything away again
<ajmitch_> morning
<mvo> pitti: no, not yet. but I have a look now
<pitti> Hi ajmitch_
<Nafallo> morning ajmitch_ :-)
<fabbione> mvo: dude.. thanks for the apt upload :)
<desrt> pitti; certainly.... a big part of why we want to make the changes is that we don't want to allow random users to perform system actions through HAL
<pitti> right
<mvo> fabbione: cheers :)
<desrt> so we're sort of on entirely different pages :(
<teroedni> http://www.directfb.org/<----anyone tried it It really look cool?
<desrt> he's advocating that we give root to hal so that it can do something that we explicitly -don't- want it to be able to do :)
<Nafallo> hehe
<pitti> that is the path to the dark side
<desrt> you're a bit hardcore, eh?
<siretart> no, he is just a sane thinking person
<siretart> huhu pitti :)
<pitti> "Dark the other side is"  - " Be quiet Yoda, and eat your toast!"
<pitti> Hi siretart 
<pitti> desrt: I just refuse to accept the fact that we should introduce a centralized point of failure/attack just because of laziness
<pitti> s/fact/proposal/
<desrt> pitti; you're preaching to the choir :)
<desrt> on the plus side, writing a architecture-agnostic power management daemon is something that ubuntu could really give back to the community
<desrt> on the other hand, i would -really- like to avoid stepping on richard's toes... he's been pretty kind to me in the past
<desrt> ho hum
<fabbione> hey desrt 
<fabbione> desrt: do you still want my address? 
<desrt> oh.  sure :)
<desrt> well
<desrt> hmm
<Nafallo> hehe
<desrt> it'd be better for you to remind me before the next conference
<desrt> it's the sort of thing that i really need to give to you in person
<desrt> i felt so stupid for not brining it to UBZ
<fabbione> desrt: hmm ok.. i just don't know where the next conf is going to be
<desrt> germany sounds likely
<desrt> "or capetown"
<fabbione> yeah but our fearless leader tends to change idea about locations :)
<fabbione> desrt: but sure. i will remind you :)
<Keybuk> #  The removal of all Bluetooth-related files from /proc (they are in /sys/class/bluetooth now).
<Keybuk> \p/
<chmj> o.O
<pitti> Hi chmj 
<chmj> hi pitti 
<pitti> Keybuk: good to see /proc *slowly* going back to its original purpose
<Keybuk> I wouldn't be surprised if within a year, we just have /proc/<pid> like all the other kernels
* desrt waits for the day where /proc contains only processes and they move it into /sys/processes/
<Keybuk> and maybe the /proc/sys sysctl mirror
<Keybuk> but nothing else
<Diziet> I'm not sure I see the point of reorganising it, personally, but I've not been following the kernel discussions about it.
* Diziet goes back to the bottom of the firefox pit.
<pitti> It has become a dumping ground for everything
* pitti throws some Subway cookies into that pit to relieve Diziet's pain a bit
<desrt> subway cookies!
<Nafallo> hehe
<Keybuk> Diziet: it's like tidying your room ... you never see the point of it until it's done and you think "ooh, carpet!"
<desrt> carpet is nice, if you can find it
<Robot101> there was some "/proc of crap" post to lkml ages ago :)
<desrt> Keybuk; i gave you my fingerprint, right?
<desrt> linux's abuse of /proc is a nice laughing point for *bsd
<desrt> with their clean pristine /procs
<jbailey> Keybuk: He's not sure.  Clearly it wasn't him.  Throw it away if you have it. ;)
* jbailey hides.
<Keybuk> desrt: yes, but you didn't give me a lap dance ;)
<desrt> this much is true
<desrt> daniel was handing out proxy lapdances on my behalf, though
<jbailey> desrt: Like Kinnison, Daniels, or dholbach? =)
<desrt> kinnison
<desrt> y'all are a very huggy crowd.  i like that.
<jdub> mpt: BrowserDefaults isn't specific enough
<Keybuk> hugging rocks
<wasabi> So does riding Elmo, or so I hear.
<desrt> http://www.ashotoforangejuice.com/gmrisk.html <- risk
<desrt> omg.
<desrt> elmo as in "the wild elmo"?
<jdub> elmo killed RideTheWildElmo on the wiki tho
<Amaranth> desrt: stop reading slashdot :P
<jdub> fascist
<Amaranth> yeah, i saw that
<desrt> Amaranth; i don't read slashdot
<jamesh> jdub: you could revert the vandalism
<desrt> Amaranth; but, seemingly, i have friends who do :)
<Amaranth> desrt: Good, only one of us is allowed to waste time reading it. :P
<jdub> jamesh: he locked it with an ACL
<desrt> jdub; how was TO?
<jdub> good
<jdub> lots of people to meet
<jamesh> jdub: https://wiki.ubuntu.com/RideTheWildElmo?action=recall&rev=1
<desrt> excellent.  i'm sorry i couldn't have been there.
<jdub> i just blogged about it
<jamesh> the wonders of revision history
* desrt relives it through your blog :)
<desrt> g'morn, james
<jdub> oh, he didn't lock it, i was just not logged in
* desrt hands jdub a subway cookie
* jdub fixes
<jsgotangco> hey jdub 
<jdub> okay, you can now sign up to it
<fabbione> jdub: hey dude
<fabbione> jdub: can you please give me the mailing list?
<jdub> yep
<fabbione> thanks
<mpt> jdub, not specific enough in general? or some points in particular?
<jdub> mpt: it's very handwavey about the start page
<mpt> hmmm'
<pitti> Keybuk: can I kindly point you to https://wiki.ubuntu.com/AutomatedProblemReports ? Maybe we can discuss this today? It's a bit hairy
<mpt> trulux, ping
<mpt> ajmitch_, ping
<ajmitch_> mpt: pong
<mpt> ajmitch_, https://wiki.ubuntu.com/SELinux is marked as "needs fattening up" in https://launchpad.net/distros/ubuntu/+spec/selinux
<ajmitch_> yes..
<mpt> Is that something you can fix in the next few hours?
<ajmitch_> not likely, I'm at a friend's place
<mpt> ok
* ajmitch_ won't have regular net access for another week
<Keybuk> pitti: yeah, I'm going to look at my spec pile in a little bit
<Keybuk> where I'm going to deliberately try and push "in a little bit" so it falls off the end of the conference, muahahaha <g>
<pitti> *grrr*
<mpt> pitti, ?
<mpt> oh
<mvo> pitti: changelog generation script is (hopefully) fixed, I'm re-runing it at the moment
<pitti> mvo: thank zou!
<pitti> mvo: you, even (still have problems with en_US keyboard)
<Treenaks> pitti: Thank Zou sounds movie-german ;)
* sivang .oO( wonders about specs that are not listed in https://launchpad.net/distros/ubuntu/dapper/+specstable...)
<mvo> pitti: cheers, the script is at "m" now (in main). once that is done, I'll do universe :)
<pitti> fabbione: http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=788e05a67c343fa22f2ae1d3ca264e7f15c25eaf
<dilinger> pitti: yikes
<fabbione> wowow
<Amaranth> wow, i so don't understand wtf that means
<Amaranth> oh, nm
<Keybuk> #
<Kinnison> Morning
<pitti> Hi Kinnison 
<fabbione> hey Kinni
<jamesh> there is a new test import of bugzilla.ubuntu.com bugs at https://staging.ubuntu.com now if anyone wants to test
<jamesh> (no resolved bugs for now)
<seb128> elmo: libgsf sync please
<pitti> Keybuk: are scripts in /etc/modules obsolete now?
<pitti> erm
<pitti> Keybuk: /etc/modutils even
<pitti> Keybuk: linux-wlan-ng defines an alias, but it appears to me that it is not used anyway
<seb128> jamesh: how (no resolved bugs for now)? Have you planned to import the closed ones too?
<jamesh> seb128: I'm looking at doing that, yeah.
<seb128> cool
<jamesh> seb128: it's mostly working, but I need to do something with the duplicates table.
<seb128> jamesh: playing with staging, seems to be alright
<Keybuk> pitti: yes, have been for a very long time
<Keybuk> modutils == 2.4
<speedboy> maybe, artwork developer for Dapper should look at this http://www.ubuntuforums.org/showthread.php?t=88477
<pitti> Keybuk: k, thanks
<dholbach> speedboy: i think we have #ubuntu-art or #ubuntu-artwork
<dholbach> speedboy: #ubuntu-artwork
<janimo> jamesh, can malone be told to also write to upstream? so we have a wrapper around external bugzillas, not read-only
<speedboy> dholbach: thx for the info ;)
<dholbach> speedboy: de rien
<pef> elmo: hello, are you here ? I've a problem with uploads to universe archive
<dilinger> seb128: does #19438 look like the sort of thing totem upstream (hadess still?) would be interested in?
<seb128> dilinger: I don't know but anybody would be interested that's upstream
<seb128> dilinger: I don't intend to fork from upstream for that, I'll just forward the bug
<jamesh> janimo: we currently have the ability to pull bug status/severity info from remote bugzillas (and you can tell Launchpad to link a particular task to the remote bug)
<jamesh> janimo: Launchpad won't write to remote bug trackers though
<dilinger> seb128: ok, that's fine
<janimo> hmmm would have been nice to use one account to talk to all bugzillas out  there :)
* dilinger would really like to be able to get rid of the internal totem packages his company has had since hoary
<seb128> why do you have internal packages for 6 months?
<dilinger> seb128: the original patch just hardcoded /tmp
<dilinger> the generic patch i whipped up last night
<dilinger> after getting annoyed at having to build totem again :)
<seb128> what is the issue with using home?
<seb128> nobody ever complained
<dilinger> we use OpenAFS
<dilinger> for our home directories, that is.  and openafs doesn't allow you to create sockets
<dilinger> so, totem just gives up
<dilinger> it refuses to start at all
<jamesh> https://staging.ubuntu.com/distros/ubuntu/+source/totem/+bug/17452 <- that's dlinger's bug
<dilinger> jamesh: how do i edit my email address in launchpad?
<jamesh> dilinger: go to your person page, click edit details in the menu on the right, then edit email addresses
<dilinger> i tried that
<dilinger> Sorry, you don't have permission to access this page.
<dilinger> You are logged in as Andres Salomon.
<Kamion> jbailey: are you going to be merging glibc, or is that somebody else's job now?
<jamesh> dilinger: there seems to be two "Andres Salomon" accounts on staging
<dilinger> jamesh: i assume because there are two email address; dilinger@voxel.net and dilinger@debian.org..
<dilinger> as i used dilinger@voxel when i created my bugzilla account and dilinger@debian when i created my launchpad account
<jamesh> dilinger: you'd need to merge the accounts (don't bother doing so on staging.ubuntu.com though -- just do it on launchpad.net)
<dilinger> jamesh: ok
<dilinger> i'll wait, then.  both addresses work for now anyways
<highvoltage> i can't change mine either. in #launchpad they said it might take effect when the cron job runs again.
<jamesh> dilinger: on launchpad.net, make sure your bugzilla email address is registered to your existing account and everything should work correctly when we do the real import.
<jamesh> (you can have multiple email addresses registered)
<dilinger> oh, ok
<Diziet> Bizarre.  Breezy's firefox 1.0.7 has a patch which makes a clone of the typeaheadfind module, called typeaheadfindsea.
<pitti> Diziet: 'sea' as in SeaMonkey?
<Diziet> No, I think `sea' as in `search'.
<Diziet> The code is identical.  Just the interface names, contract id, and the like are different.
<Diziet> The .diff.gz has a complete copy of the .cpp which implements it.
<Diziet> No trace of it in the changelog.  Oh well, I'll get rid of it.
<Diziet> This whole thing definitely has an air of the bazarre about it.
<lifeless> bazzar please
<pitti> bazaar?
<lifeless> YHBTHANDHTH
<mpt> like an internal conjoined twin
<dilinger> i'd like to buy a vowel?
<lifeless> :)
<Kamion> infinity: please clear installation-locale's dep-wait
<dilinger> mm.  no hoary->breezy upgrade love.
<infinity> Kamion : Done.
<Keybuk> http://people.ubuntu.com/~scott/packages/bootchart_0.8-0ubuntu1_all.deb
<infinity> Keybuk : \o/
<Kamion> infinity: ta
<slomo> infinity: please give-back mono-tools if that's the correct way to fix them ;) they build fine here in pbuilder and the old builderror seems to be temporary... but it's not in the archives and not on the dapper.all.i386 list
<\sh> hehe...what I have to read on jdubs post? he will visit RH HQ in raleigh? he should ask if spot is still working there..this guy we could need for support issues :) and some coding stuff  
<infinity> slomo : Done; no promises that it will build. :)
<slomo> infinity: do you know what the problem was? ;)
<infinity> slomo : No, didn't look at the log.  I will right now.
<slomo> infinity: it didn't find some packages which are definitly there
<infinity> slomo : Oh, that's an apt bug.  Yell at mvo.  That would have been retried eventually anyway.
<mvo> elmo: please sync grep from debian (override ok)
<mvo> apt bug?
<pitti> mvo: have you looked at the subject of #debian-devel?
<infinity> mvo : The "Oh no, the archive is wedged, I better delete all my lists!!" bug.
<mvo> infinity: dam, yes
<mvo> elmo: please don't sync grep!
<mvo> pitti: *arg* thanks
<pitti> mvo: from incoming should be fine
<infinity> Yeah, I smacked the Debian maintainer around a bit for that grep/pcre upload.
<infinity> Though, ironically, enabling pcre in grep does close one of my Ubuntu bugs.
<mvo> elmo: please sync grep from *incoming* (and sorry for the noise :/)
<infinity> Kamion : Do we still want busybox-cvs at all?
<infinity> Kamion : If so, the priority should be dropped, so debootstrap doesn't try to install both.  If not, we need to get rid of it.
<slomo> elmo: please sync gv, gtksourceview-sharp, gtksourceview-sharp2 from debian/unstable and avahi from debian/experimental... all ubuntu changes (if existing) can be dropped
<Kamion> infinity: busybox-cvs | 20040623-1ubuntu22 | dapper/universe | amd64, hppa, i386, ia64, powerpc, sparc
<\sh> Keybuk: do u have somewhere a video of your hct talk?
<Nafallo> if it was on debconf it should be on videos.debian.net or something like that, no? :-)
<rob^^^> Whee 3 cheers for 1 less page in UbuntuExpress!
<Surak> Hello folks
<Surak> Seb128: there?
<rob^^^> howdy SUrak
<infinity> Kamion : Sure, but both the source and busybox-cvs-initramfs are in main. :)
<anavim> how many devs here are working on the kernel?
<Keybuk> eenie, meanie, miney, mo ... in which header should struct msghdr go?
<anavim> is there room for one more?  :D
<janimo> anavim #ubuntu-kernel
<anavim> janimo, thx  :)
<Amaranth> seb128: For MenusRevisited setting NoDisplay=true will hide the item in the menus but keep the 'Open With...' mime stuff.
<slomo> infinity: please give-back banshee for ppc ;) that will be the last one for today :)
<seb128> Surak: pong
<Surak> Seb, can you help me with http://bugzilla.gnome.org/show_bug.cgi?id=316341
<Surak> ?
<Nafallo> Simira: please send me your signature :-)
<Simira> Nafallo: didn't I?
<Nafallo> Simira: nope :-)
<Simira> Nafallo: remind me tomorrow, will you?
<Nafallo> Simira: oki :-)
<Simira> I'm pretending to work right no
<Simira> now
<Nafallo> :-)
<seb128> Surak: hint: highlight is better to be read
<seb128> elmo, Kamion: could you promote libgsf-1-113 (soname change) so goffice/gnumeric can build?
<seb128> Surak: sure, do you want to build the debug package yourself?
<Surak> Anything is ok to me. I just want to help fixing this bug. Rather ugly to put a dvd on ubuntu and totem automatically lock ;-)
<Surak> I can build them. If they're already somewhere, it's fine too.
<seb128> Surak: there is no, but I should probably do one
<seb128> Surak: https://wiki.ubuntu.com/DebuggingProgramCrash to get one
<seb128> Surak: feel free to ask anything if there is an issue
<seb128> Surak: dapper has a 0.8.7 package, you may want to try it as well, maybe it fixes the issue
<Surak> Seb128: thanks, I'll let you work now and do my homewor with debug package.
<Surak> seb128: once the issue is discovered, is there any chance to fix it in breezy?
<Kamion> seb128: done
<seb128> Kamion: thanks
<seb128> Surak: if upstream have an idea on it/a patch, sure
<Surak> ok
<spstarr_work> did bugzilla meltdown? :(
<seb128> spstarr_work: works fine for me
<highvoltage> bugzilla works fine for me
<highvoltage> (referring to bugzilla.ubuntu.com)
<spstarr_work> my bug has 'vanished'
<highvoltage> bit slow though.
<seb128> spstarr_work: number?
<spstarr_work> looking for it
<Simira> Nafallo: I'm checking prices for making stickers and aliminium marks now. Shipping to Sweden will probably work out fine.
<Nafallo> Simira: yay! all I need is money then :-)
<Nafallo> Simira: should I take that as Mithrandir didn't take a sticker for me at ubz? :-P
<pitti> elmo: mozilla-locale-fr sync, please
<Simira> Nafallo: he did. But I meant for the Swedish community in general. I do ship t-shirts to whole Europe, you know.
<Surak> minghia: ping
<Surak> minghua: ping (sorry, typo)
<spstarr_work> cant find it...
<spstarr_work> hrm...
<spstarr_work> it was a qla driver bug issue
<highvoltage> spstarr_work: what was it about?
<highvoltage> ah
<spstarr_work> there was/is no final solution
<highvoltage> i can't find a message containing "qla" in the bugzilla e-mails either.
<spstarr_work> there was an email history for it
<Nafallo> Simira: ah, sure :-). just gimme an URL and I put it in topic so that the wiki-ppl can play with it :-).
<spstarr_work> http://lists.ubuntu.com/archives/ubuntu-bugs/2005-August/074328.html
<spstarr_work> NEEDINFO now
<seb128> elmo: menu-xdg sync from Debian please
<highvoltage> spstarr_work: i can see your bug fine at http://bugzilla.ubuntu.com/show_bug.cgi?id=8879
<spstarr_work> yeah its there but searching 'qla' didnt find it
<spstarr_work> oddly
<spstarr_work> ok, now thats thats solved, time to get a newer eric3 merged into Ubuntu :-)
<Simira> Nafallo: http://ubuntu.no/T-skjorte This is what we got for now
<spstarr_work> kubuntu/ubuntu :)
<Simira> Nafallo: Or https://wiki.ubuntu.com/t-shirt, if you're bad reading Norwegian ;)
<seb128> elmo: libbonobo libbonoboui sync please
<seb128> elmo: djvulibre sync too, thanks
<spstarr_work> should we drop eric3 from Dapper? since there is eric and eric == eric3?
<spstarr_work> eric3 is 3.4.1 and eric is 3.7.0 (I have it working with 3.8.0) 
<dholbach> good night
<Simira> g'night, dholbach
<Surak> dholbach: night
<spstarr_work> I should have a newer version of eric to add to ubuntu/kubuntu tonight for dapper unless the maintainer of the package is working on bumping to 3.8.0?
<minghua> Surak: yes?
* Kamion uploads the d-i merge. Let's see how much stuff breaks
<Nafallo> :-)
<Mithrandir> elmo: please sync ttf-indic-fonts, ttf-freefont, overriding ubuntu changes is ok.
<Mithrandir> Kamion: the Merge Of Doom? :-)
<Kamion> uh-huh
<Kamion> hideous
<Nafallo> sounds fun, when do we start making cds? ;-)
<Kamion> next week I hope
<Mithrandir> I pondered hacking on it earlier, but saw the whole lot was assigned to you, so I merged other stuff.
<Nafallo> baah, you've fixed all bugs till then probably :-P
<Mithrandir> is it just me or is bugzilla _extremely_ slow when making updates today?
* Nafallo knows he's talking to gods in here :-)
<Kamion> Mithrandir: oh I meant the debian-installer source package proper. 313910 lines of upstream diff
<Mithrandir> like, > 1 minute to comment on a bug.
<Mithrandir> Kamion: oh joy.
<Kamion> though most of that was removing the manual (I've yet to do *that* merge to installation-guide)
<Nafallo> removing the manual?
<Nafallo> why? :-)
<Kamion> moved to a different source package
<Nafallo> ah, oki :-)
<Nafallo> makes sense
<Mithrandir> we discovered nobody read manuals anyway, so no point in maintaining it.
<Kamion> 42885 lines not counting the manual removal
<Kamion> Mithrandir: thanks for doing iso-scan at least
<Nafallo> so I'm nobody now I am? ;-)
<Mithrandir> Kamion: it was up for grabs, so. :-)
<Nafallo> s:I am:,am I:
<Mithrandir> Nafallo: haha. ;-P
* Nafallo is just odd :-)
<Nafallo> who else downloads dvds from ftps via nautilus? :-P
<Kamion> Mithrandir: feel free to take choose-mirror, kbd-chooser, localechooser, elilo-installer at least
<Kamion> Mithrandir: choose-mirror should get simpler in dapper with 1.16 though, so I was thinking of waiting for that
<Kamion> localechooser is usually a fiddly merge due to the UTF-8 crap but should otherwise be straightforward-ish
<Mithrandir> Kamion: I'm off to bed soon, but I could look at them tomorrow.  If you could add any relevant comments to the bugs, that'd be useful for me.
<Mithrandir> elmo: please sync taglib, transfig from Unstable.  Overriding ubuntu changes ok.
<mjg59> Why did I just get an email telling me that https://launchpad.net/distros/ubuntu/+source/drscheme/+bug/4043 had had a state change?
<Mithrandir> mjg59: because you're a member of the ubuntu core development team, which is a member of the motu merge team, hence you're effectively one of the subscribers for that bug.
<mjg59> Nnnngh.
<mjg59> Is there any way of not getting motu merge mails?
<Mithrandir> make ubuntu core development team not member of motu merge team?
<Mithrandir> we're down to 270 merge bugs.  That's not too bad.  IIRC, it was over 300 this morning.
<mjg59> It would be nice to have fine-grained control over that sort of thing
<Keybuk> "not getting" ?
<slomo> BenC: what will you do with libraw1394? we currently have a really ancient version (0.10.1), newest is 1.2.0 which is already needed by some apps... can i update or will you kill me? ;)
<mjg59> Keybuk: I'm not really involved in doing motu merges, so receiving emails about it doesn't seem necessary
<Mithrandir> Keybuk: my apologies for any ACCEPT mails you may have received because of my failure to update debian/changelog files today.
<Keybuk> I didn't realise people were filing merge mails in launchpad
<Keybuk> I've specifically _not_ done that, because it also sends the mails to the Debian maintainers
<mjg59> Keybuk: See https://launchpad.net/distros/ubuntu/+source/drscheme/+bug/4043
<Mithrandir> elmo: please sync libdb3 from unstable, overriding Ubuntu changes is ok.
<Mithrandir> and then I'm off to bed.
<mdke> ouch, bad luck jdub 
<pitti> Mithrandir: can you please close the merge bug then?
<Nafallo> Mithrandir: gnight :-)
<pitti> Mithrandir: I just set it to pending
<Mithrandir> pitti: I'm reassigning them to me, close them when I see the sync.
<pitti> ok
<Kamion> Mithrandir: no particular hurry, certainly
<Mithrandir> pitti: but I agree "pending" is probably more correct.  PENDING doesn't have a nice "assign to me" checkbox, though.
<TheMuso> .c
<pitti> Mithrandir: you can still reassign to you
<Mithrandir> pitti: in two operations, yes.  I'm a lazy bastard. :-)
<sistpoty> Keybuk: why does filing merge bugs in malone spam dds? can this be avoided somehow?
<siretart> Keybuk: why does filing bugs in malone spam debian developers?
<Keybuk> because debian developers are registered against Ubuntu packages through the Maintainer field
<\sh> argl
<sistpoty> that's bad :(
<siretart> Keybuk: since when is that? 
<siretart> Keybuk: can't this be turned off?
<\sh> there must be a difference on the product...cause the bugs are filed against affects /distros/ubuntu/gv and not other products
<\sh> but indeed...this is a serious problem
<Surak> seb128: ping
<siretart> we need to organise some merge bugs. shall we setup our own rt for that?!
<seb128> Surak: pong
<Surak> seb128: /tmp/ccH6BmIh.s: Assembler messages:
<Surak> seb128: /tmp/ccH6BmIh.s:1996: Error: suffix or operands invalid for `pshufw'
<Surak> seb128: make[9] : ** [libmmxsse_la-fdct_mmx.lo]  Erro 1
<Surak> seb128: this is for gstreamer0.8-ffmpeg
<seb128> urg
<Keybuk> siretart: always
<sistpoty> siretart: maybe s.o. in launchpad knows a workaround... I'm asking
<slomo> Surak: that's maybe my fault... what are you doing?
<tseng_> that is pretty broken behaviour.. if i build gtk# against a different version of gtkhtml that cause a bug not in Debian
<pitti> WOO! number of merge bugs just dropped below 300
<tseng_> why should they get an email
<seb128> Surak: I'll build a debug package tomorrow
<\sh> Keybuk: that means, that anyone who is filing bugs against a package in ubuntu, will bug the debian maintainer as well, which is terrible wrong im my eyes
<TerminX> anyone have any idea why upgrading mplayer (from multiverse) screws the permissions on a bunch of stuff in /dev every time?
<Surak> slomo: building debug packages for gstreamer and gstramer-ffmpeg
<Surak> to help fixing issues with dvds in breezy.
<slomo> Surak: can you try something for me? remove the -DRUNTIME_CPUDETECT for configure in debian/rules and try to build the debug package then
<Surak> ok
<slomo> Surak: remove the whole lines around that... the complete ifeq, else, endif block
<Keybuk> \sh: not to mention bug the technical board ... cf. mjg59's irateness
<Surak> ok
<slomo> TerminX: please file a bug in malone and assign it to me (slomo)... i'll work on that then
<\sh> Keybuk: I have this strange feeling that this is not easily to change? or was it purpose?
<Keybuk> \sh: no eye deer
* \sh opens a bottle of beer...and think about another solution
<Surak> slomo: there's nothing on debian/rules about it. The only occurrences of RUNTIME_CPUDETECT are at gst-libs/ext/ffmpeg/libavcodec/libpostproc/postprocess.c
<Surak> slomo: removing them does not make the error disappear.
<slomo> Surak: what version?
<slomo> Surak: of gst-ffmpeg? breezy or dapper one?
<Surak> gst-ffmpeg-0.8.6
<Surak> breezy
<jdub> GOOD MORNING FREEDOM LOVERS!
<slomo> ok, simply ignore me... sorry
<slomo> i was talking about dapper
<Simira> morning jdub
<slomo> hi jdub :) be happy, there's a working gnome-user-share now in dapper ;)
<Surak> hello jdub
<Nafallo> jdub: ! :-)
<Surak> slomo: the problematic line is  cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libavcodec -DHAVE_AV_CONFIG_H=1 -fomit-frame-pointer -Wall -Wno-switch -msse -g -Wall -O0 -MT libmmxsse_la-fdct_mmx.lo -MD -MP -MF .deps/libmmxsse_la-fdct_mmx.Tpo -c fdct_mmx.c  -fPIC -DPIC -o .libs/libmmxsse_la-fdct_mmx.o
<Surak> seb128: it's ok, I can bother you tomorrow then about those packages. Anyway, am I correct in supposing that this should not happen?
<seb128> it should work
<seb128> hey hey jdub
<crimsun> jdub: ready for pizza?
<Surak> seb128: there's not much things I could do wrong til here. Two or three lines :-)
<slomo> seb128: maybe it isn't compiled with mmx, sse, whatever support on the buildds but on this guys machine? what gets compiled in is detected while configure with the breezy package
<seb128> maybe 
<Surak> slomo: but on my machine? how?
<slomo> Surak: what kind machine do you have?
<Surak> plain p4
<slomo> Surak: so mmx, sse, see2... what is in the x86 buildds?
<Surak> slomo: how can I verify that?
<slomo> Surak: no idea...
<slomo> infinity: what cpu is in the x86 buildds?
<Nafallo> cat /proc/cpuinfo | grep flags
<Surak> slomo: flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
<slomo> Surak: ok, fine... now we need infos for the buildds :P
<Amaranth> i think infinity or elmo would be the ones to talk to for that, if you really need it
<slomo> Amaranth: yes, i already pinged infinity... but he seems to be away :/
<jdub> crimsun: got my red hat shirt on :)
<Surak> slomo: time to go home. May I ask your help on this tomorrow?
<Kamion> hmm, I guess seb128's done for the day
<slomo> Surak: sure
<Surak> thanks. good night
<mdz> jdub: http://people.ubuntu.com/~mdz/low-power.png
<Keybuk> mdz: heh, my laptop currently thinks it's fully charged at 0%
<neuralis> Keybuk, did it just change to 0% suddenly?
<jdub> mdz: rad
<Keybuk> neuralis: well, after a boot
<neuralis> Keybuk, ah. i had the machine think it has 0% battery left all of the sudden both on your laptop model, and on the nc4200.
<Keybuk> syndicate scott% cat /proc/acpi/battery/C13A/state
<Keybuk> present:                 yes
<Keybuk> capacity state:          ok
<Keybuk> charging state:          charged
<Keybuk> present rate:            0 mA
<Keybuk> remaining capacity:      2856 mAh
<Keybuk> present voltage:         12492 mV
<Keybuk> -- 
<Keybuk> is hal bug :)
<mjg59> Keybuk: Try running that 10 times or so
<Nafallo> Keybuk: just so I don't forget. loved your HCT-talk on debconf :-). made me both laugh a lot and actually understand why all of those branches \sh wants makes sense :-).
<\sh> Nafallo: I never said it was my idea...it was siretart 
<Nafallo> \sh: baah. he didn't have _nothing_ to do with gajim ;-)
<\sh> Nafallo: but he tought me the new way of working...
<Nafallo> hmm oki
<Kamion> SO CLOSE to installable ubuntu-{desktop,live}
<Nafallo> anyway. now I understand why. and that's Keybuks... ehm, fault ;-)
<Kamion> I think we'll get it in a couple of cron.daily cycles
<Nafallo> so next week is in a couple of hours then :-)
<Nafallo> nice
<Keybuk> mjg59: no change
<Keybuk> watch -n 0.1 ... doesn't show any change
<mjg59> Keybuk: Ok
<Keybuk> sivang: could you _please_ fix your mailer's reply-to functionality
<Kamion> Nafallo: well, we're all about to travel home from UBZ and I won't be working again until Monday, so maybe not
<Kamion> but we'll see
<Nafallo> ah, still there :-)
<slomo> elmo: please sync seahorse from debian
<Nafallo> gnight dudes :-)
<Kinnison> night Nafallo 
<sivang> Keybuk: oh, sorry. what does it do?
<Keybuk> sivang: you keep trying to send mails to ubuntu-devel-announce
<sivang> Keybuk: hmm, weird. I never tried to send an email there, I just subscribed to receive
<jbailey> sivang: Make sure your client honours the reply-to. =)
<sivang> jbailey: how do I make sure of that?
<Keybuk> read the headers before you hit Send
<sivang> Keybuk: ah ok, probably there was something sent to -anounce and I replied to it, sorry
<mvo> elmo: please sync libgksuui1.0 from debian/unstable (override ok)
<slomo> elmo: please sync cowbell from debian/unstable... ubuntu changes can be dropped as always ;)
<Keybuk> \o/  I have all of udev compiling against klibc now
<mvo> elmo: please merge memprof from debian/unstable (override ok)
#ubuntu-devel 2005-11-16
<TerminX> slomo: I can't seem to post a bug to malone regarding my mplayer issues, but I've tracked the problem down to the MAKEDEV v4l in the postinst script
<slomo> TerminX: why can't you post a malone bug?
<TerminX> it gives me a 404
<slomo> TerminX: https://launchpad.net/malone/bugs/+package  <--- get here, enter ubuntu as distribution, mplayer as pacakge name and fill in the other stuff... give me the bug number afterwards ;)
<TerminX> anyways, the MAKEDEV v4l is wiping out all of my audio related device nodes and replacing them with ones owned by root with group root with permissions 700
<TerminX> wait, not even 700
<TerminX> 600 ;)
<Kamion> slomo: (https://launchpad.net/distros/ubuntu/+filebug)
<slomo> TerminX: well, if you can file a bug assign it to me or give me the bug number... i'll write it on my todo list now anyway ;)
<TerminX> alright
<robertj> has there been any discussion about using a user list with gdm?
<TerminX> slomo: I searched for people to assign it to and it came up with "ewald_dieser@web.de" for "slomo"; is that correct?
<TerminX> slomo: bug 4166
<TerminX> slomo: however, it's not actually a bug in Ubuntu, it was something on my system, so you might as well just close it ;)
<TerminX> just figured it out, heh
<mvo> elmo: please sync file (override ok)
<kornito> Seveas: you gotta unban me in ubuntu
<kornito> i didn't do anything
<Seveas> kornito, do not take such issues to #ubuntu-devel
<Seveas> #ubuntu-offtopic is more appropriate
<\sh> bingo
<\sh> now i need mvo to teach me how to create nice gtk UIs ,)
<mvo> \sh: hello
<mvo> \sh: glade is a lovely tool :)
<\sh> mvo: ok...then I need some python-glade love :)
<\sh> naja...das lern ich noch schnell morgen :)
<\sh> oops
<sistpoty> hehe
<\sh> mvo: ok..i learn it as fast as possible tomorrow
<mvo> hehe :) that's the spirit!
<sistpoty> i could only serve you with an gtk-example for python, written directly ;)
<mvo> \sh: let's get into it tomorrow, I will go to bed very soon 
<\sh> and I hope end of next week we have a nice reportbugs replacement with or without UI for LP
<mvo> \sh: use "SimpleGladeApp" as the basis and it will be all fine
<mvo> \sh: *yum* reportbug ... auto-transmiting information like the version of the package that the bug is filed against? that would so rock
<siretart> sistpoty: \sh: awesome work for today. lets see: http://revu.tauware.de/~sistpoty/MoM/index.py?state=new and http://tiber.tauware.de/~shermann/motu-tools/lpbugs.py in just few hours of work!
<\sh> siretart: thx to u .. u were the inspiration
<siretart> mvo: check the that links
<siretart> mvo: thats not about general bug filing, just to help us to get an overview about what to do about universe merges
<\sh> mvo: which is quite easy to achive..sourcepacke version is not a hard thing to integrate...but the hard thing is to magic regexp search throughout the html source of LP 
<siretart> mvo: currently malone requires a gpg signature for filing bugs :(
<sistpoty> siretart: thx :)
<\sh> "I have many  signatures of my fellow citizens, but the xmlrpc interface is missing" (slighty changed quote out of Fahrenheit 9/11) 
<mvo> siretart, \sh there has been some talk about a xml-rpm interface, do you know more about it?
<mvo> *autsch*
* mvo should go to bed
<mvo> "xml-rpc" :)
<\sh> xml-rpm ?
<\sh> hihi
<siretart> mvo: there are xml-rpc interfaces to launchpad, but they are not accessible to the public right now afaik
<mvo> oh, ok
<siretart> mvo: I think the launchpad guys are quite busy with soyuz right now, so I'd say lets wait for after Feature Freeze and think then about a general and nice to have bugreporting tool
<mvo> siretart: *nod* 
<siretart> ok. /me needs sleep. urgently. 
<siretart> good night, see you tomorrow!
<\sh> i'm testing the close function now
<\sh> and it looks like that this works too
<minghua> the MoM status page is awesome
<sistpoty> thx minghua
<\sh> minghua: it is sistpoty did a good job
<sistpoty> fortunately i had to hack only pretty few things, as this is basically much of revu2-infrastructure that i misused ;)
<\sh> shit..closing does not work...i don't actually know if its now my fault or the fault of lp
<minghua> sistpoty: good job indeed, it motivates me to do more merge work :-)
<psusi> I'm trying to compile a package from source and the configure script says the c compiler can't create executables... well it can... how can I trace how the configure script is invoking the compiler?
<psusi> I tried strace -eexecve and -e vfork... no calls
<sistpoty> hehe, thx minghua... actually my only idea was that i thought that only the scotts logs might lead to confusion
<\sh> grmpf
<\sh> my fault
<\sh> i used the non signed mail text
<\sh> fixed
* spstarr_home loads eric :)
<sistpoty> minghua: just because I saw that right now... please use s.th. with "merge new debian version" as bug title for your next merges... that way the merge-tracker will know it's a merge-bug and update the status
<\sh> sistpoty: motu hopefuls will use from tomorrow on (somehow) the lpbugs.py :) which is easier to handle :)
<\sh> sistpoty: we have to push this nifty tool to the universe
<sistpoty> sure thing... I just try to avoid having to manually update status of 30-40 merges in the db when i wake up ;)
<\sh> sistpoty: ;)
<spstarr_home> uh oh, one of the ubuntu mirrors has a bad GPG key
<spstarr_home>  http://ca.archive.ubuntu.com
<spstarr_home> \sh: to build eric with whats listed in MoM, dependency for python-qtext -> python2.4-qtext
<\sh> spstarr_home: as I said, please wait until debian upstream is ready. we will sync asap.  
<spstarr_home> im waiting, i was just trying out whats currently in queue :)
<\sh> spstarr_home: if eric is not building because of some dependencies, we will work on it. python-qtext should default to python2.4-qtext
<spstarr_home> yeah i fixed that in the patch
<spstarr_home> the last thing i need to fix is the default site-packages location (it put it in python2.3)
<spstarr_home> then it runs 
<spstarr_home> so while i wait for the official build, im good to go
<spstarr_home> eric3conifg.debian 2.3 -> 2.4 
<spstarr_home> oh even easier then I thought
<\sh> spstarr_home: ?? which eric package are u using?
<spstarr_home> http://people.ubuntu.com/~scott/ongoing-merge/eric/
<\sh> spstarr_home: ah now
<\sh> aeh no
<\sh> don't use it
<\sh> it
<\sh> it'
<\sh> damn...it's broken
<spstarr_home> a little
<\sh> a little too much
<spstarr_home> aside from fixing rules and the location of eric3config stuff ? there's other bits broken?
<neuralis> mdz: ping
<neuralis> nevermind, he's not here.
<spstarr_home> fixed that, it now installs to python2.4
<spstarr_home> oh
<spstarr_home> eric3 now needs lua
<\sh> elmo: please remove eric3 from the repositories. eric3 is not used anymore...please please let it disappear magically (no morgue needed) thank you so much :)
<\sh> elmo: eric is replacing eric3 (fyi)
<spstarr_home> :)
<spstarr_home> hmm,  my QScintilla is too old
<spstarr_home> hrm
<\sh> spstarr_home: a new qscintilla is already in dapper...as the whole python-qt/kde toolchain
<spstarr_home> odd, something broke with this build
<spstarr_home> AttributeError: luaGroupBox
<spstarr_home> trying to figure out which python module has this
<spstarr_home> oh
<spstarr_home> i think I know why
<spstarr_home> 'ericWizardsDir'      : r'/usr/lib/python2.4/site-packages/eric/Wizards',
<spstarr_home>  <- wrong
<spstarr_home> it got moved to /usr/share/eric/modules/Wizards
<spstarr_home> hmm, some of the new patch code breaks.. now i see ;)
<spstarr_home> oh we dont have python2.4-sip4-kde3?
<tkup> What is the process like of submitting code/programs for inclusion in ubuntu?
<LaserJock> for universe packages you can add it to wiki.ubuntu.com/UniverseCandidates
<tkup> Thanks for the link. I just snuck a peek at it. Do you all would rather not deal with small packages (read < 200 lines of code) or should I just put on a flame-resistant suit and dive in?
<LaserJock> hmmm, you might ask over at #ubuntu-motu, it probably depends on the usefulness, etc.
* ..[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 | First Dapper CDs: http://cdimage.ubuntu.com/daily/current/ http://cdimage.ubuntu.com/daily-live/current/
<Kamion> I have ABSOLUTELY NO IDEA whether these will boot, install, work, or eat your system
<Kamion> use at your own risk, but testing would be nice - I won't be able to test these until Monday
<LaserJock> Kamion: is the live cd any safer than the install cd? Seems like it should be
<Kamion> LaserJock: I have no information on either. In reality I think neither is particularly likely to actually eat your system, but I have to say that kind of thing just in case.
<Kamion> If the install CD doesn't install successfully then you can always use the rescue mode it offers.
<LaserJock> I am downloading the live cd as we speak ;-)
<LaserJock> I haven't tried a Ubuntu live-cd yet and I am running my Windows laptop this weekedn
<Kamion> if I had to bet on one working properly at the moment, I'd bet on the install CD; so don't judge Ubuntu by this one if the live CD fails :)
<Kamion> if you just want something that works, use the released 5.10 live CD
<LaserJock> yeah maybe, I
<LaserJock> am in a testing mood though
<Kamion> ok, cool
<Kamion> you get to be the first one to test a dapper image, then ;)
<LaserJock> working on the universe merge makes me want to try stuff
<infinity> Kamion : Found the purge bug.  Shouldn't happen again.
<infinity> (famous last words)
<neuralis> infinity, have a second?
<Burgundavia> neuralis, think you could extend that server testing framework to laptops?
<neuralis> Burgundavia, the catalog? sure, easily.
<Burgundavia> neuralis, then we could do away with the wiki page cludge
<Burgundavia> and get a lot more people on with better testing
<neuralis> Burgundavia, i'm all for it. in fact, there's probably no reason for us not to extend our official certification program to laptops, as well.
<Burgundavia> can you do completely automated testing of laptops?
<Burgundavia> or do we need a gtk app to say "now press the fn+f1 key"
<neuralis> certainly not completely automated, but we can automate what we can, and provide clear instructions on how to test the rest.
<Burgundavia> excellent
<Burgundavia> neuralis, can you coordinate with mjg59 over what exactly he needs from the laptop testing stuff
<Burgundavia> ?
<neuralis> Burgundavia, yes, but that's on the backburner for the time being. servers first, and i won't even implement that until february.
<Burgundavia> matthew might even be interested in writing it himself
<Burgundavia> no fears, laptop testing is a long term thing anyway
<neuralis> oh, you're talking about the actual testing app. yeah, i can talk to him about it, sure.
<Burgundavia> neuralis, cheers
<neuralis> i'll support different hardware classes in the catalog when i write it, so we can do things like 'laptops', 'servers', 'pdas' (for embedded ubuntu), and so on.
<neuralis> i'll fire off an e-mail to malcolm and see how he feels about laptop certification.
<hunger> My Thinkpad runs great since breezy. Hoary was a catastrophy, but breezy is *NICE*
<hunger> Thanks for all the laptop work you guys already did.
<neuralis> Burgundavia, you worked on the menusrevisited, right?
<Burgundavia> hunger, you are not the only one who saw a major improvement from hoary to breezy
<Burgundavia> neuralis, that I did
<Burgundavia> i wrote most of it
<hunger> Burgundavia: It basically went from "unusable" to "rocks":-)
<hunger> Burgundavia: Thanks!
<neuralis> Burgundavia, i saw a great proposal regarding gnome menus somewhere that i wanted you to look at, let me see if i can dig it up
<Burgundavia> hunger, my job was purely secretarial
<Burgundavia> neuralis, fire away
* hunger hopes his HDD crash sensor will work in dapper.
<hunger> Let's see whether the kernel devs will get the necessary support into the kernel in time.
<neuralis> Burgundavia, i can't seem to find it now. although, i did wonder: what happened to the actions menu in gnome?
<Burgundavia> neuralis, it was replaced by places and system
<Burgundavia> because it contained bits of both
<Burgundavia> I saw the proposal for resurrecting it as a true actions menu
<Burgundavia> I liked the idea
<neuralis> i think that might've been what i was looking at
<infinity> Kamion : Dude, ubuntu-desktop became uninstallable like an hour after we built the livecds... TIMING. :)
<neuralis> infinity: can you glance over the rewritten TestingServerHardware spec?
<Burgundavia> neuralis, that was on desktop-devel
<zakame> hi all
<neuralis> Burgundavia, the thing an actions menu is good for is not pieces of 'places' and 'system', but from pulling in the very, very bare minimum from 'applications'.
<Burgundavia> a
<Burgundavia> ya
<neuralis> Burgundavia, 'write an e-mail', 'surf the web', 'chat with friends', 'edit photos', 'play music', spacer, 'write a document', 'create a presentation', 'create a spreadsheet'.
<neuralis> with that there, i'd be a whole lot less concerned about clutter in the remainder of the menus turning off new users (even though it's great that it's being addressed.)
<Burgundavia> neuralis, that is probably dapper+1 at least
<tseng> i would say that 4 menus is too many
<Burgundavia> tseng, I happen to agree with that
<tseng> besides what is the actions bar for vs what is the applications bar for
<Mithrandir> my top bar is getting really crowded and there's no way I'd have room for an "actions" menu.
<tseng> and yes, *I* can understand your distinction
<Burgundavia> the thing that would be most logical to remove if we added actions would be applications
<Burgundavia> and that is gnome 3 (ie, currently most crack) territory
<tseng> its still two places to launch an app
<tseng> if you coddle people too much, there will come a time they want to do something more
<tseng> and be baffled
<neuralis> tseng, i agree that 4 menus is too much, and i wouldn't want (or use) an actions menu. but it seems it's much friendlier to a new user than having to search for an application through the app categories.
<tseng> neuralis: it might seem that way in the simplist of cases
<Burgundavia> there are a huge number of corner cases that need to be worked out on such a major shift like that
* hunger thinks that having several ways to access one app is more confusiong than having a biggish menu.
<tseng> i wouldnt call them corners at all
<neuralis> what if the applications menu only had those choices i listed above, and then a "Show all programs >" entry on the bottom, which expands into the application menu that we have today?
<Burgundavia> ick
<hunger> Users are (usually) not stupid.
<Burgundavia> if we are going to switch to that sort of menu, we need to do it cold turket
<Burgundavia> turkey, even
<Mithrandir> neuralis: it would be horrible and I would really, really like to have an option to turn it off.
<Mithrandir> or, I
<Mithrandir> or, I'd probably would just remove the whole menu.
<Mithrandir> and use deskbar-applet instead.
<tseng> Mithrandir: openbox++
<Mithrandir> tseng: I already use openbox, but that doesn't have a panel thingy.
<Burgundavia> I can a menu of the places menu, the actions menu and the deskbar applet
<tseng> it has a menu
<tseng> and i know you do :)
<Burgundavia> I can see
<neuralis> Burgundavia, in any case, i'm not happy with these ideas either, but it also seems like there's a better way to do it than we do now.
<Mithrandir> tseng: yes, but nautilus grabs the root menu
<Mithrandir> and I like having somewhere to stuff my applets.
<neuralis> Burgundavia, maybe just killing clutter in the menus will be sufficient.
<tseng> Mithrandir: i remap it to middle click.
<marilize> hi everybody
<zakame> hi marilize
<Burgundavia> neuralis, it is a good start
<Burgundavia> salut marilize 
<Mithrandir> tseng: Alt-F3 gives me deskbar and I can usually just whack in what I want and press enter and it's the right thing.  Hitting keys is easier than hitting stuff on a menu.
<Burgundavia> marilize, is it possible to get 100 or 200 cds shipped without their covers?
<hunger> neuralis: There already is a "debian" menu for "all stuff". Why not keep the normal menus cleaner?
<Burgundavia> hunger, debian menu is a legacy hack
<neuralis> hunger, ugh. that menu needs to die.
<viviersf> right, why would it get a : "/dev/initctl not found " error ?
<hunger> Hiding the admin stuff for non-admins is a good step, doing anything more is overkill IMHO.
<Burgundavia> hunger, then comment with specific reasons why in th appropriate place
* neuralis has to run out and get groceries
<Burgundavia> hunger,  I did blog about it
<neuralis> Burgundavia, i'll mail mjg re: laptop testing later today, and cc you
<Burgundavia> neuralis, can you email the laptop-testing list?
<neuralis> instead of, or in addition to, mjg directly?
<Burgundavia> neuralis, instead of
<hunger> Burgundavia: What is the proper place?
<Burgundavia> he and I and a lot of others are on the list
<neuralis> Burgundavia, will do.
* Burgundavia knew that question was coming
<Burgundavia> https://wiki.ubuntu.com/MenusRevisited/Comments
<neuralis> Burgundavia, i'll probably wait until i hear from mdz regarding the server spec, though.
<Burgundavia> neuralis, np
<marilize> Burgandavia: wow, never asked that  before, I'll have to find out....
<marilize> why dont you want covers?
<Burgundavia> marilize, the reason I am asking is for a future project of mine
<neuralis> marilize, what's the current count on breezy cds shipped?
<Burgundavia> marilize, malcolm and I are talking about Ubuntu in library catalogues. The plan as I envision it would be for loco teams to buy dvd cases, print localized inserts and covers and distribute them to local libraries
<marilize> Burgundavia: will find out for you.....
<Burgundavia> marilize, cheers
<marilize> neuralis: not sure, Silbs would have to correct count
<hunger> Burgundavia: I'll try to remember to comment on that as soon as I can access the page:-)
<Burgundavia> hunger, welcome to our wiki
<neuralis> *muttermutter*mediawiki*mutter*. :)
<hunger> Burgundavia: Not the wiki's fault. I do not have net access from here:-)
<hunger> At least not to https sites.
<Burgundavia> neuralis, don't I wish
<Burgundavia> hunger, if you email me your comments, I will but them their
<Burgundavia> s/their/there
* Burgundavia is ashamed that he is a native English speaker/writer
<magnon> better than french 
<Burgundavia> well, with mistakes like the ones I have been making tongith
<hunger> Burgundavia: Well, I will have email access once I have web access, too:-)
<Burgundavia> hunger, ah
<hunger> Burgundavia: Have you read "The humane interface" form Raskin (the Mac guy)? It is a really cool book.
<highvoltage> Burgundavia: why?
<highvoltage> nevermind... /me should read properly :)
<highvoltage> some people compare english to windows. it's easy to learn, and just as easy to mess up.
* hunger never had trouble with windows since about the 95 Version.
<hunger> That I switch to linux at that time might have something to do with that.
* highvoltage never had trouble with windows since the xp version. by a huge co-incidence, this was also the time i stopped using windows.
<highvoltage> hunger: :)
<sivang> morning all
<janimo> fabbione, ping
<janimo> just read you mail re. xubuntu, I must migrate from that old mail address
<dholbach> hellas
<janimo> hey daniel
<dholbach> hey jani
<dholbach> how are you?
<janimo> dholbach, fine thanks
<janimo> trying to get organized :)
<janimo> it seems unphysiological
<janimo> and how's DJ-ing ;) ?
<dholbach> janimo: excellent, but i still need a table that's higher than usual ones
<dholbach> janimo: apart from that, i'm quite happy ;)
<janimo> or high heels ;)
<janimo> and a wig
<janimo> or is that another branch of entertainment ;) ?
<dholbach> erm
<dholbach> no, you're wrong ;)
<janimo> are you using headphones or is murphy enjoying it too?
<dholbach> both, i use headphones and murphy enjoys over the speakers :)
<Burgundavia> whiprush_, for planet news http://www.tomshardware.com/howto/20051110/index.html
<Mithrandir> chmj: please close the merge bugs when you are done with them
<seb128> elmo: menu-xdg libbonobo libbonoboui djvulibre syncs please
<chmj> Mithrandir: sure, gonna do that just now 
<Mithrandir> dholbach: you want dasher, as it's gnome-team now, or should I?
<dholbach> Mithrandir: i can do that
<Mithrandir> dholbach: coolie
* Mithrandir looks at boost and thinks "you know it's bad when the ubuntu patch is almost four times the size of the .orig.tar.gz"
<Nafallo> lol
* chmj laffs 
<highvoltage> Mithrandir: is there an ubuntu package for dosage?
<Mithrandir> highvoltage: no idea, why?
<highvoltage> Mithrandir: seems that there's a debian package, but not for ubuntu. i'd like to take it for -motu, if no one else is working on a package
<dholbach> elmo: can you please sync dasher from sid? ok to override
<seb128> lamont-away, infinity: please push a rebuild for goffice it broke due to a libgsf soname changes and binary not promoted yet
<chmj> elmo: ping - imlib2 sync please, ubuntu override ok 
<\sh> elmo: please sync arpack++ from debian unstable, ubuntu override ok
<\sh> elmo: please sync aview from debian unstable, ubuntu override ok
<infinity> neuralis : It looks okay to me, but ultimately, you want mdz's feedback, not mine (especially since I thought the previous messy/ugly spec was okay...)
<neuralis> infinity, yeah, i requested feedback from him through launchpad
<neuralis> just wanted a sanity check
<infinity> neuralis : I really appreciate all the work you and HCS are willing to put into this, BTW.
<highvoltage> g/win 11
<neuralis> infinity, my pleasure. i want us to be an unmatched server distribution.
<neuralis> with server-candy, certification and clustering, i think we're getting there.
<infinity> I don't think that's an unreasonable goal.
<infinity> We're pretty much there already, IMO, it's all about the polish required to make sure others agree.
<infinity> (And widespread testing to find the really embarassing bugs before release...)
<Diziet> gdk--  #  case GDK_COPY: xvalues.function = GXcopy; break;   etc. etc. etc.
<infinity> neuralis : Do you have the facilities/expertise to do MySQL stress testing?  I need to make a hard decision on 4.1 versus 5.0 within weeks.
<neuralis> infinity, i'm away from cambridge for the next two months, which makes it more difficult.
<infinity> neuralis : Right, I'll set it up in my living room, then. :)
<neuralis> infinity, how do you plan to do it? i do have some very large datasets on hand, but not any particularly complex queries.
<infinity> neuralis : The biggest issue is finding a mess of rather, uh, messy datasets to shuffle around and attempt to break it.
<\sh> infinity: mysql stresstesting in your livingroom? wow...
<infinity> \sh : <shrug>... I'm a hardware nerd.  There's a reason I do server stuff.
<infinity> neuralis : Massive datasets would be nice.  Nicer if they include insane relations and stored procedures and such.  Nicer again if they come with a chart of the DB I can glance at to construct arbitrarily convoluted and confusing queries. :)
<\sh> infinity: hmm...8 node cluster mysql installation stresstesting...this in your livingroom.please send pics ,)
<infinity> (The latter can probably be done randomly, though, and would probably be better random anyway)
<sistpoty> infinity: I do have some tough datasets/queries at hand, but unfortunately I don't know if they work with mysql (they where made for postgres/oracle)
<infinity> \sh : 3-node, probably, but.. <shrug>
<infinity> seb128 : goffice unbuggered.
<infinity> sistpoty : In theory, MySQL 5.0 should support pretty much every feature pgsql does (well, more or less), but getting the data from one to the other can be a chore.
<infinity> sistpoty : One probably not worth doing, when I can create random tables and relations if I have to.
<neuralis> infinity, i think your living room is your best bet. it'd be a lot easier for me to help if i were back in the states. :/
<infinity> neuralis : No big deal.  The living room and I will have words when I get home.
<sistpoty> infinity: I'll take a look at the datasets... iirc i used to have scripts to create plain insert statements, so it might be trivial... (I needed these in both postgres and oracle)
<neuralis> infinity, otoh, if you just want a big dataset to mutilate and play with, grab http://download.wikimedia.org/wikipedia/en/20051105_pages_full.xml.7z (package 'p7zip' to unpack)
<infinity> sistpoty : It's not the insert statements that suck, it's all the incompatibly named types that may or may not be aliased (and, hence, may require rewriting table creation syntax) that can make it a pain in the butt.
<infinity> neuralis : Yeah, someone mentioned wikipaedia before.  Big dataset, good for testing storage backends and general stability, but not complex enough to be useful for catching corner cases.
<infinity> neuralis : And I really hope upstream's in a position to pass the former tests with flying colours.
<neuralis> infinity, right, but catching corner cases usefully would require some very careful test suite development, i think
<neuralis> infinity, i don't think you can easily come up with any test that their QA department hasn't developed and run in-house already.
<infinity> Incredibly complex relations that are next to impossible to dump/restore + pseudo-random code generation = profit.
* Diziet runs diff on the output from 3diff.
<infinity> neuralis : No, I can't come up with ideas they haven't, but I can hit different bugs with sheer luck. ;)
<neuralis> i'll cross my fingers ;)
<infinity> Mostly, I'm expecting community testers will catch most the hideous stuff in the next month now that 5.0 is GA, but I do want to test ON UBUNTU, for obvious reasons.
<neuralis> aye. when do you need to decide?
<infinity> I'm setting myself a hard limit of... Uhh.. "Christmas... ish"
<infinity> I want to do the final "rebuild the whole effin' archive against the libmysqlclient I want to keep in main" in early January, so it's done before the sprint.
<mdke> dholbach!
<mdke> are you not fixing GOK in breezy?
<neuralis> infinity, wikimedia will possibly have have switched to 5.0 by then, and what they lack in relational complexity, they make up in insane usage patterns. i'll let you know if they reach any conclusions about 5.0 before your personal deadline.
<neuralis> s/have have/have/
<infinity> neuralis : Cool, thanks.
<dholbach> mdke: you think i should upload the dependency change to breezy-updates? hrmmm
<infinity> neuralis : What OS do they run on?
<neuralis> infinity, linux. fc mostly.
<mdke> dholbach, yes, very much so. You may also remember that seb agreed
<infinity> neuralis : Alright, should be close enough to get a decent view anyway.  I'll still need to do some sanity testing in Ubuntu, obviously.
<dholbach> mdke: will get approval for it
<mdke> thanks dholbach 
<mdke> it's a big blocker for accessibility in breezy
<neuralis> infinity, yeah, makes sense. and i have my sights on eventually converting them to ubuntu.
<infinity> neuralis : A noble goal, but hey, I'm just happy if they're not running WinNT or a commercial UNIX at this point. :)
<infinity> neuralis : (and for my own selfish testing needs, it's nice that they're running Linux)
<neuralis> infinity, it's against policy for them. they do foss only, unless it's absolutely necessary to do otherwise (e.g. their donated sun machine runs solaris).
<sistpoty> infinity: http://revu.tauware.de/~sistpoty/for_infinity/database.tar.gz
<infinity> sistpoty : That's an awfully tiny DB...
<neuralis> infinity, you know, you might want to just get in touch with their QA people and ask to borrow some of *their* test datasets?
<sistpoty> infinity: well... the tables should be ~1000 entries iirc
<infinity> neuralis : Yes, I will be doing that too.
<infinity> sistpoty : Yes, that's tiny. :)
<sistpoty> infinity: hehe, but it was big enough for students (that actually had to do these sql-statements) *g*
<infinity> neuralis : I have open dialogue with MySQL upstream about 5.0 in dapper, so I'll tap whatever resources I can get away with.
<neuralis> infinity, great. when asking, offer to receive their datasets under NDA if there's no other way - all we really care about is whether the tests run nicely on ubuntu.
<infinity> neuralis : <nod>... They'll be more than willing, they seem pretty keen on seeing us support 5.0
<neuralis> cool.
<infinity> (To be honest, I'm leaning toward 5.0 too, just cause I don't want to backport security fixes to 4.1 for 5 years... But I'm so not willing to commit without some hard facts)
<neuralis> yeah, +1 on 5.0 here, for a couple of reasons. 
* infinity ponders wandering downstairs for his last hotel breakfast...
<sistpoty> I stopped using mysql somewhere at 3.x... so no clue about the latest changes
<mdke> geez what sort of crazy network content-filters planet.ubuntu.com
<mdke> :/
<infinity> sistpoty : It's grown up a lot since 3.23
<sistpoty> infinity: maybe I'll give it a try once i get to it ;)
<infinity> sistpoty : It's now got every feature under the sun that people kept asking for (stored procedures, subqueries, standard data types, etc, etc), yet somehow maintains the age-old incredible speed.
<neuralis> mysql 3.23 still makes baby cthulhu cry.
<infinity> sistpoty : Worth giving it a test.
<infinity> neuralis : I had 3.23 on my colo machine until... Uhh.. 2 months ago.
<infinity> neuralis : *cough*
<neuralis> infinity, that's very unfortunate.
<infinity> neuralis : Who needs fancy things like transactions anyway?.. 3.23 was basically a FAT filesystem with a SQL frontend. :)
<infinity> (A fast one, though)
<sistpoty> hehe
<neuralis> infinity, yep, but i find myisam to be all but horrid in production, except in tightly controlled use cases.
<magnon> pitti!
<pitti> Good morning
<infinity> Yo, pitti.
<infinity> pitti : Heading to breakfast?
<infinity> The Last Brekkie.
<pitti> infinity: still want to shave, shower, etc.
<pitti> infinity: just mail exchange with my gf for now :)
<infinity> Bah.  Cleanliness is for people who don't do software development.
<Simira> haha
<Simira> ah, you're going home today
<Simira> these days went so fast
<pitti> yes, this afternoon
<sistpoty> elmo: please sync haddock (0.7-1) from unstable ubuntu override ok
<sistpoty> damn my punctuation *g*
<infinity> Has anyone actually tested our Crack of the Day dapper CDs yet?
<infinity> I'm terribly curious if they.. Uhm.. Boot.
<infinity> (working otherwise would be even cooler)
<seb128> infinity: thanks for the goffice build
<pitti> mvo: can you please use -v when you merge packages?
<mdke> ooh dapper cds
<mvo> pitti: ups, yes
<mdke> infinity, are there 3 different dailies for today?
<mdke> oh no
<mdke> just powerpc in different folders
<Mithrandir> mvo: I'd appreciate if you would close bugs when you've merged stuff.  I spent some time this morning merging imagemagick because the bug was still open. :-/
<mvo> Mithrandir: I'm very sorry for that. I usually close the bugs, this one must have slipped through :(
<seb128> pitti: thanks :)
<Mithrandir> mvo: ok, np.  Slips happen. :-)
<seb128> pitti: so I don't feel alone to ask people to use -v :p
<pitti> hehe
<seb128> Mithrandir: have you looked on this weird gtk ia32 hack?
<seb128> Mithrandir: I've reassigned the bug to you, let me know if that's the wrong place :)
<mvo> Mithrandir: I go over my accepted mails now and check if I forgot any other close
<Simira> yay! I'm first in the phone support queue
<neuralis> there's a phone support queue?
<Simira> uh, yes...
<neuralis> this is not ubuntu you're talking about, right? :)
<Simira> no
<Mithrandir> Simira: you're still going to be home for a while, right?
<Mithrandir> seb128: it's probably my bug, yes.
<Simira> rather my private adsl line
<Simira> Mithrandir: yes? 
<neuralis> Simira, ah, makes sense.
<Mithrandir> Simira: goodie, dhl just called and they _still_ had the wrong address, so they'll drop by in a little while.. I might come home soon. ;-)
<Simira> wrong address? Nonnegata or Holtegata?
<Mithrandir> they thought I lived in Holtegaten still.
<Simira> ahrg... phonesupport....
<Simira> how can I step forward in the queue when I'm first...?
<seb128> do we do sync automatically for <n>build1 versions?
<pitti> yes
<seb128> cool
<pitti> (that's the whole point)
<seb128> so /me wonders why easytag 1.99.7-1build2 is not updated
<seb128> debian has 1.99.8 for some weeks
<seb128> and I've updated to 1.99.9 yesterday
<Mithrandir> iz gtk bug?
<Nafallo> :-)
<seb128> Mithrandir: no, it starts with a "e" :p
<mvo> elmo: please sync debianutils (override ok)
<Mithrandir> seb128: zpeling iz hard. ;-P
<seb128> elmo: please sync gazpacho
<seb128> slomo_: around?
<sivang> hmm, there is some kind of a problem with the web site
<sivang> every link I click gives me "Site Error"
<sivang> ah, it's only some of them now
<Nafallo> someone else experience problems with gksudo on an up-to-date dapper?
<seb128> not me
<dholbach> me neither
<Nafallo> none of you guys is on amd64, right?
<dholbach> i am
<Nafallo> odd
<Nafallo> I have to kill sudo to be able to use X again
<Nafallo> I'll try rebooting, brb
<Mithrandir> elmo: can you please sync icu or NEW the binaries?  It seems to be needed for the newer boost.
<Nafallo> nafallo@darkelf:~ $ gksudo echo echo
<Nafallo> echo
<Nafallo> Segmenteringsfel
<Nafallo> segfault! joy :-P.
<Nafallo> after killing a process like this one to make gksudo not steal my keyboard:
<Nafallo> /usr/bin/sudo -S -p GNOME_SUDO_PASS -v
<seb128> does sudo work?
<Nafallo> yes
<seb128> weird
<seb128> ask mvo, he did the syncs
<Nafallo> I kill sudo, which makes gksudo continue and launch stuff with privilegies ;-)
<Nafallo> I'll do :-)
<Nafallo> mvo: ping ^ :-)
<mvo> Nafallo: gksudo fails for you?
<Nafallo> yes
<Nafallo> and it executes things when I kill sudo :-P
<mvo> Nafallo: hm, I suspect the build-dep for libgksu1.2 is not strong enough, let me check it
<Nafallo> oki :-)
<mvo> Nafallo: right, it seems like libgksu1.2 already got updated, but gksu is waiting for the libgksuui1.0 sync
<mvo> Nafallo: that makes gksu fail apparently
<Nafallo> that means I should test it I guess? :-)
<mvo> Nafallo: hm, not a lot to test until libgksuui is updated :)
<Nafallo> or rather, I'll try it :-)
<Nafallo> building debians libgksuui locally and then update gksu :-)
<mvo> Nafallo: yes, that should work. take the gksu from dapper, it's already (as source) in the archive
<Nafallo> was just about to ask :-)
<Diziet> pref("font.default.ar", "sans-serif");
<Diziet> pref("font.default.el", "serif");
<Diziet> etc.   ???
<dholbach> setting default fonts for certain locales?
<Diziet> Yes.  But why serif for some and sans for others ?
<dholbach> maybe certain font sets don't contain the appropriate letters? *shrug*
<dholbach> or look prettier :)
<Kamion_> seb128: gdm (and probably others) need to be changed to depend on the new libgsf, if you didn't know already
<Diziet> So, now we have the shiny new feature specs mechanism and everything, supposing I read a spec and want to comment to say `you have forgotten X, which you ought to deal with in way W if you care' ?
<Diziet> Bothering the Assignee or Drafter on IRC seems the wrong answer.
<Diziet> Am I allowed to go and add witter to the end of the wiki ?
<Mithrandir> just add a comment at the end of the spec
<Kamion_> if it's cleanly separated (e.g. "== Comments =="), it's fine to add stuff
<Mithrandir> or hassle the assignee on IRC, I'd say, depending on if you think it'll generate a discussion or not.
<Mithrandir> Kamion_: ah, I was just looking for you.  What's a good way to test cloop-utils?
<Kamion_> usually a good idea to tell the assignee that you've done so since many of us don't subscribe to all the relevant wiki pages
<mdke> you can create a subpage of the spec called "talk" or "comments" and link it from the main page
<mdke> if you don't want to comment on the page itself
<Kamion> Mithrandir: create_compressed_fs is what the buildds use to build the live filesystem, but I don't really know much about it
<Mithrandir> Kamion: it seems to build, and it looks mostly ok, so... I could just upload it and have you or infty yell at me when it blows up.
<sivang> we should have some sort of emailing events for the spec tracker..
<sivang> hey Diziet 
<Diziet> sivang: Hello.  How're things ?
<Kamion> Mithrandir: that's one usual technique ;)
<Mithrandir> Kamion: and it's because it's used for the generation of compressed fs-es I'm a bit wary of just doing "merge, upload, run away"
<sivang> Diziet: pretty good, thanks.
<Mithrandir> but heck, it's still early in the cycle.  What could _possibly_ go wrong?
<Kamion>       create_compressed_fs $IMGNAME $COMP > livecd.${FS}.cloop-${fsbs}
<Kamion> Mithrandir: ^-- that's the livecd invocation
<Nafallo> famous last words :-)
<Kamion> $IMGNAME having been attached by losetup shortly before
<Mithrandir> it didn't segfault, uploading. :-)
<Kamion> (well, you probably want to *detach* too)
* Diziet comments on NetworkMagic re non-libc readers of resolv.conf.
<Diziet> No, just my house network.  xenophobe is the firewall (I'm going to get rid of NAT RSN honest ...)
<Diziet> Oops, leaking.
<Kamion> elmo: please sync debianutils
<Kamion> (ok to override)
<Kamion> oh, er, never mind, mvo already requested that
<Nafallo> mvo: works now :-). gnome-python-extras, gnome-system-monitor and gnome-volume-manager had to be rebuilt to get libgksuui1.0-1 in :-)
<Nafallo> mvo: thanks.
<mvo> Nafallo: thanks for testing
<mvo> Kamion: are you back? did you had a good trip?
<Kamion> mvo: still in the hotel, going sightseeing this morning
<mvo> Kamion: have fun then :)
<Mithrandir> elmo: please sync tspc from unstable, overriding ubuntu changes is ok.
* Mithrandir kicks bugzilla
* Simira kickes Mithrandir in direction of the station
* Kamion raises his eyebrows at Keybuk^WMithrandir
<Simira> Mithrandir: I'm heading off now
<Mithrandir> Simira: ok, see you in a bit, then.
<Mithrandir> Kamion: yeah, I suck at updating the changelog. :-/
<Mithrandir> elmo: please sync upx-ucl-beta from unstable, overriding Ubuntu changes is ok.
<Mithrandir> Kamion: I should probably put a dch --release into the command line.
* lamont kicks aptitude
<lamont> aptitude, rpm, and xrdb are main packages that build-depend universe binaries.
<freeflying> smurf:hi
<smurf> freeflying: ?
<freeflying> I have sent you a mail
<freeflying> smurf: I'm a chinese ubuntu user
<janimo> Kamion, for starting to build xubuntu dapper dailies where should the seeds be published?
<freeflying> smur: have you know our site for ubuntu
<mdke> freeflying, go to #ubuntu-locoteams
<freeflying> mdke:thanks
<Kamion> janimo: up to you
<smurf> mdke: actually, no -- <freeflying> smurf: we have a spec for support CJK user betrter
<janimo> Kamipon, I asked since I assume you run the builds. So any public http will do for you?
<Kamion> janimo: (I did say before that you'd have to find another system to build xubuntu dailies on, didn't I? I can help with setting that up, although not this week)
<mdke> smurf, :) i thought it was a website thing
<janimo> Kamion, for breezy yes
<janimo> for dapper too?
<Kamion> janimo: I said before that cdimage is maxed out
<Kamion> for dapper, we'll see, but I don't want to commit cdimage to it right now
<Kamion> xubuntu still requires universe, doesn't it?
<janimo> well for dapper only as I stated in the original question to you
<Kamion> yes, I understood that
<janimo> that's another question yes, should I work on a mainpromotion spec for xfce &c o?
<janimo> right now it universe mostly
<slomo_> seb128: here i am ;)
<Kamion> it's not a separate question, because cdimage only builds from main (and I have various reasons for not wanting to change that)
<janimo> it's a separate question but same answer :)
<janimo> I did not know that
<Kamion> yes, main promotion would be good to arrange if you think your team can commit to long-term support for it
<janimo> sure
<janimo> xfce has had no security issues in years
<\sh> janimo: don't say this lighthearted....3 years is a hell a lot of time
<janimo> \sh, that was even the 3.x series which got rewritten since so no sec issues then at all :)
<Kamion> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements, anyway
<\sh> janimo: think about this...it will be the first release of xubuntu and already the first release has to be supported for 3 years....which is not easy
<Kamion> janimo: also, at present, any extra builds running on cdimage involve a certain amount of care and feeding by me
<janimo> I started on xfce main inclusion stuff a whle ago
<\sh> anyways..I have to go....later babes
<Kamion> janimo: my workload is insane, and I'd rather any extra CD builds ran outside cdimage.ubuntu.com until Launchpad CD building exists and can take some of that workload off me
<janimo> Kamion, is the system going to be more automated in the future? I assume it is hard enough already with kubuntu and edu
<Kamion> in the future, yes
<janimo> in dapper timeframe?
<janimo> I am in no hurry just want to be prepared when/if you are
<Kamion> I mean obviously it's already pretty automated, but I have to fix bugs in CD generation and stuff
<Kamion> unlikely to be in dapper timeframe
<janimo> any docs on how I can reproduce what you do locally?
<Kamion> I can give you instructions next week
<janimo> thanks that will be great
<Kamion> today I'm busy sightseeing, packing, and travelling, as soon as I get round to leaving
<janimo> sure np, as I said no hurry, just preparing and planning
<janimo> oh and enjoy your sightseeing :)
<smurf> freeflying: https://launchpad.net/distros/ubuntu/+spec/input-methods -- subscribing to that spec and talking to the people mentioned on that page should be a good first step
<ogra> lamont, around ?
<lamont> ogra: yes
<ogra> lamont, could you remove or kick gcompris ? 
<ogra> (if you can remove all except orig.tar.gz that would be preferred, else i'll wait until the current version built)
<lamont> ogra: I have no archive modification rights
<lamont> I can make gcompris try to build somewhere, but that's about it
<ogra> ok, then just kick it 
<ogra> thats fine with me...
<Robot101> anyone know any bug in breezy's xorg with the i810 driver where totem starting up (initialising xvideo?) causes the X server to crash, and then continue crashing every time you start it subsequently until rebooting?
* ogra grumbles at bootchart.... doesnt work with LTSP :(
<highvoltage> when i install it, it complains that my initrd has changed and it cannot install.
<ogra> highvoltage, you wont gain anything *if* you install it...
<highvoltage> ogra: doesn't it work with the main ubuntu installation, or doesn't it work in the ltsp environment?
<ogra>  /var/log becomes r/w too late in the bootprocess
<highvoltage> ogra: really? i was promised i will get screenshots of my boot process in a folder in /var!
<jsgotangco> ogra: what does it do? creates a chart of the boot process?
<ogra> yup
<jsgotangco> speeds it up?
<ogra> in /var/log/bootsplash
<ogra> nope
<highvoltage> well, i'll have more and more time over the next few weeks. I want to help test things if it's needed.
<ogra> it gives you only a chart of the sigle procs and their time footprint
<highvoltage> then again, my ubuntu is a bit far customised on this laptop, perhaps my charts will be a bit skew.
<ogra> i'll check if it word with /tmp as target folder, but we'll need to start it later in the bootprocess for sure, so the measuring wont include the initramfs...
<ogra> s/word/works
<ogra> it works fine on a normal ubuntu/edubuntu ...
<ogra> highvoltage, try: dpkg-reconfigure linux-image-`uname -r` if the update-initramfs doesnt work
<lamont> hrm... looks like openssl needs a merging.
<infinity> lamont : pitti is already doing openssl stuff, Colin and I had asked him to hold off for a day or two before uploading.
<lamont> ok
<lamont> I wasn't planning to do it, just grumbling about it...:0)
<lamont> I'm fixing kdepim instead.
<slomo_> hm, will we get debhelper >= 5 soon?
* lamont wanders off for a bit
<gypsymauro> hello
<gypsymauro> I've created an iso apt-cdrom addable with the full italian localization, acrobat reader, skype, realplayer, some games and educational software (600 MB of iso) but I've not a place where to publish it.. it's possible on ubuntu servers or somewhere else?
<mdke> does Ubuntu have a default mail server?
<mdke> i mean, is one mail server preferred over another?
<BenC> I only show one MX record for ubuntu.com
<mdke> i mean, in terms of software shipping with the distribution
<BenC> ah
<mdke> i remember postfix used to be in -base
<BenC> postfix is default, I believe
<mdke> but now it isn't
<ompaul> mdke, there is no live one on 5.10 - afik more people are using postfix 
<mdke> ok
<ompaul> mdke, check the server version 
<mdke> i ask in terms of preparing some documentation for dapper
<ompaul> it may have one in there - but I guess it will have both sendmail and postfix
<mdke> should we prefer a specific piece of software for a mail server, or just pick one we like?
<ompaul> there is no default mta you have to get one 
<ompaul> postfix is easier for a new user
<ompaul> sendmail.cf is something I never got to grips with - I have used postfix for as long as it has been an option
<mdke> so all the major ones are fully supported, no single one is preferred over others basically?
<ompaul> let me look at what is in the repos
<mdke> exim4 is in universe
<mdke> postfix is in main
<ompaul> and sendmail is in universe
<ompaul> that says something :-)
<mdke> ok that kinda answers my question
<mdke> thanks ompaul 
<ompaul> mdke, what did I do :-)
<mdke> hey you helped out
<Nafallo> postfix is preferred :-)
<lamont> mdke: postfix is no longer part of the standard install, but it is the default MTA if you install something that wants an MTA
<mdke> lamont, thanks. is it in ubuntu-server by default?
<ompaul> mdke,  only if your doing a mail server 
<lamont> mdke: doubtful
<mdke> is there a list of packages on that cd?
<lamont> policy says that you don't ask questions unless grandma will know the answers
<lamont> and when you install an MTA, you really need some admin-grade answers.
<lamont> that's why we dropped it.
<mdke> fair enough
<lamont> grandma doesn't need an MTA
<mdke> hopefully gran will be able to read our server guide if she wants an MTA
* Kinnison grins
<lamont> I'm 90% certain that postfix is on the server ISO, but haven't actually checked.
<lamont> Kinnison: you highlight on 'grandma'??
<mdke> lol
<ogra> lol
<Nafallo> postfix is in ubuntu-ship, no?
<lamont> yes
<Kinnison> lamont: You don't?
<lamont> lol
<mdke> what is ubuntu-ship?
<Nafallo> then it should definatly be in ubuntu-server I belive :-)
<lamont> mdke: it's the seed that generates what goes on the iso
<mdke> kthx
<lamont> ship: * postfix             # LaMontJones; our chosen mail server
<mdke> wow
<mdke> you have a WikiName in real life?
<Nafallo> wow. lamont is our mail server :-)
<mdke> ok anyhow my question has been well and truly answered
<mdke> thanks all
<lamont> Nafallo: _chosen_ mail server, puhleease.
<Nafallo> :-)
* mdke goes to see if ubuntu-desktop is installable on dapper
<lamont> and the remaining postfix binary debs are in server-seed, which puts them on the server iso.  doc and dev are just in supported.
<lamont> mdke: wasn't as of last night
<mdke> nor of this morning...
<lamont> well, as of 0615 data-center-time
<Nafallo> ehm? UTC? :-P
<ompaul> mdke, on the server iso there is a directory /doc/install/manual/en 
<mdke> ompaul, i'll see if I can download the iso
<mdke> ooh so close to installing ubuntu-deskotp
<mdke> just nautilus and gdm
<Nafallo> will be more after the syncs are done ;-)
<mdke> oh well
* mdke wanders off
<ompaul> mdke, http://releases.ubuntu.com/releases/ubuntu-server/5.10/  << may be a useful url for that
<dilinger> what does it mean when a bugzilla bug is assigned to debzilla@ubuntu
<dilinger> ?
<dholbach> "unassigned"
<dholbach> or a bug that was imported from debian
<dilinger> ok, thanks
<dilinger> are there people triaging unassigned bugs?
<dilinger> or should i figure out who to assign it to? :)
<dholbach> we have bug days quite irregularly :/
<dholbach> but matt is assign-o-matic :)
<Nafallo> :-)
<dilinger> i would think they'd be quite important, as they affect hoary->breezy upgrades :/
<dholbach> ouch
<LaserJock> hmm, I can't get dapper-live-i386.iso to burn
<LaserJock> md5sum checks  out, it just fails <50% done
<dholbach> elmo: could you please sync freetype from sid? ok to override ubuntu changes
<slomo_> infinity: be happy :P we can have a new haskell-cabal from debian... should be fine this time but depends on ghc6 << 6.4... shall i sync it or just ignore?
<Diziet> On dapper, will `gcc' be gcc-4.0 ?
<slomo_> Diziet: it was 4.0 for breezy already
<Diziet> Oh, so it is !
<Diziet> Breezy's firefox has a patch to set CC=gcc-4.0 in some of the makefiles.  More the fool me for assuming stuff in the breezy patches was actually needed.
<Diziet> vanishing exceptions--  #  try { setOKAction(); } catch (exception) { /* keep it set to "OK" */ }
<dholbach> elmo: please sync netpbm-free from sid, ok to override martin's changes
<seb128> Kamion: will do the changes for libgsf, thanks
<slomo_> seb128: ping
<seb128> slomo_: pong
<slomo_> seb128: ;) you asked me 8 hours ago if i'm there... is it still relevant? ;)
<seb128> slomo_: probably not
<slomo_> seb128: ok :)
<slomo_> seb128: i talked with lool today about getting wavpack in debian... the only issue now seems to be unknown patent situation... nobody seems to know if there are patents on it or not, even the author doesn't...
<Diziet> Wahey!  I found a useful patch in our Firefox which _isn't_ in 1.5 beta !
<slomo> elmo: please sync gv, gtksoureview-sharp, gtksourceview-sharp2, seahorse from debian/unstable and avahi from debian/experimental... ubuntu changes can be dropped for all
<_thierry> seb128 : just added the patch for malone bug #3941, if you want to apply it...
<slomo> elmo: thanks :)
<mvo> Mithrandir: around?
<slomo> elmo: please sync dnspython from debian/unstable
<Chipzz> http://www.mattb.net.nz/blog/2005/11/07/cool-new-feature-in-ssh-40-weekend-update/
<Chipzz> hmm nm that
<dholbach> good night
<pitti> night dholbach 
<pitti> dholbach: see you in .de :)
<dholbach> you visit me? :)
<mvo> infinity: could you please kick the gksu build? the dependencies should now be available
<pitti> 99.5% of the way
<dholbach> haha :)
<dholbach> right... see you then :)
<pitti> dholbach: but I will certainly haunt you at some day
<dholbach> be sure to do that :)
<LaserJock> Diziet: ping?
<Nafallo> Keybuk: hi! care to sponsor an upload? :-)
<Keybuk> Nafallo: hmm?  what is it?
<Nafallo> http://www.magicalforest.se/~nafallo/imagemagick_6.2.4.5-0.2ubuntu2.debdiff
<Nafallo> added libxext-dev as build-dep :-)
<Keybuk> I don't think I've ever used that ...
<Nafallo> I just fixed it cause kismet needs it ;-)
<Nafallo> (libmagick9-dev that is)
<slomo> oh, it's really the 9-one... i need it too ;)
<Nafallo> ... and the pressure builds up ;-)
<tashiro> doko: I'm really sorry about what happened. I hope that you weren't offended by me or man-di. And if yes, then please accept my apologies. This was just a slip-up and some misunderstandings.
<Nafallo> Keybuk: so. do I have a sponsor? :-)
<Keybuk> Nafallo: I'm not going to be home until Tuesday, so you'd have a long wait
<Nafallo> Keybuk: ah. I'll see if I can find someone else then :-)
<slomo> oh no... pitti wanted to merge openssl and now he's gone and i need it :(
<slomo> infinity, lamont-away: please give-back gtksourceview-sharp, gtksourceview-sharp2 and seahorse
<zyga> hllo
<zyga> hello even
<slomo> Kamion: can you look at openssl and get this synced? pitti has already written in the corresponding bugreport that it can be safely synced... i need it for another package :/
<Nafallo> elmo: please sync kazehakase from unstable (ubuntu override okey)
<dilinger> grr.  galeon in breezy crashes a lot :/
<HiddenWolf> dilinger, isn't galeon dead?
<dilinger> no
<tseng> HiddenWolf: long term, maybe
<dilinger> i just need to write my own browser, that's all
<HiddenWolf> dilinger, fix epiphany so we can all ditch firefox. ;)
<dilinger> i don't consider epiphany to be fixable
<wasabi_> what's wrong with it?
<wasabi_> i love it. ;)
<dilinger> the emacs keybinding stuff is the first thing that comes to mind
<slomo> elmo: please sync gmime2.1 from debian/unstable... ubuntu changes can be dropped
<tseng> slomo: they can?
<tseng> slomo: i thought you just said the b-d was still messed up
<slomo> tseng: they can... did you look at what we've changed? only cosmetical changes to build-depends and updated to upstream
<slomo> tseng: they are... but it doesn't break the package... it only pulls in too many packages which are not needed
<tseng> ok
<tseng> works for me.
<slomo> hehe
<tseng> lets lart someone
<tseng> with cli policy
<slomo> yes... will you do it or shall i? ;)
<tseng> probably should be a bug
* tseng works on that
<slomo> :)
<Simira> http://tellus.err.no/gallery/ubz
<tseng> can i file a bug against a source package?
<Nafallo> Simira: yay! :-)
<tseng> Package: gmime2.1
* tseng hates debugs
<Nafallo> Simira: btw, signatures? :-)
<slomo> tseng: sure... but the debian bts i annoying ;)
<slomo> they need some kind of webinterface to fill bugs
<\sh> simira: rock
<tseng> slomo: er
<tseng> slomo: the latest only depends on cli-common and mono-mcs
<tseng> slomo: http://ftp.debian.org/debian/pool/main/g/gmime2.1/gmime2.1_2.1.17-2.diff.gz
<tseng> slomo: am i missing something?
<slomo> yes
<slomo> Build-Depends: debhelper (>> 3.0.0), libglib2.0-dev, gtk-doc-tools, autotools-dev, docbook-utils, zlib1g-dev, cli-common [i386 powerpc amd64 ia64] , mono-mcs [i386 powerpc amd64 ia64] , mono-gac [i386 powerpc amd64 ia64] , libgtk2.0-cil [i386 powerpc amd64 ia64] , gtk-sharp2-gapi [i386 powerpc amd64 ia64] 
<slomo> Standards-Version: 3.6.2
<tseng> we are not looking at the same package I think
<tseng> look at my link
<slomo> 2.1.17-2
<tseng> oh im a tool
<slomo> hmm
<tseng> firefox doesnt break lines
<tseng> its scrolled way off to the side
<slomo> hehe
<Simira> Nafallo: mission complete
<mdke> nice photos
<Nafallo> Simira: yay! gothcat to? :-)
<mdke> maybe someone has said this before, but \sh must be the most laid back guy ever
<mdke> going by the photos :)
<tseng> mdke: prost!
<mdke> bless you
<Simira> Nafallo: yup
* jdub wonders why osdir did a screenshot tour of dapper now
<Nafallo> Simira: *hugs* :-)
<tseng> jdub: have they screenshot toured FreeDOS yet?
<\sh> mdke: WH
<\sh> AT?
<mdke> \sh, the shades, they are so cool
* \sh is drunk ever
<mdke> and you always seem to be wearing them in the photos i've seen
<\sh> thanks to ogra
<\sh> and carnival
<Nafallo> lol
* Nafallo tries to run gpg -L 509CBA71 ;-)
<\sh> jdub: not only your luggage as exrtreme hazard alike
<\sh> s/as/was/
<sistpoty> elmo: please sync hmake (3.10-1) from debian unstable, ubuntu override ok
#ubuntu-devel 2005-11-17
<\sh> sabdfl: please ride the wild elmo !!!!!!!!!!!!!
<mdke> he's not here \sh 
<mdke> ;)
<\sh> mdke: so WHAT?
<mdke> fair enough
<\sh> it was a RIDE REQUEST
<Nafallo> oops
* Nafallo uploaded amd64.changes :-P
<jdub> not many people have signed up to the page
<crimsun> nice talk last night, jdub 
<\sh> jdub: sorry dude that I was so drunk at that evening..that I pissed u off
<jdub> thanks crimsun 
<jdub> \sh, hrm?
<ajmitch_> evening
<\sh> jdub: yes.,..come one..I went on your nerves...but it doesn't matter
<Simira> ajmitch_, jdub: know anything more about the thefts? Do you get any refund or insurance-money?
<jdub> Simira, i know at least spiv and i have company insurance - ajmitch_, did you have travel insurance to cover it?
<jdub> oh, you had a LTT lappy, right?
<\sh> outch
<ajmitch_> yeah, but travel insurancve will have to try & cover it
<jdub> cool
<\sh> tomorrow I have a really serious hangover
<ajmitch_> we'll see what happens, I've got to contact claire again about the hotel into
<ajmitch_> s/into/info/
<ajmitch_> for now I
<Simira> jdub: what about you?
<ajmitch_> 'm just trying to enjoy the rest of my holiday :)
<\sh> ajmitch_: don't worry
<jdub> Simira, see above
<\sh> be happy
* ajmitch_ is visiting NYC tomorrow with some friends, should be interesting
<Simira> jdub: ah, I just read "spiv"
<\sh> oh dudes..../quit 0900 question about lady whaetever
<elektranox> hello
<elektranox> I only want to report a bug in gksu: if I insert more than 3 chars the X-Server crashed completly. [Ubuntu 5.10] 
<crimsun> elektranox: bugzilla.ubuntu.com
<Nafallo> elektranox: known :-)
<Nafallo> elektranox: will be fixed when libgksuui1.0-1 arrives in main.
<Mithrandir> Nafallo: not if he's using breezy?
<Nafallo> elektranox: dapper, right? :-)
<elektranox> yes
<elektranox> dapper
<elektranox> mh oh it's 6.04 sry
<Nafallo> then the workaround is to kill this process:
<Nafallo> /usr/bin/sudo -S -p GNOME_SUDO_PASS -v
<Nafallo> on a terminal outside of X ofcourse
<Nafallo> sudo from a terminal works, so sudo synaptic will still start it etc... :-)
<elektranox> yes from terminal by sudo is ok I know
<TerminX> anyone else upgrade today and now have fonts that look like crap?
<Nafallo> TerminX: upgrade every half-hour, but no. they look like usual :-).
<TerminX> I'm sure it's something in the new version of freetype but god, they look awful now, heh :\
<TerminX> they look okay after dpkg-reconfigure fontconfig and selecting autohinter instead of native
<jdub> hrm
<jdub> need a new poll on the fridge
<tritium> jdub, your next few stops on the tour are still TBD?  (Utah, San Francisco, Mexico)?
<jdub> yeah
<tritium> jdub, okay...but in the next few days, I presume?  You're not going to cancel them are you?
<jdub> i'll definitely be in SFO
<jdub> dunno about utah
<jdub> definitely mexico
<tritium> I see...Utah is within driving distance for me.
<tritium> You're still welcome to stop in New Mexico before you go to Mexico
<LaserJock> how about NV? ;-)
<zul> tritium: oh good you can firebomb sco for us
<tritium> zul, are they here in NM?
<zul> utah
<tritium> Oh, I see what you mean :)
<zul> or a drive by
<tritium> hm, I love ubuntu and all, but I don't think I'd get arrested over it ;)
<zul> but you would be doing a public service :)
<tritium> heh
<anavim> I thought sco was done for
<anavim> an internet sit-in to protest sco's behavior would be cool though
<anavim> or similar gandhi-like tactic  :D
<lamont> grep ^processor /proc/cpuinfo | tail -1; uname -a
<lamont> processor       : 7
<lamont> Linux nio 2.6.12-9-hppa64-smp #1 SMP Mon Oct 10 15:10:01 UTC 2005 parisc64 GNU/Linux
<lamont> now that's a nice breezy machine
<crimsun> hah, nice
<Lathiat> heh
<Lathiat> gimme :)
<zul> lamont, is that the same one you had a ubz?
<lamont> zul: no.  that's an N-class 8-way machine
<zul> not bad
<lamont> similar to the one that will be a porting machine in the DC once we can scrounge such a beast and ship it.
<lamont> the one at UBZ was a 2-way A500 with a dead powersupply
<jdub> need a new fridge poll
<Keybuk> UbuntuBelowZero
<Keybuk> 1) the floor
<Keybuk> 2) the temperature
<Keybuk> (from jbailey)
<jdub> Keybuk, while you're here,
<jdub> if the installer finds an adaptec device and a megaraid device in a particular order
<Keybuk> After UbuntuBelowZero. I now have:
<Keybuk> 1) a cold
<Keybuk> 2) an upset stomach
<Keybuk> 3) herpes
<jdub> but an installed system finds them in the opposite order,
<Keybuk> 4) all of the above
<Keybuk> jdub: yeah, it does that a lot
<jdub> what's a useful way to fix the installed system order?
<jdub> sda moves
<jdub> which makes the baby jesus cry
<Keybuk> cotdeath
<Keybuk> aside from blacklisting the annoying one, I can't think of anything
<Keybuk> we don't try to keep sdXY things
<jbailey> /etc/mkinitramfs/modules
<jbailey> You can force the load order.
<jdub> jbailey, order those?
<jdub> ok
<jdub> thanks
<Keybuk> for dapper, we're fixing this by allowing root=/dev/by-uuid/blahblah type things
<jbailey> I imagine that for dapper, the installer and the initramfs detection will probably be somewhat more unififed anyway for the cases where by-uuid isn't an option.
<jdub> that worked - thanks
<jdub> (providing tech support to my host!)
* Keybuk wonders whether Jordi made it to NYC alive
<Keybuk> or whether he's stuck in some Truck-Stop cafe having been sold into servitude for not wearing the red curly wig
<jbailey> Jordi's blog mentioned something about a flat tire.
<jordi> Keybuk: I am in NYC!
<jordi> After getting stuck at the border for a while tho.
<Keybuk> jordi: did jblack let you honk his horn?
<jordi> Keybuk: haha
<Keybuk> I should go to bed soon really
<highvoltage> Keybuk: you should have a 5) all of the above, and i didn't even attend!
<Diablo-D3> hey, has anyone noticed the dissapearance of gimp-print?
<Diablo-D3> the package is just completely missing
<Diablo-D3> did it get renamed and someone forgot to setup a forward?
<minghua> Diablo-D3: the source package is renamed to gutenprint
<Diablo-D3> minghua: okay...
<Diablo-D3> now here comes the $64k question
<minghua> but it doesn't seem to be in ubuntu yet
<Diablo-D3> what package do I install to get gimp to print again?
<Diablo-D3> gargh.
* Diablo-D3 is hoping breezy didnt ship in this broken state
<Diablo-D3> because it'd be pretty bad if gimp users cant print =P
<Amaranth> um
<Amaranth> you must not be on breezy
<Diablo-D3> Im not
<Amaranth> oh, yeah, that's only in dapper
<anavim> not seeing it in breezy
<Diablo-D3> okay
<Diablo-D3> bleh
<Amaranth> upstream changed the name of the project so debian changed the name of the package
<anavim> guten-print or gutenprint
<Diablo-D3> not only does gimp not show the file->print option...
<Diablo-D3> firefox dies if I try to print
* Diablo-D3 senses mass conspiracy
<anavim> cupsys-driver-gimpprint is there...
* Amaranth sends the black helicopters after Diablo-D3 
<Diablo-D3> anavim: having that installed doesnt convince gimp to enable printing.
<Diablo-D3> /usr/lib/mozilla-firefox/firefox-bin: symbol lookup error: /usr/lib/mozilla-firefox/components/libgfxps.so: undefined symbol: FTC_Image_Cache_New
<Diablo-D3> Im thinking its related to that.
<crimsun> it's the new libfreetype6
<crimsun> there are bugs open in Debian for it already
<Diablo-D3> you know what the great part is?
<Diablo-D3> kde apps arent affected <3
<Diablo-D3> *effected
<Amaranth> no, you had it right the first time
<Diablo-D3> er, oh.
<Diablo-D3> doh
* Diablo-D3 is testing out print drivers for his printer
<Diablo-D3> I feel weird having to buy print drivers, btw
<Diablo-D3> for $40, I can use every printer that cups doesnt already support.
<Diablo-D3> (turboprint.de, btw)
<Diablo-D3> and the drivers work with ubuntu fine
<Diablo-D3> what, no one is going to point and laugh
<Diablo-D3> ?
<minghua> Diablo-D3: you got bitten by the libfreetype ABI breakage
<Diablo-D3> minghua: yeah,  crimsun said
<Diablo-D3> any word on when thats going to be fixed?
<Amaranth> when all those apps get rebuilt :P
<Diablo-D3> hah
<Diablo-D3> btw, 2400dpi is amazing
<Amaranth> meh, 2400dpi doesn't make my english papers look any better
<Diablo-D3> well
<Diablo-D3> atleast the text of said english paper will be readable =P
<pef> hello
<Alessio> sorry
<Alessio> i'm an ubuntu member and i have signed CoC, who should i contact for @ubuntu.com?
<Nafallo> Alessio: you get it automatically when you are in that team
<Alessio> oh great..
<Nafallo> elmo: please sync libdc0 from debian/unstable (ubuntu override okey)
<pitti> Hi folks!
* pitti . o O {nice to be at home again}
<Nafallo> morning pitti :-)
<slomo> infinity, lamont-away: please give-back gtksourceview-sharp, gtksourceview-sharp2 and seahorse
<sivang> pitti: Martin!
<sivang> pitti: how was your flight?
<siretart> hey martin, morning sebastien!
<pitti> siretart: Hi!
<pitti> sivang: pretty smooth, although I had to run 2 km in the Frankfurt airport
<seb128> hi siretart, pitti
<sivang> pitti: lol, run 2km? didn't they have the shuttles ready?
<seb128> pitti: welcome to the club :)
<pitti> hi seb128 
<siretart> technical question: what shall we do about library package, where we have choosen to strip off the 'c2' suffix, but the debian maintainer insists on having a 'c2' suffix?
<seb128> pitti: with 1h20 between flights, I had to run a lot to catch my next plane
<pitti> sivang: the Frankfurt airport is a mess...
<sivang> seb128: bon jour seb :)
<siretart> example: we have binary package 'libfoo', debian has 'libfooc2'.
<Nafallo> sivang: that's one word, bonjour :-)
<sivang> pitti: I had to wait like for 20 minutes in LHR for the shuttles to arrive :)
<sivang> Nafallo: oops
<seb128> pitti: getting the boarding pass, going through security (lot of people waiting here) and running all over the place
<pitti> seb128: me too, I even had to put off my shoes for separate scanning
<sivang> Nafallo: probably that's why Seb is not answering :)
<pitti> seb128: and they wanted my laptop again
<seb128> pitti: utch, security guys really don't like you it seems
<Nafallo> sivang: naah, he just ignores you ;-)
<seb128> hi sivang Nafallo
<Nafallo> morning seb128 :-)
<seb128> no, I just don't say hi 20 times
<sivang> :-D
<seb128> elmo: gazpacho sync please
<slomo> seb128: are you aware of librsvg2-2 disappeared from the archives?
<seb128>  *** 2.12.5-0ubuntu1 0
<seb128>         500 http://archive.ubuntu.com breezy/main Packages
<seb128>         500 http://archive.ubuntu.com dapper/main Packages
<seb128> slomo: it didn't?
<slomo> seb128: hmm... up-to-date pbuilder: libgnome2.0-cil: Depends: librsvg2-2 (>= 2.9.5) but it is not going to be installed
<slomo> seb128: same for seahorse yesterday for example
<seb128> not going to be installed is usually a broken dep
<slomo> hmm
<seb128> slomo: I've closed you gazpacho merge bug, I've asked a sync yesterday for it
<slomo> seb128: thanks... i filed it only because you didn't file one and i didn't want the work to be done two times
<seb128> slomo: there is no need to file a bug every time you ask a sync
<slomo> in case of universe there is for merging... it's our policy ;) and otherwise our little tool gets confused which shows the unassigned, assigned and fixed merges
<Nafallo> our MOTU-tool to keep track depends on it ;-)
<slomo> seb128: oh sorry because of the rsvg thing... it isn't installable because of libgsf-1... i really need to wake up before saying something ;)
<seb128> slomo: I'm going to work on libgsf today
<seb128> will be fixed soon
<seb128> slomo, Nafallo: where is your tool?
<slomo> thanks :) can you notify me then? i've currently >5 packages which ftbfs because of that
<Nafallo> http://revu.tauware.de/~sistpoty/MoM/
<seb128> slomo: sure
<slomo> ok... /me gets some food now :) bbl
<seb128> same here
<seb128> later
<Nafallo> elmo: please sync tora from debian/unstable (ubuntu override okey)
<seb128> 8 merge bugs for avifile? what are you guys doing ... ?
<Mithrandir> seb128: ARE WE THERE YET? :-)
<seb128> MOTU ON CRACK
<tseng> seb128: iz gtk boog
<Mithrandir> I didn't know the MOTUs where implemented using GTK+.
<Nafallo> there are more than 8 :-)
<seb128> Nafallo: are you doing autofilling?
<mdke> some problems with LP it seems
<seb128> ?
<Nafallo> seb128: nope. a python-script that filed two indentical bugs right after each other for siretart. now lp seems to have a bug found :-P.
<siretart> seb128: there is something really weird going on with lp
<siretart> seb128: I filed ONE (1) bug with the malone email interface
<siretart> seb128: I'm not sure if there couldn't be actually 2 emails sent out because of some problems with the script I'm using to do that, I already fixed that
<siretart> seb128: the problem is, that appearently launchpad keeps on processing the same email as new. unfortunatly, noone from the launchpad guys seem to be awake atm
<seb128> utch
<siretart> yeah :/
<Nafallo> I wonder why the avifile bug is only even numbers...
<Nafallo> is there other bugs filed for the odd numbers aswell somewhere? :-/
<siretart> try to finde one :)
<Nafallo> *puuh* :-P
<siretart> seb128: I will write a mass merge email when launchpad stops filing new bugs. until then, I have to wait :(
<seb128> siretart: I've marked the bug as dup
<siretart> they keep on getting more. thats the problem here :(
<seb128> yeah
<slomo> seb128: thanks for fixing librsvg :)
<seb128> slomo: np
<slomo> seb128: am i right that you can upload to debian? do you want to sponsor 2 packages by me? gnome-user-share and service-discovery-applet? they just need some polishing before
<seb128> I can upload to Debian, but I'm quite busy and I prefer to not start beeing sponsor for new packages, I've enough atm
<slomo> ok, np :)
<seb128> for GNOME stuff, #gnome-debian is the right place
<seb128> you can join pkg-gnome if you are interested
<slomo> (on gimpnet?) i'll ask there for these 2 packages after lool is ok with my wavpack package ;)
<seb128> k
<\sh> hmmm
<\sh> glade-gnome is not installable
<\sh> (breezy that is)
<seb128> that's gnome1
<seb128> who cares :)
<seb128> this package should have been dropped
<siretart> thats the spirit! :)
<\sh> ah -2 is what i want :)
* \sh has a light hangover so it's ok
<seb128> elmo: aalib sync please
<seb128> ups, this one has already been required by other people
<seb128> elmo: pyorbit sync from Debian please
<seb128> siretart: are you sure that's not your mail setup sending the same mail for the launchpad dups?
<siretart> seb128: I keep on checking my maillog
<siretart> >> grep new@bugs.launchpad.net /var/log/exim4/mainlog
<siretart> 2005-11-12 12:49:21 1Eatsm-0004H6-RK => new@bugs.launchpad.net R=dnslookup T=remote_smtp H=fiordland.ubuntu.com [82.211.81.145] 
<siretart> 2005-11-12 12:49:21 1Eatsn-0004HC-GB => new@bugs.launchpad.net R=dnslookup T=remote_smtp H=fiordland.ubuntu.com [82.211.81.145] 
<siretart> not any other mails are sent to new@bugs.launchpad.net since then
<ogra> siretart, is there any kind of autoreply/bounce in your exim config ?
<siretart> ogra: even if there was, all outgoing mails would be logged to the logfile
<zyga> ogra: hi
<siretart> does anyone happen to know who is in charge for the MTA on bugs.launchpad.net?
<zyga> ogra: are you the author of hwdb-client?
<ogra> hey zyga 
<ogra> yup
<zyga> ogra: bash! :-)
* ogra hides
<zyga> for not following the ubuntu code of conduct :P
<zyga> ogra: you neglected i18n, any i18n 
<ogra> huh ? 
<ogra> thats not written in the CoC :)
<zyga> ogra: hmm /me checks (if not CoC then something similar)
<zyga> anyway
<zyga> do you have plans on adding i18n?
<ogra> zyga, i planned to fix that up for dapper... but no promises, its not very high prio on my list
<zyga> ogra: cool, I'm partially done
<zyga> ogra: I  was hoping to give you patches
<ogra> thats fine with me
<ogra> i will also put it up in a bzr tree at some point... but curretnly merge work and ltsp are higher priority for me...
<zyga> okay, if it appears in bzr give me a hint
<zyga> I'll use breezy's sources as base okay?
<ogra> will announce it
<zyga> (unless dapper brings something significant)
<ogra> yup, thats fine
<ogra> the only requested change i currently have is to add a question in the end to optionally give your mailadress if you want to participate in kernel testing...
<ogra> and the older bugs that idle in bugzilla indeed
<zyga> just make sure you use gettext in that patch, I'll nicely merge with my stuff ;
<ogra> will do
* zyga has found that stuff, it's not in CoC
<zyga> ogra: http://www.ubuntulinux.org/, second list item from the top
<zyga> aww, third list item
<ogra> and ? that doesnt mean i violate anything :)
<zyga> you did not follow that point, that's for sure ;-)
<ogra> as our desktop doesnt include the best "accessibility infrastructure" yet
<siretart> seb128: are you doing all those merges manually via webinterface?
<seb128> siretart: yep
<seb128> I don't trust the mail stuff :p
<siretart> hehe
<siretart> thanks. I was doing the first 20 myself, but now I rather wait until that terror ends :/
<seb128> launchpad guys are on it
<seb128> I guess it'll be fixed soon now
<siretart> seb128: they are? great news
<siretart> I'm really sorry for the mess :(
<seb128> not your fault don't worry
<seb128> siretart: mail moved, should stop the bug creation
<seb128> elmo: please sync pxlib
<siretart> seb128: great news. 
<siretart> seb128: in future, who should I contact when such bugs occurs?
<seb128> #launchpad
<siretart> hm. I tried, but there was no one responding :(
<seb128> no luck today because that's saturday and most of launchpad guys are travelling back from UBZ or just arrived home
<siretart> I thought so, okay
<siretart> seb128: did you catch all dups or are some left?
<seb128> siretart: I think I caught them
<zyga> where can I address kernel howto questions?
<siretart> seb128: thanks a lot!
<ogra> zyga, #ubuntu-kerne
<ogra> err #ubuntu-kernel
<zyga> (seems asleep)
<ogra> its saturday :)
<seb128> siretart: np
<zyga> darn
<zyga> I need a kernel with squashfs and unionfs on monday :/
<highvoltage> sounds handy for a livecd.
<zyga> exactly
<zyga> I'm looking for an easy way to build a snapshot of my current install as a live cd
<zyga> I've found linux-live.org
<zyga> but I really don't know how to build the kernel based on what I'm running that would also include those modules
<highvoltage> squashfs comes with the kernel, you can just choose it with your configure options, i'm not sure if unionfs comes with default kernel yet, but it's an easy install.
<highvoltage> (if you have your kernel tree somewhere)
<zyga> unionfs is as a source 
<zyga> I've never really built kernels before, I've got  linux-tree and linux-headers packages
<highvoltage> i think the easiest way to start is to download a kernel from kernel.org, apt-get install libncurses5-dev and do a make menuconfig
<highvoltage> but i think there's a proper ubuntu way too. hold on..
<seb128> infinity, lamont-away: please give a retry to libwpd
<zyga> is there any way to feed the config I'm running to that kernel?
<highvoltage> zyga: http://wiki.clug.org.za/index.php/How_do_I_compile_my_own_kernel_into_a_deb%3F
<seb128> do you use an ubuntu linux package?
<zyga> highvoltage: thanks :-)
<zyga> seb128: yes
<seb128> zyga: /boot/config-... is the config
* zyga learns new thing :-)
<seb128> learning is good ;)
<zyga> thanks guys, I'll read on and try to make this work
<zyga> with a bit of luck I might end up with ubuntu-snapshod-as-livecd package that does the work
<mdke> ubuntu-desktop is installable!!
* mdke installs ravenously
<mdke> awesome
<zyga> seb128: how to pass -j3 for the make invoked by make-kpkg
<zyga> I've got a SMP box here and I'd like to use it
<zyga> seb128: nothing, sorry :>
* zyga should read first, ask later
<zyga> cool, it builds nicely
<robertj_> *sigh* /. is already carrying a link to Dapper Screenshots...
<bob2> haha
<zyga> what?!?
<luis_> maybe I haven't been paying a whole lot of attention, but doesn't it look like breezy?
<robertj_> luis: nonono, it says very distinctly in the bottom right hand corner of the greeter that it is Dapper...
<siretart> yippie!. gjdoc_0.7.6 build depends on java-gcj-compat-dev, which itself builddepends on gjdoc (>= 0.7.6)
<siretart> life is great, isn't it? :/
<luis_> robertj_: oh, well, then
* jdub boggles at a) osdir posting dapper sshots, b) slashdot posting about dapper opening
<Chipzz> jdub: sorry to hear about the laptop man
<Chipzz> jdub: I hope you didn't loose to much work?
<jdub> about 5 weeks
<jdub> had a good backup before i left
<jdub> but had to reconsitute my talk and so on from a muuuuch earlier version
<Chipzz> sucks :/
<Chipzz> but fortunately it was on the last day I guess
<jdub> it'll be ok, i'm drowning myself in positivity
<jdub> actually, that was the annoying bit
<jdub> if it were earlier, losing my credit card wouldn't have been such a hassle ;-)
<Chipzz> hmyea
<Chipzz> but kinda ironic that that's what you get for doing work which benefits the public
<jsgotangco> jdub: sonia replied back we've fixed things already
<jdub> jsgotangco, great :-)
<jdub> Chipzz, i haven't been contributing enough to montreal's drug industry
<Chipzz> jdub: *g*
<jsgotangco> haha
<jsgotangco> dapper sshots hah
<mdke> mmm dapper
<mdke> i was thinking recently...
<mdke> the equivalent name for "colony" would tip us off about the duck/dragon controversy
<mdke> but it turns out they have the same collective noun, goddammit
<jsgotangco> a colony of ducks
<siretart> it is a flight of drakes
<mdke> yes it is
<mdke> but a "flight" applies to dragons and ducks equally
<jsgotangco> well ducks fly
<jdub> so we were looking for interesting ambiguities during UBZ
<jdub> and someone mentioned to me that both ducks and dragons lay eggs
<jdub> i told mdz about this fascinating discovery
<mdke> both breathe fire too
<mdke> oh no
<jdub> and pondered out loud how we could abuse it
<jdub> when he turned to me
<jdub> glaring
<jdub> and said
<seb128> hum
<jdub> "DRAGONS DON'T EXIST."
<mdke> lol
<jsgotangco> hehehe
<siretart> hey jdub!
<jdub> i think we know which side of the fence mdz stands
<mdke> mdz just lives in this crazy world with no dragons
<siretart> hbd.com
<jsgotangco> we do have dragons except that its only by name and they don't fly (komodo dragon for example)
<mdke> heh
<jsgotangco> i've seen this slashdot entry about a prehistoric godzilla
<jsgotangco> heh
<Simira> stupid mdz. Of course dragons exists!
<robertj_> Dragons should be a strategic marketing choice for widening Ubuntu's appeal among women
<desrt> if dragons don't exist then how come the new ubuntu version is named after one?
<jsgotangco> women are into dragons?
<robertj_> jsgota: yeah
<mdke> desrt, it's not
<Simira> they are?
<Simira> I mean, we are?
<desrt> if you wanted it named after a duck you should have gone for like "Mediocre Mallard"
<Simira> I thought that was more about the knight killing the dragon, desrt?
<robertj_> It's right after the Doplhin phase and before the ceramic crap phase
<mdke> desrt, all the Ubuntu versions have been named after unspectacular animals
<Nafallo> desrt: it isn't :-). it's a god damn duck! ;-)
<mdke> of course it's a duck
<Simira> Nafallo: IT'S A DRAGON!
<Simira> hrmf...
<mdke> this dragon business is just a coincidence
* Simira goes to get some food
<Nafallo> Simira: IT'S A DUCK! :-)
<desrt> mdke; a badger that also happens to be breezy is quite spectacular in my books
<Simira> DRAGON!
<mdke> lol
<mdke> desrt, so is a duck which also happens to be dapper
<seb128> ducks are just boring
<Nafallo> Simira: maswan even has pictures of a couple of them :-P
<desrt> all ducks are dapper
<seb128> dragons rock
<desrt> except for diseased ones
<desrt> they just looks really sweet
<Simira> why aren't they dapper ducks then, eh?
<desrt> s/looks/look/
<Simira> oh, no...
<janimo> I am waiting for the Pining Parrot
<desrt> because 'dapper duck' isn't as cool as 'mediocre mallard'
<Simira> Freaky Ferret
<Simira> :)
<neuralis> i'd rather my server breathes friggin fire than swims around lazily on a pond.
<desrt> i want to know what happened to the dapper dingo!
<Treenaks> hollandse haring?
<mdke> neuralis, hopefully it won't do either
<jdub> next release will start with E
<jdub> so i'm pitching for Edgy Eagle or similar
<desrt> the excellent eggplant
<neuralis> jdub, i was partial to elegant elephant. 
<desrt> [...] 
<siretart> how about angry aardvark *g*
<mdke> elephants don't exist!
<siretart> lol
<neuralis> mdke :-D
<Treenaks> lumpy lion
<desrt> mdke; my baby sister got stepped on by an elephant.  she died.
<desrt> they exist.
<neuralis> zealous zebra?
<siretart> hrhr
<jdub> the release after dapper is definitely going to be more edgy than elegant
<Treenaks> Glorious Gentoo?
<Nafallo> neuralis: we are following the alphabet here ;-)
<neuralis> Nafallo, the alphabet doesn't exist.
<mdke> did everyone see that site that someone wrote to generate ubuntu release names? i forget where i saw it
<Nafallo> ehm, :-P
<Treenaks> Nafallo: the very special South African alphabet that goes 'W, H, B, D, E' ?
<mdke> maybe sounder
<desrt> hmm
<Nafallo> Treenaks: nope, we started from dapper forward. don't you ppl read mails? :-P
<neuralis> treenaks: Wait! Here Be Dragons, Edgar!
<desrt> the ubuntu release name letters are clearly spelling out some monoalphabetic encryption key
<desrt> everyone pay attention!
<Treenaks> neuralis: then dapper _should_ have been Angry Aardvark
<siretart> edgy elk?
<slomo> eager elephant like tseng proposed ;)
<neuralis> effervescent estemmenosuchus? :)
<Treenaks> 
* Treenaks pokes his ipw2200
<Treenaks> please stop crashing your firmware
* desrt awaits the sexy spaceman release
<Treenaks> desrt: "he's an animal"
<Keybuk> Mark will have to loose some weight first ;)
<desrt> :)
<Treenaks> desrt: have a look at wiki/ExampleContent ;)
<Treenaks> desrt: especially the XCF proposal
<janimo> Keybuk, is your bootchart package different from the one in sid?
<Keybuk> janimo: yeah, the one in sid just replaces init with bootchart
<Keybuk> which is a bit late for Ubuntu, we do a lot of stuff in initramfs
<Keybuk> mine installs itself as an initramfs scripts and hooks
<jdub> Keybuk, 'lose'
<Treenaks> or loosen
<Treenaks> ;)
<desrt> Treenaks; oh i do love those
<Treenaks> jdub: how did you like the extremely-long-talk video?
<desrt> Treenaks; my friend made one of those of himself
<desrt> Treenaks; with all of his pants and shirts
<Treenaks> desrt: cool :)
<jdub> Treenaks, only watched bits of it - will have to watch again some time :-)
<Treenaks> <SCENE DELETED>
<Nafallo> Treenaks: ohoh? where is that video availible for my hungry wget? :-)
<ogra> Keybuk, no luck with bootsplash on ltsp :/
<Treenaks> Nafallo: Not yet.
<ogra> s/bootsplash/bootchart
<Treenaks> Nafallo: Once jdub's World Tour is over, I'll make it available
<Nafallo> Treenaks: so where will it be? :-)
<Treenaks> Nafallo: I'll post a bittorrent link on my blog (which is on planet)
<Keybuk> accidentally discovering a pant-less sabdfl on the desktop would be disturbing
<Nafallo> nice :-)
<Treenaks> Keybuk: "We need to keep the content as in-offensive as possible" is a nice note on that page too :)
<Keybuk> ogra: no luck in which way ... did you install the package?  did it regenerate the initramfs to include "bin/nanosleep" and "scripts/init-top/initramfs" ?  is there a S99zzz-bootchart-stop in rc2.d ?
<ogra> Keybuk, all my mounted dirs are read only ... they get read write very late in the bootprocess
<Keybuk> ogra: that's ok ... it uses /dev/ as the place to live throughout the boot process as it's the only bit of the filesystem that survives into userspace
<ogra> i get a /var/log/bootchart dir, butr nothing in it indeed
<Keybuk> right
<ogra> so it gets copied from somewhere in the end ? 
<Keybuk> can you do the following for me
* ogra listens
<Keybuk> gunzip -c /boot/initrd.img-$(uname -r) | cpio -t | egrep "(nanosleep|bootchart)"
<highvoltage> Keybuk: it might encourage more woman to get involved in ubuntu?
<ogra> bin/nanosleep
<ogra> 22239 blocks
<ogra> scripts/init-top/bootchart
<ogra> Keybuk ^^
<Keybuk> highvoltage: the first time I ever met Mark, he'd just come out of the shower and was wearing a bath-robe ... it was the most interesting "hi, I'm your new boss" experience I think I've had
<Keybuk> ogra: and that's the initramfs that gets given to the clients?
<ogra> lol
<ogra> yup
<highvoltage> Keybuk: lol!
<ogra> i'm in the chroot
<Keybuk> ogra: ok, look in /dev/.bootchart -- does that directory exist?
<highvoltage> Keybuk: the first time i met him, i was filthy, been cleaning up a bunch of really old computers, i think that was even worse for me
<ogra> Keybuk, nope
<Keybuk> ogra: ok, does /etc/rc2.d/S99zzz-bootchart-stop exist ?
<ogra> yup
<Keybuk> when that runs, is /var/log writable?
<ogra> yup
<Keybuk> ok...
<Keybuk> edit that for me, and comment out the "clean_jail" line right at the bottom
<ogra> it gets writable  in S32 of rcS.d
<ogra> right before create_chart ? 
<ogra> done
<Keybuk> then reboot
<ogra> one sec ...
<ogra> still nothing
<Keybuk> right, do you have a /dev/.bootchart now?
<ogra> nope
<Keybuk> ok ... this suggests that the initramfs bit isn't getting run
<Keybuk> can you reboot and add "break" to the kernel command-line
<ogra> i have .initramfs-tools , .static and .udevdb
<Keybuk> oh, and take off "splash"
<ogra> there is no usplash in ltsp yet
<Keybuk> ok
<Keybuk> wel, boot it up with break, and it'll drop you in the initramfs
<Keybuk> check that scripts/init-top/bootchart exists there
<Keybuk> and that /dev/.bootchart exists there too
<ogra> oki
<Keybuk> probably also ps and see whether a bunch of "bootchart bottom" processes are running
<highvoltage> ogra: how much more ram does usplash take?
<hunger_> There are some packages suggesting/recommending ssh. Shouldnn't that be openssh-client/serve?
<ogra> highvoltage, donno, i havent experimented with it yet...  but way to much imho
<ogra> the prob is that we need to have the framebuffer modules loaded, they eat the memory...
<highvoltage> ogra: i was just thinking about the 32MB target. usplash will make that slightly more difficult.
<ogra> as all modules will
<ogra> i think we'll add a lowmem option you can set... this will avoid sound, local devices and usplash
<ogra> neither of there will work with 32M
<ogra> s/there/these
<highvoltage> ouch
<highvoltage> sorry, i read the rest now.
<highvoltage> ogra: i think that's a good idea. most 'new' second hand pc's have 128mb RAM.
<highvoltage> and if your old computers are still using 32MB, you should probably consider getting some free computers with more ram.
<ogra> i think our default target will be 64M but with a lowmem option you can castrate it down to 32M 
<ogra> Keybuk, scripts/init-top/bootchart doesnt exist
<Keybuk> right
<ogra> neither does /dev/.bootchart
<Keybuk> which initramfs do you give to the client?
<ogra> hmm there are actually two...
<ogra> one taken from tftp and the other one from the chroot 
<ogra> let me try something... 
<Keybuk> the one from the chroot is almost certainly not the one :)
<jbailey> Keybuk: I suppose I can take initramfs out of my nick highlight now... =)
<Keybuk> you may need to regenerate the tftp one so it includes the script
<Keybuk> jbailey: why?
<Keybuk> what's wrong with initramfs?
<Keybuk> jbailey: do you not like it anymore? :p
<ogra> Keybuk, right, and i forgot to run ltsp-update-kernels to link them together...
<ogra> lets try another boot
<Keybuk> do that gunzip...egrep to make sure the initramfs has both of the bits in
<jbailey> Keybuk: Not at all.  But you and Adam certainly seem to have it well in hand, I probably don't need to look at IRC everytime someone mentions it. =)
<ogra> i'm sure it will work now...
<ogra> was a silly mistake on my side
<jbailey> Keybuk: Specifically, I'm more impressed that what I was showing off at UDU is still basically what we wound up going with. =)
<ogra> hmm, strange... i lost my console on the thin client. ...
<Keybuk> jbailey: which bit?
<jbailey> The hook/scripts structure.
<ogra> WOAH
<ogra> i have a working bootsplash !!! in ltsp :)
<Keybuk> now share the png
<highvoltage> ogra: does it take much more mem?
<ogra> Keybuk, not bootchart :)
<ogra> i dunno why i lost the console, i cant get to it
<Keybuk> heh
<hunger_> Would it be possible to get all those transitional packages out of dapper/main?
<ogra> and usplash times out :/
<jbailey> ogra: Didn't bootsplash work for Breezy?  It was supposed to.
<Keybuk> heh, maybe you got the initramfs wrong?
<jbailey> usplash, rather.
<jdub> jbailey, he meant bootchart
<jbailey> Keybuk: I never tested it, but I did get 3 or 4 success reports.
<ogra> jbailey, nope... 
<jdub> no he didn't
<ogra> jdub, both :)
<jdub> ogra, START MAKING SENSE! :)
<ogra> lol
<highvoltage> hehe
<jbailey> jdub has clearly not recovered from UBZ with expectations like that.
<highvoltage> jdub: too much coffee?
<Treenaks> wrong timezone?
<ogra> jdub, i'm playing with th initramfs... so i work on both ends ;)
<ogra> hmm, where is my console gone ....
<Treenaks> who needs a console :)
* ogra installs sshd on the thin client
<jdub> Keybuk, did we have no-name-yet.com at that first UK meeting?
<jdub> Keybuk, or did we set it up there?
<Keybuk> set it up there I think
<ogra> Keybuk, ok, /dev/.bootchart/ is there now
<Keybuk> ogra: is there png in /var/log/bootchart ?
<ogra> nope
<Keybuk> ok ... so let's debug that
<ogra> oh, it seems it took some time
<Keybuk> is there a /var/log/bootchart.tgz ?
<ogra> it just appeared :)
<Keybuk> ah
<Keybuk> heh
<Keybuk> are you sure that your addition of usplash didn't break your boot a bit? :p
<Keybuk> also if the client is somewhat gutless, generating the chart could take a while
<ogra> when i ran ps ax after boot it had: 9674 ?        S      0:00 /bin/sh -e /etc/rc2.d/S99zzz-bootchart-stop start
<Keybuk> ok
<Keybuk> it was still booting then
<ogra> its a VIA 533 Mhz 
<ogra> with 128M
<Keybuk> let's see the chart
<ogra> http://people.ubuntu.com/~ogra/edubuntu/breezy-20051113-1.png
<ogra> i already wiped a lot of the uneeded bootscripts but it still takes 1:24 to boot  :(
<Keybuk> well, straight off, most of your time is spent in dexconf
<Keybuk> the rest in S40hotplug
<ogra> is there a way to supress kgameportd from being started at all ?
<ogra> its useless
<Keybuk> that's a kernel thread
<ogra> mdz, http://people.ubuntu.com/~ogra/edubuntu/breezy-20051113-1.png <-- thin client bootchart
<Keybuk> blacklist the joydev driver, or whatever one causes it to be started
<ogra> Keybuk, thats enough ? 
<Keybuk> yeah, it just a kthread that deals with the gameport
<siretart> joysticks on ltsp clients! rock!
<siretart> ;)
<ogra> lol
<Keybuk> could be a PCI driver that's loading it also, so fiddle a little
<ogra> fine then :)
<Keybuk> look in /sys, find the driver, then find the devices bound to it
<ogra> i havent looked at the modules stuff yet ...
<Keybuk> though it's almost not work worrying about, kernel threads don't really affect the system
<zyga_laptop> ogra: how do you generate that chart?
<ogra> i guess its something generic from hid or so ...
<zyga_laptop> ogra: it could be great for performance analisys of gettext+.desktop
<Keybuk> your ldm looks somewhat slower than gdm
<mdke> does everyone else have invalid keysignatures when updating on breezy?
<ogra> since this thin client has no gameprt 
<ogra> Keybuk, its gnome-canvas in pygtk ...
<Keybuk> zyga_laptop: http://people.ubuntu.com/~scott/packages/bootchart_0.8-0ubuntu2_all.deb
<ogra> sure its slower
<zyga_laptop> Keybuk: do you make that package?
<zyga_laptop> ;-)
<Keybuk> zyga_laptop: yeah
<zyga_laptop> Konfigurowanie bootchart (0.8-0ubuntu2) ...
<zyga_laptop> /boot/initrd.img-2.6.12-9-k7 was been altered.  Cannot update.
<Keybuk> ogra: interesting, the first 20s of your boot is basically initramfs
<zyga_laptop> was been
<Keybuk> the next 20s is dexconf
<Keybuk> then 25s of hotplug
<Keybuk> then the rest is ldm
<Keybuk> zyga_laptop: did you just install a new kernel or something?  that means it wasn't able to update your initramfs
<zyga_laptop> Keybuk: I was talking about the grammar bug
<Keybuk> isn't mine
<zyga_laptop> s/was/has/
<zyga_laptop> ah ;-)
* Keybuk points at jbailey ... initramfs is his
<zyga_laptop> actually... no
<zyga_laptop> I didn't upgrade the kernel 
<ogra> Keybuk, i'd like to get rid of the initial delay of initramfs and of the hotplug delay, then i'd be fine 
<Keybuk> ogra: no idea what the initial delay is
<ogra> tftp probably
<Keybuk> it looks almost entirely modprobe
<Keybuk> which means you're stuck with it unless you go for a per-machine monolithic kernel
<ogra> i mean everything is working over the net ...
<ogra> at least at this point
<Keybuk> at that point, the initramfs should have been downloaded and be in memory
<ogra> i'm not aiming for 30 sec boots anymore, thats for sure, but 45 should be reachable 
<Keybuk> interesting that you've removed readahead from the boot sequence
<Keybuk> an S01readahead might help a LOT
<HiddenWolf> ogra, aim for instant boot, and see how far you can get. ;)
<Keybuk> as it can haul in everything over the network into memory while the machine's fucking about dealing with hardware
<janimo> mdke, ar e you using the us. mirror by any chance?
<ogra> Keybuk, readahead in 32MB systems will work ??
<Keybuk> ogra: sure
<Keybuk> you've got to load that stuff into memory ANYWAY
<mdke> janimo, no, archive.u.c
<janimo> hmm
<Keybuk> you may as well do it while the machine's doing other things, so you eliminate the network from the speed problems
<janimo> I only had bad sigs with the us. mirror
<zyga_laptop> jbailey: typo ping :)
<ogra> Keybuk, will play with it ...
<Keybuk> will also be interesting to see how much the removal of hotplug will help you
<ogra> it breaks X currently ....
<janimo> Keybuk, didn;t the spec said something about RA not helping with systems < 128M ?
<ogra> i already tried the evil way :)
<Keybuk> janimo: which spec/
<janimo> I don;t recall but oneo f the UBZ ones
<Keybuk> readahead seeds the page cache with files that are going to be read anyway
<janimo> speeding up boot or something
<janimo> does it read them into memory?
<Keybuk> yes
<Keybuk> but they've got to be read into memory anyway
<janimo> but before it could use some it may have to swap them out again
<janimo> if the memory fills faster than the apps need that info no?
<Keybuk> *shrug* swapping to a local swap partition is still going to be more efficient than having to haul them over ethernet
<janimo> oh, for ltsp
<janimo> was there something about swap over nbd? for diskless stations?
<Keybuk> though I suspect if your boot sequence needs more memory than the machine has, you have problems
<Keybuk> if you need to load 64MB of apps to boot a machine with 32MB of memory ... you're screwed speedwise
<janimo> https://wiki.ubuntu.com/LiveCDPerformance?highlight=%28readahead%29
<janimo> Keybuk, that's where I saw about readahead
<janimo> and small memory
<ogra> Keybuk, i'll add a lowmem option that switches off nearly everything and just boots up x... that should work with 32M
<jdub> holy crap
<jdub> really need a new poll
<Keybuk> the theory of readahead is that it reads into the page cache files you need later in the boot sequence
<Keybuk> if the sum total of all the files you need is greater than the amount of memory you can spare for page cache, it won't be a win
<jdub> our readahead data files haven't been updated since warty though
<jdub> which ends up sucking
<Keybuk> except if the sum total of files you need is greater than the amount of memory, you're going to hit swap during boot!
<Keybuk> let alone when the user is trying to use it
<janimo> I know, I was just pointing out that what I said earlier is not my idea, read it somewhere :)
<Keybuk> so it's probably time to go back and figure out why you need more memory to boot the machine than you have
<Keybuk> and cut out memory-usage so you don't
<janimo> soem of the memory may be used then discarded, it may not add up
<Keybuk> jdub: yeah, see the ski-slope on http://people.ubuntu.com/~scott/bootcharts/20051109-2.png
<janimo> whereas with readahead that is what's happening
<ogra> Keybuk, swap is no option at boottime ...
<Keybuk> janimo: some maybe, but if you're using lots of memory just to boot the machine that you don't need while running it; again you have problems to solve
<ogra> i use nbd, its needs to be set up first :)
<jdub> 404 man
<jdub> dapper- :)
<Keybuk> uh http://people.ubuntu.com/~scott/bootcharts/dapper-20051109-2.png
<tseng> jdub: dont worry
<tseng> jdub: http://shots.osdir.com/slideshows/slideshow.php?release=500&slide=22 < here is what dapper looks like
<ogra> Keybuk, looking at the cpu/disk diagrams.... 
<tseng> should hold you over for a bit
<ogra> Keybuk, .... you know that bootchart was not intended as painting tool ?
<Keybuk> ogra: hmm?
<ogra> your bootchart loks like you tried painting rohrschach pictures with it :)
<Keybuk> heh
<Keybuk> all breezy+dapper boots have that
<ogra> mine doesnt
<Keybuk> yours doesn't have readahead in it :p
<ogra> (not the ltsp one)
<Keybuk> really, what's your normal one look like?
<jdub> ah, that is what ubuntu looks like
<jdub> oh, i can see what they mean about the brown
<ogra> Keybuk, http://people.ubuntu.com/~ogra/dapper-20051111-1base.png
<ogra> i got it down to 1:04 by removing all the servers and down to 0:54 by removin readahead !
<Keybuk> damn, you have the modprobe from hell in there
<Keybuk> you're almost entirely in I/O-wait throughout your boot
<ogra> yup
<ogra> its not everytime there
<Keybuk> I/O-wait is bad
<Keybuk> it means your machine is constantly waiting for the drive to spin
<ogra> yes, but it doesnt occur every boot and i have no idea why 
<Keybuk> you want solid blue in the top graph, and solid-pink in the bottom one
<Keybuk> disk or IDE controller is too slow for your machine?
<ogra> its a 4200 rpm laptop drive :)
<Keybuk> you're only peaking at 20MB/s
<Keybuk> whoah, dude, that's WAAYYY underpowered for an AMD64
<ogra> yup
<Keybuk> no wonder it takes frickin' ages to boot
<ogra> a fresh hoary booted in 35-45 sec
<tseng> should i run it on a 10k rpm raid0 ?
<ogra> (*felt*)
<tseng> :P
<Keybuk> I'd suggest building some new readahead lists for the the whole sequence, and putting readahead right at the start
<Simira> ahrg! I'm drowning in "cheap software"-spam!
<Keybuk> that way your machine won't spend all of it's time going "ARE WE THERE YET?" to your disk
<ogra> then readahead will wait for the disk to spin up... where is the diff ?
<tseng> ogra: it will read it all at once
<Keybuk> readahead will do everything at once for the whole sequence
<ogra> oh, k
<tseng> instead of spinning up and down like crazy
<Keybuk> so you spend 10s reading everything you need into memory
<Keybuk> then the entire boot happens from memory
<Keybuk> rather than every, single, operation, needing, to, wait, for, the, disk
<ogra> ah k
<jdub> anyone seen an X series tablet in the flesh?
<thierry_> https://wiki.ubuntu.com/ seems down...
<tseng> thierry_: not really.
<thierry_> tseng : mmm yeah it works now... strange
<Znarl> It's slow, thanks to slashdot.
<HiddenWolf> wiki got slashdotted?
<Znarl> Yes
<HiddenWolf> LOL
<HiddenWolf> only over the nice dapper drake "nothing has changed yet" daily's ? :)
<HiddenWolf> People should get a life. ;)
<Znarl> Broke one of our cdimage machines too.  *grumbles*
<HiddenWolf> Znarl, wiki has been slow a lot the last few weeks. Is anything going on, or is it outgrowing itself?
<Znarl> HiddenWolf : I've not heard this complaint before... I'll take a look.
<HiddenWolf> Znarl, it's not terrible or anything, but perhaps worth a look.
<seb128> Keybuk: when installing bootchart I get "/boot/initrd.img-2.6.12-9-k7 was been altered.  Cannot update.", is that known?
<Keybuk> seb128: yeah, some people seem to get that, no idea what it means
<seb128> $ update-initramfs -v -u
<seb128> /boot/initrd.img-2.6.12-9-k7 was been altered.  Cannot update.
<Keybuk> I think it means that the initramfs was altered since update-initramfs was last run
<seb128> grumpf
<Keybuk> try just mkinitramfs -o /boot/initrd.img-2.6.12-9-k7
<Keybuk> or ...
<Keybuk> update-initramfs -t -u
<seb128> k, I used -t
<Keybuk> one of those will do it
<seb128> time to reboot
<janimo> why do debian update binary packages instead of source as ubuntu?
<janimo> s/update/upload/
<siretart> janimo: because thats the first barrier which hinders ppl uploading stuff which doesn't build at all
<janimo> hmm a good reason
<Burglaptop> janimo, I believe it is also because for some of the obscure archs, the only person who has it is the uploader
<Burglaptop> ergo they cannot upload source and get it built in a debian run buildd
<janimo> ah
<siretart> Burglaptop: then that arch would only have those package that developers uploads :P
<siretart> no, there are autobuilders for every debian release architecture
<Burglaptop> ok
<Burglaptop> even for things like m68k?
<siretart> for m68k, there is an army of autobuilders in order to keep up with unstable
<luis_> is anyone else seeing the latest gksudo hang regularly? (in dapper)
<Burglaptop> luis_, there is a report int he ubuntuforums about that
<Burglaptop> hmm http://www.gnome-look.org/content/show.php?content=31128
<luis_> the tango guys have some similar-looking mockups as well
<ogra> i wonder why they used kde to make gnome mockups :p
<Riddell> ogra: they have?
<luis_> that panel setup, at least, screams CDE :)
<lsuactiafner> rpc aint used on 5.10 but older system on the network needs it, so 5.10 aint backwards compatible with older system that require rpc for nfs
<lsuactiafner> and gcc doesnt cross compile 32bit code, so its also borked.
<neuralis> Treenaks, ping
<jdong> elmo: ping
<jdong> yep, guess he's busy :)
<kmr> is there a resource where maintainers discuss which upstream versions dapper will contain? Specifically, I'm concerned about which version of mysql dapper will contain.
<mdke> kmr, mailing list is a decent start
<kmr> mdke: ubuntu-devel, right?
<neuralis> kmr, it's not decided yet.
<mdke> kmr, yeah
<kmr> I figured that it is not decided, I'm just wondering if there was a typically spot. ubuntu-devel seems like an area of last resort
<neuralis> kmr, i meant mysql. adam will be making the 4.1 vs 5.0 decision sometime before christmas, pending heavy stress testing and community feedback.
<kmr> i appreciate for the specific information on mysql. in terms of community feedback (of which I have none to contribute at the moment), where do you imagine that will take place
<kmr> ubuntu doesn't use bts, right? So, there wouldn't be some sort of "wishlist" bug like "please consider version x.y.z for dapper" for discussions to take place
<mdke> kmr, yes, you can try that
<mdke> kmr, see it at http://bugzilla.ubuntu.com
<neuralis> kmr, end user version-wishes are less important in this case; we're after hardcore testing on complicated mysql installations. if those come back greenflagging 5.0, 5.0 it is. otherwise we'll fall back to 4.1.
<kmr> mdke: thanks. I heard ubuntu used bugzilla, but never saw the web site
<mdke> we are switching bts soon, but that is the place for now
<kmr> mdke: very good
<kmr> neuralis: that sounds very appropriate
<kmr> actually, I'm quite interested in the results of the hardcore testing. I'm deploying a server cluster for mysql, and I have the same question in my mind -- use 4.1 or 5.0.
<kmr> 5.0 does have some carrots for utf-8 encoding innodb tables which the application heavily uses
<kmr> but, 4.1 has been working great for use thus far on light development duty
<kmr> mdke: what will be the new bts system?
<neuralis> kmr: http://launchpad.net/malone
<kmr> thanks, I'm looking at malone now. I need to provide a bts for the new application
<neuralis> malone is not open source (yet), so you can't deploy it somewhere else, if that's what you mean.
<kmr> i see. also, it's strength seems to be tracking remote bts. probably bugzilla will be a better choice for a standalone project
<kmr> oh, I have another ubuntu-devel question...
<kmr> back when I was the debian maintainer of sbcl, I created a binary sbcl package for amd64 (to bootstrap the generation of future amd64 sbcl packages). I noticed that package is not in ubuntu. 
<kmr> how would I go about asking the project to take the _amd64.deb debian sbcl binary and putting it in ubuntu?
<neuralis> kmr: bugzilla is the 800lb. gorilla of bts packages. for smaller projects, look at Trac (integrates with vcs, provides wiki) and Eventum.
<kmr> appreciate the tip. yes, I've played with a toy installation of bugzilla. it does seem like overkill for a project with a handful of developers. I'll look at Trac - thanks!
<spstarr_home> trac == good
<kmr> vote noted, thanks!
<mdke> kmr, you could use malone if you like.
<kmr> mdke: thanks for the info. Likely, I'll prefer to run a local copy of the bts on the new cluster for the team
<kmr> bbiab
<mdke> fair enough
<spstarr_home> mdke: when is malone source going to be available?
<spstarr_home> I'd like to use that for other stuff
<mdke> i don't know. but I hope it will not be available in the near future
<spstarr_home> 'not'? :-(
<mdke> the whole point is to have everything in the same place
<spstarr_home> I'd like that to become the defactor big system replacing bugzillas everywhere
<mdke> but I'm not involved in development, so I'm not the best guide for you
<spstarr_home> defacto
<mdke> spstarr_home, me too
<spstarr_home> s/big/bug
<spstarr_home> :)
<kmr> mdke: i see your point. however, using open-source software everywhere, I want our bts data be be processed back a package where we have the ability to examine and modify the source
<kmr> s/back/by/
<mdke> kmr, fair enough
<kmr> mdke: as is your goal as well
<mdke> yeap
<jbailey> zyga_laptop: 'sp?
<zyga_laptop> jbailey: typo in the profiling package
<zyga_laptop> 'was been'
<zyga_laptop> jbailey: just grep for it
<jbailey> profiling package?
<jbailey> Like gprof?
<zyga_laptop> jbailey: nono
<zyga_laptop> jbailey: bootchart
<zyga_laptop> jbailey: anyway, someone said it was in your code
<zyga_laptop> jbailey: bootchart was unable to regenerate initramfs
<zyga_laptop> and displayed 'was been'
<jbailey> bootchart is thoroughly not my code.
<jbailey> =)
<zyga_laptop> jbailey: I know :)
<zyga_laptop> zyga_laptop /boot/initrd.img-2.6.12-9-k7 was been altered.  Cannot update.
<zyga_laptop> * Keybuk points at jbailey ... initramfs is his
#ubuntu-devel 2005-11-18
<jbailey> zyga_laptop: Right.  That's a kernel packaging problem.  Add -t to the command line in the meantime to fix that.
<zyga_laptop> jbailey: no no
<zyga_laptop> jbailey: I'm talking about bad grammar
<zyga_laptop> 'was been'? is that wabbit talk?
<kmr> comparing trac and eventum, it seems like trac will be more helpful as a bts for our interal development. The integration with subversion is a win for us.
<netdur> hey, is Matthew Paul Thomas here?
<crimsun> mpt is not online presently.
<netdur> how do I contact him?
<netdur> ubuntu-devel?
<netdur> I mean maillist
<neuralis> Treenaks, ping
<Simira> ahrgle...
* freeflying is away: Away at the moment
<Aegir> I gotta get me one of them sexeh Ubuntu stickers for my laptop... If the damn thing ever comes back from the repair shop...
<moquist> I'm new to packaging, and I've used dh_make and dpkg-buildpackage -rfakeroot on the game 'apricots'.  dpkg-buildpackage seems to build [almost?]  everything, and then it errs out.  http://paste.ubuntulinux.nl/d4452 shows the error I'm getting; I don't understand why fakeroot isn't taking care of the "Permission denied" problem.
<Amaranth> moquist: #ubuntu-motu is probably better for packaging help
<moquist> Amaranth: right.  thx.
<Amaranth> that's where the excellent masters of the universe hang out
<crimsun> the error's pretty simple; you used an absolute path
<crimsun> -ECHANNEL
<feugan3333> Hi all. Is there documentation on how apt works? I want to know exactly what happens when I specify the "-b" option to apt-get source package1.
<Amaranth> man apt-get
<Amaranth> -b just builds it the same way you could with dpkg-buildpackage
<feugan3333> Thanks Amaranth, so I need to look at dpkg's documentation?
<Amaranth> i guess
<Amaranth> if you're looking for some kind of architectural overview I don't think one exists.
<feugan3333> Amaranth: What I really want to do is build a package with debug information included. I don't think there is any way to do this with apt,dpkg,etc. I would just download the source from the packages site and then build it that way. But I'm having trouble getting this to work. So I'd like to see what was done to get the package to build on ubuntu.
<Amaranth> ah, well, that's easier
<crimsun> remove the call to dh_strip
<Amaranth> it's just an environment variable you set before you run apt-get -b source package
<Amaranth> i can't remember the variable though
<crimsun> should be NOSTRIP
<crimsun> DEB_BUILD_OPTIONS=nostrip,noopt,debug
<feugan3333> Thanks crimsun, Amaranth
<Treenaks> `/lastlog treenaks
<Treenaks> hm
<Treenaks> neuralis: pong
<Amaranth> sounds good
<Amaranth> err -ECHANNEL
<Treenaks> yay 7:12 on a Sunday morning ;)
<Amaranth> yay 12:14 on a sunday morning
<Treenaks> Amaranth: 12:14?! what kind of place are you in then?
<Amaranth> middle of the us
<Treenaks> oh wait, 0:14
<Treenaks> not 12:14 ;)
<feugan3333> Does here use anyone use dh_make?
<feugan3333> Err, Does anyone here use dh_make?
<zyga> feugan3333: probably
<pef> hello
<feugan3333> zyga: I think there is a bug in the script at line 405. Mine says "if ( -x '/usr/bin/bzip2' && -x '/usr/bin/gizp' )"
<zyga> feugan3333: looking
<zyga> feugan3333: re
<zyga> feugan3333: so what is the bug?
<feugan3333> zyga: what the hell is gizp? I think they mean gzip. And it is not located in /usr/bin. It's located in /bin
<zyga> feugan3333: ahh!
<zyga> I didn't notice the typo
<zyga> good catch!
<zyga> will you mail the maintainer?
<feugan3333> Neither did I, untill struggling for a few minutes
<zyga> and file a bug about it
<feugan3333> sure, do I need to create a patch?
<zyga> mark it as trivial
<zyga> feugan3333: you could, it's a one liner :)
<feugan3333> zyga: where do I post the bug report? :-)
<zyga> feugan3333: bugzilla.ubuntu.com or .debian.org
<feugan3333> thanks
<zyga> feugan3333: thanks for taking a look at it :)
<feugan3333> sure, it's nice to actually contribute :-)
<feugan3333> Seems like someone found it first: http://bugzilla.ubuntu.com/show_bug.cgi?id=17846
<feugan3333> but they don't seem to notice that gzip is not located in /usr/bin
<zyga> add a comment
<feugan3333> ok
<zyga> and attach a patch too
<feugan3333> zyga: How do I create a patch. Is a unified patch good enough? "diff -u oldfile newfile > mypatch"
<zyga> feugan3333: perfect
<zyga> diff -u is great
<smurf> elmo: Please get gnutls12 from Debian
<pef> elmo: please add my gpg key to keyring so I can upload to archive (gpgid: 601FA31D, launchpad id: loic)
<zyga> has anyone seen pitti/
<mdke> zyga, it is sunday
<highvoltage> sunday bloody sunday
<zyga> sunday is the day I get worried about monday's project
<zyga> anyone with little kernel knowledge around
<zyga> I've recompiled the standard ubuntu i386 kernel
<tseng> its much easier to ask your question and hope for an answer than keep asking about presence
<zyga> but after booting it panics with
<zyga> 'unable to mount root fs on unknown-block(0,0)
<zyga> and before that: cannot open root device hda1 or unknown block(0,0)
<zyga> what did I do wrong?
<mdke> they can probably help you in #ubuntu
<zyga> will try but I don't have high hopes
<mdke> well your hopes are higher there than off-topic in here tbh
<Seveas> #ubuntu-devel is not for support
<mdke> zyga, alternatively, try the support mailing lists or the forums
<HiddenWolf> zyga, either you don't have ide-support enabled, or it's something with lvm, would be my guess.
<tseng> HiddenWolf: more like he didnt build and load an initrd
<zyga> mdke: I'll check the forums
<zyga> I used make-kpgk
<zyga> okay, in #ubuntu
* luis_ is away: Away
<\sh> grmpf...wtf is this?
<Treenaks> this is IRC
<Treenaks> Welcome.
<\sh> infinity: ping 
<mdke> does anyone around know much about keybuk's bootchart package?
<mdke> i get an error when installing, and I wondered if it is problematic
* luis_ is back (gone 00:18:25)
<mdke> http://pastebin.com/427780
<\sh> damnit
<\sh> gajim orig.tar.gz in ubuntu is smaller then debians version...which means katie is bitching around...
<slomo_> \sh: not the first package this merge-round with this problem :/
<\sh> slomo_: sadly...it means I can forget about the merge and merge upstream changes and debian changes by hand..or I bring in gajim 0.9.0+cvs
<highvoltage> should i have gotten any kind of notification for the lpbugs i sent yesterday? i still can't see anythin on launchpad about it.
<slomo_> \sh: make a -Xubuntu1 with the merged changes... where's the problem?
<slomo_> \sh: it only means that we have to care for it for the remaining time of 0.8.2
<\sh> slomo_: our package is 0.8.2-0ubuntu1 debian is 0.8.2-1 and we will have 0.8.2-1ubuntu1
<slomo_> \sh: yes
<\sh> slomo_: and this is now the problem..because 0.8.2-1 orig.tar.gz is some bytes bigger then 0.8.2-0ubuntu1 
<slomo_> \sh: upload a 0.8.2-1ubuntu1 which uses our different tarball
<\sh> slomo_: for that I have to find out what is different between our tarball and the debian one...because we used the normal upstream tarball
<slomo_> \sh: yes... diff it ;) i guess debian took a tar.bz2 and repackaged it...
<slomo_> pitti: hi, do you have the time to look at a MainInclusionReport atm?
<\sh> slomo_: argl
<\sh> infinity: can u please have a look at http://people.ubuntu.com/~lamont/buildLogs/a/ardour/0.99-3ubuntu1/ardour_0.99-3ubuntu1_20051110-0202-i386-failed.gz because it has this little nasty scons bug again....thx :)
<Manny> hi
<Manny> I'm not sure whether to ask here or in #ubuntu-motu...I'm supposed to get Ubuntu play nicely with ThinkPads. It looks like most of the software is available already (kernel, xorg drivers for the special mouse device etc.). Whom do I have to contact to get the packages into ubuntu, and which packages are suitable? Is there an additional laptop-related driver package, or should this go into stock xorg/stock kernels?
<Manny> by stock I mean the stock ubuntu packages, not the stock tarball
<Manny> for instance, http://web.telia.com/~u89404340/patches/touchpad/2.6.11/ has a kernel patchset. Am I supposed to just file a bug report an lean back?
<lifeless> Manny: I suggest you file bugs for all of them
<lifeless> Manny: and then depending on the reaction you may need to do new packages, put patches in existing packages etc
<Manny> lifeless, thanks
<lifeless> Manny: also, if you think a patch to an existing package is appropriate, do that when you file the bug
<Manny> lifeless, new bugs through launchpad, right?
<lifeless> Manny: that way the person getting it can decide to just apply the patch :)
<Manny> lifeless, so I should try them out and compile them by hand first?
<lifeless> Manny: re launchpad for new bugs, I don't know if the transition happened yet.
<Manny> the problem with hardware-related patches is always that WFM doesn't mean works for all
<lifeless> Manny: I would file the bugs first. That way discussion starts now,.
<Manny> http://bugzilla.ubuntu.com/show_bug.cgi?id=19566 if any kernel bug triager is interested
<siretart> Manny: which packages are missing?
<Manny> siretart, I think none, xorg-driver-synaptics seems to be available :)
<siretart> Manny: it is.
<siretart> Manny: did you check which of these patches are actually missing in the ubuntu kernel?
<Manny> siretart, I grepped the debian changelog, and neither found synaptic nor [Tt] hink[Pp] ad nor TAP
<Manny> let me check...
<siretart> I remember there has been quite some work on getting alps support right
<Manny> hrm you seem to use a driver called cPad. http://web.telia.com/~u89404340/patches/touchpad/2.6.11/ has patches for alps stuff, though. The alps.c file is almost not touched with the current kernel diffs.
<Manny> (at least with patch-2.6.12-9.23)
<mdke> Manny, our head laptop guy is mjg59, you can try getting in touch with him too if you like.
<Manny> mjg59, ping
<mdke> Manny, you can also try the laptop testing mailing list, see http://lists.ubuntu.com/mailman/listinfo/laptop-testing-team
<mdke> he reads that, in case you don't catch him here
<Manny> mdke, thanks
<mdke> np
<mdke> i have a thinkpad myself
<Manny> mdke, he's also available on the GIMPnet, so I can bug him whenever I want :)
<mdke> sure
<neuralis> Treenaks, ping
<mdke> Manny, oh, one last place is #ubuntu-laptop
<siretart> lol: http://www.flickr.com/photos/mbp_/61725150/
<thierry_> how could I take a list of files and open all of them with gedit at once in a bash script?
<crimsun> -ECHANNEL
<crimsun> but you'd just pass them to gedit, like: gedit a b c d e f [...] 
<thierry_> ok and to count how many files I have in the list?
<mdke> i wonder if there is something wrong with the mailing list
<mdke> every SINGLE time I post to it and someone replies, I get two copies, one from the list and one from the sender
<daniels> err
<daniels> look at the To field
<daniels> it
<daniels> 'll have you and the list both there
<mdke> it has me in the to field, and the list in Cc
<mdke> it only happens on -devel
<bob2> someone should invent a header that specifies if you should get a CC or not on list-replies
<mdke> the mailing list shouldn't be sending me mail where I am in the to field, iirc
<mdke> for example, on the -doc list, people reply-to-all constantly, and I never get two copies
<mdke> only on -devel
<neuralis> mdke, that's a configurable mailman setting which most list admins do not turn on.
<mdke> yeah
<daniels> reply-to-list is crack
<mdke> daniels, it's not reply-to munging, it is just the list doesn't send the person mail if they are in the to field
<mdke> it's a pain getting two copies of everything
<daniels> there's a very common procmail recipe you can find that caches message-ids and throws away duplicates
<mdke> i don't use procmail
<mdke> neuralis, ah could it be first_strip_reply_to that you were referring to?
<neuralis> mdke, no, actually it looks i was misremembering. mailman has a "do not send members a copy of their own post" switch, and i thought i saw a "do not send members a copy of replies for which they're in the To/CC field", but i was wrong.
<mdke> well something must do it, because -devel is the only list I get two copies of peoples' mails
<neuralis> mdke: do the other lists have explicit reply-to headers set?
<mdke> neuralis, i'm not sure, i can post two headers, one from -doc and one from -devel
<mdke> http://pastebin.com/428302 and http://pastebin.com/428303
<neuralis> 428303 is not a list mail, it's a reply that was sent to you personally.
<mdke> ah
<neuralis> look at the headers for any *list* mail on -doc, and see if the Reply-To: <-doc list address> header is there.
<mdke> i guess because the list didn't send me a copy of that one, because I was in To:
<mdke> try 428308
<mdke> no hang on
<neuralis> yes, that's devel, and incidentally that's the mail i just sent you ;)
<mdke> 428310
<mdke> heh, coincidence
<neuralis> well, you have evolution sending a Reply-To: <you> header anyway, so if you didn't get a duplicate of the 428303 paste, it's a mailman setting i'm not familiar with.
<mdke> i'm poking around in mailman to see if I can find it
<kapputu> Hello everyone, I would like to spend my spare time on Ubuntu, I have no specific interests but initially I'd like to be told to do till I find my grounding 
<kapputu> *told what to do 
<kapputu> how should I go about it?
<neuralis> kapputu, you can help with documentation or bug triaging on the less technical side, and packaging on the more technical side. 
<mdke> kapputu, if you are interested in development, #ubuntu-motu. if documentation http://doc.ubuntu.com, if art http://art.ubuntu.com, etc
<neuralis> kapputu, #ubuntu-motu for packaging, #ubuntu-doc for documentation.
<kapputu> what's motu?
<mdke> actually, http://www.ubuntu.com/community/participate has a rather good list of stuff
<neuralis> kapputu, https://wiki.ubuntu.com/MOTU
<kapputu> I think I'd like to get started with documentation since that'd give me a better understanding of things
<mdke> kapputu, definitely check out doc.ubuntu.com then
<kapputu> thanks folks 
<kapputu> I'll do as you guys suggested 
<mdke> welcome to the community
<kapputu> thanks mdke 
<kapputu> I have been making use of open-source a lot and I think it's time I gave something back
<mdke> :)
<Burgundavia> neuralis, you still up?
<neuralis> Burgundavia, yeah, give me three minutes, busy atm
<Burgundavia> neuralis, np
<Burgundavia> neuralis, when you get a chance, can you take a look at https://wiki.ubuntu.com/BetterLaptopTesting
#ubuntu-devel 2005-11-19
<neuralis> Burgundavia, good start, i'll work on it when i get a chance
<neuralis> Burgundavia, do you have mdy's e-mail address?
<daniels> malcom.yates@canonical.com will almost certainly work
<neuralis> daniels, thanks
<mdke> his LP id is mdy
<mdke> dunno if he'll have a redir
<neuralis> yeah, checked, he doesnt have an address registered, and the wiki-page is empty
<neuralis> daniels: that's malcolm.yates, isn't it?
<daniels> yes
<daniels> everyone has first.last@c.c
<neuralis> daniels, yeah, you wrote malcom (no second 'l', was just checking).
<daniels> i've not seen mallcom anywhere
<neuralis> malcom vs malcolm.
<daniels> oh
<daniels> yeah
<Burgundavia> mdy@canonical.com also works
<Burgundavia> neuralis, I might also have someone to help you with the coding of the server stuff
<neuralis> Burgundavia, awesome, though i don't think it'll be necessary. it's looking to be one weekend of work.
<Burgundavia> neuralis, for both the server and laptop backends?
<Burgundavia> well, I guess would be a general hcl backend
<neuralis> Burgundavia, it's the exact same backend. there's a "hardware class" parameter, which lets you specify the input mask and data collected.
<Burgundavia> ok
<Burgundavia> I assume you have planned for different versions of ubuntu (both in de and in number)
<sivang> hey Burgundavia , neuralis 
<Burgundavia> salut sivang 
<neuralis> hey sivang 
<sivang> Burgundavia: how are you? how are thing?
<sivang> err, things even
<sivang> neuralis: Hi Ivan, what backend are you going to work on? :-)
<Burgundavia> sivang, good. Just planning for the next installfest here in Victoria and the beginnings of the Ubuntu in library catalogues idea
<neuralis> sivang, the hardware certification and community testing catalog
<neuralis> Burgundavia, ubuntu version is just a dropdown in the input mask. reports from multiple versions are aggregated the same way as reports from multiple people: through the "alternate profiles" functionality.
<Burgundavia> ah
<sivang> neuralis: oh cool, does it have a spec?
<Burgundavia> this going to be pygtk or webbased?
<neuralis> sivang, TestingServerHardware and CommunityServerHardwareTesting
<Burgundavia> and BetterLaptopTesting for that side
<neuralis> Burgundavia, the backend is web-based for obvious reasons (we're testing servers, remember?). i envision someone will want to create a pygtk frontend for the laptop stuff eventually, but it'll still be posting to the same web backend.
<Burgundavia> neuralis, my ideas exactly
<sivang> neuralis: sounds cool, are you going to interface with each vendor's test suits or are we talking more in collecting data from users?
<neuralis> sivang, it's in the spec - we're building our own test suite.
<neuralis> sivang, vendors can only produce hardware test suites, but we care about how well *ubuntu* works on the hardware.
<sivang> neuralis: Is the HCS and you doing that as a contribution to Ubuntu ?
<neuralis> sivang, yes.
<sivang> neuralis: wow, rock on dudes! when you reach the p5 pServers part, ping me up - I may be able to help. I've been working with the beasties for the last year or so :-)
<neuralis> sivang, sure thing, thanks.
<sivang> neuralis: I also think DLPAR and LPAR tests are needed, to see if Ubuntu operates nicely under this environments
<neuralis> p5 is not my area of expertise, but it's something we can certainly consider.
<sivang> neuralis: I just happen to have a personal fetish for the beast ;)
<neuralis> sivang, in that case, we'd be happy to have you help. that's dapper+1 material, however.
* neuralis is an HP ProLiant guy
<sivang> neuralis: ah I see, what platforms are going to be doing this for dapper?
<neuralis> sivang, all three that we support -- i was talking about DLPAR and LPAR having to wait until dapper+1, not powerpc.
<sivang> neuralis: the ProLiants are intel based?
<neuralis> sivang, not all. xeons and opterons, depending on specific models.
<sivang> neuralis: and I take it the HCS also has enough ppc's ? :)
<neuralis> sivang, the certification process happens on hardware that vendors send us.
<sivang> neuralis: ah
<sivang> anyway, I'm way out of my timezone sleep time :) Laterz people, good night in the meanwhile.
<sivang> neuralis: thanks for the discussion
<neuralis> sivang, sure thing. g'night
<mdke> does anyone know if elmo managed to get planet synched with jdub's archive yet?
<psusi> is there a way to enable debug messages for a specific kernel driver?  I see calls to printk that specify a debug level and driver name in the source, so I assume there is a way to turn those on
<crimsun> generally yes. If it's modular, check via modinfo.
<crimsun> otherwise you'll need to pass it as an option to the kernel command line
<psusi> is there something like a file in /proc I can write to to turn on the printks in that module?
<zul> not really it depends on the module
<psusi> hrm... how so?  the module is making calls to printk... when it calls printk it specifies a debug level and the name of the calling module
<psusi> so it looks like printk has some logic you can tune to filter messages on a per driver and level basis
<crimsun> like chuck mentioned, it depends on the module
<crimsun> for instance, ipw2200 has a 'debug' parameter
<psusi> module sata_raid has no parameters according to modinfo -p
<psusi> sata_via rather
* psusi reads printk's source
* psusi pokes SEJeff 
* SEJeff rubs eye
<SEJeff> psusi: hey
<psusi> SEJeff, hey... how's it going?  do you happen to know how to enable all the nice debug printk's from a given module?  the module seems to pass printk a debug level and it's module name, so it looks like the idea is that printk somewhere can be told which ones to show and which ones to drop
<SEJeff> psusi: use modinfo to see if the module has a debug param
* psusi is trying to figure out why the sata_via driver bitches after suspend/resume
<psusi> it doesn't... but I can see in the source it is calling printk, but I don't see those messages
<SEJeff> psusi: Do you have xconsole open?
<SEJeff> and do you look at dmesg?
<daniels> echo 9 > /proc/sys/debug
<psusi> well, when I'm interested in seeing the messages, it's at the console during suspend/resume... also checked dmesg and the syslog
<SEJeff> /proc/sys/debug is a directory
<SEJeff> Just /var/log/messages?
<SEJeff> Or anything else
<psusi> printk(KERN_INFO DRV_NAME "(%s): routed to hard irq line %d\n"
<SEJeff> psusi, /var/log/debug maybe?
<psusi> see, it gives it's name... so I would think you could filter on a per module basis
<daniels> er, make that echo 9 > /proc/sys/kernel/printk
<psusi> hrm... I'll try that
<psusi> ok... going single user then suspending... bbiab
<Burgundavia> for a good laugh --> http://www.ubuntuforums.org/showthread.php?t=89926
<psusi> the acpi scripts make calls to vbetool to save/restore the video state, only the lines to save it are commented out, and I can't find this vbetool on my system or in synaptic... anyone know where it is and why it was commented out?
<bob2> ?
<bob2> vbetool is the package name, too
<psusi> searching for vbetool comes up with nothing
<bob2> your sources.list is broken, packages.ubuntu.com/vbetool
<psusi> ohh, it only exists for i386, strange
<psusi> I'm running amd64
<bob2> it runs real-mode code, iirc
<psusi> why would that preclude amd64?
<psusi> the processor supports real mode
<psusi> or rather, v86 mode, which is where that would be run
<tkup> has anyone wrote code to deal with slowness of programs when coming back from suspend modes?
<psusi> what do you mean?
<tkup> well, when I turn on my laptop from hibernate mode, programs take a while to launch (reponse/interactivity). have you noticed anything?
<bob2> everything is in swap
<tkup> bob2, that's right. it's all on disk
<psusi> that's because when you suspend, the filesystem cache is emptied... so everything you start up when you resume has to be read from disk fresh, just like after a clean boot
<bob2> if you really care, swsusp2 restores it
* psusi is still trying to figure out why suspend/hibernating with the acpi scripts borks his system, but echoing to /sys/power/state doesn't
<tkup> psusi, my T30 still freezes/locks every once in a while. unfortunately, the ubuntu bug hasn't been resolved
<psusi> tkup, when I suspend/hibernate with the scripts, when the system comes back up, the disk driver complains about a register not being in the state it wants, and errors on the first IO, then usually seems to reset and recover
<psusi> though the first sector that the IO error happens in, reiserfs seems to simply accept as unreadable and fail all IO to files that it needs that sector to find
<psusi> rather than simply retry it... very annoying
<psusi> but if I just echo mem or disk to /sys/power/state, it's fine
<psusi> very odd
<tkup> I guess I was talking about another problem, not related to yours...
<Burgundavia> psusi, the best person to talk to about suspend/hibernate issues is mjg59 on #ubuntu-laptop
<psusi> hrm... interesting
<tkup> anyway, I wrote this program that makes your program as interactive as if you haven't really suspended/hibernated your laptop
<tkup> you can checkit out at http://freshmeat.net/projects/shra
<tkup> I guess I'll post it on ubuntu-laptop as well.
<psusi> tkup, you probably would be better off with swsusp2
<psusi> it saves/reloads more data so the system is more responsive after resume... though it takes longer to actually suspend/resume of course
<tkup> psusi, never heard about swsup2..I'll read about it now
<psusi> ther'es a howto posted on the ubuntu forums
<tkup> psusi, I just read about swsusp2 and it seems like it doesn't solve the problem I talked about earlier.
<tkup> as far as I read, it only compresses the ram image to disk but it fails to solve the interactivity problem
<psusi> tkup, it also allows you to save more data to disk instead of throwing it out
<psusi> which increases the responsiveness after resuming
* psusi wonders WTF this undocumented /usr/sbin/PowerManager is and how it is messing with the acpi scripts
<tkup> psusi, does swsusp really throw data away on suspend. I thought that it only does that when disk_space < ram_image_size
<psusi> tkup, as far as I could tell, swsusp allways throws out as much as it can... swsusp2 uses ram_image_size and other settings to decide how much it should keep or throw out
<lamont>   ubuntu-desktop: Depends: rss-glx but it is not going to be installed
<lamont> ubuntu-live is _SO_ close
<highvoltage> hi marilize. got any breezy cd's?
<marilize> highvoltage: ? you want to order?
<highvoltage> marilize: i'd like to borrow some of your copies, i work at 12 plein :)
<marilize> highvoltage: heh, i'm just waiting for a load to be released by customs... should be here about tomorrow or wednesday
<highvolt1ge> sorry, battery ran out ther.
<Diablo-D3> yargh
<Diablo-D3> yesterday I asked about gimp printing
<Diablo-D3> and I forgot the answer
<Diablo-D3> which package is screwing up printing in gimp on dapper?
<viviersf> Kamion : ping
<mdke> doko, you deleted the page ItalianRedirect on the wiki. 100 other pages redirect directly to it. Please don't do that! if deleting pages on the wiki, please ensure they are not linked to by any page by doing a full search on their name (click the page title) before you delete.
<sivang> Good morning
<Diablo-D3> is anyone having problems with kdesktop atm?
<viviersf> Chmj : ping 
<viviersf> pitti, you have an idea where i can get the list of modules loaded by the debian installer ?
<viviersf> *kernel modules
<pitti> viviersf: you might change to vc2 and use 'lsmod'
<viviersf> bleh
<Diablo-D3> hrm
<Diablo-D3> you know what would be a cool feature?
<Diablo-D3> being able to tab complete apt-get install package=
<viviersf> pitti, i dont mind the modules loaded by hotplug 
<viviersf> cos the deb installer loads stuff like ide_generic etc
<viviersf> im working on booting the impi cd
<viviersf> :/
<pitti> viviersf: hm, can you please ask Kamion about this?
<viviersf> he is never here ;/
<viviersf> but its cool
<sivang> pitti: morning :)
<neuralis> Diablo-D3, your shell can likely do that. zsh certainly can.
<pitti> Hi sivang 
<Diablo-D3> neuralis: it can, sure, it just doesnt. ;)
<Diablo-D3> neuralis: I can tab complete the package name, but not the version
<neuralis> Diablo-D3, there's something for you to hack on ;)
<Diablo-D3> neuralis: no
* Diablo-D3 is not taking on any more projects atm
<Simira> marilize: Shipit wants me to pay taxes for the Breezy-cd's :(
<Diablo-D3> Simira: heh?
<Diablo-D3> Simira: what country you in?
<Simira> uhm, not Shipit... the Norwegian customs, of course...
<Diablo-D3> theres a letter for that
<marilize> simira: not us, customs, you can send them the customs letter on the website
<Diablo-D3> yeah, what marilize said
<Diablo-D3> I wish countries would quit doing that
<Diablo-D3> they're only making themselves look stupid.
<Diablo-D3> anyhow, kdesktop pisses me off
<Diablo-D3> its crashing somewhere in a function in lib from libarts1c2
<Diablo-D3> downgrading libarts1c2 to the one in breezy doesnt fix it
<Kamion> viviersf: hi?
<viviersf> ah you here
<Kamion> viviersf: of course I wasn't here the last few times you asked, I was kinda busy travelling and recovering from jetlag
<viviersf> :)
<viviersf> its kewl
<Kamion> viviersf: apt-get source hw-detect
<viviersf> kk
<viviersf> im checking quick
<Simira> marilize: the guy on the customs office were really bad, and claimed there's no way to get around it. I spoke to another guy on the post office's outland section though, and he was nice and told me to bring the letter so they could register an exception case. :)
<marilize> simira: yes, this is a problem for us, the best i can do is to email you a personalized letter, but unfortunately after that, not much we can do
<Simira> marilize: I'll give you feedback on it tomorrow, after fetching the cd's (hopefully). I'm also going to check out further possibilities to avoid those taxes-
<marilize> simira: yes, let me know, thanx
* Mithrandir looks at the init script for fetchmail and blinks.  Heavily.
<Lathiat> Mithrandir: ??
<Mithrandir> if ! id $USER >/dev/null 2>&1; then
<Mithrandir> 	if [ "$USER" = "fetchmail" ] ; then
<Mithrandir> 		adduser --system --ingroup nogroup --home [...] 
<Mithrandir> adduser.  in an init script.
<Treenaks> OMGWTF?
* Treenaks dies
<neuralis> Treenaks, ping
<mvo> infinity: can you please kick the gksu build?
<Treenaks> neuralis: ?
<Lathiat> heh
<Mithrandir> neuralis: pinging somebody who have said something less than a minute ago is kinda useless. :-P
<pitti> mvo: infinity is not here until tomorrowish
<pitti> mvo: I can kick it for you if you want
<neuralis> Mithrandir, gives them the ability to say "can't talk, busy", though.
<mvo> pitti: that would be great, please to it
<neuralis> Treenaks, i'm writing an article on ubz for a local it professionals' magazine, getting us some media love. is there any chance you'd be willing to relicence some of your photos as attribution-SA without the NC clause?
<neuralis> my camera, as it were, died shortly after i got to montreal.
<Treenaks> neuralis: pm :)
<Simira> Mithrandir: aren't you in interviews right now?
<Mithrandir> Simira: I thought it was at 1000, but it's at 1100 instead.
<pitti> mvo: hmm, sorry, no
<Mithrandir> Simira: Amund and I've made some questions and stuff, though, so good I was a bit early in.
<pitti> mvo: that has to wait for lamont, I'm afraid
<Simira> Mithrandir: are you going to ask them about shoe sizes?
<Mithrandir> Simira: no, that's just when interviewing people for the student society.
<mvo> pitti: ok, thanks 
<sivang> Mithrandir: what are you interviewing people for? :)
<mvo> lamont-away: could you please kick the gksu build?
<zyga> morning
<zyga> mvo: how is .deb click-to-install going?
<mvo> zyga: good, I'm waiting for gksu to be build before I can upload a first version to universe
<zyga> mvo: is it python based?
<mvo> zyga: yes, python-{gtk,apt}
<zyga> :-)
<zyga> python is a nice tool indeed :>
<Mithrandir> sivang: just helping out a bit at hardware.no, we're looking for a programmer.
<seb128> elmo: hi.gazpacho aalib pyorbit pxlib easytag (why is this one needed, that's -build2 version?) syncs please
<pitti> Kamion: can you do syncs until elmo is back?
<Kamion> pitti: theoretically yes, but there's some weirdness with queue/launchpad/ that I don't entirely know how to drive
<seb128> lamont-away: could you give a retry to build libwpd ?
<Kamion> pitti: I expect elmo to be back RSN anyway
<pitti> Kamion: ok, thanks
<zyga> carlos: hi
<zyga> carlos: when is the next language pack sheduled?
<pitti> zyga, carlos: hi
<zyga> hey pitti :)
<carlos> zyga, soon, but I don't know it exactly
<zyga> carlos: will it include 'X-Ubuntu-Gettex-Domian' ?
<seb128> hey carlos
<seb128> carlos: are you going to clean all these xxx-deprecated po files this week? :)
<carlos> zyga, I don't think so
<carlos> that's a dapper feature
<zyga> carlos: are you going to release the scripts that put the domain name?
<zyga> I'd like to test this on breezy, dapper scared me untill release
<viviersf> Kamion, how do i run just hw-detect from the cd ?
<viviersf> not using the debian installer
<Kamion> viviersf: you don't unless you have the rest of the d-i infrastructure available, sorry
<Kamion> hw-detect is a part of d-i; it's not designed for external use
<viviersf> the d-i installer is present
<viviersf> i just dont use it
<Kamion> that's so horrible
<viviersf> :/
<viviersf> well the d-i takes long
<Kamion> well, you could try running it with DEBIAN_FRONTEND=none
<Kamion> (in the environment)
<viviersf> kk lemme check
<Kamion> I can't guarantee that won't break badly though
<Kamion> you probably need to have loaded debconf templates first (see rootskel)
<Diablo-D3> hey guys
<Diablo-D3> we /are/ getting rid of bugzilla, right?
<Kamion> Diablo-D3: yes
<Diablo-D3> good.
<viviersf> Kamion, could you explain how the hw-detect scanning works ?
<Diablo-D3> blah, has no one filed a bug on kdelibs before?
<viviersf> or it just to much hassle ?
<Kamion> viviersf: which scanning?
<dholbach> U
<dholbach> hellas
<viviersf> ok udev / hotplug hw detection works fine
<viviersf> then there loads modules such as ide_generic and ide_cd etc
<viviersf> though the d-i
<carlos> zyga, it will be an intltool patch
<viviersf> and i just want to find out how the d-i knows those drivers need to be installed
<carlos> zyga, so you will have it available, yes
<Kamion> honestly, it's going to be quicker for you to read through the hw-detect shell script - it's really just a load of manual actions
<mvo> elmo: please sync gmp from debian
<viviersf> kk Kamion 
<Kamion> ide-generic and ide-cd are just always loaded
<Kamion> (if available)
<viviersf> yeah
<Kamion> ideally all that stuff would either be removed or move to udev
<viviersf> and some scsi stuff 
<Kamion> the SCSI stuff is conditional; search for the module names
<Diablo-D3> https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/4435
<chmj> elmo: iptraf sync please, ubuntu override ok 
<carlos> seb128, no, this week will still be there, but will try to have the patch ready for next production update next Tuesday (next week)
<seb128> k, thanks
<chmj> elmo: bluez-hcidump sync please, ubuntu override ok 
<Mithrandir> Kamion: what's the reason for a lot of non-latin1 locales as being listed as "type 1" in localechooser?  (type 1 is "ok to use in latin1-only environment")
<Diablo-D3> ahh here comes the fun
<Diablo-D3> https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/4439
<Kamion> Mithrandir: haven't looked at that much yet, you'd probably have to ask bubulle
<Mithrandir> Kamion: 'k, thanks.
* ..[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
<Kamion> (topicdiff: remove dapper CD links, which are a bit broken anyway)
<Diablo-D3> wheres daniels
<Diablo-D3> hrm, guess he doesnt hang out in here anymore
<slomo> lamont-away, infinity: please give-back gtksourceview-sharp, gtksourceview-sharp2 and seahorse
<slomo> elmo: please sync gmime2.1, ubuntu changes can be dropped
<tepsipakki> kamion: it seems that d-i supports preseeding lvm-config, but how to enable that? Docs aren't updated
<Kamion> tepsipakki: I was not aware that that was supported
<Kamion> (not sanely, anyway)
<tepsipakki> i'm not sure it is..
<tepsipakki> there's partman-auto-lvm
<Kamion> that doesn't support preseeding usefully; there have been no partman recipe format extensions for LVM as far as I know
<tepsipakki> ok
<slomo> elmo: please sync libextractor from debian/unstable... ubuntu changes can be dropped
* kbrooks pokes everyone
<kbrooks> Attention please? Is a Ubuntu developer here?
* pitti points kbrooks to the topic
<pitti> kbrooks: this channel is full of them
<kbrooks> Well.
* kbrooks thinks hard 
<kbrooks> okay. How do I get this addition of a init script for Subversion into breezy + 1 ?
<Kamion> file a bug
<kbrooks> OK
<Kamion> if it makes sense to do so, you could also file the bug in Debian and we'll pick it up
<kbrooks> Well, I'd have to check
<poningru> question will xorg 7.0 be in backports? or is that too much work?
<seb128> poningru: is there any interest to start backporting such stuff? you can as well use the new distro
<kbrooks> I want to be a Ubuntu developer. ;)
<dholbach> kbrooks: #ubuntu-motu would be a good start for that
<dholbach> :)
<dholbach> hi BenC 
<kbrooks> K
<kbrooks> https://launchpad.net/people/cmpfixer/+filebug # hmmm
<codepoet> seems you guys will be reading my bug reports on the ubuntu-devel mailing list haha
<viviersf> hmmf
<viviersf> i just cant get ahead
<Kamion> pitti: could you check MainInclusionReportGlew (I left the security section blank), please? I need it either approved and promoted, or declined and rss-glx modified to match, in order to get ubuntu-desktop installable
<pitti_> Kamion: yes, I can take a look at it
<Kamion> thanks
<DevinT> anybody ever talk to Mark Shuttleworth?
<zul> couple of times
<HiddenWolf> DevinT, sure, he's around, but it's a busy guy.
<mvo> Kamion: aptitude needs a "libcppunit-dev" (unit-test framework) to build in the new 0.4.0 version. I assume I need to write a main-inclusion report for it? 
* bob2 even met him once!
<DevinT> isn't he worth half a billion dollars?
<chmj> O.o
<HiddenWolf> DevinT, just check fortune. ;)
<dholbach> mvo: i should think so
<\sh> DevinT: why is this important?
<Kamion> mvo: yes
<seb128> pitti: are you taking care of this gtkmathview main promotion or should I do it so we get abiword again?
<pitti> seb128: hrmpftime
<pitti> seb128: after I finished my current thingie, I'll look at Kamion's thingie
<pitti> seb128: if you want to speed it up, feel free to create a wiki page and do the bug research already :)
<seb128> pitti: same for me, but every daily build page has a good list of abiword and I know than some people use it
<seb128> pitti: k, will do
<BenC> dholbah: hey
<mvo> pitti: let me know if I can (further) help with cppunit and it's main inclusion
<pitti> Kamion: glew looks fine to me; do you want to promote it right away?
<pitti> Kamion: if so, I directly put it into 'approved and promoted' in the queue
<Kamion> pitti: promoted, thanks
<pitti> Kamion: yay, transitional postgresql package waits in anastacia for demotion
<pitti> Kamion: can you demote it right away, so that we catch new packages which b-dep on postgresql-dev?
<Kamion> pitti: done
<pitti> merci
<Kamion> de rien
<Nafallo> BenC: how broken could the new kernel be? should it be able to boot? :-)
<zul> hmmm...wha?
* Nafallo just read the changelog NOTE ;-)
<Kamion> Nafallo: the binaries won't reach the archive for a while, until new udev is available
<Nafallo> oh :-(
<Kamion> well, at least they won't become the default until new udev is available
<Kamion> because you need new udev in order to boot
<Nafallo> lol. that means the new kernel won't boot then ;-)
* Nafallo keeps away from those sources
<pitti> mvo: mmmmm, C++ unit testing - how could  I say 'no'? :-)
<bob2> hahaha
<HiddenWolf> Kamion, any eta on that new udev?
<mvo> pitti: heh :) thanks
<marga> mako_: ping?
<BenC> Nafallo: it boots for me on my laptop and p4 system
<BenC> Nafallo: but the rt2500pci driver is broken for my p4
<Kamion> HiddenWolf: it's nothing to do with me; no idea
<BenC> ran fine the whole week of ubz on my laptop though (sempron with airo wireless)
<pitti> HiddenWolf: last week Scott told me that he had it ready more or less, just waiting for new kernel
<HiddenWolf> pitti, let the breakage begin. ;)
<pitti> HiddenWolf: I look forward to the new hotplug system *so much*
<Kamion> fabbione: is the sparc buildd alive at all? I'd like to fix any debian-installer issues it has?
<Kamion> s/\?$/./
<BenC> Kamion: new kernel boots fine without new udev, it's just old kernels wont boot fine with new udev :)
<HiddenWolf> pitti, fast, shiny, and easy too boot? ;)
<BenC> Hidden: basically he's ripping out all the bad parts of udev
<BenC> err, bad parts of hotplug
<Kamion> BenC: oh, it does? ok
<Kamion> will it boot all the way up to a normal full-functioning Ubuntu desktop, or just boot to a shell? :)
<BenC> boots to desktop
<Kamion> cool
<Kamion> well, that's much better than I thought
<BenC> on my laptop, everything worked fine, except that my cdrom didn't get mounted automaitically
<BenC> but then, sound and accel video didn't work on my laptop to start with, so I can't tell if there are any regressions there :)
<BenC> but hotplug pulled in all the modules that should have been there
<pitti> seb128: is there already a wiki page? otherwise I do it now
<slomo> pitti: did you already request a openssl sync? i'm currently waiting for it ;)
<pitti> slomo: yes, I did
<slomo> ok, so let's wait :)
<pitti> slomo: I did the tests last week and mailed elmo
<slomo> pitti: is a rebuild for everything depending on it needed?
<seb128> pitti: I'm doing it
<pitti> slomo: yes
<seb128> pitti: I've the wiki editor open
<pitti> slomo: infinity wanted to do this wholesale with a script
<Nafallo> hmm, looks like I will try the new kernel anyway then :-P
<slomo> Nafallo: ?
<Nafallo> slomo: you should get yourself a proxy with backlog functionality ;-)
<pitti> seb128: security and packaging of gtkmathview look fine to me
<slomo> Nafallo: tell me :P there's a new kernel but why do you want to try it _anyway_?
<Nafallo> slomo: there is a big NOTE in the changelog ;-)
<seb128> pitti: https://wiki.ubuntu.com/MainInclusionReportGtkmathview
<slomo> Nafallo: oh well... i need 2.6.15 anyway :P
<seb128> pitti: cool
<pitti> seb128: thanks, I process it right away
<Nafallo> slomo: and it seems it might have booted on one system :-)
<seb128> pitti: thank *you* :)
<Nafallo> pitti: could you please add MainInclusionReportLogcheck to your internal queue? :-)
<slomo> Nafallo: hm, i hope ppc works... that's the one i need ;)
<slomo> pitti: can you please add MainInclusionReportXSP to your queue too? ;)
<Nafallo> slomo: gl ;-)
<desrt> pitti; word on the street (and in my inbox) is that g-p-m won't accomidate our requests.  start writing code :)
* desrt overruns pitti's queue :)
<Nafallo> hehe
<pitti> Hi desrt 
<desrt> g'morn.
<pitti> desrt: in terms of UI or architecture?
<desrt> architecture... i didn't even touch on UI
<seb128> you will make dholbach cry
<pitti> desrt: given that upstream at least moves into our direction UI-wise, it does not seem too hard to let the daemon run as a system process, or is it?
<pitti> desrt: s/given/if/
<desrt> daniel is already crying.  he wants his christmas.  who can blame the boy?
<seb128> ;)
<seb128> not me!
* dholbach takes holidays until christmas
<desrt> pitti; i'd guess it is.
<desrt> :)
<desrt> pitti; we're not only modifying it to not run as a user and not depend on gnome at all and not do all of the stuff it does in the session....
<desrt> we have to modify how it performs its actions
<desrt> due to your hal fascism :)
* pitti thinks that writing a shallow UI around pmi is easier
<highvoltage> oooh. hal fascism.
<desrt> pitti; i pretty much agree
<desrt> pitti; and i've done some of it already
<desrt> does ubuntu have cvs/svn/whatever or am i expected to use this baz business?
<pitti> desrt: given that mjg59 is on TB now, you have a fair chance to overrule me in terms of hal :)
<dholbach> desrt: bzr rather :)
<desrt> pitti; but i don't want to.
<mjg59> Nngh.
<desrt> uh oh
<mjg59> I *still* haven't heard a good argument why fucking about with pmi stuff is supposed to be better than adopting the solution that upstream is likely to go with
<mjg59> Especially since it's significantly less functional - we need a session daemon in any case
<mjg59> As far as I can tell, the only issue is that hal will happily trigger a suspend no matter who asks it to
<desrt> security problems, lack of working with [kx] ubuntu, lack of working at the login screen
<pitti> mjg59: IMHO letting a wide open daemon like hal run as root and perform all sorts of system wide actions is wrong
<mjg59> desrt: Other than the first, these are all trivially solvable
<pitti> mjg59: it would become the centralized point of failure/attack
<desrt> (this might just be my perception) it doesn't work half the time
<mjg59> If there are bugs, we fix the bugs
<desrt> right
<mjg59> But the basic problem here is that hal is providing functionality
<desrt> anyway.  suggest a fix for the security issues?
<mjg59> And hal is running as root
<mjg59> This is a problem that's only going to grow
<pitti> mjg59: it's not
<desrt> pitti; upstream disagrees
<mjg59> pitti: To which bit?
<pitti> hal       6696  0.0  0.3  17064  3972 ?        Ss   11:38   0:00 /usr/sbin/hald
<desrt> the hal-as-root debate is heating up
<pitti> mjg59: hal has never run as root in Ubuntu
<mjg59> Hal is going to end up providing functionality that requires it to run as root
<pitti> mjg59: no
<desrt> it does some weird shit like mounting filesystems for you now (for the pmount-impaired?)
<mjg59> Or, at the very least, spawning helper programs that do
<pitti> mjg59: hal already has functionality to call separate binaries as callouts
<mjg59> There's no other way for it to provide the functionality that people want it to do
<mjg59> pitti: Ok. Replace "hal runs as root" with "hal runs stuff as root"
<pitti> mjg59: providing suid root helper binaries with a small codenbase and a narrow interface is fine for me
<Diablo-D3> why is hal as root shit bad?
<mjg59> That's not an issue
<mjg59> Diablo-D3: Because it's a large code base
<Diablo-D3> ahh.
<mjg59> (So is X, but still)
<desrt> Diablo-D3; and because it has an awful lot of bugs in it
<pitti> Diablo-D3: because it had a hell of a lot of buffer overflows in the past
<Diablo-D3> so why not, say, give it a kernel module to do the fun stuff?
<pitti> Diablo-D3: and the world can communicate to it
<mjg59> The fundamental issue is that hal needs some form of authentication
<pitti> mjg59: I think auth can be provided through dbus
<Diablo-D3> authentication =/
<pitti> mjg59: at least as long as we can define permissions in terms of users/groups
<desrt> mjg59; no.  there really are two issues
<mjg59> Arbitrary applications run by arbitrary users should not be able to request that hal suspend the system, or eject my CD, or whatever
* pitti agrees
<desrt> mjg59; and one of them is that the code in hal is -not- trustworthy yet
<desrt> mjg59; the other is the auth issue
<mjg59> Users at the console should be able to do all of these things
<desrt> right.  we need a "am currently in control of the console" auth system
<mjg59> Which is a basically solvable problem
<desrt> and it needs to deal with userswitching
<mjg59> Now, it's a solvable problem that may need some kernel support...
<desrt> surely there's some ioctl on /dev/tty or something that can tell you what the current console is?
<pitti> (like removing CAP_SYS_PTRACE from users, and similar stuff)
<desrt> then check the system log
<desrt> pitti; ??
<mjg59> desrt: Yeah, utmp is supposed to be trustworthy
<desrt> desrt    :0       -                16Oct05 ?xdm?  29:08m 19.59s x-session-manag
<pitti> desrt: when processes can ptrace other processes, or inject into their ptys, telling apart console from remote logins does not make much sense
<desrt> it doesn't say "tty7" >:|
<mjg59> desrt: No, but that line is written by gdm
<mjg59> We can fix that
<desrt> pitti; users can only trace their own processes though
<pitti> desrt: right
<desrt> pitti; which means that in order to trick us they'd need to be in control of the console anyway
<mjg59> desrt: Anyway, yeah - you can check what the foreground console is
<pitti> desrt: I'm not talking about telling apart different uids, but telling apart processes which "own" a console, and processes which not
<mjg59> See fgconsole
<desrt> mjg59; ah.  nice.
<desrt> Couldnt get a file descriptor referring to the console
<desrt> pfah
<desrt> need root?
<mjg59> desrt: Needs root
<desrt> i guess everything does these days....
<mjg59> If you're in X, you don't own the tty - root does
<mjg59> Works as a user at the console
<desrt> 7!
<Diablo-D3> I hate how X works
<desrt> ya.  X is -vile-
<Diablo-D3> it needs to get rid of the fucking 2D driver bullshit
<Diablo-D3> that shit belongs in the kernel
<desrt> we need a single X server with multi-user support
<mjg59> Diablo-D3: Why?
<Diablo-D3> mjg59: because framebuffers belong in the kernel.
<mjg59> The only thing that needs to be in the kernel is resource allocation and locking
<mjg59> The rest can trivially be done in userspace
<desrt> Diablo-D3; what you're discussing has some seriously negative performance implications
<Diablo-D3> desrt: not true.
<mjg59> And is, in fact, the model that X is moving towards
<desrt> Diablo-D3; a syscall for every single primative graphics operation?
<Diablo-D3> desrt: I didn't say that.
<desrt> Diablo-D3; don't kid yourself into thinking that 2d videocards are framebuffers
<Diablo-D3> desrt: I didn't say that either
<desrt> ...
<Diablo-D3> desrt: thats like saying I need a syscall to upload every triangle in DRI.
<desrt> i'm confused how you'd expect this to work
<mjg59> Diablo-D3: The only way you get acceleration out of the framebuffer drivers is to do ioctls
<Diablo-D3> what we need is sort of a DRI for 2D =/
<mjg59> DRI works fine for 2D
<Diablo-D3> mjg59: not in the way I was thinking.
<mjg59> There's just no 2D drivers that use it
<Diablo-D3> I mean, sure, exposing the gpu to do 2D work is quite fun
<mjg59> pitti: Ok. So, basically, for certain operations hal should check that the user who requested that operation is at the console
<desrt> mjg59; feel like convincing dbus upstream to integrate a 'console user' policy?
<Diablo-D3> but thats not what I was thinking
<pitti> mjg59: I'm not yet convinced that this can be done robustly
<desrt> mjg59; hal defers the authentication problem entirely to dbus
<mjg59> pitti: Why not?
<pitti> mjg59: but for the sake of argument, let's say hal can check that
<mjg59> desrt: Sure
<pitti> mjg59: as I said, the current kernel/userspace allows processes to ptrace or tty-control other processes of the same uid
<mjg59> pitti: Why's that a problem? If the user has console access, then...
<Diablo-D3> why would you need an ioctl, though?
<pitti> mjg59: so grouping an user's processes into 'has console', and 'is remote' doesn't work ATM
<desrt> pitti; no... we don't group processes
<desrt> pitti; we do the entire user
<Diablo-D3> why can't you let the userspace encode instructions or whatever (like how the userland half of dri drivers do it)
<pitti> mjg59: I'd rather assign a group membership to users who should be able to control power state
<desrt> pitti; if desrt is logged in at the console than any of my processes have access
<Diablo-D3> speaking of which
<desrt> *then
<Diablo-D3> X needs to quit 'owning' the dri stuff
<desrt> pitti; that's an awful idea
<desrt> sorry :)
<mjg59> pitti: All users at the console should be allowed to control power state in many cases
<Diablo-D3> I mean, in the way that the dri userland stuff 'comes with X'
<pitti> mjg59: I agree
<desrt> oh wait.  you mean globally assign group access
<pitti> mjg59: since they have hardware access anyway
<jsgotangco> hello
<Diablo-D3> you know what
<Diablo-D3> I give up
<Diablo-D3> X sucks
<Diablo-D3> hardware sucks
<Diablo-D3> computers suck.
<pitti> mjg59: do you know how sane RedHat's pam_console is?
<mjg59> If a user is logged in at the console and also logged in remotely, why does it matter that the remote session can trigger events that the user could do anyway?
<desrt> Diablo-D3; please
<mjg59> pitti: It does what it tries to do fine, but it's not ideal
* Diablo-D3 is just in a bad fucking mood right now
<mjg59> pitti: Users can open devices when logged in and keep them open after they've logged out - then they can still access them remotely at some later point
<pitti> mjg59: anyway, let's assume we have a way to define power ctl privileges for users
<pitti> mjg59: right, that's what I meant
<desrt> pitti; also... if you give a group to a user once, they have it forever
<pitti> mjg59: this priv should be assigned to an uid
<desrt> pitti; even across reboot
<mjg59> Whereas checking whether a user is actually at a console is robust
<pitti> desrt: sure, sgid binaries
<pitti> mjg59: by checking if any process of that user has any /dev/tty open?
<desrt> mjg59; it's worth noting that windows and mac os do not let unprivileged users modify the power settings
<mjg59> pitti: By checking whether gdm has recorded that that user is on the foreground tty
<Diablo-D3> mjg59: but that requires a dm.
<Diablo-D3> not all users use dms.
<mjg59> Diablo-D3: Sucks to be them.
<pitti> mjg59: k, that sounds reasonable for Ubuntu
<Diablo-D3> mjg59: how so?
<hunger> What is a foreground tty?
<desrt> mjg59; but in any case, adding a "can change power settings" group is a trivially additional layer on top of what we're discussing
<mjg59> hunger: The tty that is displayed the system console
<Diablo-D3> mjg59: what happens if the dm shits out? then you have no X.
<mjg59> "on the"
<pitti> hunger: just skip the foreground, it does not make sense anyway
<mjg59> Diablo-D3: Yes. So?
<Diablo-D3> mjg59: so I shouldnt require a dm to use X.
<hunger> mjg59: The system console? Which one is that?
<pitti> hunger: for me, asking gdm whether user X is logged in seems sane
<Diablo-D3> dms are apart of the desktop environment, X doesnt require a desktop environment to run.
<mjg59> hunger: The console that is plugged into the system.
<hunger> mjg59: I have 4 Xsessions running at this time as 4 differnt users.
<pitti> hunger: (although highly Ubuntu specific)
<mjg59> hunger: There's a fringe case of multi-head machines, but you don't want power management in that case
<desrt> Diablo-D3; please write a spec about how to fix it for dapper
<Diablo-D3> desrt: easy
<Diablo-D3> get rid of X
<hunger> pitti: I do not even use gdm!
<desrt> so go write a spec
<desrt> please.  do us the favour
<pitti> hunger: as I said, it would be highly specific, and maybe there is a more general approach
* Kinnison ruffles desrt 
* desrt is early-morning-ruffled
<mjg59> pitti: Ideally, all DMs would record the tty in utmp
<hunger> mjg59: This is a simple laptop, not multiheaded at all and definitly in need of PM.
<desrt> mjg59; i think we might have other ways to find out
<pitti> hunger: however, I'm the side that evaluates the security, not usability :)
<Kinnison> desrt: it was a mid-afternoon ruffling, you have to wait 5 hours for it to cross the ocean
<mjg59> hunger: So the foreground tty is the one that's currently being displayed
<desrt> i see.
<pitti> mjg59: right
* Diablo-D3 thinks this conversation sucks.
<hunger> mjg59: OK... and that may change PM settings?
<mjg59> hunger: They may all change PM settings, but only the active user will be able to trigger them
<pitti> mjg59: why should it matter whether a login session is displayed or not?
<desrt> mjg59; look in the lastlog
<mjg59> pitti: An idle user whose session isn't displayed shouldn't be able to trigger a suspend
<hunger> mjg59: Ah, OK. I think that sounds sane enough:-)
<desrt> mjg59; actually forget that.  it's useless if it has wrapped since
<pitti> mjg59: erm, no user should actually
<mjg59> desrt: Mm?
<mjg59> pitti: Uh.
<pitti> mjg59: I though we talk about *configuring* the power daemon
<mjg59> pitti: Surely the entire point of this is to provide functionality for user-triggered suspends?
<hunger> mjg59: What happens when the lid is closed without anyone being logged in?
<desrt> mjg59; lastlog has the info but isn't promised to still have it since it may have been rotated
<mjg59> hunger: That's a separate issue
<mjg59> desrt: IRC lastlog?
<desrt> mjg59; the system wtmp
<mjg59> desrt: Oh - surely that's pseudo-ttys?
<mjg59> I don't see my tty in there anywhere
<pitti> mjg59: you want any user process be able to directly poweroff the machine?
<mjg59> Oh, probably because it's wrapped
<desrt> you're right.  i -am- an idiot :)
<hunger> mjg59: I do not see the problem...
<desrt> ok.  seriously though... does gdm even know?
<desrt> it says to the X server "start"... and X picks a console
<desrt> then gdm connects to :0
<hunger> mjg59: Surely an idle user won't trigger a suspend anyway since he is idle:-)
<mjg59> pitti: A hostile program can already delete all your files
<desrt> gdm probably has no idea that it's on tty7
<hunger> mjg59: Why shouldn't I be allowed to suspend from remote?
<mjg59> pitti: And it can already tell gdm to halt the system
<desrt> hey
<desrt> what if we used the gdm machinary to do this?
<mjg59> pitti: See gdm-signal
<hunger> send a Wake-on-lan, do something, suspend the box again seems a valid use case to me.
<mjg59> Breezy already allows arbitrary user processes to suspend things
<pitti> mjg59: My main concern is not a DoS, but more a race between several processes who concurrently want to do power operations
<mjg59> pitti: Then we need some sort of locking
<pitti> mjg59: in the case of multiple logins
<desrt> mjg59; surely only if they're currently logged in through gdm?
<mjg59> pitti: If there are multiple logins, only the one in the foreground should be able to trigger anything
<mjg59> desrt: Yes, but that's by far the most common use case
<desrt> mjg59; but will it restrict all other users?
<mjg59> desrt: ?
<desrt> do non-logged-in-under-the-current-gdm-session-users get to use gdm-signal?
<mjg59> I'm getting confused here. Shall I just write down what I think should happen ? :)
<hunger> Please do not focus so much on gdm... there are enough other login managers around.
<mjg59> hunger: It's trivially applicable to other dms
<hunger> Would be a shame if things broke for me just because I am on kubuntu;-)
<bob2> then their users can handle adding the hooks
<mjg59> 1) User logs in. DM records the tty of the user.
<desrt> 1a) if it knows it
<mjg59> 2) User a switches to user b. DM records the tty of user B.
* hunger fails to see the reason for tty recording.
<mjg59> 3) User a's PM settings notice that he's been idle for 15 minutes. They ask for a suspend
<desrt> hunger; we ioctl /dev/tty to determine the 'active' VT
<desrt> hunger; then we see who is logged in there
<desrt> hunger; and only they are allowed to change power settings
<mjg59> 4) User A is not on the foreground console. The request is refused.
<hunger> You will need to do locking anyway.
<dholbach> i'm out for a walk... be back later
<desrt> dholbach; cheerio
<hunger> So why the foreground console magic?
<mjg59> 5) User B explicitly asks for a suspend
<mjg59> 6) User B is on the foreground console. The system suspends.
<mjg59> That's how I imagine things working. Does any part of that seem insane?
<hunger> mjg59: Why that distinction?
<desrt> mjg59; it's not bad
<desrt> mjg59; certainly handles my one use case of sharing your laptop with an evil sibling with a sick sense of humour
<mjg59> hunger: Why what distinction?
<hunger> mjg59: I think that is only useful on a single-userish box... and there will be only one user 99% of the time anyway.
<hunger> mjg59: user on foreground tty and user somewhere else.
<fabbione> Kamion: sparc is building stuff... i didn't give love to the buildd the last 2 days (been sleeping all time).. but it's catching up as we speak
<fabbione> Kamion: i was way too sick to stay out of bed
<desrt> mjg59; and hal runs as a locked-down user and shells out to setuid helpers?
<mjg59> hunger: Dapper should have nice switch user functionality. If it has that, and if users are able to configure PM settings for idle timeouts, it's vital that the non-active user isn't able to suspend the machine from underneath the active user
<mjg59> desrt: Yeah
<desrt> mjg59; it's not bad
<mjg59> Which lets us use g-p-m as is
<pitti> desrt: I'd really like to see this as a dbus service instead of being tightly integrated into hal
<hunger> mjg59: non-active timers need to be global to all users I think.
<mjg59> hunger: Why?
<Xof> I don't know where hunger gets his 99% statistic from, but I for one am in the 1%
<desrt> mjg59; assuming you have other ways of addressing the kde-users-left-out-in-the-cold/login-screen problems
<mjg59> desrt: I think the sensible thing in those cases is to run g-p-m and provide some other way to configure them
<desrt> pitti; we've talked about two things....
<desrt> 1) what should be done
<desrt> 2) what can reasonably be done in dapper timeframe
<hunger> mjg59: Do you want to suspend the box while someone is working on it via ssh?
<mjg59> Unless gconf is considered unacceptable in Kubuntu
<mjg59> hunger: Given that the user could press the power button, that's not an issue
<hunger> mjg59: agreed:-)
<mjg59> Remote users should, in most cases, not be able to trigger suspends
<desrt> hunger; we don't need a voting system :)
<desrt> "does everyone currently logged in agree to suspend?"
<desrt> mjg59; unless of course the remote user is the local user :)
<mjg59> It's quite important to have the power management as a session daemon, though. User apps need to be able to veto it.
<hunger> mjg59: Given that the ssh user could run "shutdown -h now" the distinction is rather blurry.
<desrt> mjg59; dbusdbusdbus
<mjg59> If I'm running totem in full screen mode, it needs to tell g-p-m not to suspend
<desrt> hunger; only if they're root
<mjg59> desrt: Yeah
<mjg59> Now, g-p-m already has this functionality. We're just missing the authentication layer.
<hunger> desrt: Right:-) So why not have a group of users alowed to suspend.
<mjg59> hunger: Why?
<desrt> hunger; because that's not a good dynamic policy
<desrt> hunger; who we want to be able to suspend changes as users log in/out of the console
<hunger> desrt: Maybe. But it is necessary in a multiuser setup anyway.
<desrt> hunger; we already have a good mechanism worked out
<hunger> desrt: In my uni we routinely had people sitting on "servers". They should never be shut down.
<desrt> oh.  this.
<hunger> desrt: Then don't let me keep you:-)
<desrt> right
<hunger> desrt: Granted: They could pull the plug.
<mjg59> Server installs should have a different default policy
<desrt> 09:49 <desrt> mjg59; but in any case, adding a "can change power settings" group is a trivially additional layer on top of what we're discussing
<desrt> :)
<desrt> mjg59; he's absolutely right.  some users should be unable to do power stuff, even at the console
<hunger> mjg59: The destinction between client and server used to be blurry in my uni... users were sitting on boxes and worked there that were happily exporting drives to the entire department.
<desrt> mjg59; think "internet sharing" in a library, for example
<hunger> mjg59: No money for real servers, so we used what was there:-)
<mjg59> desrt: Ok, I think that's a good argument for checking that the user is a member of a group (and in the default install, default to adding new users to that group)
<pitti> desrt: how do you want to keep local users away from shutting down a machine?
<desrt> mjg59; or "print server" in a library
<mjg59> pitti: The machine may be in a locked box
<desrt> pitti; in my hypothetical library, we have additional physical security
<pitti> ok
<hunger> pitti: Think internet caffee: monitor, keyboard and mouse are accessible, the rest is locked away.
<mjg59> But that's no problem, it's just another lookup for the policy
<desrt> *ahem* *alt-ctrl-f1* *ctrl-alt-del*
<desrt> what about that one, EH?
<mjg59> desrt: (Can be disabled in inittab)
<hunger> desrt: /etc/inittab
<sladen> except with X is crashing and keeps respawaning that doesn't work
<desrt> mjg59; something we want to provide a UI for? :)
<mjg59> desrt: A general lockdown UI might be nice
<desrt> do we have sysrq-hacking support enabled?
<desrt> or magic sysrq key or whatever they call it
<mjg59> desrt: Can be disabled through /proc
<desrt> oh.  that's very nice indeed
<mjg59> So, if gconf and glib are acceptable for kubuntu, that just leaves a UI and a light patch to KDM to make the Kubuntu case work
<pitti> desrt: I'd rather try to find the power plug
<desrt> pitti; that's not something we can fix
<desrt> pitti; these other things are
<mjg59> If not, then we need a configurable settings backend (not too much pain)
<pitti> desrt: right :)
<desrt> pitti; and generally speaking, for a given user (like a library) solving the logistics of making the machine physically secure is one heck of a lot more intuative to them than working out how to hack the OS
<desrt> my ubuntu email address is not working >:|
<desrt> elmo; ping?
<Znarl> desrt : What part is not working?
<desrt> when i send to it i get a bounce
* mvo wonders if Znarl has a nick-highlight on "elmo" ;)
<mjg59> pitti: desrt: So does this sound (a) achievable, and (b) broadly sane?
<desrt> mjg59; you have to stick your fingers into a -lot- of places
<mjg59> desrt: But it gives us a framework that works for other situations, too
<desrt> mjg59; something tells me you're used to that, though :)
<desrt> mjg59; ya.  that's true.
<mjg59> It's not PM specific
<pitti> mjg59: TBH I'm not totally convinced about the multiple userspace daemons, but I wouldn't veto against it
<desrt> i have one marginal use case that your system breaks... but it's really marginal
<pitti> mjg59: if we can solve the backend with a separate dbus service instead of integrating everything into hal, it works for me
<mjg59> pitti: I think it simplifies matters to have per-user daemons
<desrt> say we have a physically secured laptop (like library style)
<desrt> but at the end of the day the librarian wants to be able to close it and have it go to sleep
<mjg59> pitti: As far as I'm concerned, something should get the dbus signal and do something appropriate. At the moment hal has code to do that, but I don't have any religious beliefs here
<desrt> ((no distinction between user-triggered actions and system-event-triggered actions))
<pitti> mjg59: providing a simple dbus service on top of PMI should be easy
<mjg59> pitti: Well, that's basically what hal does right now (except for the "simple" bit)
<mjg59> desrt: Hrm. At the moment, that could be done through the gdm menu.
* desrt pops out for some breakfast
* desrt pops in a moment
<desrt> hm?
<pitti> mjg59: however, dbus currently only authenticates against uids or group membership
<jsgotangco> good night =)
<mjg59> desrt: System/logout/shutdown
<mjg59> Oh, sleep
<mjg59> Right. Hrm.
<desrt> mjg59; we have to assume that we're going to deal with that
<mjg59> desrt: gtksudo wrapper in that case?
<mjg59> pitti: Yeah, the authentication thing needs to be sorted
<desrt> mjg59; you close your laptop and a gksudo box pops up asking for your pw?
<mjg59> desrt: Well, pressing the sleep key
<desrt> hmmmmmm
<mjg59> There's obviously no way of dealing with the case where if one user closes the lid it should suspend and not for another user
<mjg59> Unless the librarian logs out and in again
<desrt> well -- system daemon :)
<desrt> ya.
<desrt> that's a bit evil.
<Znarl> desrt : What email address is bouncing?
<desrt> we could expand the 'system actions' at the gdm menu to ask for a u/p of an admin user
<desrt> (right now you need root)
<desrt> Znarl; desrt@ubuntu.com
<pitti> mjg59: your model would not work with closing the lid when no user is logged in, though
<mjg59> desrt: Yeah
<mjg59> pitti: Right. In that case, gdm should be running a daemon
<desrt> pitti; presumably we have something up where gdm invokves its own g-p-m
<mjg59> And then kill it during login
<pitti> that's soo crackful
<Diablo-D3> heh
<desrt> pitti; absolutely
<mjg59> There's a tiny race where the gdm one is dead before the user one starts, but, well
<desrt> pitti; but we don't have time to do it properly
<pitti> right *shrug*
<desrt> as i see it
<desrt> post-dapper we're going to want to do something better
<desrt> -much- better
<Znarl> desrt : Yeah, that doesn't exist.  Can you create a RT job requesting it's creation please?
<desrt> which probably means diverging from g-p-m again anyway (unless richard suddenly does an about-face and realises that his architecture is flawed)
<desrt> Znarl; RT?
<pitti> but if we are going for a system daemon in dapper+1 anyway, why bother with putting effort into anothers olution?
<mjg59> Basically, nobody is trying to solve this problem at the moment. To solve it we're going to need to create new framework, and the best way of convincing people is to show them the code
<desrt> pitti; this is my idea
<desrt> pitti; use what we have now.  make it better.
<mjg59> pitti: Because it's not much effort and it uses existing code
<Znarl> desrt : rt@admin.canonical.com
<desrt> Znarl; thanks.
<mjg59> The only difficult bit here is the authentication stuff, and we almost certainly want that anyway
<mjg59> As in, we'd want that even for the system daemon case
<mjg59> So we might as well solve that now, and then push for it to be standardised cross-distros
<desrt> so what.. ubuntupowerdaemon?
<ogra> wasnt acpid once though for all this ?
<mjg59> ogra: No
<desrt> fwiw, pbbuttons is -definitely- more than enough
<desrt> and pbbuttons runs on non-macs :)
<mjg59> pbbuttons is more than enough, but...
<desrt> pbbuttons has a bit of a problem right now in that it will take power management commands from arbitrary users
<desrt> *ahem*
<mjg59> desrt: Yeah. We end up having to solve the same problems, and we end up doing it in a way that integrates less nicely into the desktop
<desrt> it uses poor-man's-dbus
<mjg59> Yeah
<mjg59> Let's get the framework implemented, and then worry about the future after that
<mjg59> No matter what sort of decision we make, that needs to be done
<desrt> right
<pepito> hello
<desrt> i wonder if redhat would accept the patch to dbus
<desrt> that seems like a reasonable place for it
<mjg59> We should speak to the dbus guys, yeah
<mjg59> They'll probably just want to go with a pam_console solution, though
<desrt> pam_console is vile
<desrt> i always turn it off :)
<mjg59> Which doesn't actually solve the problem
<pepito> Im trying to get Ubuntus source packages used at boot-up for hardware detection and activation, could anyone let me know something about? thanks
<mjg59> pepito: We just use hotplug
<desrt> blisfulyl, not for long
<desrt> *blissfully
<Diablo-D3> hrm
<Diablo-D3> hey
<mjg59> So, who wants to raise this with the dbus guys? :)
<desrt> not me
<Diablo-D3> why can't we use dbus to ask the kernel whos logged into a real terminal?
<mjg59> Diablo-D3: The kernel doesn't know
<pepito> mjg59 Im just trying to see some source code that helps me when setting up a mouse whether is usb, ps/2 or serial
<desrt> i filed a bug against them "your supposedly-threadsafe library isn't" ages ago and have gotten very little reply :)
<Diablo-D3> mjg59: why can't it?
<mjg59> Diablo-D3: How should it?
<mjg59> The kernel doesn't care
<desrt> Diablo-D3; even if it had a concept of "who do the processes that are using this terminal belong to?" it would see that X belongs to root
<Diablo-D3> I dunno, maybe our tty program should communicate with dbus?
<mjg59> Nnnnnnnnnnnnnngh.
<desrt> out come to the cocks
<desrt> seriously though, i should eat breakfast
<Diablo-D3> mjg59: isn't dbus the magic way to fix everything?
<mjg59> No
<Diablo-D3> wow, could have fooled me.
<pepito> so mjg59, hotplug is used to recognize mouse at boot time?
<pepito> could you let me know packages name?, sorry I just dont use ubuntu
<Nafallo> hotplug
<pepito> ok thanks, Ill look for it whithin your repository
<Robot101> mjg59: what's the dbus issue?
<Robot101> mjg59: /me is upstream now :D
<Mithrandir> doko: would you mind if we synced zlib from Debian?  I think the only change we'll be missing out on is "Explicitely set -march/-mtune options for 64bit i386 build."
<pitti> Mithrandir: oh, Debian has the multiarch bits now? nice
<mjg59> Robot101: We want dbus to be able to authenticate events based on whether or not the user sending the request is the user with a login session on the foreground console
<Mithrandir> pitti: yes, broonie merged them.
<Robot101> mjg59: on the system bus?
<mjg59> Robot101: Use case: User sends request to system bus saying "Please suspend the machine". If user is not on the foreground console, this request should be declined.
<mjg59> (extend to requests like "Please eject the CD")
<Diablo-D3> mjg59: these permissions can be changed, right?
<Diablo-D3> like anyone who is root should be able to do this no matter where they're logged in, remote or not
<mjg59> Diablo-D3: Dbus policy is configurable. See /etc/dbus
<mjg59> See /etc/dbus-1, rather
<mjg59> Robot101: Things like pam_console don't fix it, since multiple users may have that permission but you don't want them all to be able to suspend it (see gdm's switch user functionality)
<pepito> Ok nafallo I got it, by the way, cose Im not an expert programmer, havent worked with hotplug before, do you know about any other resource I may look at in order to detect and activate a mouse at boot-time?. I havent found any, is just for a custom linux-from-scratch live-cd
<mjg59> pepito: mdetect is used at X configuration time
<mjg59> But not in normal boots
<pepito> ahm, the thing is Ive developed ncurses apps, so I need to know mouse device in order to setup gpm as well
<mjg59> pepito: Well, that's all we use
<pepito> ok, but what do oyu mean with "not in normal boots"?
<hunger> pepito: Just using /dev/input/mice and hoping for the best does not suffice?
<mjg59> mdetect is run when X is configured. In general, it is not run.
<pepito> no, cose if its usb the mouse?
<pepito> should be /dev/input/mouse0, and if is a laptop /dev/input/mice probably
<Robot101> mjg59: I suspect your best bet would be to make a service on the system bus which implemented this policy for you, you could give it something like the username and it would do whatever grubbing around was necessary and tell you if they were the current user
<hunger> pepito: PS2 mice show up in /dev/input/mice as well.
<hunger> pepito: So do Bluetooth mice. Dunno about serial mice.
<Xof> mjg59: does nautilus display of newly-plugged-in usb filesystems also come into your current discussion?
<mjg59> Robot101: It would be nice if it was a generalisable mechanism
<Robot101> mjg59: you have ~0 chance of convincing havoc to include something that hairy (mapping X displays to users, yada) in the bus daemon itself
<mjg59> Xof: Not really
<pepito> dont know just not an expert, Im gonna look for mdetect
<hunger> pepito /dev/input/mice is a "merging" of all mouse devices the kernel recognizes as such.
<Robot101> mjg59: it is a generalised mechanism... org.freedesktop.DBus.ConsoleAuthentication can be called by anyone, and you use the security policy on the system bus to ensure the name is only taken by the real deal
<mjg59> Robot101: Hmm. So we'd end up with a service that would basically scrub stuff and then rebroadcast?
<Robot101> mjg59: no, upon recipt of a message that you wanted to authenticate came from the current console user, you'd ask the console authenticator service to say yea or nay
<pepito> ah, didnt know that hunger, so if I user /dev/mice, independent of what kind of mouse would be, it is supossed to work?
<mjg59> Robot101: Ah, I see
<mjg59> Robot101: But that involves modifying every daemon that might want this sort of policy
<hunger> pepito: It should.
<Robot101> mjg59: they'd have to be modified somehow anyway
<Robot101> mjg59: there are too many variables and system specific crap to try and implement this in the bus daemon itself, especially considering it's meant to be a secure and minimal message routing implementation
<hunger> pepito: PS2/usb/bluetooth do, dunno about serial mice.
<desrt> Robot101; can dbus take auth modules?
<Robot101> mjg59: remember the message daemon itself runs as an unpriveledged user, it can't poke people's environment variables and stuff
<mjg59> Robot101: Why? If we did the rebroadcast thing, the user could just request it from one service
<pepito> aha, thanks anyway
<desrt> mjg59; recall also that we need root to do the ioctl on /dev/tty
<desrt> oh man this sucks
<mjg59> desrt: Yeah, but that could be done by a helper app
* desrt watches us spawn 23482938 small setuid helpers
<Robot101> mjg59: rebroadcasting is ugh,it requires allowing an app to forge messages from something
<Robot101> mjg59: which is understandably avoided
<Robot101> mjg59: I do think that this helper app you want is a service in its own right that you interrogate for this information
<mjg59> Robot101: Rebroadcast was possibly the wrong term. Basically, send the message and have a security policy that only allows the daemon to receive events from that service
* desrt watches us spawn 23482938 small system dbus services :)
<pepito> ok, got the mdetect in source & binary form, gonna boot-up & try, thanks very much everybody!
<mjg59> Robot101: Buggerit. Where are you right now?
<desrt> mjg59; i think we patch dbus
<desrt> mjg59; your original intuition was sufficiently sane
<Robot101> desrt: please don't smoke crack
<desrt> mjg59; and the dbus policy framework seems easy to mold
<Robot101> mjg59: CB2, but working
<Robot101> mjg59: we could discuss over beer later
<mjg59> Robot101: Already booked up this evening. Tomorrow?
<desrt> too much OOB data :)
<desrt> ciao.
<Robot101> mjg59: should be fine
<\sh> doko: Do u want me to visit an asylum? 
<mjg59> desrt: I get higher bandwidth if I discuss this with upstream face to face :)
<Robot101> I'm still a reasonable n00b, but I'm learning from the master of punting on complex issues... Havoc :D
<Robot101> mjg59: I worked out how to do that finding the system bus thing, you want a BusStation on the system bus for storing a registry of a user's session bus names
<Robot101> bonus points if you can also include a bus conductor somewhere :)
<seb128> Kamion: can you promote libgtkmathview-dev (it has been accepted for promotion by pitti) so abiword can build?
<mjg59> BusStation. Excellent.
<Mithrandir> elmo: please sync liboil, overriding ubuntu changes ok.
<dilinger> Mithrandir: does that fix #12362
<dilinger> ?
<Nafallo> elmo: please sync kismet from debian/unstable (ubuntu override okey)
<Mithrandir> dilinger: I think so, yes.
<desrt> elmo; please sync /dev/hda1 from /media/iAudio (umount -l okay)
<dilinger> Mithrandir: cool (new upstream is all that's needed)
<doko> Mithrandir: the sync should be fine, I hope lamont-away or infinity can fix gcc-opt soon
<doko> \sh: ?
<Mithrandir> doko: ok, thanks.
<Kamion> seb128: done; please seed libgtkmathview-bin if you think those tools ought to be in main too
<Mithrandir> elmo: please sync zlib from unstable; overriding Ubuntu changes is ok.
<seb128> Kamion: k, thanks
<doko> Mithrandir: hmm, but the build will fail then ...
<doko> we still need the gcc-opt workaround
<Mithrandir> doko: gnnr, ok. :-/  Wouldn't it be better to just fix that then?
<Kamion> pitti: libparse-debianchangelog-perl has a lot more dependencies listed in anastacia output without approved inclusion reports
<doko> Mithrandir: sure, but it was delayed after breezy
<Mithrandir> doko: it's after breezy now, so I guess we can harass lamont or infinity when they're around.
<sbalneav> Mithrandir: I was interested in helping out with the X11 dbus backend.  I don't know much about dbus, but what you're looking at doing for the Dapper LTSP would be usable by us in the LTSP main, and I'd be interested in trying to sync the efforts.  What can I do to help?
<mpt> Does anyone know why the Ubuntu Developers team has a maltese cross in a circle as their emblem?
<mpt> Just wondering...
<Mithrandir> sbalneav: that spec is assigned to Diziet, but basically it just needs to be written.  I discovered that there's a TCP transport already written, so just basing something around that would probably be the easiest.
<pitti> Kamion: I'll take a look at them later (tomorrow probably), but most of the stuff is a no-brainer (just simple perl modules)
<Kamion> pitti: yeah, I figured. no enormous rush, before Thursday is fine
<sbalneav> Mithrandir: What's the spec name?
<Mithrandir> sbalneav: ThinClientLocalDevices, iirc
<Mithrandir> sbalneav: https://wiki.ubuntu.com/ThinClientLocalDevices
<doko> Mithrandir: hmm, strange, I do have a merge zlib here, which I didn't yet upload ...
<Diziet> Ooh, hello people.
<Mithrandir> doko: well, if you've got it merged and nuked the duplication, just upload and close 19104?
<sbalneav> Oh, so there's not a separate spec for the dbus + net then.  OK.  I already had the localdev spec.
<Diziet> X11 dbus backend> Yes, we do need one of those.
<Diziet> X isn't quite like TCP because it's made of messages rather than just a bytestream.  But the AF_UNIX and/or TCP driver would be a good template provided you remember to rip most of it out.
<Kamion>      - Remove locale generation part from prebaseconfig
<Kamion> Mithrandir: ^-- did you also move it to post-base-installer?
<Diziet> I see the spec isn't quite finished.  Do we know if ogra is still working on the drafting ?
<doko> Mithrandir: done
<Mithrandir> Kamion: yes, it's there all right.
<ogra> Diziet, he will...
<Diziet> Ah, hello :-).
<Mithrandir> Kamion: it was just the by-hand merge changes I had to do.  MOM did her work too.
<ogra> Diziet, i'm just busy with some other stuff currently... but i will finish it
<Kamion> Mithrandir: cool, thanks
<Diziet> Sure.  But even so, the dbus X11 transport is something that people seem to keep wanting for things.
<ogra> its not bound to this particular spec
<Mithrandir> Kamion: but we should really get bubulle to change to format of the languagelist file.
<Mithrandir> it's insanely hard to read.
<Kamion> mm, it does suck for merging
<Kamion> all the ; and :
<Mithrandir> even tab would be better.
<Robot101> Diziet: you can send point to point messages between X clients? ICE?
<Diziet> robot101: Yes, XSendMessage IIRC.
<Diziet> XSendEvent, in fact.
<Diziet> RTFM for details.  You need to know the Window to send it to, eg the Window belonging to the client.  But in X you can have special kinds of windows called `input-only' windows which don't have to appear on the screen, for purposes like this.
<mjg59> Some applications ignore XSendEvent
<Robot101> Diziet: would this be for the session bus or the system bus?
<Diziet> mjg59: Yes, but that's not relevant at this point.
<Diziet> robot101: System bus.
<Diziet> (In this case.  Although a generalised dbus X transport could be used for either.)
<Robot101> Diziet: for the remote desktop case, so that your local box can speak to remote apps running on the local X server?
<Robot101> (and vice versa)
<Diziet> Exactly.
<Robot101> hmm
<Robot101> does this solve the authentication problem though>
<Diziet> Yes, in this case.
<Diziet> Have you read https://wiki.ubuntu.com/ThinClientLocalDevices ?
<Mithrandir> elmo: please sync heimdal from unstable.  Overriding Ubuntu changes is ok.
<mvo> Kamion: can you please kick the gksu build?
<Diziet> dd if=/dev/zero of=/mount/point/make-filesystem-full> Zeno's reiserfs.
<dholbach> http://wiki.ubuntu.com/Autodeb ... :(
<Kamion> mvo: done
<mvo> thanks!
<Robot101> mjg59: I was thinking about the dbus auth thing, if you wanted to do it generically, you could make a pretty simple D-Bus interface for an authentication service
<Robot101> mjg59: so the rule for talking to $service would be that $authservice that implements org.freedesktop.DBus.Auth said yes
<mjg59> Ah
<mjg59> Nifty
<Robot101> mjg59: and pass it the relevant information about the message you're trying to authenticate
<Robot101> mjg59: ie sender username, bus ID, etc
<Diziet> The dbus X transport has the nice property that you can reuse the X authentication and not have to worry about it much more.  (If that's what you wanted, of course.)
<Robot101> sure, it is a good way of exposing your session bus to remote apps. however, I'm not sure if it's desirable having the system bus daemon attempting to maintain connections to the X servers on the system, some kind of bridge that runs per X-session seems safer
<Diziet> robot101: Oh, no, you misunderstand.  The LTSP server's system bus (if there even is one) would not be involved.
<Robot101> Diziet: I mean the system bus on the machine you're sitting at
<Robot101> Diziet: the goal is to make the clients on the remote box be able to talk to the system bus daemon on the local system
<Diziet> Right, but that of course is just your LTSP think client.  So plumbing it through to your what your session thinks of as the system bus is right.
<Robot101> Diziet: talking over X gets you to the right box, but how do you link the X server and the local box's system bus together?
<Diziet> By `remote' you mean the LTSP server and by `local' the thin client ?
<Diziet> robot101: Easy: the local box's programs talk to the local X server.
<seb128> Lathiat: please ask here before mailing the list to say "I don't know where to send this mail so let's make some noise here" :)
<Diziet> I need a gizmo which teaches VM to decide what to put in my From: depending on what the message I'm replying to had in its To/CC.
<Robot101> Diziet: but these are potentially priveledged system daemons like acpid or whatever
<thierry> seb128 : at https://launchpad.net/malone/bugs/3947 by not forcing the extension do you mean I should only put the file name without like .xpm
<Robot101> Diziet: you want them to maintain connections to the user-controlled X server?
<seb128> thierry: yep
<Robot101> Diziet: this seems a little concerning - the system bus daemon is meant to enforce the security policy
<poningru> https://launchpad.net/distros/ubuntu/+spec/migrating-to-ubuntu
<poningru> is anyone working on that?
<thierry> seb128 : so every bug I opened should be like that too? 
<Diziet> robot101: Sorry, I didn't make myself clear.  The system bus daemon would connect to the local X server so that it can communicate with the remote clients.
<seb128> thierry: I've not looked on the other patches, but you should not force the extension right
<Diziet> I'm not suggesting getting rid of the dbus daemon on the local end.
<thierry> k... going to resend about 7 or 8 patch :(
<Robot101> Diziet: right, I'm just wondering if that's sane or not... which local X server does it connect to. should you not start a 'connect this X server to the system bus' process for each X server?
<Diziet> robot101: local display :0.  In a thin client configuration it doesn't make much sense for there to be several X displays.
<thierry> could anyone tell me what is the use of the karma except to be like "Wohoo! 50 more karme points!"
<Diablo-D3> thierry: its analogous to dick size.
<thierry> ok I see... strange that malone has karma thing but has not anything to mark patch as obsolte or thing like that...
<thierry> obsolete*
<LaserJock> azeem: ping?
<Diablo-D3> thierry: it probably does but its in a weird place
<ogra> Robot101, there is no need for full duplex communication 
<ogra> Robot101, the clients system bus shall only notify the servers session bus and initiate the mount
<Robot101> ogra: you can't call it a system bus connection and not allow method invocations
<Diziet> Right.  Methods like eject this, format that.
<ogra> why ? 
<azeem> LaserJock: pong
<ogra> ltspfs cares for unmounting etc ...
<LaserJock> azeem: Are you going to get the newly released ghemical into Debian?
<azeem> LaserJock: yeah, but I was away for the weekend.  I'll try to do this tomorrow or so
<LaserJock> azeem: Do you need any help for Ubuntu?
<azeem> LaserJock: I'll let you know how it goes.  I'll try to build them for dapper before upload and get back to you in #ubuntu-motu if there are issues
<doko> BenC: should a new subversion be built with db4.2, or is it safe to switch to db4.3 ?
<LaserJock> azeem: cool
<BenC> doko: honestly I don't mess with svn anymore other than using it for the odd project here and there, so I'm not sure what the build requirements are now
<Mithrandir> Diziet: I have something like that for gnus.
<Kamion> doko: talk to infinity; AFAIK he's on top of this already
<Diziet> mithrandir: Ooh, where is it ?  Just a hacky thing in your .emacs or is it packaged ?  Care to pass it to me under the table ?
<Diziet> I could probably bash it up so it works with VM.
<Diziet> ogra: I think we disagree about how this will work.  We don't want to use ltspfs for eject and format and things like that.
<Diziet> Obviously ltspfs does stuff with unmounting which is rather special.
<Manny> hi :)
<Mithrandir> Diziet: http://err.no/dotfiles/gnus, it's the part which starts with ("in-" in the gnus-posting-styles part.
<Manny> how likely would you say that it is that Ubuntu will get the express installer as default for 6.04?
<Diziet> online dotfiles> I approve :-).
<Kamion> Manny: it's my top priority for the next six months
<ogra> Diziet, ltspfs unmounts automatically if there was no device access for n seconds
<poningru> Manny: considering that its THE critical priority
<Manny> Kamion, excellent :)
<Kamion> (after I get past this first round of stuff to merge)
<poningru> I'd say very likely
<Manny> Kamion, poningru: do you know whether gparted can resize ntfs partitions?
<Mithrandir> Diziet: it's in svn+cvs, so it's just a cronjob which checks out every five minutes.  I'm lazy. :-)
<poningru> Manny: lets take this to #ubuntu
<poningru> but yes it can
<Manny> poningru, excellent, thanks.
* Diziet saves the URL for looking at some time.
<poningru> make sure its not mounted
<poningru> before messing around with it
<Diziet> ogra: unmounting> Yes, and we want to keep that.  But only the mount/unmount is changed.
<sivang> Mithrandir: do you have your .emacs setup for python there?
<Mithrandir> sivang: I don't have any magic .emacs setup for python, but yes, my .emacs is available at (nearly) the same URL.  I'm sure you can figure out which transformation is needed. :-)
<LaserJock> Diziet: I have a question about the DeveloperDocumentation spec
<Diziet> laserjock: Sue.
<Diziet> s/Su/&r
<LaserJock> Diziet: how will the UDR be worked on, will be on a svn repo? 
<LaserJock> Diziet: like how the doc team does it
<Diziet> I was going to use hct if it was sufficiently stable by then; otherwise maybe bzr or maybe just directly editing the Debian package.
<Kamion> LaserJock: (it would have to be something suitable for keeping track of changes to the DDR, so a separate svn repository wouldn't cut it)
<Diziet> Documentation is an easier problem because it doesn't tend to be full of diffs that take a lot of time to comprehend.
<LaserJock> Diziet: have you talked to the doc team about it much? There is a Ubuntu Packaging Guide project on https://wiki.ubuntu.com/DocteamProjects that I was going to work on but it seems somewhat redundant now
<Diziet> I've not spoken to the docs team in any detail but it's somewhat orthogonal.
<Diziet> I've not seen the Ubuntu Packaging Guide and there's no link to it on that wiki page or the corresponding launchpad page.
<LaserJock> Diziet: I believe it was going to be the content from the  introdeveloperdocs  package mostly
<Kamion> LaserJock: guides/tutorials are a different matter - there's still a valuable position for a reference work maintained by the development team
<Diziet> What Kamion said.
<Diziet> introdeveloperdocs is more of a tutorial/howto type thing.  There's room for those too but they tend to multiply because people have different views about how things should be done.
<LaserJock> Diziet: Ok, well I just wanted to talk to you guys about it. I don't want to have a bunch or redundant work going on
<Diziet> Sure.
<LaserJock> I will probably try to work on both (at least keep track) so that the overlap will be minimized
<Diziet> You (or whoever is doing it) should update the https://wiki.ubuntu.com/UbuntuPackagingGuide wiki page to refer to introdeveloperdocs (if that's what it is).
<LaserJock> yeah, I just found out by looking at your spec that that is what it is. I have been trying to track down what it was, because I am not the original author
<Diziet> My Approver wanted me to take out that note about introdeveloperdocs.  I feel vindicated :-).
<LaserJock> Diziet: good, it's funny because I am supposed to be working on it for the doc team and I didn't even know 
<Diziet> We did have someone from the doc team in one or both of the bofs at ubz.  Are you on ubuntu-devel-announce ?
<LaserJock> Diziet: Me? yes
<seb128> infinity, lamont-away: please give a retry to libwpd
<Diziet> The approved specs were all posted there IIRC.
<Diziet> But, communications are something of a problem for us sometimes.
<Diziet> I'm afraid I have to go now.  Feel free to email me (iwj@ubuntu.com) or witter here and I'll read scrollback or talk to me tomorrow.
<LaserJock> Diziet: thanks, I just wanted to see if I should abandon the Ubuntu Packaging Guide
* mvo goes to play hockey
<ogra> Kamion, did you see #19407 ?
<ogra> looks like #15244
<Kamion> ogra: I hadn't yet, but I would have done
<Kamion> could be the same thing - I'm buried in trying to figure out why current CDs won't boot though
<ogra> dont worry, i'll play with it... i think its the same issue
<Kamion> sounds promising, certainly
<Kamion> it's probably in one of the TCP *_WAIT states; netstat -a would say
<Kamion> (netstat -an actually)
<ogra> i'll check
<Kamion> hmm, sshd does use SO_REUSEADDR though
<Kamion> oh, I see, we don't use SO_REUSEADDR in x11_create_display_inet
<Kamion> ... but that's probably good
<Kamion> ogra: is it possible to get the remote end to close the X11 forwarding channel first, rather than killing sshd? I'm pretty sure that would solve the problem
<Kamion> ogra: see http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
<Kamion> ogra: basically the problem is that if you kill the server, it has to send the first TCP FIN, which means that it ends up sitting in TIME_WAIT for two minutes
<Kamion> though quite why it's apparently stopping at the first port it tries (6010) rather than continuing and trying the next one, I'm not quite sure
<ogra> lets see... at least i can confirm that problem is gone with setting this option...
<Kamion> which option?
<ogra> limiting sshd to ipv4
<ogra> (AddressFamily inet)
<Kamion> hmm, it used to be that X11 forwarding sockets only worked on IPv4, IIRC; if that's still true, it could mean that it's falling back from IPv4 to IPv6 (rather than to the next IPv4 port) and then falling over somehow
<Kamion> I'll ask the reports
<Kamion> er, reporter
<\sh> doko_: ping
<dieman> congrats on the db2 certification
<dieman> now just need oracle ;)
<sivang> dieman: they will come :)
<sivang> dieman: I hope..
<mpt> Kamion, ping
<janimo> if an upload got REJECTED (twice) because of errors and then got ACCEPTED is there anything else needed for it to get in the build?
<janimo> the same version number was kept
<seb128> no
<janimo> are there two windows/hour when packages enetr the build?
<slomo> janimo: :03 and :33
<janimo> so I thought
<janimo> and lamont's site is updated about when the build of a package finishes?
<janimo> exo got accepted at ':50 but it did not appear in the build logs, so I am waiting tosee it so I can go to sleep :)
<slomo> no idea... maybe every 15 minutes or something... i didn't get the real intervals yet ;)
<sivang> night all
<bmonty_laptop> hi LaserJock 
<Kamion> janimo: ~lamont/buildLogs/ is updated every 20 minutes I think
#ubuntu-devel 2005-11-20
<dholbach_> good night everybody
<mdke> night
<mdke> man bugzilla is slow right now
<ogra> daniels, ping
<daniels> ogra: pong
<ogra> daniels, i'm trying to preseed some xorg values for ltsp clients ....
<ogra> namely i want to force 16 bit as default colordepth
<daniels> hrm
<ogra> in the setup script mdz calls dpkg-reconfigure -fnoninteractive $xserver_package (where $xserver_package == xserver-xorg)
<daniels> i don't think that's preseedable at the moment
<ogra> oh, ok
<daniels> actually, no
<ogra> i tried to put preseed $xserver_package $xserver_package/config/display/default_depth "16" above ... nbut if the package doesntr recognize it anyway, nevermind...
<daniels> just preseed xserver-xorg/cponfig/display/default_depth ... oh
<daniels> it should only be resetting it if the seen flag is false, afaict
<daniels>   db_fget xserver-xorg/config/display/default_depth seen
<daniels>   if [ "$RET" = "false" ] ; then
<daniels>     db_set xserver-xorg/config/display/default_depth $DEFAULT_DEPTH
<daniels>   fi
<daniels> although, right, it's reset if we're calling -reconfigure
<ogra> cat you change that in one of the future versions ? its important for low end clients ..
<daniels> err
<daniels> not really
<ogra> so what should i do ? 
<daniels> i mean, I don't think that will get called if you preseed autodetect_display=false
<daniels> but then you, well, lose all the display autodetection
<ogra> hmpf
<daniels> i have a hard requirement that dpkg-reconfigure reset everything and do what people expect, from mdz
<daniels> i could stick in an XORG_FORCE_DEPTH=16 variable if you liked
<ogra> yeah, that'd be enough
<ogra> the original ltsp does that by default ... i'm trying to find out why we need more than twice as much memory 
<ogra> and this seems to be one of the hogs...
<daniels> it should be making a total of 4mb difference on 1600x1200
<ogra> thats much ...
<daniels> and about 1.5MB difference on 1024x768
<ogra> i'm fighting for every MB currently
<daniels> actually, wait, that's comparing to 8bpp
<daniels> 786kb on 1024x768
<ogra> the lowest footprint i could get it working with is 40MB ... ltsp uses 32
<daniels> almost 2MB on 16x12
<ogra> so i still have to loose 8 meg
<wasabi_> Hmm. Trying to get X to work with a 1920x1600 monitor
<uenyioha> could someone explain to me what this "special" gcc function call does _dl_allocate_tls...?
<uenyioha> anyone knows what it does....im reading through linuxthreads code and came across it...i'd appreciate the help 
<uenyioha> ?
<bob2> linuxthreads is poking tls stuff?
<uenyioha> say bob2: thanks...but could you explain more 
<uenyioha> say bob2: or at least point to a URL
<uenyioha> say bob2: i know it seems to be some sort of memory allocation at the least...
<bob2> uh, your irc client seems to be broken
<uenyioha> bob2: i know it seems to be some sort of memory allocation at the least...
<uenyioha> bob2: sorry missed the slash
<bob2> I have no idea what it does or what it is
<uenyioha> bob2: ok thanks...i dunno....the most i can tell now is that it seems to be some sort of special gcc call...
<uenyioha> ok..i see it now....its a linux call to allocate memory that is local to a thread
<desrt> Kinnison; ?
<viviersf> doko : ping
<doko> viviersf: just ask
<viviersf> just making sure you in
<viviersf> there has been in a problem in OO 2 since beta
<viviersf> if i open a big document 
<viviersf> its just dies
<bob2> have you filed a bug?
<viviersf> yes
<doko> yes, there are some bug reports ...
<viviersf> bob2, the bugzilla told me that my bug report does not have enough data
<viviersf> i really dont know where the problem is
<viviersf> but i could propably get you a doc that makes it crash if that would help
<doko> viviersf: yes, if you have such a document, it would be nice to attach it
<viviersf> kk
<viviersf> kk
<ctd> 17:43 < stuporglue> I'm from Provo, UT, USA where Jeff Waugh was supposed to 
<ctd>                     speak tomorrow.
<ctd> 17:44 < stuporglue> I'm hearing roumors that he's canceled his trip, and I was 
<ctd>                     wondering if there were anyone that could help me get ahold 
<ctd>                     of his wife for confirmation, or that knows if this is true.
<ctd> anyone heard anything 'bout this?
<crimsun> ctd: he flew out of RDU on Saturday
<crimsun> ctd: I don't know his current itinerary
<Burgundavia> lamont-away, ping
<JaneW> has everyone seen this review yet? It's very good and echos exactly how I feel about Breezy - I love it cos it just WORKS :) http://www.tectonic.co.za/view.php?id=645
<Burgundavia> JaneW, tectonic might as well work for canonical with the reviews they write
<Burgundavia> not that that is a bad thing...
<Treenaks> JaneW: There's an article in a Dutch computer magazine, giving it 9 points out of 10 (SuSE 10 gets 8), and they say "it's ready to take on windows, if enough people install it"
<JaneW> Treenaks: awesome
* JaneW would totally recommend it to friends and family, whereas I hesitated with Hoary reckoning they'd need quite a lot of support and hand holding with it...
<Treenaks> JaneW: now imagine Dapper
<JaneW> Burgundavia: yes I gather they do like Ubuntu (the idea of it) as well as the product
<JaneW> Treenaks: indeed!
<robitaille> JaneW,  of course we have seen that tectonic article. It was on the Fridge a little while back :)
<JaneW> Treenaks: I hope your flight was good, I managed to NOT buy anything in MOntreal airport, but did some damage to my visa card in Schipol airport - that place just shouts BUY ME! ;)
<JaneW> robitaille: good, sorry I am just slow then ;)
<Treenaks> JaneW: I only bought batteries for my MP3-player :)
<Mithrandir> JaneW: no, is shouts "DRR, BUY, FLY" :-)
<Mithrandir> s/DRR/SEE/
<JaneW> Treenaks: and I tried purfumes until the shop assistant gave me a dirty look ;) So I 'smelled like a girl' like jdub does ;)
<Treenaks> JaneW: LOL
<Burgundavia> JaneW, ouch
<JaneW> Mithrandir: hehe so it does - well it worked!
<Burgundavia> JaneW, I'm hearing roumors that he's(Jeff Waugh) canceled his trip. This true?
<JaneW> Burgundavia: he does! cvd bought him a women's deodorant ;)
<JaneW> Burgundavia: I heard an hour so so back that he is in Sydney, I don;t know anything else, or even if he is back sooner than expected...
<Treenaks> If he's back now, that's much sooner than expected
<JaneW> oic, wonder what happened then...
<robitaille> it seems he was coming home a week early:  http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013043.html
<Mithrandir> what's up with bugzilla?  It's amazingly slow.
* JaneW is trying to install dotproject (I really don't want to ever have to boot into windows again), I need to set up a web server to get dotproject to work properly, can anyone give me some pointers on how to do this?
<Mithrandir> any web server?  Just install the apache2 package
<JaneW> Mithrandir: ok, will do
<sivang> morning all
<pitti> Hi sivang 
<Burgundavia> JaneW, you played with planner?
<sivang> pitti: hey Martin
<JaneW> Burgundavia: no, do you recommend it?
<Burgundavia> JaneW, I heard it is not all full featured as  MS Project but nicer to use
<Burgundavia> JaneW, and it a gnome app, no need for a webserver and nasty PHP
<JaneW> Burgundavia: sounds good to me! I will check it out :)
<Burgundavia> night all
<seb128> is bugzilla slow for other people too?
<Treenaks> seb128: yes, I saw someone complain earlier
<Treenaks> 09:54 <  Mithrandir> what's up with bugzilla?  It's amazingly slow.
<Treenaks> 01:07 <        mdke> man bugzilla is slow right now
<seb128> k
<seb128> so that's not only me :)
<seb128> thanks
<mvo> seb128: yep, for me too
<seb128> yeah, after a few min I got the start page
<seb128> let's search for a bug now :p
<Mithrandir> seb128: it's mostly changing stuff which is slow for me.  Other things are just bugzilla-slow.
<seb128> Mithrandir: here it's "take 2 min to load a page" slow
<Mithrandir> yeah, but it seems to only be for stuff which changes bugzilla for me.
<Mithrandir> anyway, I'm looking at the Merge Of Doom, so I don't mind ATM.
<seb128> do we have some ftpmaster of buildd admin today?
<seb128> I need syncs and to get some builds kicked
<seb128> s/of/or/
<Mithrandir> seb128: infinity should be back home, so I think so, yes
<seb128> cool
<Mithrandir> uhm, dpkg-statoverride shouldn't be called from maintainer scripts, should it?
<Kamion> seb128: I can kick some builds for you ...
<Mithrandir> morning, Colin
<Kamion> morning
<seb128> Kamion: hi. Giving a retry to libwpd would be nice, it's required to build abiword/gnumeric
<\sh> who is able to sync, when elmo is not around? 
<Kamion> seb128: done
<seb128> Kamion: thanks
<Kamion> \sh: mdz or I technically, but the state of the sync directory is currently weirding me out, so I'm refusing for the moment
<seb128> elmo should be back today no?
<Kamion> oh, hang on, the sync directory is saner now
<Kamion> seb128: I should think so
<Kamion> go ahead with any urgent syncs, I think I can manage them
<\sh> ok...so i'm waiting for elmo...
<slomo_> Kamion: while you're at it... can you give-back gtksourceview-sharp, gtksourceview-sharp2 and seahorse if it's not too much of a problem? ;)
<seb128> Kamion: I've some sync but that can wait for elmo, I'll ping you later if he's still not around
<Kamion> slomo_: done
<slomo_> Kamion: thanks :)
<\sh> seb128: btw...I updated to dapper yesterday evening...and now xchat doesn't show small tabs anymore..but it's enabled...is it more a font issue (bitstream sans mono) or can it be an xchat problem?
<Mithrandir> Kamion: I guess looking at the merge bugs in the "PENDINGUPLOAD" state would be a good list for stuff to sync.
<Kamion> Mithrandir: I'm not going to go out proactively looking for them, for the moment
<Mithrandir> Kamion: but then, no idea what's urgent about it, so I guess we can just wait for elmo
<Mithrandir> s/it/them/
<Kamion> feel free to ping me with urgent ones, but otherwise I have other things to do. :)
<Mithrandir> and .. which of them ...
<Mithrandir> yup, I know. :-)
<seb128> \sh: hum, why a font issue? I would say that's an xchat issue. Feel free to ping dholbach when he's around, he has worked on this update
<\sh> seb128: because I found a font issue in gnome-terminal...the font is not displayed as it was in breezy that's why I'm asking
<sivang> is bugzillla dead? :)
<mvo> sivang: not quite, but very slowish
<sivang> mvo: ok, thanks
<chmj> I can't access is either 
<chmj> s/is/if/
* chmj gives up
<\sh> dholbach: good morning..
<dholbach> hellas! :)
<dholbach> hi \sh 
<\sh> dholbach: I'll paste u my former statement to seb128 ... 
<\sh> dholbach: \sh seb128: btw...I updated to dapper yesterday evening...and now xchat doesn't show small tabs anymore..but it's enabled...is it more a font issue (bitstream sans mono) or can it be an xchat problem?
<Nafallo> \sh: I can reproduce :-P
<dholbach> \sh: no idea, will investigate
<Nafallo> fwiw
<\sh> Nafallo: ah good to know :)
<sivang> hmm p.u.c also doesn't respond. nice
<\sh> dholbach: thx :)
<\sh> dholbach: and gnome-terminal looks as well strange with this font issue
<dholbach> \sh: i think it's rather freetype
<\sh> dholbach: gnarf...
<doko> chmj: pong
<chmj> doko: hi, about the java packaging, where do I get info on that 
<doko> should be in the wiki, JavaRoadmap
<[-Jarod-] > hi everybody !
<[-Jarod-] > i'm a 3rd year student in a french engineering school and I currently manage an open source project aiming to control dynamic lights for show
<[-Jarod-] > i work with c / c++ / glade
<[-Jarod-] > but I'm a complete beginner in c
<[-Jarod-] > i've installed gcc / g++ with apt
<Nafallo> [-Jarod-] : you are better of by installing build-essential
<Mithrandir> [-Jarod-] : this channel is for developing ubuntu, not for developing applications.  and what Nafallo says.
<[-Jarod-] > and a piece of open source code found on the net call a .h called "vlc.h" and i cannot found it
<[-Jarod-] > i know Mithrandir i know
<Mithrandir> [-Jarod-] : it's a user question; #ubuntu, but I think you're just missing libvlc0-dev
<Mithrandir> apt-cache search vlc dev shows you relevant info
<[-Jarod-] > thank you
<[-Jarod-] > that's all i need
<[-Jarod-] > sorry for disturbing you
<Kamion> could somebody look at preparing main inclusion reports for gdome2 and gmetadom? they're (build-)dependencies of gtkmathview, which was recently added to the archive for (iirc) abiword
<dholbach> Kamion: i can do that
<Kamion> thanks
<infinity> Kamion : Thanks for driving wanna-build for sb.  I'm in and out, alternately mucking with initramfs (yay, rebooting and no IRC), and trying to get over the cold/flu I seem to have developped from travelling.
<infinity> s/sb/seb/
<Kamion> np
<pitti> Hi infinity 
<pitti> infinity: seems that everybody's health suffered from UBZ at some point :/
<infinity> pitti : I was fine during the conference, it was the flight home that seems to have killed me.
<infinity> pitti : Or maybe it was the climate change when I got here.  I dunno.
<sivang> pitti: yes, I think the germs has also had  a mini conf over UBZ....
<sivang> infinity: take vitamine C pills, they really help
<sivang> infinity: that's how I got over my flu
<Kinnison> desrt: I was, unsurprisingly, asleep at 03:49
<zyga_mini> carlos: ping
<carlos> zyga_mini, pong
<zyga_mini> carlos: is there any progress with adding support for multiple templates per package (rosetta)
<carlos> zyga_mini, we already support multiple templates per package since long ago
<neuralis> zijev
<carlos> zyga_mini, what do you want/need?
<zyga_mini> carlos: we do?
<zyga_mini> carlos: since when!? 
<carlos> zyga, since the first days
<carlos> zyga, take a look to gtk+ 
<zyga_mini> checking
<zyga_mini> this is great news :)
* zyga_mini thought otherwise
<zyga_mini> carlos: care to show a url?
<zyga_mini> carlos: I see that there are two versions 1.2 and 2.0
<zyga_mini> but I don't see multiple templates
<carlos> zyga, https://launchpad.net/distros/ubuntu/breezy/+source/gtk+2.0/+translations
<zyga_mini> hmm
<zyga_mini> thanks I'll look into this
<zyga_mini> carlos: and any (non distro) product can have multiple templates?
<carlos> zyga, yes, it's the same
<zyga_mini> thanks, sorry to bother you with inexistent problems :-)
<Kamion> isolinux is giving me a headache. for some reason I can't get current dapper i386 CDs to boot, even though I undid all the isolinux fiddling I experimentally tried
<dholbach> Kamion: did those inclusion reports... gmetadom wanted to have findlib as build-dep too, so 3 reports :)
<dholbach> gtkmathview fun! :)
<Kamion> dholbach: pitti will need to approve them
<dholbach> Kamion: sure
<Kamion> hm, but these images boot fine in qemu. WTF
<pitti> yes, I'll process the queue again today
* Mithrandir read that as gmetadon and went wtf?
<pitti> BenC: *sigh* when can we test the 2.6.15 crack? :)
<dholbach> Mithrandir: hahaha :)
<Mithrandir> dholbach: would be a nice name for a tool which removed crack, but not much else, really.
<Kamion> pitti: well, it failed to build ...
<pitti> right, that's what I meant
<pitti> (just tickling)
<pitti> ajmitch_: just uploaded a merged cron with SELinux support :)
<Kamion> damnit, I've just wasted four hours on what turned out to be something like a dirty DVD drive :(
* Kamion bangs head on desk
* dholbach comforts Kamion and gives him a tea
* fabbione hugs Kamion
<pitti> hardware just sucks.
<pitti> Hey jbailey 
<Mithrandir> emulate it all in software
<pitti> Mithrandir: in the matrix?
<jbailey> Heya Martin, Tollef & everyone else.
<Mithrandir> hiya Jeff
<fabbione> hey jbailey 
<jbailey> Heya Fabio
<Kamion> chmj: why did you merge aalib rather than requesting a sync? the version in Ubuntu was identical to the base version in Debian
<Kamion> (and I noted that in the changelog for the benefit of whoever next looked at it)
<chmj> Kamion: didn't notice that 
<Kamion> chmj: please be more careful; now we have to wait for the next Debian upload before we can come back into sync
<Kamion> which is annoying because the Debian maintainer of aalib is one who occasionally goes through Ubuntu changes and remarks on them publicly in his blog
<chmj> Kamion: ok 
<seb128> hey Keybuk
<fabbione> bella Scott
<Keybuk> heyhey
<Mithrandir> Keybuk: I don't think I've told you before, but mom's a godsend.
<Keybuk> heh, did it get a merge right?
<seb128> Keybuk: do you know what modprobe does to take such a long time on boot? http://people.ubuntu.com/~seb128/dapper-20051112-1.png
* Lathiat laughs
<pitti> Hi Keybuk 
<seb128> Keybuk: or that's usplash?
<Keybuk> not sure, it could be the modprobe of everything on the PCI bus
<Keybuk> or it could be the modprobe of framebuffer things
<Keybuk> I'd guess from its location that it's the former
<mjg59> Framebuffer modprobing doesn't take anywhere near that long
<mjg59> That'll be stuff being loaded in the initramfs. No idea why it's taking so long, though
<Kamion> interesting ski-slope up at the top there
<Lathiat> yeh i was thinking that
<mjg59> seb128: Is your usplash exiting before init starts?
* Lathiat looks at his
<Keybuk> Kamion: isn't it ... I have one of those later in the boot sequence
<pitti> seb128: you could try booting in single mode, then you will see a detailed output
<Lathiat> hrm my modprobe is pretty quick there
<Kamion> Keybuk: does udev use 'modprobe --quiet' anywhere (as opposed to 'modprobe -q')? if so, it'll need the same change that I made to hotplug yesterday
<Lathiat> liek 2-3 s
<Kamion> (I know hotplug is dying, but I want to make d-i work)
<seb128> mjg59: yep
<mjg59> I wonder if the ski-slope thing is an artifact of the logger
<Keybuk> Kamion: udev doesn't use modprobe yet, though it'll have to I guess; what change did you have to make?
<seb128> mjg59: I thought it was going to timeout or something
<Kamion> Keybuk: s/--quiet/-q/g
<Kamion> er - what loads modules in the NWO then?
<Keybuk> heh, it should've been -Q
<mjg59> seb128: It times out after 15 seconds of not getting any messages. And it's not getting any messages from that modprobe
<Keybuk> "NWO" ?
<Mithrandir> Keybuk: it usually makes my work a lot less painful.  Does it now save the Debian versions, so we won't be affected if snapshot.d.n dies again?
<Kamion> new world order
<Keybuk> udev will do
<Kamion> Keybuk: busybox modprobe doesn't support -Q
<Kamion> what does -Q do? it's not documented in modprobe(8) here
<chmj> elmo: procps sync please, ubuntu override ok 
<mjg59> On the bright side, once init starts we seem to be in pretty constant io blockage
<Keybuk> Kamion: it's one our patches to module-init-tools to make it silent
<Kamion> I'm also not convinced that busybox modprobe does aliases usefully, so I might have to switch back to module-init-tools for the moment
<Kamion> (sigh)
<Keybuk> yeah I strongly suspect busybox modprobe won't cut it
<Keybuk> it'll need both alias and blacklist support
<Kamion> it does seem to have some alias support, by grep
<Kamion> not blacklist though unless it won't match grep -i blacklist
<Keybuk> "by grep" ?! :)
<Kamion> as in, 'grep -i alias' in the source suggests it has some alias support
<Keybuk> so it wouldn't handle an alias like "pci:d*s*..." then??
<Keybuk> oops, bit of baz-finger on the ? there
<Kamion> Keybuk: no, it doesn't use grep internally
<Kamion> I meant *I* was using grep
<Keybuk> ohh
<Kamion> rather than actually reading and understanding the source
<Keybuk> heh
<Keybuk> does it look like it supports the blacklist keyword?
* ogra cruses gnome-screensaver uptream for reinventing the wheel ...
<Treenaks> ogra: which wheel?
<Kamion> Keybuk: no
<seb128> chmj: you could have asked a sync for aalib
<Kamion> seb128: I mentioned that to him above
<Keybuk> Kamion: example: /etc/modprobe.d/blacklist
<seb128> Keybuk: anything I can try to reduce the modprobe blocker so?
<Keybuk> seb128: find out what it's doing :)
<Keybuk> make it log with timings to a file in /dev
<seb128> Kamion: k. I've asked a sync 3 days ago but since no elmo around ... :)
<Kamion> Keybuk: the word "blacklist" doesn't appear anywhere in the source. Anything else I should be looking for?
<seb128> Keybuk: is there an easy way to do get this log?
<Mithrandir> Treenaks: a square one, probably.
<ogra> Treenaks, if you want to see the xscreensaver hacks in gnome screensaver you have to create a .desktop file for the config and description ... it should just use the available xml file for that ... its ahell lot of work to adapt all the configs
<Keybuk> seb128: edit /usr/share/initramfs-tools/scripts/functions and make it log :)
<Treenaks> ogra: ouch
<ogra> yup
<Keybuk> Kamion: the word would be sufficient as it's a config keyword
<seb128> Keybuk: thanks
<ogra> and there is no visible advantag in this scheme anywhere... i dont knwo what they think they'll gain with this ..
<Keybuk> ogra: probably an fd.o "how to register a screensaver" spec
<ogra> Keybuk, but you still need additional configs, it only holds name, description (which is not shown anywhere in the gui) and the command to run...
<Treenaks> ogra: not the different options etc.?
<ogra> nope
<Treenaks> *headdesk*
<ogra> heh
<Keybuk> I read that gss aren't planning to have options-per-hack
<Keybuk> but instead if you want different options, you make a new description file for it
<seb128> nop, that's a point of the FAQ
<ogra> anyway, i'm done with converting the ubuntu default set for now
<Treenaks> Keybuk: urgh...
<mvo> ogra: did you send him a mail asking about it?
<ogra> mvo, i will ... for now i just wanted to have the hacks working, so we have screensavers to get bugs for
<seb128> pitti: 20050713/totem_1.1.2-0ubuntu6_translations.tar.gz ... what the heck?
<seb128> pitti: current archive version is 0ubuntu3, how can the translation be 0ubuntu6?
<pitti> totem | 1.2.0-0ubuntu3 | http://de.archive.ubuntu.com dapper/main Packages
<seb128> pitti: ups, 1.1.2 is not 2.0
<pitti> seb128: 1.1.2 is ages old
<seb128> pitti: yeah, but that's the data rosetta has
<seb128> carlos: continue here with pitti :p
<pitti> well, then this is carlos' problem :) 
<seb128> I got a bug saying that 5.10 has no translation for "Sidebar"
<seb128> and the 1.2.0 tarball has it
<seb128> rosetta mention 1.1.2-0ubuntu6
<carlos> pitti, people's tarball say that latest is the ubuntu6
<carlos> s/people's/people.ubuntu.com/
<pitti> ./20050922/totem_1.2.0-0ubuntu3_i386_translations.tar.gz
<pitti> ./20050912/totem_1.2.0-0ubuntu2_i386_translations.tar.gz
<pitti> ./20050906/totem_1.2.0-0ubuntu1_i386_translations.tar.gz
<pitti> ...
<carlos> seb128, wait....
<carlos> seb128, is it 1.1.2 vs 1.2?
<carlos> then it's my fault
<carlos> I got confused
<seb128> carlos: yep
<seb128> carlos: page says 1.1.2 but current is 1.2.0
<carlos> seb128, please file a bug and I will look into it this week
<seb128> k, thanks
<seb128> carlos: another point, rosetta refuse to send me mails, is that a known issue? I've asked for a po some hours ago and no mail, my email works fine
<BenC> pitti: re: 2.6.15, for some reason there was a build failure for 2.6.15-1.1, and the build log doesn't even explain why, just something about zddevlist.h generation
<BenC> pitti: looking into it now
<pitti> thanks
<carlos> seb128, I got an email for a download request an hour ago or so....
<BenC> it built fine in the breezy chroot, so I'm wondering if it's dapper related
<carlos> seb128, so no, it's not a know bug
<carlos> seb128, would be possible a problem with spamassassin?
<seb128> carlos: should I ping some launchpad guy about this?
<seb128> carlos: I doubt so, let me look
<fabbione> BenC: be careful that the buildd go for make -jN
<fabbione> BenC: so perhaps the error is way before the end
<BenC> fabbione: no, it's zddevlist.h, make shows error for that target
<BenC> for i386 and amd64 builds
<fabbione> ah ok
<carlos> seb128, anyway, ask stub, I'm not able to debug that
<fabbione> BenC: well if you plan an upload, it would be wise to pre-upload k-p with your ppc patches and bump the build-deps
<seb128> carlos: hum, sorry, it got redirected to an another of my mailbox
<BenC> is awk something I can expect by default?
<fabbione> BenC: at least we can get ppc to
<seb128> carlos: I'll just fill the totem outdated bug for today so
<BenC> yeah, I can do that
<seb128> carlos: thanks :)
<fabbione> BenC: iirc mawk is installed, but not gawk
<BenC> maybe it doesn't like mawk
<carlos> seb128, ;-)
<siretart> BenC: will the next linux-restricted-modules upload include the 'new' madwifi driver? is anyone already working on that (I want to avoid work duplication)
<BenC> I can't touch l-r-m
<fabbione> siretart: -> infinity 
<siretart> oh. thanks for pointer
<seb128> carlos: #4486
<siretart> infinity: will the next linux-restricted-modules upload include the 'new' madwifi driver? is anyone already working on that (I want to avoid work duplication)
<siretart> ;)
<carlos> seb128, thanks
<BenC> yep, it's mawk
<mjg59> There's a close to working open atheros driver
<BenC> doesn't like the awk script that generates zddevlist.h for zd1211 driver
<mjg59> The zd1211 driver is on so much crack
<fabbione> annoying
<BenC> I've cleaned it up a bit to get it compiled
<siretart> mjg59: could you give me pointers to this 'close to working open driver'? is it based on madwifi?
<mjg59> Oh, do we actually ship the zd1211 firmware?
<mjg59> siretart: Yes
<pitti> Keybuk: do you want to merge hdparm yourself to take the new udev changes into account?
<fabbione> BenC: is there any reason why we need to generate that include at build time?
<pitti> Keybuk: otherwise I assign it to me and wait for the new udev
<mjg59> http://mateusz.agrest.org/atheros/
<siretart> so it's rather an open hal for madwifi
<mjg59> siretart: Yeah
<Keybuk> pitti: yeah, I'll do that one
<pitti> Keybuk: k, I assign it to you then, thansk
<siretart> mjg59: my concern/problem with madwifi atm is that the driver in breezy does not support background scanning, which I find very painful.
<siretart> mjg59: the 'new' madwifi codebase is supposed to support that
<mjg59> Right
<siretart> thats why I'm asking
<BenC> fabbione: does hppa have gcc-4.0?
<mjg59> http://lists.gnumonks.org/pipermail/ath-driver-devel/2005-November/000053.html is kind of promising
<BenC> mjg59: I think we do ship the firmware
<Mithrandir> Keybuk: could you make MOM put something in the signature line which would cause dpkg-buildpackage to fail to build?  I'm annoyed at myself for uploading as you so often. :-)
<siretart> mjg59: so whats the mid-term plan concerning madwifi in dapper?
<Keybuk> Mithrandir: yeah, I've considered not including a valid tail line to the changelog
<Keybuk> the trouble there is that both dch and emacs consider different things invalid
<Mithrandir> Keybuk: don't put in a tail at all?  Or does that cause one of them to fall over?
<Mithrandir> Keybuk: make it not syntactically valid so dpkg barfs on it when running dpkg-genchanges?
<fabbione> BenC: yes, but i am not 100% sure it can build the kernel
<Keybuk> makes them both fall over
<Keybuk> dch seems to fall over in all situations that dpkg itself falls over
<Keybuk> which strikes me as somewhat silly
<BenC> fabbione: no reason to do it at build time other than consistency... I don't want someone doing an update to zddevlist and not getting an updated zddevlist.h (ran into this with ndiswrapper and it's generated files when we did zmd64)
<BenC> *amd64
<mjg59> Ah!
<mjg59> siretart: http://www.ath-driver.org/
<fabbione> BenC: ok..
<BenC> fabbione: ok, I'll leave the build dep there, but it isn't enforced at the moment (no hppa patches in the tree yet)
<Treenaks> no background scanning? that explains corey's problems with network manager at UBZ :)
<Keybuk> yeah, network manager flat out doesn't work with atheros cards
<Keybuk> though I've never had a problem getting my atheros to scan, in the background or foreground
<fabbione> BenC: hppa is FTBFS anyway because of the missing configs
<Keybuk> it seems to continually scan anyway
<fabbione> BenC: so i wouldn't worry too much about it
<fabbione> BenC: i had rather get sparc up and running and show the world that sparc > hppa :P
<siretart> mjg59: I'm a bit confused about that ath-driver.org. They seem to reimplement the complete madwifi driver
<BenC> Kamion: ping
<siretart> having a glance at the files in their tarball
<Keybuk> siretart: yeah, it is
<Kamion> BenC: hi
<Keybuk> siretart: ie. they implement both the open source and closed source bits of the madwifi driver
<Keybuk> but both as open source
<BenC> Kamion: will you be around in about 1-2 hours to process a NEW for linux-source-2.6.15?
<siretart> Keybuk: why that? madwifi is gpl. why not forking madwifi?!
<Kamion> BenC: should be, yes
<BenC> Kamion: cool, thanks
<Keybuk> siretart: mafwifi isn't gpl
<Keybuk> 90% of madwifi is closed source
<BenC> then I'll be /away till it's done
<siretart> Keybuk: only a quite small hal module is closed, most of the driver is gpl, afair
<Keybuk> siretart: the other way around, all the interesting driver stuff is in the closed HAL
<Keybuk> the driver is mostly just talking to the HAL
<siretart> hm. i see
<siretart> then i'll help testing ath-driver
<Keybuk> I played with ath-driver a bit, and it worked ok
<BenC> fabbione: BTW, I have 54g antennas ready so I can run network out to the second building where I live...so hopefully the e3k will be up this weekend
<Keybuk> didn't seem to support as many modes as madwifi though, so I bookmarked it with "look at again later"
<fabbione> BenC: ah cool
<siretart> Keybuk: do they support background scanning? *g*
<fabbione> BenC: my sparc is catching up on dapper backlog
<Keybuk> siretart: I've no idea what "background scanning" is
<fabbione> BenC: and the queue is still deep
<BenC> hopefully I can help knock it out
<siretart> Keybuk: with madwifi, everytime you do a 'iwlist ath0 scan', your connection to the AP dies
<Keybuk> madwifi supports sending a scan request, and picking up the results later
<Keybuk> no it doesn't
<siretart> okay. then it supports :)
<fabbione> BenC: yeah but i am not sure it's worth to put online another buildd... specially if we are going to switch to LP. We won't be able to run buildd and upload for a while
<Keybuk> that's a bug in network-manager
<Keybuk> it deliberately drops off the AP before scanning
<Keybuk> or, if you prefer, it's a bug in the wireless API for not having a consistent method of asking cards to scan :)
<Treenaks> Keybuk: yay kernel :)
<mjg59> siretart: My guess would be that some of the code has been altered to deal with their hal setup
<Keybuk> I've yet to investigate what network-manager is doing wrong
<Keybuk> but I know it is doing something wrong, because I wrote an equivalent some time ago which works fine on my card (shockingly :p)
<siretart> Keybuk: I'm experiencing the problem not only in network-manager, but also with wpa-supplicant
<Keybuk> one of the supplicants doesn't work for me either
<Keybuk> I thought it was xsupplicant that didn't work, and wpa_supplicant that worked fine
<siretart> Keybuk: as well when I do manually a 'iwlist ath0 scan'. This lack of 'background scanning' was admitted on madwifi-users mailing list by one of the developers
<siretart> have to look up the name
<siretart> wpa_supplicant works fine
<Keybuk> siretart: do you see it drop off the AP with iwevent?
<siretart> but every few minutes, I loose connection for about 30seks
<siretart> Keybuk: I do
<Keybuk> interesting
<siretart> as after a few seks, a reassociating event
<siretart> s/as/and
<Keybuk> ahh, and you do it as root?
<Keybuk> right
<Keybuk> sorry, I understand now
<Keybuk> yes, the atheros does leap off the AP when you do that
<Keybuk> the trick is _not_ to do that, but just tell the card to continually scan
<siretart> and the madwifi developers call this 'background scanning'
<siretart> extremly annoying, imo
<Keybuk> yeah
<Keybuk> I remember now, I came across that when doing wifid
<Keybuk> it's because an explicit scan on the atheros is implemented as a "change your network" call
<Keybuk> which means it also drops your essid and key preferences
<Keybuk> whereas the card itself continually updates its internal list of nearby APs
<Keybuk> which it uses for best-strength preferences
<siretart> lets see if ath-driver.org does a better job
<mjg59> It may not actually work yet
<mjg59> And its card coverage isn't as good as madwifi
<mjg59> But we should look into it - it's obviously more maintainable
<mjg59> Obvious first step (when it works) is to use it for cards it supports, and fall back to madwifi for the others
<siretart> mjg59: how do you want to package it? in an extra kernel-module package or integrate that into linux-source?
<mjg59> siretart: Possibly keep it external for now - once it actually usefully works, merge it into linux-source
<siretart> agree
<Keybuk> does anyone know, off-hand, of a format of changelog entry that dpkg will reject but dch won't?
<Keybuk> dch seems to refuse to edit badly formatted changelog entries, even if the kind of edit would fix it
<pitti> chmj: gmp is FTBFS, FYI
<fabbione> who has a breezy ppc chroot (other than davis) that could kindly use to build something for me?
<Mithrandir> Keybuk: add -MERGE to the package name?
<pitti> darn, I upgraded my laptop to dapper two weeks ago
<fabbione> pitti: can you build a chroot there?
<Keybuk> Mithrandir: dpkg doesn't reject that
<Keybuk> it'll just warn and upload anyway
<pitti> fabbione: do you want me to build a kernel on this poor iBook?
<Keybuk> you'll hit NEW, of course, so you'd have to hope elmo had his coffee that morning
<Mithrandir> Keybuk: dpkg-source: error: source package has two conflicting values - kbd-chooser and kbd-chooser-MERGE
<fabbione> pitti: no.. i have the kernel.. i need to build d-i
<fabbione> pitti: with the custom kernel on davis
<Keybuk> Mithrandir: oh, hmm
<fabbione> pitti: problem is there are no d-i B-D on davis and nobody to install them
<Mithrandir> Keybuk: it's not pretty, but I can't make it fall over in any other case.
<pitti> fabbione: Znarl can't?
<fabbione> pitti: he is not around
<pitti> oh
<Mithrandir> Keybuk: or just make the distribution "merge" or something.
<Keybuk> so far it's just been easier for me to get the accepteds, and send them to elmo for revoking of upload privileges when Tollef reaches 10
<Keybuk> uh, was that my out-loud voice?
<Keybuk> :)
<pitti> fabbione: it'll take a substantial amount of time, but I can do it if necessary
<Mithrandir> Keybuk: haha :-)
<fabbione> pitti: nah.. ok.. i will wait i guess :/
* fabbione watches the counter dangerously increasing to 2 days and linux on ppc yet
<Keybuk> anyway, that's a good idea
* Keybuk makes mom do that
<Keybuk> BenC: btw, are you compiling our shiny new kernels with CONFIG_KOBJECT_UEVENT turned on?
<Keybuk> it's apparently disabled on alpha in Debian by accident
<Kamion> 'tar xzOf linux-source-2.6.15_2.6.15-1.1.tar.gz `tar tzf linux-source-2.6.15_2.6.15-1.1.tar.gz | grep '/config/.*/.'` | grep CONFIG_KOBJECT_UEVENT' says yes
<Keybuk> where did you get that from? :)
<Kamion> get what from?
<BenC> Keybuk: let me check
<BenC> Keybuk: yep
<uenyioha> hi guys
<Keybuk> oh, BenC uploaded it already
<uenyioha> please is it possible to get the source code for the NPTL
<uenyioha> ?
<Keybuk> my brain is stuck firmly in flappy-paddle gear today
<BenC> yeah, mawk caused it to fail
* Keybuk hates red-eye flights
<Kamion> uenyioha: it's in the glibc source package
<uenyioha> say Kamion: it isn't called linuxthreads by any chance?
<uenyioha> Kamion: it isn't called linuxthreads by any chance?
<Kamion> uenyioha: linuxthreads is a different (earlier) threading implementation
<uenyioha> Kamion: right
<Kamion> uenyioha: 'apt-get source glibc', 'cd glibc-2.3.5', 'debian/rules unpack' and look in build-tree/glibc-2.3.5/nptl/
<uenyioha> Kamion: thanks....i got the 2.3.6 tarball 
<Kamion> if you're looking at the upstream tarball then just look in nptl/
<jbailey> Is nl.archive.ubuntu.com known to be broken in the same way that us.archive.ubuntu.com and ca.archive.ubuntu.com are?
<Treenaks> jbailey: Haven't heard complaints yet, but in what way would that be?
<jbailey> gpg error from apt-get update on the breezy repo.
<Treenaks> no problem for me (nl.archive)
<Kamion> nl.archive == archive
<mvo> jbailey: gpg errors on the archive again? hrm :/
<jbailey> Treenaks, Kamion: Thanks.
<pitti> chmj: ping
<mvo> jbailey: if you get these errors, can you please comment all sources out (all but offending one) and run "apt-get update -o Debug::Acquire::http=true" and put the result into a paste.ubuntulinux.nl?
<pitti> mvo: is #19232 (gksuui merge) obsolete now?
<mvo> pitti: yes, is merged already
<pitti> mvo: so it can be closed?
<mvo> pitti: yes, will do that now 
<mvo> pitti: and check my other merges too
<pitti> thanks
<Mithrandir> Kamion: hmm, any idea why the kbd-chooser changes aren't merged upstream?
<dholbach> i'm out for a walk... bbl
<chmj> pitti: pong
<pitti> chmj: can you please fix this gmp FTBFS?
<chmj> pitti: yes 
<mjg59> Can we enable DHCP's dynamic DNS support by default?
<pitti> mjg59: you mean the 'send-hostname' option?
<mjg59> Yeah
<pitti> this was a great thing at ubz
<mjg59> It's irritating having to manually configure it on every machine
<pitti> mjg59: I just set it manually, can it be told to use the `hostname -f` output?
<Kamion> Mithrandir: most of them are specific to the keymapper thing smurf did and somewhat useless without it; I'm also not very convinced that their cdebconf handling is at all correct. fjp did some hacking recently which might let the translation handling be done better
<Mithrandir> Kamion: hmm, ok.  I thought the keymapper thing was put in upstream as well?
<Kamion> Mithrandir: not yet, no. I strongly think it should be turned into a cdebconf plugin before it goes upstream - at the moment it's a hack in cdebconf core
<Kamion> but we have to fix that for ubuntu-express anyway
<Mithrandir> Kamion: point.  Anyway, It merged without any problems in kbd-chooser so I'll just upload that.
<mjg59> pitti: Hm. It should just be registering the short name, not the FQDN
<pitti> mjg59: ok, makes sense
<mjg59> At least, that's what Windows does
<Kamion> Mithrandir: we really need to sort out cdebconf to let people do out-of-tree plugin builds soon
<Mithrandir> Kamion: I can do that tomorrow instead of doing merges, I guess.
<ogra> mjg59, how does that behave if all machines in the network send the same name ? 
<ogra> mjg59, ltsp thin clients are all called ltsp
<mjg59> ogra: Then you don't configure your DNS server to accept the updates
<Kamion> Mithrandir: I'll love you forever, or at least buy you lots of beer at the distro sprint
<ogra> mjg59, what about dhclient ... doesnt it slow it down or something if it is blocked ? 
<Mithrandir> Kamion: :-)
<siretart> what about switching to dhcpcd by default?
<mjg59> ogra: No - the hostname is sent in the request packet
<ogra> ah, fine then :)
<mjg59> It's dhcpd that passes on the update
<ogra> siretart, ?
<ogra> (oh missed the c :) nevermind)
<siretart> :)
<siretart> mjg59: perhaps we can make the dhclient postinst script to provide a suitable 'send-hostname' line in /etc/dhcp3/dhclient.conf
<mjg59> siretart: Or we could add functionality to dhclient...
<siretart> mjg59: what functionality exactly? to send-hostname the hostname by default if not disabled in the config file? or another commandline switch?
<pitti> Mithrandir: AFAICS we can sync krb4, but could you please have a second look onto the patch?
<Mithrandir> pitti: will do
<mjg59> siretart: One of those two, yeah
<siretart> mjg59: I'd prefer the former, but since this is rather intrusive, I'd go for changing the postinst script due to lazyness
<siretart> hi neuralis!
<mjg59> siretart: But that fucks up if anyone changes the hostname
<neuralis> siretart, hey!
<siretart> mjg59: thats right. hmm
<pitti> Kamion: if you have the time, could you please NEW openssl, so that we can upload packages against 0.9.8?
<Kamion> pitti: done
<pitti> merci
<Kamion> don't we need openssl097 now?
<pitti> infinity wanted to rebuild everything against 0.9.9
<pitti> s/9$/8/
<Kamion> but in the meantime ...
<pitti> Kamion: hm, but since our openssl now uses 0.9.8, why do we need it?
<Kamion> because otherwise libssl0.9.7 will be removed RSN and lots of stuff will break?
<pitti> oh, I thought debs remain in the archive until nothing depends onthem any more; I saw that for other libs
<Kamion> only if ftpmaster (a) uses the melanie flag to let them notice, (b) is feeling nice
<Kamion> no, that behaviour is what testing is for, and we don't use that
<pitti> Kamion: ok; that means we need to sync openssl097 from debian for a while and remove it later?
<Kamion> that was my thought
<Kamion> I dunno, elmo might disagree, I just don't see the need to break things more than we have to
<Mithrandir> pitti: seems to build for me at least, so let's try syncing it.
<pitti> Mithrandir: k, thanks
<pitti> Mithrandir: I updated the bug
<pitti> I want to collect a few more syncs until I bother Colin again :)
<seb128> Kamion: could you sync "pyorbit pxlib easytag (why is this one needed, that's -build2 version?) gazpacho goffice libgtkhtml2 (experimental) gnome-keyring (experimental)" please?
<janimo> smurf ping
<pitti> Kamion: if you are at it, could you also sync br.ispell iproute krb4 shorewall unixodbc ?
<janimo> libgnutls does not seem to install it's .pc file, is that intentional?
<janimo> config scripts looking for it using pkg_config don;t detect it
<Kamion> seb128: nothing to sync for easytag, it's already 1.99.9-1 in both sid and dapper
<seb128> Kamion: hum right, it got updated since I've listed it, thanks
<Kamion> seb128:  [dpkg-source output:]  dpkg-source: error: file gazpacho_0.6.2.orig.tar.gz has size 433368 instead of expected 438309
<BenC> Kamion: ok, new kernel-package for ppc build was just ACCEPTED, how long should I wait on the new linux-source upload, since it needs that package to build?
<seb128> k, thanks anyway (why people need to change the orig from upstream?)
<Kamion> seb128: goffice pxlib pyorbit synced, overwriting Ubuntu changes
<seb128> Kamion: thank you
<pitti> BenC: to relieve some pain from Colin, I can tell you when the package goes into the archive
<BenC> pitti: ok, thanks
<Kamion> BenC: cron.daily runs at :03 and :33; about ten minutes after that you can be pretty sure that the packages are usable by buildds
<Kamion> seb128: libgtkhtml2 gnome-keyring done too
<BenC> Kamion: so even a _all.deb will be available to all buildd's after it's done?
* Keybuk wonders whether we should estimate time in Ubuntu Days
<seb128> cool, thanks
<Kamion> BenC: yes
<BenC> cool, thanks
<Kamion> BenC: if you want to be safe, wait until you can see it on archive.ubuntu.com
<BenC> I'll go ahead and upload 2.6.15-2.2 then, and ping you in about 30 minutes :)
<Kamion> at worst you'll lose half an hour by doing that
<Kamion> pitti: done, overwriting Ubuntu changes
<Kamion> BenC: I shouldn't need to NEW the source, only the binaries, which will arrive later
<BenC> Kamion: ah, correct, I'll hold off on the upload
<pitti> Kamion: thanks
<jbailey> We need to add "Ubuntu" to all of our dictionaries. =)
<ogra> yeah
<pitti> chmj: is #19021 still valid?
<ogra> and kubuntu and edubuntu too please :)
<ogra> and sabdfl
<Treenaks> ogra: let's start with ubuntu
<slomo> elmo: please sync wavpack and gmime2.1 and libextractor from debian/unstable... ubuntu changes can be dropped
<Keybuk> Kamion: yeah, we definitely need the real modprobe, not the busybox one
<Keybuk> or heavily patch the busybox one, and forever play catch-up
* mvo needs to run now, he has a appointment, bb in 2h
<Kamion> Keybuk: I kind of hope modprobe will stabilise at *some* point
<pitti> Kamion: please sync ispell-fi and libpng; then I won't bother you any more today, promised :)
<pitti> (not urgent, though)
<Keybuk> Kamion: maybe, but it's only 20K :p
<Kamion> pitti: E: libpng12-dev is in main but it's source (libpng) is not.
<Kamion> Keybuk: upstream d-i will take this pretty soon, and 20K really matters on the floppies
<pitti> whoops? ok, don't bother then, I'll look into that
<desrt> Kinnison; i realised that somewhat after the fact
<desrt> Kinnison; no matter
<Kinnison> desrt: :-)
<Keybuk> a
<Kamion> pitti: ispell-fi done
<Kinnison> desrt: was it anything you still need resolving?
<desrt> no.  i was just going to poke you randomly
<Keybuk> Kamion: so we should patch the busybox modprobe to support blacklisting?
<desrt> i can do it now if you like
<Kamion> Keybuk: I think so, yes
<Kamion> or whatever we need in the installer
<slomo> Kamion: are you the one to ask for syncs atm? or only for really important stuff?
<Keybuk> I imagine the installer will need the same module blacklists as the ordinary userspace
<Kinnison> desrt: ill it be a pleasant random poke?
<Kinnison> desrt: or will it make me squeal like keybuk?
* desrt randomly pokes Kinnison, pleasantly
<Kinnison> woohoo!
<Keybuk> I don't squeal
<Keybuk> I moan appreciatively
<Kamion> pitti: you sure you mean libpng? it only seems to build libpng2 and libpng10 in breezy
<Kamion> Keybuk: don't see why it'd need e.g. the alsa ones
<pitti> Kamion: I just took a look at the diff, and saw the MOM bug
<desrt> i taught mao to a couple of people 2 nights ago.  that was particularly interesting.
<pitti> Kamion: but libpng is a mess anyway, I'll figure that out later
<Keybuk> Kamion: true, but we'd need the network card ones
<Simira> Kamion, Kinnison: are Sundays a nice day to have beer in Cambridge?
<Kamion> E: wavpack: not found
<Kamion> slomo: ^--
<Kamion> slomo: (i.e. wavpack is not in Debian; did it come from somewhere else?)
<slomo> Kamion: sorry, it's still in incoming :/
<Kamion> slomo: gmime2.1 and libextractor done; I'd kind of rather not do syncs of new packages from incoming, since then we have to duplicate the manual checking that Debian does
<slomo> Kamion: ok, np... isn't that important anyway :) but it's not NEW for us, we already have it in universe and the packaging only differs slightly... needed to change some small things for my sponsor
<Kamion> slomo: I know, but still
<Kamion> the Debian NEW queue is pretty quick these days, so we can sync it later
<slomo> Kamion: yes, sure... that's actually the reason why i asked for the sync ;) i thought it was already in as it was accepted last night
<Kamion> oh, duh, I'm a moron, incoming == accepted not new
<Kamion> all the same I don't know where to get the Sources file for incoming, so you'll have to wait anyway ...
<slomo> np :)
<Keybuk> Kamion: ah, I remember why I picked those statuses for Bugzilla now
<Keybuk> there's a *shock* comment above the line of code
<Keybuk> it's the default set of statuses in a Bugzilla search
<Keybuk> mom-in-Bugzilla, that is
<Kamion> ah
<Keybuk> http://bugzilla.ubuntu.com/buglist.cgi?product=Ubuntu&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Bug+Number&field0-0-0=alias&type0-0-0=regexp&value0-0-0=%5Emerge-
<Keybuk> ^ btw, randomly useful Search to Save
<fabbione> that's trunked
<Keybuk> no it's not
<fabbione> truncated even
<Keybuk> so isn't
<Keybuk> it's just hand-edited to not contain a billion keys
<fabbione> ah ok
<fabbione> the last - was suspicious
<ogra> pitti, chmj, whats going on with coreutils ??
<Kamion> ogra: did you look at the diff against Debian in chmj's upload?
<ogra> nope
<Kamion> I suggest you do
<ogra> i just noted that i have a totally different version than others... and uniq is missing options used in some scripts
<Keybuk> http://people.ubuntu.com/~scott/patches/coreutils/coreutils_5.2.1-2.1ubuntu1.patch
<Kamion> the only changes were a standards-version change and a versioned dependency on perl-base that the version of perl-base in warty matches
<pitti> ogra: we just synced it?
<ogra> oh, it didnt build yet ... 
<Kamion>  coreutils |     5.93-2 |        dapper | source, amd64, i386, powerpc
<doko> Keybuk: really announce the allocator change to -announce?
<ogra> now i understand ... seems others already have 5.93
<Keybuk> doko: sure, it's an "upcoming change" that somebody might go "ooooh, need to fix something" for
<seb128> Keybuk: that's typically the kind of stuff the distro team want to read I guess
<Keybuk> -devel-announce is the signal, CAN'T STOP THE SIGNAL! :p
<Diziet> Bah, I suppose sabdfl will grumble if I `accidentally' break the Home/Desktop distinction in firefox by dropping this patch.
<smurf> janimo: 
<Kamion> jbailey: you have syncs outstanding from pre-breezy; do you need to give them to other people?
<pitti> ogra: edubuntu-server is the only package that keeps postgresql-8.0 in main. I already updated the seeds a while ago, can you please update the metapackage?
<pitti> ogra: (updated for 8.1(
<ogra> pitti, oki
<janimo> smurf, hey
<janimo> what does that mean?
<janimo> pong? :)
<Keybuk> Kamion: btw, ~18900 is the first dapper merge
<smurf> janimo: You ping me, I pong you
<janimo> see the two lines I wrote after the initial ping
<Kamion> #18992 is the first open one
<janimo> libgnutls vs pkg_config
<Keybuk> smurf: that meant ping though, you wanted  for pong
<Keybuk> Kamion: wow, I'm so good
<janimo> where does one learn this stuff?
<janimo> I'd like to know what is the sign for please sync
<fabbione> Keybuk: what was the url to that bootchart thingy?
<Keybuk> fabbione: the package?  people.uc/~scott/packages
<fabbione> thanks
<smurf> Keybuk: ?? ping is , according to gucharmap
<smurf> janimo: I'll have a look, thanks
<janimo> smurf, thanks
<Keybuk> smurf: maybe I'm confused then
<Keybuk> I always thought ping was \ and pong / ... but if gucharmap disagrees, it's probably right :p
<wasabi_> xscreensaver somehow does not work with PAM properly. =(
<ogra> wasabi_, xscreensaver will die
<wasabi_> good.
<wasabi_> on breezy it's impossible for me to unlock it
<ogra> we move to gnome-screensaver ...
<wasabi_> Oh, gnome-screensaver has the same problem for me heh.
<ogra> hmm, but it has pam support compiled in ...
<wasabi_> Yeah, but for whatever reason it fails auth, and only tries pam_unix.
<wasabi_> My pam setup is a bit complicated.
<elmo> DEAR *, THIS IS A PUBLIC SERVICE ANNOUNCEMENT: when your package is REJECTED, you need to actually CHANGE something before reuploading it.  THAT IS ALL.  KTHANKS.
<seb128> hi elmo :)
* ogra looks for *
<seb128> elmo: nice to have you back :p
<doko> elmo is live again ;-P
<janimo> ogra, what were the probs with xscreensaver?(link) thanks
<ogra> janimo, ?
<janimo> why is it being replaced I mean
<janimo> is gss in gnome core?
<ogra> janimo, its not as good integrated with the desktop as g-s-s
<ogra> it requires a lot of patching to have a beatiful lock dialog
<ogra> the code is ancient ...
<janimo> right now it seems it looks ok to me
<ogra> it uses .xscreensaver files 
<Kamion> doko: some people have responsibilities that require them to be in other places than in front of a computer :P
<janimo> for xubuntu I guess it will stay
<ogra> which makes it hard to integrate with the rest of the desktop which uses gconf ...
<ogra> janimo, i think the main parts will move to universe ... only the hacks we ship will stay in main
<janimo> isn;t it a single package?
<ogra> nope 
<ogra> its three currently ...
<doko> Kamion: sure, that was just the nice "I'm back" message
<ogra> and it will become 5
<janimo> uh
<ogra> yes :/
<jbailey> Kamion: The pre-breezy syncs are generally ones that got assigned to me last minute when I was hacking on other things, so missed the deadline.  If others are idle, they're welcome to do them, otherwise they'll get done after the glibc/lkh update.  I'd expect them all to be done by mid next week.
<ogra> sabdfl request ... the hacks already split into gl and nongl packages ... plus the binary (daemon/client) 
<ogra> he wants to have the hacks split into sipped and unshipped ...
<ogra> *shipped
<janimo> why do the hack remain in uni if g-s-s replaces x-s-s?
<Treenaks> sounds reasonable, if you have a shitload of hacks
<Treenaks> or want "screensaver themepacks"
<janimo> can g-s-s use some of x-s-s data?
<ogra> the x-s-s-hacks-ship and x-s-s-gl-hacks-ship packages will go to main... the rest gets dropped
<Treenaks> ogra: not universe?
<ogra> they will be tweaked so you can use them with g-s-s
<ogra> Treenaks, dropped into the big universe of packages :p
<Treenaks> ogra: ah *phew*
<janimo> hmm will that tweakage prevent x-s-s using them ?
* Treenaks can't live without his precious jumping cow
<ogra> janimo, nope
<janimo> ok then
<ogra> janimo, i just have to add a .desktop file foe every hack we ship...
<ogra> *for
<janimo> thanks
<ogra> x-s-s will ignore that
<elmo> ok, who merged lm-sensors?
<Kamion> elmo: please sync mac-fdisk, perl
<fabbione> elmo: afaik Mithrandir 
<elmo> Mithrandir: DEAR TOLLEF, PLEASE BE AWAKE WHEN MERGING.  IT HELPS, NO REALLY.
<fabbione> hi elmo
* Mithrandir turns down the elmo-volume-o-meter.
<elmo> Mithrandir: dude, unscrew lm-sensors, and I'll quiten down
<Keybuk> who uses lm-sensors anyway?
<fabbione> *cough*
<Treenaks> uh, doesn't mithrandir have a Thinkpad? Doesn't lm-sensors break on thinkpads?
<elmo> Mithrandir: specifically, it shouldn't be building 2.4.xx kernel modules ...
<Mithrandir> Treenaks: amazingly enough, I have other machines too.
<Mithrandir> elmo: it doesn't build any 2.4 modules here.
<Mithrandir> I was pondering nuking that part from debian/rules, can do that though
<elmo> katie@jackass:~/queue/new$ ls lm-sensors*
<elmo> lm-sensors-2.4.27-2-386_2.9.2-5ubuntu1_i386.deb      lm-sensors-2.4.27-2-k7-smp_2.9.2-5ubuntu1_i386.deb
<elmo> it does on our buildds :-P
<Mithrandir> silly buildds. :-P
<Mithrandir> I'll fix it
<elmo> Kamion: done
<fabbione> elmo: thanks for the sparc NEW love
<Mithrandir> elmo: ok, package with all traces of module building uploaded, though I have no idea how that happened.
<Kamion> Mithrandir: hmm, localechooser's breaking on current CDs in qemu
<Mithrandir> Kamion: oh joy.  Breaking how?
<Mithrandir> elmo: can you please sync heimdal, ttf-indic-fonts, ttf-freefont, liboil?  Overriding ubuntu changes is ok.
<Kamion> Mithrandir: I select "English", "United Kingdom", and localechooser exits 20
<elmo> Mithrandir: done
<Mithrandir> Kamion: localechooser doesn't have an "exit 20" in it, though.
<Mithrandir> Kamion: I might have screwed up languagelist when merging it; can you get a trace?
<Kamion> Mithrandir: ah, it's "20 Incorrect number of arguments" from debconf, due to db_get without arguments
<Kamion> Mithrandir: it's the "When running under oem-config" block ...
<Kamion> Mithrandir: ok, I've got it, will fix
<Mithrandir> Kamion: thanks.
<Mithrandir> elmo: thanks a lot.
<mdz> morning
<seb128> hi mdz
<seb128> pitti: http://live.gnome.org/GStreamer_2fesd FYI
<slomo> elmo: please sync balsa from debian/unstable... ubuntu changes can be dropped
<fabbione> hey mdz
<pitti> seb128: thanks for the link
<pitti> Hi mdz!
<pitti> elmo: can you please sync ocaml? (override ok, I tested the package locally)
<pitti> elmo: it has a NEW package, though
<slomo> elmo: and please sync gnunet from debian/unstable... ubuntu changes can be dropped
<Simira> Nafallo: got your mail? I got one of yours in return
<pitti> mdz, Kamion: btw, I reviewed (and still reviewing) the anastacia output and I created a couple of reports
<pitti> Kamion: since you wanted to promote some packages soon
<Nafallo> Simira: ah, yes :-).
<Nafallo> Simira: have jenny sent the signatures to you yet?
<mdz> pitti: anything ready to promote?
<pitti> mdz: yes, see the queue
<pitti> mdz: this should make at least abiword buildable
<pitti> mdz: I'm still digging through the plethora of perl modules that po4a introduces
<pitti> but several packages b-dep on po4a, so I hope to finish this today
<Keybuk> cooky, mom doesn't notice when a file is added differently on both sides
<BenC> mdz: ping
<mae> theres a lot of buzz on launchpad about dapper
<mae> !
<slomo> BenC: ping?
<HiddenWolf> is the switch bugzilla -> malone still going ahead?
<Keybuk> so, err
<Keybuk> could someone install BenC's shiny new kernel, and see if their machine will boot <g>
<Treenaks> Keybuk: I think we have a volunteer in #ubuntu-nl
<Keybuk> does he knowingly know it might not boot? :p
<pitti> Keybuk: -amd64 just hit accepted/
<pitti> Keybuk: I'm eager to try it :)
<Nafallo> is it NEW'd? :-)
<sivang> Keybuk: I wouldn't mind either , but I have to reach home before :)
<Nafallo> Keybuk: he told me he runned it on his laptop the whole ubz-week when I asked ;-)
<Keybuk> I'd be interested to know how he gets /dev
<Keybuk> in particular, /dev/input
<Treenaks> Keybuk: yes
<Treenaks> Keybuk: but anyway, I'm trying it on my _other_ laptop :)
<Treenaks> (oh, and don't ever post photos of conferences on your site. you won't like the bandwidth bill)
<Keybuk> I don't pay for bandwidth :)
<pitti> $ sudo dpkg -i linux-image-2.6.15-2-amd64-generic_2.6.15-2.2_amd64.deb - whoo!
<BenC> slomo: pong
<BenC> FYI, amd64 is _completely_ untested :)
<pitti> BenC: then you will hear me screaming soon :)
<Treenaks> BenC: I'm currently downloading .15-2
<Treenaks> Keybuk: I do, and it sucks :) but oh well :)
<BenC> i386 and ppc I can say "works for me", and that you should get the same hw I have if it doesn't work :)
<BenC> if this channel is empty after 30 minutes, I guess I'll have to go hide somewhere
<Treenaks> BenC: Then a coordinated effort to hunt you down will begin, I guess
<Keybuk> BenC: and you have stuff in /dev/input? :p
<Keybuk> cooky
<Keybuk> kooky too
* Diziet gets to the end of the firefox `files to merge list'.  Excellent, I can spend tomorrow trying to get it to build.
<Diziet> That'll make a nice change from reading huge and often incomprehensible diffs.
* Keybuk hugs smerge-mode
<Diziet> -1s/merge list'/merge' list/'
<BenC> Keybuk: my G4 actually works ok, except that my gnome desktop will not accept that my cdrom is mounted (it is, but it wont open it)
<Diziet> The real problem was that I had little idea what most of the changes did.  Luckily the vast majority seem generally irrelevant for 1.5beta.
<Diziet> Now, dinner !
<Diziet> TTFN all
<BenC> my i386 has problems with the new rt2500pci, but other than that, all the USB devices work (lots of joysticks and stuff, because it's a mame arcade machine)
<Keybuk> curious
<Keybuk> various people have sworn blind that old udev flat-out doesn't work
<pitti> mdz: can you please promote the lot in UbuntuMainInclusionQueue? This should clean up anastacia a lot
<BenC> my G4 shows three mice in /dev/input, which matches because I have a Logitech Internet Nav keyboard
<BenC> and it shows three ts# devices...what are those?
* pitti tries 2.6.15 amd64, brb (hopefully)
<Treenaks> touchsceeen?
* BenC hopes pitti returns soon
<Treenaks> :)
<Treenaks> This is why I have spare boxes to test on
<BenC> yeah, removing tsdev removes those
<Keybuk> BenC: udevinfo -a -p $(udevinfo -q path -n input/ts0)
* Treenaks fires up the reboot thingy
<Treenaks> BenC: my framebuffer looks al weird now, but it seems to boot
<slomo> BenC: do you plan to update libraw1394 to the newest upstream? it's needed by some packages
<Treenaks> BenC: vertical stripes, with a hint of "something's scrolling here" in them
<BenC> slomo: I currently have no way to do it in debian, if that's what you mean
<BenC> Treenaks: weird, does console work after it boots to gdm?
<Treenaks> BenC: *try*
<Treenaks> BenC: yes, ctrl+alt+f1 is fine
<BenC> vga16fb must be a bit broken then
<BenC> usplash enabled?
<slomo> BenC: can i update it and give it to you for review? (for ubuntu that is)
<BenC> slomo: by all means, please
<Treenaks> BenC: usplash-enabled; vga16: yes
<BenC> I need to do some more testing with usplash, my i386 here doesn't have it enabled
<Treenaks> BenC: so vga16fb-brokenness could very well be
<slomo> BenC: thanks... i'll do it later
<BenC> Treenaks: other than that, sound working, networking?
<Treenaks> sound, yes
<BenC> amd64?
<Treenaks> network (wired): seems to work
<Treenaks> network (wireless, ipw2200) looks broken
<BenC> yeah, I had heard that it was
<BenC> I wonder if it's the ieee80211 stack that's broken...my wireless rt2500pci was broken aswell
<Treenaks> ah firmware
<slomo> elmo: please sync gnunet from debian/unstable... ubuntu changes can be dropped
<BenC> oh yeah, that's what it was, firmware
<BenC> let me mark that down for fixing
<pitti_> wow, that was smooth
<pitti_> Keybuk, BenC: apart from a totally broken usplash video mode, 2.6.15/amd64 boots and works fine here
<BenC> nice
<BenC> do you have wireless?
<pitti_> Keybuk, BenC: X11, sound, usb hotplug, network work fine
<Treenaks> pitti_: usplash is broken for me too
<Treenaks> pitti_: or at least, the video mode
<pitti_> BenC: only on my laptop
<BenC> vga16fb is broken
<BenC> usplash works on my G4
<BenC> pitti_: what wireless card?
<pitti_> BenC: there is no signal in the corner of the room where my desktop stands
<BenC> I'm really interested in a lot of wireless feedback, since that's what most of our external drivers are related to
<Nafallo> BenC: rt2x00 beta drivers?
<pitti_> BenC: once ppc kernel has built, I'll upgrade my ibook and test linux-wlan-ng
<BenC> Nafallo: yeah, 2.0.0-b2
<pitti_> BenC: I have another wireless card that 2.6.12 did not support OOTB
<Nafallo> BenC: scary :-P.
<pitti_> BenC: however, lemme just plug it in and try
<BenC> pitti_: my G4's Airport card seems to be working ok for almost 24 hours now
<pitti_> wow
<BenC> not Airport Extreme, just 11b
<pitti_> BenC: I don't have an airport extreme for my ibook yet, but if it works, I'll buy one
<pitti_> BenC: wil that work for ppc?
<BenC> I don't expect Airport Extreme to work, my laptop's wireless used that dirver, and it just crashed
<pitti_> [  755.669540]  prism2usb_init: prism2_usb.o: 0.2.2 Loaded
<pitti_> [  755.669544]  prism2usb_init: dev_info is: prism2_usb
<pitti_> [  755.675334]  usbcore: registered new driver prism2_usb
<pitti_> [  755.707042]  wlan0 (WE) : Driver using old /proc/net/wireless support, please fix driver !
<BenC> my G5 has Airport Extreme, so I'm hoping to get some testing soon
<pitti_> BenC: above is dmesg for my prism2 card which I normally use on my laptop
<slomo> pitti_: there's a driver in development... afaik it can already kismet but no sending ;) i'll test it when 2.6.15 for ppc is built
<Keybuk> pitti_: ok, that's good then
<BenC> slomo: the bcm43xx driver?
<BenC> s/pitti/slomo/
<Treenaks> oh yeah, mine complains about "pci driver ipw2200 has a struct device_driver shutdown method, please update!"
<magnon> afaik the driver for airport extreme is being reverse engineered and they're making a spec 
<BenC> err, yeah
<magnon> so there should be a driver soon
<slomo> BenC: yes... someone on their ml wrote about using it with kismet
<BenC> that driver is in the 2.6.15-2.2 upload
<BenC> you can try it, but I doubt it works
<magnon> exactgly
<magnon> -g
<slomo> BenC: oh, nice :) but i prefer trying svn every few days
<BenC> the checkout was from 11-09, so it's pretty recent
<BenC> definitely let me know if it ever starts working
<pitti_> BenC: iwconfig says 'no wireless extensions' here, but I never tested that prism2 thingy on my desktop
<BenC> pitti_: weird
<Keybuk> mjg59, mdz, sabdfl: ping
<slomo> BenC: sure, i'll yell at you :P when will we get 2.6.15 for ppc?
<pitti_> BenC: hmm, maybe I should install the l-wlan-ng package :)
<BenC> pitti_: can you see if there is another driver that supports it in your modules?
<BenC> I recall that there was more than one driver that worked on prism2
<BenC> slomo: depends on how fast the buildd is, I suspect it is chugging on it right now
<Kamion> BenC: I already did the legwork to extract the firmware for my laptop's AE, so I'll try it out in not too long
<fabbione> BenC: my ppc is installing right now
<slomo> BenC: fine, so i can start breaking my ibook soon :)
<BenC> glad that so far everyone atleast can boot it
<fabbione> BenC: as soon as we can get all pieces together, i can test too
<BenC> fabbione: nice
<fabbione> i am not sure tho this version of the Airport is supported at all
<fabbione> the hw on the new powerbook is barely supported by linux :/
<fabbione> Olof said that the trackpad doesn't work.. and other stuff too.. but i don't have X yet
<Kamion> fabbione: it'll be an Airport Extreme surely - Apple haven't shipped Airports with PowerBooks for years
<BenC> if it's Extreme, which it probably is (11g) then no, if it's just an Airport, then it will work
<Kamion> but yours should have a PCMCIA slot
<BenC> fabbione: track pad should work with out patches
<pitti_> BenC: my Siemens Gigaset USB wireless is not recognized, but that required an external driver in 2.6.12, too
<fabbione> BenC: not according to Olof on the new serie
<pitti_> BenC: that worked after a lot of fiddling and driver compilation
<BenC> fabbione: ah, ok
<fabbione> Kamion: yes, that doesn't bother me.. i am on cable here
<magnon> fabbione: my trackpad works with the appletouch driver
<BenC> pitti_: if you can track down the driver, we can include it
<fabbione> magnon: on the new serie?
<magnon> is there another one?
<magnon> mine is from may
<fabbione> yes
<fabbione> there is a new one 
<magnon> bah
<fabbione> from like a month ago
<pitti_> BenC: that's the atmel driver
<fabbione> magnon: but there are also other problems on this new hw
<pitti_> BenC: http://atmelwlandriver.sourceforge.net
<fabbione> like sleep doesn't work
<fabbione> but benh is already working on getting it fixed
<BenC> pitti_: thought we had that driver...guess I'll have to check
<pitti_> BenC: I compiled it successfully (after some fiddling) against several kernels
<pitti_> BenC: linux upstream does have atmel drivers, but not for the USB cards
<magnon> fabbione: not surprising...
<BenC> pitti_: can you try rmmod prism2(whatever the module is called) and modprobe hostap_cb?
<BenC> I think that was the one that also supported prism2 cards
<pitti_> BenC: for the netgear one? sure
<dholbach> is everybody in #ubuntu-meeting? it's TB meeting :)
<Treenaks> BenC: ooh, when I press the power button, it shuts down nicely
<Treenaks> BenC: but at poweroff -> PANIC
<BenC> Treenaks: hmm, email the panic to bcollins@u.c please?
<pitti_> BenC: [ 1373.080276]  hostap_cs: 0.4.4-kernel (Jouni Malinen <jkmaline@cc.hut.fi>)
<pitti_> BenC: however, no wireless card in iwconfig now
<Treenaks> BenC: uh, no serial on that machine.. and I'm _not_ going to copy a screendump manually ;)
<pitti_> BenC: and no other output
<BenC> Treenaks: pictures work ok :)
<Treenaks> BenC: oh DOH
<BenC> pitti_: ok
<Treenaks> BenC: the picture is 4MB; ok to mail? :)
<BenC> Treenaks: hmm, guess it's worth a shot :)
<pitti_> BenC: it seems that the hostap drivers are only for pcmcia and pci
<BenC> oh, thought that had a usb one too
<Treenaks> BenC: sending... :)
<Treenaks> BenC: OK, sent
<BenC> thanks
<mpt> Kamion, ping
<Kamion> mpt: hi; if you include the actual question with your pings we'll have fewer one-day round trip times :)
<mpt> heh
<mpt> Kamion, I have a couple of questions to tidy up UbuntuExpress/PartitioningTool
<ogra>  hrm, is gksudo broken for anybody else ? 
<mdke> ogra, yes
<ogra> ah, ok, then i'm at least not alone :)
<Kamion> mpt: ok, that might take a while and I'm giving up for the evening soon; can it be done by e-mail?
<mpt> Kamion: first, how long will/might it take to scan all the disks and see how much space is available on each one?
<mpt> sure, no problem
<dholbach> ogra, mdke: should be fixed now
<dholbach> ogra, mdke: the new libgksuui will fix it
<Kamion> mpt: it's quick enough that we already do it at the partman main menu in our existing installer
<ogra> dholbach, thanks :)
<Kamion> not instant, but pretty short
<neuralis> mdz, ping
<Kamion> BTW you know UbuntuExpress/PartitioningTool is already approved, right?
<mpt> yes
<Kamion> ok
<mpt> it's approved, but I thought it might be incomplete
<ogra> mpt, the code is afaik
<Kamion> ogra: of course it is
<mpt> Kamion, the other question was, what if a partition is so fragmented it can't be resized?
<Kamion> mpt: libparted deals with that
<Kamion> non-prehistoric systems automatically defragment
<mpt> perhaps, but libparted doesn't have a gui of its own
<mpt> I mean, where do we take the person if libparted comes back with an error
<Kamion> mpt: it doesn't matter, libparted automatically restructures e.g. the FAT when resizing
<Kamion> there is no such thing as "so fragmented it can't be resized" AFAIK
<mpt> oh, great
<Kamion> if libparted comes back with an error, we present the error, but that's not generally one of the cases where that will happen
<Kamion> we can do our best to avoid such situations happening, but partitioning is a complex subject and from time to time things will go wrong
<dilinger> oh yea
<mpt> All right, that's all I wanted to know
<mpt> thanks Kamion 
<dilinger> i forgot to submit my parted patches
<Kamion> ok, cool
<Kamion> no problem
<mpt> ogra, "the code is ___________ afaik"?
<ogra> <mpt> it's approved, but I thought it might be incomplete
<mpt> so the code is approved, or the code is incomplete? :-)
<ogra> the latter one :)
<Kamion> we're talking about a spec, not the code
<mpt> indeed
<mpt> that's why I was confused :-)
<Kamion> a week and a half after the conference I think it's obvious that the code will be incomplete ;)
<ogra> Kamion, was this newly discussed at ubz ? i didnt know that...
<Kamion> ogra: all of UE was re-discussed
<ogra> ah, ok
<mpt> ogra, https://wiki.ubuntu.com/UbuntuExpress/PartitioningTool
<Keybuk> ok ... either the hdparm maintainer is on crack, or I need to have coffee
<ogra> did he implement the hdparm settings in gconf ? 
<Keybuk> no, but it looks like the upgrade stuff in postinst will do almost exactly the wrong thing
<ogra> mpt, looks cool ... 
<Riddell> ogra: what time is dapper dev meeting on thursday?
<Keybuk> preinst, even
<Keybuk> Riddell: 0800
<Riddell> ug, early
<ogra> Riddell, just stay up :)
<Riddell> ogra: given my current sleep pattern that's not unlikely
<dholbach> brb
* xhaker banhoca
<Nafallo> hmm
<Nafallo> is it normal that usplash is screwed on the new kernel? ;-)
<pitti_> Nafallo: for me, too
<Nafallo> good to not be alone :-)
<Nafallo> my "mousewheel" moves my pointer up and down ;-)
<pitti> hm, works for me
<Nafallo> synaptic touchpad?
<Nafallo> oh!
<Nafallo> looks like rt2500 still can scan atleast :-)
<BenC> I think I figured out the usplash problem
<BenC> and oddly enough it seems to be a usplash bug :)
<sladen> fore soth, usplash doth have many corners
<sladen> have you tracked it down enough to file it?
<BenC> it's not really a bug, I guess
<BenC> just the location of softcursor.ko changes (video/console/ instead of video/)
<BenC> but I can't understand why there isn't a modprobe in initramfs, so it didn't have to use insmod
<BenC> would solve the problem easily
<Kamion> BenC: looking back through irclogs, apparently the original reason was that modprobe would require an updated modules.dep in the initramfs
<BenC> but the initrd does in fact call depmod several times :)
<BenC> atleast that's what I gathered from some of the BOF's at ubz
<Kamion> yeah, but that's going to go away I think
<Kamion> and the depmod would have to happen at run-time rather than initramfs-build-time because initramfses can be concatenated at boot
<BenC> only because modules.dep will be expected to be sane
<Kamion> http://people.ubuntu.com/~fabbione/irclogs/archived/2005-09/ubuntu-devel-2005-09-10.html
<Kamion> near the bottom, there's a discussed
<Kamion> discussion
<Kamion> the conclusion seemed to be that modprobe --show-depends would help
<slomo> BenC: 2.6.15 works fine here on my athlon... good work :)
<BenC> slomo: good to hear, thanks
<BenC> well, seems the problem wasn't simply the softcursor module
<BenC> well, usplash isn't even showing up for me
* BenC spits out one more "well" for good measure
<Nafallo> BenC: scrolling on my synaptics touchpad stopped working, except that it seems working :-)
<Nafallo> (famous last words :-P)
<BenC> yeah, I noticed the same with my synaptics too, but I can't test it anymore
<Nafallo> good, only reproducible stuff yet then :-)
<BenC> yeah, so far nothing deadly too
<xhaker> broken deps ;)
* xhaker back!
<Mithrandir> xhaker: please turn off public away
<xhaker> Mithrandir, sorry. i thought xchat did it only at the network i was in
<xhaker> ame seems to spawn at every network :S
<slomo> elmo: please sync gnunet-gtk from debian/unstable... it's NEW
<fabbione> infinity, lamont-away, elmo: is any of the ppc buildd munging the kernel?
<elmo> err, "munging"?
<psusi> so what's up with all the talk on the ml lately about init?  What's wrong with init that supposedly makes it slow?
<fabbione> elmo: did you ever use "munge" on amiga to do debugging?
<elmo> I was an Atari person :P
<fabbione> elmo: it become a synonimous of "working hard" on something
<fabbione> tsk ;)
<Keybuk> psusi: nothing
<Keybuk> it's just one of those shiny things that everyone blames who hasn't actually bothered to find out what the problems really are
<Keybuk> it's the layman's -pipe
<Mithrandir> Keybuk: but -pipe -pipe -pipe is _even_ faster.
<crimsun> elmo: please sync xsidplay, xmltv, xine-ui, xfstt, wmtv, wmsysmon, waili, and vpnc from Sid (ok to override ubuntu changes)
<psusi> ok... that's what I figured
<BenC> anyone know why I wouldn't have a /dev/null in my initramfs?
<BenC> usplash is failing because of that
<elmo> fabbione: no - it broke, given it back
<fabbione> elmo: thanks
<sladen> BenC: /win 22
<Keybuk> BenC: weird, it's created right at the top of the initramfs init script
<psusi> I need to give that boot profiler a try... I've timed my boot time at 27 secconds but I wonder what's going on in there... but first I need to finish working out the power management kinks in the sata_via driver
<Nafallo> elmo: thanx for all syncs :-)
<Kamion> oh damn, helps to rebuild d-i after changing stuff in the initrd
<BenC> wait, this is an old initramfs-tools
<elmo> crimsun: done
<elmo> slomo: no, it's marked as BROKEN in josie - I'll post about the BROKEN packages later
<bmonty_laptop> elmo: did you get the sync requests I sent you via email?
<slomo> elmo: josie?
<elmo> bmonty_laptop: not yet gotten to the sync email backlog
<elmo> slomo: the program that does syncs
<bmonty_laptop> elmo: ok, thanks
<slomo> elmo: hmm, maybe broken because we didn't have a new enough gnunet until a few hours ago? or what are the possibilities why it detects something as broken?
<elmo> slomo: as I said, I'll post about the broken packages later, kinda busy now, sorry
<slomo> elmo: np :) just curious
<crimsun> elmo: thanks!
<shaya> anyone know what this error is from
<shaya> Undefined color: "#000000 " when trying to run emacs in dapper
<shaya> xrdb issue?
<Hirion> shaya: same here with vim
<seb128> probably xrdb called with -nocpp where is should cpp
<seb128> gnome-settings-daemon change maybe
<Kamion> it should be using mcpp in dapper
<daniels> yes
<seb128> Kamion: it is
<Kamion> ok, you're scaring me. how did you see that?
<daniels> because I am fucking ninja
<daniels> also, good morning everyone
<seb128> hi daniels
<Nafallo> morning daniels :-)
<shaya> so any way to fix it so I can get my emacs back? :)
<dieman> so like, if ive got a really flipping annoying nfs bug in hoary and I can find the patch to fix it, is there a way to get it in someday as part of hoary slipped in with a security update? ;)
<dieman> or 'just upgrade to breezy, damnit'
<daniels> shaya: fix what?
<daniels> i guess this has something to do with xrdb
<shaya> $ emacs
<shaya> Undefined color: "#000000 "
<Treenaks> shaya: space at the end of your line
<shaya> me too
<Treenaks> bad bad bad
<daniels> shaya: that's not a problem with xrdb, that's you missing /etc/X11/rgb.txt or such
<daniels> oh
<daniels> but treenaks has a very good point
<shaya> no, I have it
<shaya> -rw-r--r-- 1 root root 17371 2005-08-17 08:15 /etc/X11/rgb.txt
<Treenaks> shaya: there's a space at the end of the relevant line in your xrdb input file
<sivang> night all
<Treenaks> shaya: night sivan
<shaya> where's that input file
<Treenaks> you put it there ;)
<shaya> no
<daniels> shaya: maybe .Xdefaults, maybe .Xresources, who knows
<shaya> I hvae none
<daniels> grep for '#000000 ' over /etc, but this is seriously #ubuntu territory
<shaya> this came w/ an upgrade to dapper
<slomo> daniels: i have the same problem ;)
<slomo> daniels: "Warning: Color name "#efebe7 " is not defined" with vim
<shaya> also tk
<shaya> tkinfo
<shaya> Application initialization failed: this isn't a Tk applicationinvalid color name "#efebe7 "
<daniels> works for me?
<shaya> are you uptodate w/ dapper?
<daniels> yes
<daniels> i'm not just saying that for fun
<shaya> I just rgrep'd /etc and /home/spotter no matches
<seb128> works for me too
<sistpoty> shaya: do you have xrgb installed?
<shaya> yes
<shaya> dpkg --status xrgb | grep Status
<shaya> Status: install ok installed
<slomo> daniels: xrgb uses mcpp now? is it maybe related to this error? http://pastebin.com/430934
<shaya> when I run xrdb by hand it hangs
<BenC> ok, usplash works for me now
<shaya> nevermind
<shaya> seems to wait for input
<shaya> ctrl-d closes it
<daniels> ... well, yes.
<daniels> it doesn't magically just guess resources to merge for y.
<daniels> slomo: don't worry about that error
<shaya> anyways, the colors erroring on are no where to be found
<slomo> ok, then i have no idea what causes this ;)
<slomo> and it magically disappeared for me now... wtf
<ogra> daniels, slomo, byciclerepair
<daniels> ogra: herbivoroushelicopter
<ogra> blbl
<daniels> i can concatenate words together too! ;)
<daniels> if you're saying that bicyclerepair makes things break, it's installed here
<ogra> no i mean the addon we had in hoary and breezy ... it keeps the vim63 directory undeleted ... 
<ogra> or kept
<ogra> not sure if it changed 
<daniels> well, it's installed here, and still wfm.
<shaya> wonder if it has to do w/ xrgb 0.99.1-1 -> 0.99.2-0ubuntu
<ogra> i had this error too...
<Kamion> shaya: note that daniels uploaded both of those
* ogra reboots to new kernel
<shaya> daniels: so to work around it, anyway I can set that resource?
<daniels> shaya: i don't know man, so far I haven't seen any specific problem, or reproducible, just random apps complaining that they can't find colours
<shaya> right, how can I fake it out
<shaya> so that color is set
<shaya> until I can spend time investigating it
<daniels> poke in /etc/X11/rgb.txt, but you probably need an X server restart for this
<shaya> ok
<Nafallo> Keybuk: you should s/Resynchronise/Merge/ for your own uploads or something :-). that's less to write anyway ;-).
<Keybuk> Nafallo: it's in the changelog from mom
<ogra> hmm, intresting, my mouse (touchpad) sensitivity has changed with the last upgrade ...
<Nafallo> ogra: same here :-)
<daniels> 'tis a kernel thing
<ogra> yup
<shaya> figured out why I think
<shaya> spotter@dent:~$ xprop -root |grep RESOURCE
<shaya> RESOURCE_MANAGER(STRING) = "*Box.background:\t#efebe7 \n*Box.foreground:\t#101010 \n......
<shaya> any idea where that gets set from?
<shaya> I'm also getting XKB errors on startup that led me in that direction
<shaya> the bug is in mcpp
<shaya> mv mcpp mcpp.bak ; cp cpp mcpp ; restart x ; no more bug
<shaya> xprop -root |grep RESOURCE
<shaya> RESOURCE_MANAGER(STRING) = "*Box.background:\t#efebe7\n*Box.foreground:\t#101010\n.......
<daniels> if you can file a bug with a complete diff of exactly what changes between cpp and mcpp, that would be useful
<shaya> all I can tell is my xprop output
<shaya> I'll try to file a bug w/ that later
<shaya> need ot do some work right now, so dont wnat to restart X again
<daniels> your call
<mdke> mdz, around? We're waiting for a nod or shake of the head from you on http://bugzilla.ubuntu.com/show_bug.cgi?id=13746
<mdz> mdke: I'm very, very far behind on email at the moment
<mdke> mdz, heh, ok sorry
<mdz> I just got home last night and will be working through the backlog this week
<mdke> good luck!
<mdke> i can imagine
<mdke> mdz, did you get over that illness ok?
<neuralis> mdz: have a sec?
<mdz> mdke: yes, I'm feeling ok
<mdz> neuralis: regarding what?
<mdke> mdz_, mdz, clone yourself just in case, good thinking
<neuralis> mdz, i suppose it doesn't need to be now -- when you get a chance, would you please look at the rewritten TestingServerHardware spec (high priority)?
<mdz> my laptop just resumed from hibernate and had a client running
<mdz> neuralis: sure, an email reminder would be great as I won't get to it today
<neuralis> mdz, will send one now. thanks.
#ubuntu-devel 2006-11-13
<zul> hey
<_ion> Hi
<_ion> Here's a piece of text about the Trevio sources.list episode: http://soijabanaani.net/tmp/the_trevino_story
<Spads> ogra, everone: see your mail for mdz's clarification that there *is* an organized event tonight at 8
<Spads> er, 7
<Spads> er, wrong channel
<Keybuk> and that you need to bring your "special item"
<BenC> Keybuk: what wireless access point are you using?
<lifeless> canonical2
<BenC> sucks, I can't see that one
<Spads> where is it?
<lifeless> calistoga
<Mithrandir> slightly ironic I can see a Norwegian ISP's wlan from here.
<lifeless> ?!!
<Mithrandir> it's an ad-hoc
<BenC> I can see "linksys" and "Pete's Cafe"
<BenC> both work, but they're not "official" :)
<lifeless> come down
<keescook> BenC: yeah, you must be near me; I see the same.  :)
<BenC> I think I'll keep leaching Pete's bw from my room :)
<BenC> should broadcast some torrents on the subnet for ubuntu cd's
<Burgundavia> hey jono: why are you still in MTV?
<jono> hey
<jono> I am at the Canonical allhands summit in San Francisco
<mjg59> Hey people
<mjg59> I've uploaded everything needed for compiz integration love
<mjg59> Once desktop-effects hits the archive, if people could test that, compiz, compiz-gnome and the new gnome-session, that would be great
<Keybuk> mjg59: could you make a wiki page explaining what we need to install/remove and config?
<mjg59> Keybuk: Just posted to -devel
<mjg59> I can cut and paste it
<Keybuk> perfect
<Keybuk> I'll NEW desktop-effects once it's built
<mjg59> It's NEWed already, isn't it?
<Keybuk> (waiting on ia64 and sparc)
<Keybuk> source has been, not the binaries
<mjg59> Oh, yeah, binaries need doing separately
<mjg59> Thanks
<mjg59> Keybuk: Can you remove the compiz-plugins source package?
<Keybuk> sparc and ia64 ... bollocks to it, I'll new it now
<Keybuk> compiz-plugins | 0.5-0ubuntu5 | edgy/universe | source, amd64, i386, ia64, powerpc, sparc
<Keybuk> ?
<mjg59> Yup
<Keybuk> just the source or the binaries too?
<mjg59> Binaries as well, I guess
<mjg59> As long as that doesn't nuke the compiz-plugins binary that comes from compiz now
<Keybuk> ah, this could be tricky
<bluefoxicy> "Though Avahi is actually quite popular these days, we only had a single security sensitive bug. (And almost no other bugs.) The bug triggered an assert (i.e. it allowed a simple DoS attack) and could not be exploited in a way that code could be smuggled into the process."
<mjg59> Heh
<bluefoxicy>   -- http://avahi.org/wiki/SecurityConsiderations
<Keybuk> mjg59: the compiz-plugins binaries are so much newer, that compiz might need another upload
<Lathiat> bluefoxicy: hrm?
<mjg59> "so much newer"?
<Keybuk> 0.5 vs 0.0.38
<Lathiat> bluefoxicy: yeh that should be updated
<bluefoxicy> Back in the day, december 2005.. however, 2006 rolls around  :)  http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-2289  Oops.  I guess I'll prod the avahi devs to update their page.  :)
<mjg59> Keybuk: 1:0.3.3
<Lathiat> bluefoxicy: that bug only just came out last week :)
<mjg59> Keybuk: 0.0.38 is ancient
<Lathiat> err
<Lathiat> hrm
<Lathiat> that one
<bluefoxicy> Lathiat: 5/10/2006 is last week?
<Keybuk> hmm, the 1: is missing from madison
<Keybuk> weird
<Lathiat> bluefoxicy: sorry no we had one come out just this week too
<Keybuk> Will remove the following packages from feisty:
<Keybuk> compiz-plugins | 0.5-0ubuntu5 | source, ia64, sparc
<Keybuk> -- 
<mjg59> Keybuk: Looks good
<Keybuk> I guess madison is confused about the world
<mjg59> Oh, erm.
<mjg59> Yeah, that looks less than good.
<bluefoxicy> Lathiat:  hey i didn't see that one D:
<mjg59> I'm just about to do another compiz upload anyway, but it'd be good if it didn't become uninstallable in the intervening time period :)
<Keybuk> ah
<Keybuk> I was looking at edgy
<bluefoxicy> Lathiat:  I'm looking for a remotely exploitable in libavahi, if you see one send it my way ;)
* mjg59 reautomakes
<Keybuk> mjg59: d-e new'd
<mjg59> Keybuk: Thanks
* Keybuk finally figures out why multiverse and universe never got fully up to date
<Hobbsee> Keybuk: oh?
<Keybuk> Hobbsee: need to sync from contrib and non-free too
<Hobbsee> ahhh
<minghua> d'oh
<mjg59> Right. That upload ought to fix the fact that the window preferences applet didn't work.
<Keybuk> heh
<Keybuk> oops
<Keybuk> ETRYHARDER
<mjg59> https://wiki.ubuntu.com/CompizOnFeisty
<_ion> Cool.
<_ion> I wish the 9000 series drivers worked on my system. :-)
<_ion> Both releases so far have (known) bugs that prevent me from using them.
<robertj_> mjg59: are there any good tidings coming out of ATI?
<robertj_> mjg59: perhaps now that NVidia has a supporting driver out there will be a certain amount of keeping up with the Joneses?
<mjg59> robertj_: No idea, I'm afraid
<thiagocmartinsc> opa
<thiagocmartinsc> about install server on file /preseed/ubuntu-server.seed
<thiagocmartinsc> I put extra packages on pool/extras, how to tell d-i to install my package?
<thiagocmartinsc> d-i     pkgsel/install-pattern          string ~t^ubuntu-standard$|~n^my-package-asterisk$
<thiagocmartinsc> ?
<thiagocmartinsc> or: d-i      pkgsel/asterisk     string
<thiagocmartinsc> ?
* netjoined: irc.freenode.net -> brown.freenode.net
<_ion> Hm, Javur has been freed.
<_ion> http://www.tbray.org/ongoing/When/200x/2006/11/12/OSS-Java
<Gloubiboulga> infinity: could you run the builds for exo and libxfcegui4 on powerpc? it seems that they failed because of a space problem
<bluefoxicy> Java is now GPL
<bluefoxicy> as of like, an hour ago
<bluefoxicy> So sayith slashdot.  Take with salt.
<jdub> there's no salt
<gnomefreak> fully GPL?
<jdub> GPLv2 with classpath exception (for most components)
<gnomefreak> still cant leave multiverse than?
<mjg59> ?
<mjg59> Can be in main
<gnomefreak> even with classpath exceptions? (dependsing what they are)
<jdub> gnomefreak: go read what they are before assuming they're bad
<jdub> http://www.gnome.org/~jdub/2006/duke-in-ur-codes.jpg
<mjg59> gnomefreak: "exceptions" grant you extra permissions
<gnomefreak> ah
<mjg59> But nothing can happen yet - they've announced a commitment to releasing it, but the code isn't entirely availble yet
<Simira> mjg59: aren't you in US?
<Simira> mjg59: or, you were, maybe?
<Simira> hm...
<robertj_> bluefoxicy: official announcement coming at 9:30 PST supposedly
<robertj_> I think we are likely to see a single product today, possible J2ME, with all the rest forthcoming by early next year, we will see
<bluefoxicy> robertj:  To be honest I don't know what to think.
<bluefoxicy> I would prefer native-compiled like with gcj/classpath, far more to having any more JIT cruft
<Treenaks> as long as it's in time for feisty ;)
<bluefoxicy> I don't want the idea of actually using the JVM to catch on :/
<bluefoxicy> That being said, I hate GNU and their entire philosophy, and that's where GNU classpath comes from
<bluefoxicy> (their philosophy boils down to, "Well we should all work together for the common good; and those that don't want to, well, we should force them to!")
<bluefoxicy> Treenaks:  we don't need the JVM for feisty do we?  I certainly don't have anything that doesn't work on classpath; I guess you could add it to the Web browser but I don't want a Java plug-in by default (last I tried, Firefox crashed something like 80% of the time I hit a site with Java; screw that)
<bluefoxicy> "In related news, apparently Project Looking Glass [sun.com] , the 3d desktop, is likely to be included in the Ubuntu Feisty [java.net]  release."
<bluefoxicy> the hell is this
<Treenaks> bluefoxicy: we might not _need_ it, it would still be nice :)
<bluefoxicy> Treenaks:  perhaps, just not by default
<bluefoxicy> Besides, I am already gearing up to try to swing an article past Corbet about the very real security concerns of using Mono.  I _really_ don't want to go through this again.
<mjg59> Simira: Nope
<zul> hi
<Kryczek> hi :)
<Kryczek> I'm looking for somebody involved in the making of the Ubuntu SecurityLiveCD
<Kryczek> or anyone who knows about the Ubuntu livecd creation process
<Kryczek> (cause I'd like to make my own livecd, and all I can find are HOWTOs telling me to do a fresh install of Linux on another disk partition and then a script creates an ISO image out of it)
<_MMA_> Kryczek: Give Reconstructor a look.
<_MMA_> http://reconstructor.aperantis.com/
<Kryczek> just found the link on google then launchpad ;)
<Kryczek> hmm... dunno if it will allow me to do the extensive modifications I want to do on the livecd
<Kryczek> but that's the closest thing to what I was looking for
<Kryczek> so thanks a lot _MMA_ :)
<_MMA_> No problem.
<_MMA_> Kryczek: What are you looking to do?
<_MMA_> Theres also a terminal in Reconstructor where you can chroot and do advanced things.
<zul>  /join #ubuntu-ke
<zul> oops..
<Kryczek> make a custom ISO9660 fs myself (with steganography), modify the bootloader so that it doesnt display any message and boots on the harddrive unless you enter a correct decryption key for the LiveCD, probably patch the kernel, etc :)
<Kryczek> _MMA_: awesome, I think i'll need that
<mjg59> Has anyone (other than me) tested the compiz stuff yet?
<bhale> mjg59: something very recent?
<bhale> i tested it in edgy
<mjg59> bhale: http://wiki.ubuntu.com/CompizOnFeisty
<bhale> cool, i cant try it at work (nvidia-legacy), though
<mjg59> Ah, ok
<jdub> mjg59: fisty packages usable on edgy?
<Treenaks> jdub: "fisty"?
<jdub> Treenaks: the next release of ubuntu ;-)
<jdub> clearly
<Treenaks> jdub: clearly
<jsgotangco> i hope thats not a fetish slip?
<jdub> mjg59: uh, wow, that's *actual compiz*
<mjg59> jdub: Yes
<mjg59> Should be the entire FC6 experience, except better because compiz uses Metacity themes now
<Treenaks> and gconf instead of it's own crackful reinvention of it?
<mjg59> compiz has always used gconf
<jdub> Treenaks: you're thinking of cheap knockoffs :)
<Treenaks> jdub: well.. I'm thinking of what I used, and was called 'compiz', a few months before edgy released :)
<jdub> yeah
<jdub> that was pre-beryl molested compiz
<Treenaks> jdub: I think it was the compiz that eventually became beryl, actually
<mjg59> Everything called "compiz" in Ubuntu has always shipped with gconf support
<jdub> yes, molested compiz, pre-beryl :)
<mjg59> This time I've merely fixed it so there are sensible defaults in the schemas :)
<jdub> mjg59: rh have done great work on integration and theming stuff
<mjg59> jdub: Yup, though it's a bitch to find the source to their desktop-effects applet
<mjg59> I finally found it in the compiz SRPM
<azeem> I thought they had an additional checkbox in their joint compiz/metacity preferenced?
<azeem> preferences, even
<azeem> "enable desktop effects"
<mjg59> No
<mjg59> There isn't a joint compiz/metacity preferences
<mjg59> compiz ships its own plugin for window-manager-properties
<azeem> ah, ok
<mjg59> Then you also get a "desktop effects" applet, which has the enable button
<azeem> is there a screenshot of that applet somewhere?
<jdub> http://www.sun.com/software/opensource/java/
<mjg59> http://lunapark6.com/wp-content/uploads/2006/10/FC06-DE-01-GUI-367-GUI.jpg
<azeem> mjg59: thanks
<azeem> cute
<azeem> I still don't understand why this has to be an applet on its own, but probably an implementation detail?
<azeem> jdub: they BSD'd their mascot today as well
<jdub> azeem: interesting
<azeem> https://duke.dev.java.net/
<mjg59> azeem: window-manager-properties takes plugins on a per-wm basis
<mjg59> azeem: So it would have to be implemented in each of them
<sladen> James Gosling: "The time to open source Java is now [because we're already five years too late] "
<mjg59> I bet he's pissed
<mjg59> http://www.codon.org.uk/~mjg59/tmp/bling.png
<jsgotangco> hey look its sabdfl in a red tie
<jsgotangco> heh
<mjg59> Notice shadows plus hint of translucency
<azeem> mjg59: what's that recycle-icon applet?
<mjg59> azeem: Reboot required notification
<mjg59> I've upgraded the kernel
<azeem> ah, right
<azeem> I thought it was some leet synchronisation stuff or so
<jdub> bling ping
<Kryczek> lol
<mjg59> So if people would actually, y'know, TEST THE DAMNED PACKAGES or something, I could write up a main inclusion report
<jdub> mjg59: i'll suck 'em down now
<jdub> mjg59: current fisty?
<mjg59> Yup
<jdub> The following NEW packages will be installed: compiz compiz-core compiz-gnome compiz-plugins desktop-effects
<jdub> The following packages will be upgraded: libc6 libc6-dev libc6-i686 libdbus-1-3 libdbus-1-dev
<mjg59> Looks good
<jdub> 
<jdub> gar, damnit ;-)
<mjg59> Make sure you have current gnome-session, too
<jdub> fisty libc is ok?
<mjg59> Seems to be
<jdub> should i just ditch edgy already?
<sladen> mjg59: if you turn up the bling any further it's going to reach pukability status
* mjg59 goes to rip fruitflies apart
* sladen thought beryl was the preferred---how do compiz/beryl interrelate?
<jdub> beryl is where patches go when they're not good enough for compiz
<jdub> thus the fork
<sladen> ah so beryl actually has /more/ bling.  But of a lower quality?
<jdub> more crazy shit, less attention to detail, less integration
<jdub> also, there are some crazy smart people working on compiz, and i tend to feel their POV carries some weight
<azeem> also, beryl ditched gconf in favour of something "simpler"
<jdub> mjg59: gtk-window-decorator is segfaulting
<jdub> mjg59: hrm, might try installing metacity
<Spads> http://www.gnome.org/~jdub/2006/duke-in-ur-codes.jpg
<Spads> jdub: you fiend
<jdub> Spads: here for you!
<Spads> http://www.forgetfoo.com/images/blog/blogmonks.gif <-- jdub 
<mjg59> jdub: Ah, yes - it might well need the current libmetacity...
<jdub> mjg59: i added bits to your page
<mjg59> jdub: Got it working?
<jdub> yeah
<jdub> bit rocky, but that's compiz for the moment ;)
<jdub> mjg59: i'm on i900
<mjg59> Works reasonably here on 855
<bddebian> Howdy
<pygi> hey bddebian 
<bddebian> Heya pygi
<gnomefreak> whats the chances of getting a theme with a sticky button?
<Tonio_> hi all :)
<shwag> where do I go to discuss a bug on ubuntu.com ?
<Burgwork> shwag: on  the website itself?
<shwag> yah
<Burgwork> which page?
<shwag> http://www.ubuntu.com/usn   need to be RSS.
<Burgwork> right
<Burgwork> file a bug against the ubuntu-website product
<shwag> okay
<shwag> thanks
<Burgwork> mark is a wishlist
<shwag> yah
<mjg59> Burgwork: Mark is a wishlist?
<Simira> tihi
<Burgwork> as a, rather
* Burgwork backs away from the keyboard
<shwag> https://launchpad.net/products/ubuntu-website/+bug/71685
<Ubugtu> Malone bug 71685 in ubuntu-website "Ubuntu Security Notice page needs RSS feed." [Undecided,Unconfirmed]  
<pitti> slomo: can you please check in your hal changes into the bzr tree?
<infinity> Gloubiboulga: Done, thanks.
<bluefoxicy> what the hell
<Slant_Laptop> Where should I post to have a package diff sponsored?
<LaserJock> Slant_Laptop: is the package in Main or Universe?
<bluefoxicy> warning:  Linkspam coming up 
<bluefoxicy> http://www.securityfocus.com/bid/20955 http://www.securityfocus.com/bid/17587 http://www.securityfocus.com/bid/17955 http://www.securityfocus.com/bid/19615 http://www.securityfocus.com/bid/14785 http://www.securityfocus.com/bid/18101 http://www.securityfocus.com/bid/16320
<bluefoxicy> in the past TWO HOURS
<Slant_Laptop> LaserJock: Universe.
<LaserJock> Slant_Laptop: if there is a bug attache the diff to the bug report and subscribe the ubuntu-universe-sponsors Launchpad team
<bluefoxicy> what, one of those is old as crap, why did it just show up in my mailbox
<pygi> bluefoxicy, 6.10 not vulnarble?
<Slant_Laptop> LaserJock: Thanks.
<bluefoxicy> pygi:  I don't know.  I just saw a jillion kernel vulns in my inbox and was like "huh?"
<bluefoxicy> knee-jerk reaction, it's not like I read them all
<pygi> vulnerable*
<bluefoxicy> pygi:  they all look like updates to old issues, what the heck did they update?
<pygi> bluefoxicy, hm? :P
<bluefoxicy> pygi:  http://www.securityfocus.com/bid/14785 for example, published Sep 09 2005 12:00AM and updated Nov 13 2006 08:16PM
<pygi> right, weird
<pygi> perhaps added some new distros affected?
<bluefoxicy> pygi:  Maybe i should just watch the NVD
<bluefoxicy> but that takes longer 8)
<bluefoxicy> I really wish securityfocus had a vuln-only feed though
<bluefoxicy> their vuln feed is a direct feed of the bugtraq mailing list
<bluefoxicy> it would be awesome if I could get a rockbox module to do text to speech
<bluefoxicy> and a module to parse lists of CVEs.....
<bluefoxicy> >:)
<heno> bluefoxicy: to have track titles read out?
<heno> bluefoxicy: this is fairly lightweight: http://espeak.sourceforge.net/
<heno> but I'm not sure it will run on an iPod :)
<bluefoxicy> heno:  I was more thinking to have daily CVE lists sorted by vendor, product, vulnerability type, severity, etc; and then played back on my Ipod
<heno> bluefoxicy: would you not just do the TTS on the PC and download the wav's (mp3s) to the iPod?
<bluefoxicy> heno:  why?  That would be a lot more data
<heno> true, just not sure if the iPod has enough brain power or memory for TTS
<heno> bluefoxicy: it would be very cool though, because it would help blind people use ipods
<heno> with free software on it :)
<heno> killer app!
<bluefoxicy>        -s <integer>
<bluefoxicy>               peed in words per minute, default is 160
<bluefoxicy> someone peed in my source code :(
<bluefoxicy> haha
<bluefoxicy> it sounds like a scott woman talking like a scott man
<heno> :)
<bluefoxicy> of course i have it cursing a lot
<heno> naturally
<sladen> aye,killybenow,for ye canna tell what th' fucking seeing 
<bluefoxicy> sladen:  more like $ echo "Fucking Vuln in Linux kernel 2.6.17.9 because RedHat put fucking broken code in."  | espeak --stdin -v en/en-n -s 120 -p 60
<bluefoxicy> I am seriously considering grepping the kernel and piping the output to this
<bluefoxicy> oh god
<bluefoxicy> filters
<bluefoxicy> FILTERS
* bluefoxicy echo "I can't believe i didn't think of this before" | chef |  espeak --stdin -v en/en-n -s 120 -p 60
<bluefoxicy> heno:  you know I'm not going to get any work done tonight, right?
<TheMuso> Rockbox with espeak would be a good idea IMO.
<heno> TheMuso: and if it can be made to run on the iPod it will surely work on the OLPC too
<heno> but it probably needs direct app integration in both cases
<bluefoxicy> that reminds me
<sladen> espeak seems to have been rather a good discovery
<bluefoxicy> I need to get readahead working on the olpc
<heno> ie. no AT framework or screen reader
<bluefoxicy> I have been like.. playing final fantasy
<bluefoxicy> for a month
<sladen> good thing about the ipod way of working is that you can scroll the menus without actually clicking on anything
<sladen> so you can scroll to a point, listen for the menu item, select, scroll some more, listen, click
<sladen> how the espeak and main audio would work together I don't know
<TheMuso> heno: Rockbox does work on the newer ipods
<bluefoxicy> sladen:  and you can prefix the sound with tones
<bluefoxicy> short tones
<TheMuso> afaik
<bluefoxicy> eventually you'd learn to recognize those tones and not wait for the speech :P
<heno> sladen: we'd need to port pulseaudio to rockbox too :)
<sladen> bluefoxicy: dude, OLPC is flash---readahead really isn't going to help much in the final product
<heno> TheMuso: rockbox yes, but rockbox+espeak?
<bluefoxicy> sladen:  probably.
<heno> not proven yet at least
<bluefoxicy> sladen:  the last time we had this conversation I walked jg around in circles about whether flash is faster than ram or not
* sladen presumes that you get a normal /dev/dsp or simliar once Linux is running on the iPods
<bluefoxicy> rockbox doesn't have linux
<bluefoxicy> I should update my version
<bluefoxicy> sladen:  the final product is going to have really, really fast flash, like 26M/s; but RAM is still faster.  I'm going to alter it to do readahead in the background and in the order the bootprocess follows rather than sequentially on disk.  At the very least it'll help with the dev boards' 3M/s chip
<imbrandon> moins all
<Keybuk> heyhey
<imbrandon> heya Keybuk 
<Keybuk> all settled back home now?
<imbrandon> yup yup
<imbrandon> even been working on a few merges
<imbrandon> finaly back on my regular sleep schedule now :)
<Keybuk> heh
<imbrandon> hows SF ? weather chan said it was gonna be coler there this week.
<Keybuk> we're still at the grindstone
<imbrandon> yea
<imbrandon> s/coler/colder
<Keybuk> yeah, seems to be raining today
<Burgwork> Keybuk: what much are you discussing this week?
<Keybuk> Burgwork: it's a company all hands event, not a distro event
<Burgwork> ah
<Keybuk> Burgwork: so the only thing distro-related will be the canonical team structure, etc.
<Keybuk> anything related to the real distro was discussed last week
<imbrandon> Keybuk, is the -changes list still moded for a reason ?
<imbrandon> or just hasent been turned off yet
<Keybuk> moded?
<crimsun> (moderated, I presume?)
<imbrandon> yes
<Keybuk> it's always been
<Keybuk> you can't post to the changes list
<Keybuk> only Soyuz can
<imbrandon> no , my uploaded were accepted yesterday and i got the accepted mail, but none on the -changes
<crimsun> imbrandon: are you referring to your uploads not being announced on feisty-changes?
<imbrandon> yes
<crimsun> right, I'm experiencing that, too
<Keybuk> oh, that's interesting
#ubuntu-devel 2006-11-14
<Keybuk> someone may have not set the list up properly
<imbrandon> i had two uploads yesterday, one to a main package and one to NEW
<imbrandon> obviously the NEW hasent been processed but the main package should have shownup
<Keybuk> the NEW should have been ...
<Keybuk> Colin and I are pretty much on top of NEW
<imbrandon> ahh ok, i havent looked
<mjg59> Keybuk: Thanks for that
<mjg59> Keybuk: Everything looks good now
<imbrandon> i just woke up, i did it before i slept last night
<Keybuk> I have -changes files from the list ...
<Keybuk> what package did you upload?
<_ion> Btw, what is the reasong for having a monolithic linux-restricted-modules package instead of a plain metapackage that depends on nvidia-something, fglrx-something etc.
<Keybuk> _ion: easier
<mjg59> It means we don't need to manually retrigger half a dozen package builds every time there's a new kernel
<_ion> keybuk: It seems to me that debian/rules in l-r-m is unnecessarily complex.
<_ion> mjg59: That could be easily scripted.
<mjg59> _ion: It's not always done by the same person
<imbrandon> Keybuk, https://launchpad.net/distros/ubuntu/feisty/+source/konversation/1.0.1-1ubuntu1  shows up as built etc, but not on changes, also the NEW was processed and built soooo, i dunno whats up
<imbrandon> mirage was the package in NEW
<Keybuk> kooky
<zul> hey
<imbrandon> heya zul
<zul> hey imbrandon 
<Keybuk> ROCKY!
<imbrandon> heh
<ajmitch> morning imbrandon :)
<imbrandon> heya ajmitch
* imbrandon yawns
* wasabi_ snores.
<wasabi_> Feisty generally functional currently?
<Keybuk> actually, it's not bad right now
<Keybuk> the syncs have been done, but not most of the merges
<pygi> wasabi, but it'll become soon :P
<wasabi_> Sweet. Quick! Got to upgrade before it busts!
<Keybuk> yet because Debian has been in freeze, the difference is not great
<Keybuk> so it's not broken
<Burgwork> cjwatson: is there a newer (dapper or edgy) kickstart manual?
<Keybuk> Burgwork: cjwatson is busy :(
<Burgwork> Keybuk: might you be able to help me>
<Burgwork> ?
<wasabi_> I miss Google's lunches.
<wasabi_> Today's half assed tuna salad sandwich nearly made me cry.
<imbrandon> lol @ wasabi_
<Keybuk> Burgwork: I've no idea, I'm afraid
<Burgwork> hmm
<Keybuk> wasabi: the lunch at this hotel is pretty wet
<wasabi_> Where are you at?/
<Keybuk> one of the Hiltons in SF
<wasabi_> nice
<Keybuk> meh, just usual hotelish really
<Keybuk> you get to see a lot of them in this job :p
<Keybuk> sweet
<Keybuk> I now have a list of removals in Debian
<Keybuk> now I just need to filter those against what's in Ubuntu, and what's come back into Debian
<imbrandon> Keybuk, that will take into account stuff thats only in ubuntu intentionaly right?
<Keybuk> it processes the Debian removals file
<Keybuk> rather than comparing the two distros ;)
<imbrandon> ahh right on
<Keybuk> and it's manual, I'll have to confirm each sourec package
* pygi wonders who he can talk about cdrkit/cdrecords/etc mess ^_^
<Keybuk> pygi: Sledge in #debian-* ?
<pygi> Keybuk, I mean in ubuntu :P
<pygi> what we'll decide :)
<pygi> I know debian stance on it already
<Keybuk> we'll probably do what Debian does
<Keybuk> unless there's a compelling reason not to
<Keybuk> cdrkit is in the list of things to sync
<Keybuk> but I want to do removals first
<pygi> heh, so we sync cdrkit?
<pygi> ok,whatever you say :P
<imbrandon> Keybuk, you said the autosyncs are upto-date atm right ?
<pygi> Keybuk, and if Sledge = joerg jaspert, then no thanks :P
<Keybuk> imbrandon: yes
<Keybuk> pygi: no, Sledge = Steve McIntyre (aka. Dirty Uncle Steve), who is a fab guy
<pygi> Keybuk, aha, ok then ^_^what can he help me with/tell me about?
<Keybuk> he's the debian-cd maintainer
<Keybuk> and one of the maintainers of cdrkit
<pygi> hm,ok, I'll try to talk with him then
<pygi> thanks
<Keybuk> he's not an Ubuntu guy, obviously
<Keybuk> but he'll know what the state of everything is
<pygi> right, I understand
<Keybuk> at some point, I'll be asking him what we should do to follow
<pygi> I just got a lot of concerns about cdrkit, really
<Keybuk> oh?
<pygi> they refuse any sensful advise on what's wrong/how to fix it, as far as I am aware in the last few weeks only one developer is active on cdrkit because they want to see what Joerg's (of cdrecord) move will be (will he switch to gpl), they are basicly taking "code snippets"  from gpl'
<pygi> gpl'ed parts of cdrtools, etc, etc, etc
<pygi> but ofcourse, I am always talking non-sense, so ignore me :)
<zul> cool we are the distro of the acccording to linux journal
<_ion> Btw, thanks for the great work with libburn+cdrskin.
<minghua> zul: distro of the what? :-)
<pygi> _ion, let's wait with that until we get dvd support,ok? :P
<_ion> minghua: What's wrong with being just the distro of the? :-)
<zul> yeah distro of the year
<jdong> does that mean the other release in the year wasn't good enough though?
<jdong> ;-)
<Keybuk> zul: are we on the cover?
<pygi> jdong, heh :P
<_ion> pygi: Are you using the dvd+rw-tools source, or collaborating with its author?
<zul> no unfortunately
<pygi> _ion, we aren't using anyone's source
<pygi> _ion, everything is from scratch
<_ion> pygi: Oh, ok. It's GPL software and seems to work fine.
<zul> http://www.linuxjournal.com/article/9368
<pygi> _ion, if you listen to joerg, then you'd notice everything except things he writes is junk :P
<pygi> _ion, perhaps, but is bad code-wise, it's based on cdrecord
<pygi> _ion, and especially mkisofs, which is such mess of a code that really not many people can understand anything
<_ion> pygi: Ok, i see.
<_ion> I haven't read its source, so i didn't know. :-)
<imbrandon> zul, wow actualy looks like kubuntu , but its labeld ubuntu 
<jdong> meh same difference :D
<imbrandon> yea it is, its just strange they would mix them both
<Keybuk> pygi: what else is there though?
<Keybuk> like it or not, cdr* is the only useful set of burning tools for older drives
<zul> imbrandon: its all good
<pygi> Keybuk, and for newer sadly. For now we don't have a usable solution. I'm just telling in what state are we at linux burning scene.
<Keybuk> pygi: dvd+rw-tools seems useful enough for modern crap
<Keybuk> at least, it works for me (tm) :p
<pygi> Keybuk, bad still inherits bad codebase
<pygi> but*
<pygi> Keybuk, works for you, but a lot of users have problems
<pygi> Keybuk, I do understand that we follow debian, and that we will take their word. I just think something has to be done to ensure that the future will be different.
<Keybuk> indeed
<Keybuk> but what?
<pygi> Allocate resources to writing replacement? The problem I see is that Andy and Joerg in particular made everyone think they don't know anything about scsi, mmc standards, etc, etc
<Keybuk> who are the kinds of people that could write replacements?
<pygi> I've been able (including Thomas and Lorenzo) to write a usable replacement for data and audio cd 
<pygi> including the compatibility layer for cdrecord so no breaking of existing apps until they migrate to the libraries itself
<_ion> I've used it, it works. :-)
<_ion> (At least with my hardware.)
<pygi> Keybuk, we implemented so much stuff WITHOUT standard books, and much drives to test
<pygi> we support multi session, tao, -sao, and almost any things you can do with a cd in SVN 
<Keybuk> pygi: what kind of state is it in?
<pygi> (release date for that is unknown yet tho)
<pygi> Keybuk, it's in a state that I could really use at least one set of rainbow books :P
<pygi> Keybuk, well, it's rapidly progressing, but I cannot recommend it for serious adoption instead of cdrecord/cdrkit whatever my opinion on those two is
<pygi> at least not for now
<pygi> Keybuk, getting rainbow books (and I hope I'll get them rather sooner then later) would speed libburn development a lot
<pygi> and we are on track for implementing el torito, HFS, and HFS+ for libisofs, then we can write a compatibility layer for mkisofs called "genisofs"
<pygi> _ion, you used cdrskin with k3b?
<_ion> pygi: From command line.
<pygi> _ion, oh, ok, and it worked for you?
<_ion> Yes, i had no problems whatsoever.
<pygi> _ion, nice, expect me to throw a lot of testing use cases at you soon then :P
<_ion> Sure, i'd be glad to help testing.
<pygi> nice, thanks
<pygi> we especially need help with multi session and tao at this moment
<pygi> since they are rather new features
<pygi> _ion, my hope is that Brasero 0.5.2 will use new libburn (once it's out) and we can get Brasero in repos with libburn-enabled
<pygi> (Brasero 0.5.1 is scheduled soon)
<pygi> dunno when can we get new libburn out, since we postpone release date all the time due to a lot of new features :P)
<_ion> I only recently moved my burner to a box with X, so i have yet to burn a data CD using GUI tools. I have used Serpentine for burning audio CDs, though, and i was *very* impressed with it.
<pygi> _ion, well, let's talk with serpentine folks about porting to libburn :)
<pygi> _ion, do they burn to dvd also? because  if yes, not much we can do
<_ion> I'm not sure.
<_ion> In the "disc capacity" widget it only offers CD sizes.
<pygi> _ion, oh, interesting then ^_^
<pygi> would benefit both, as I'd get a lot of testing, and they'd get more reliable burning
<pygi> _ion, is serpentine written in C?
<Burgwork> pygi: python
<pygi> Burgwork, right ... we'd need python extensions which I don't have time to write
<pygi> and there is also where we can see advantage of a library :P
<pygi> we can have ruby, python, perl, whatever bindings
<pygi> but anyway,lemme stop about that for tonight:P
<pygi> time to do some bug hunting ^_^
<_ion> Ruby 
<_ion> I could try writing Ruby bindings some day, unless someone else does it first.
<wasabi_> Where abouts are the results of the merge these days?
<wasabi_> DeveloperResources still list it in ~scott
<pygi> _ion, but written in C :P That is, as extension :) So Ruby C api knowledge needed :P
<Keybuk> wasabi: merges.ubuntu.com
<imbrandon> merges.ubuntu.com ?
<_ion> pygi: Yes.
<wasabi_> Well that's self-evident
<pygi> Keybuk, and it's not all about low level stuff
<_ion> pygi: It's quite simple, actually.
<pygi> Keybuk, bindings around libraries are needed, and genisofs which is based on already existing libisofs isn't low level at all :)
<pygi> (genisofs has yet to be written :P)
<Keybuk> pygi: I don't disagree
<pygi> _ion, for you, yes :P For me it's rocket science :)
<pygi> Keybuk, but I know I'm bothering, so I'd rather stop
<pygi> _ion, there is actually one way to burn dvd-r(w) using libburn, but a bit hacky :P
* pygi burned several dvd-rw's, yay :)
<pygi> _ion, anyway, writing ruby bindings right now is not a good idea IHMO,because api is not yet stable
<pygi> _ion, we should wait at least until we hit 1.0
<pygi> Keybuk, I'm doing as much as I can to advance quickly, much more then it's good for my studies
<_ion> pygi: http://ruby-dlx.rubyforge.org/quick_intro_example.xhtml
<pygi> _ion, no, I refuse to open the link :P
<pygi> _ion, hm, nice actually
<pygi> but I still don't have time to write bindings sorry
<pygi> too much low level stuff to handle
<cge> _ion, you are here. I'm really shocked after reading about how the trevino issue evolved.
<_ion> cge: You probably saw http://soijabanaani.net/tmp/the_trevino_story already?
<_ion> pygi: I didn't say you should. I might write the bindings some day. :-)
<cge> _ion, yes
<cge> _ion, someone else posted a link to it on Trevino's about how you had caused them to stop using Linux.
<_ion> Heh, right.
<cge> _ion, but this is going to blow up sometime when someone does something actually malicious instead of just warning. 
<minghua> good for them and good for Linux, IMHO
<Keybuk> _ion: he should have kept the wallpaper
<_ion> keybuk: That text is written by me.
<Keybuk> _ion: ah, well done for taking action
<Keybuk> I would have kept the wallpaper and told them that they're lucky you weren't installing other things on their box
<_ion> Anyway, he already removed my repository from his list. Of course, the rest of the list is still there and he still tells people to use it.
<cge> Keybuk, my proposed method for dealing with it was replacing Trevino's sources.list mangling package with a package that coerced users to reinstall Ubuntu by bugging them about it every time apt ran. But judging from the reaction the wallpaper got, we'd probably be getting death threats if we did that. 
<Keybuk> *shrug*
<Keybuk> the death threats will be worse when someone really roots their box
<Keybuk> and when ubuntu developers refuse to accept bug reports from those people
<imbrandon> hrm, i might stick something like the walpaper in my repo
<Keybuk> it's very disconcerting seeing cjwatson quit and join :p
<cge> imbrandon, has your repo been hit by trevino?
<imbrandon> cge, no, well not that i know of, but its still a good idea
<minghua> I really contemplated the idea of packaging _ion's wallpaper stuff so that interested repo maintainers can make a similar package easily
<_ion> The packages are available for download from http://johan.kiviniemi.name/ubuntu/the_warning_wallpapers/
<cge> minghua, if you get hit by Trevino's list, I have a package that breaks his upgrader process, and then warns the user about it every time they run apt-get until they reinstall or cause the postinstall script to stop failing :)
<minghua> cge: nah.  I am good hosting, and I doubt I'll provide third-party ubuntu repo ever (since I am MOTU now)
<minghua> I would like to use it for my Debian 3rd-party repo though
<minghua> (and besides, I am quite afraid of ubuntu users' death threats :-P)
<cge> minghua, It only works against Trevino. _ion's background would have to be modified too, but would be better.
<minghua> yes, I know he says Ubuntu on his wallpaper
<cge> minghua, the package name.
<minghua> what I was really interested is the gconf lockdown part
<_ion> minghua: http://johan.kiviniemi.name/ubuntu/the_warning_wallpapers/postinst http://johan.kiviniemi.name/ubuntu/the_warning_wallpapers/prerm
<minghua> _ion: thanks!
<wasabi_> Um. Uploading a new upstream version which isn't present in Debian (waiting on Debian maintainer to respond).  Debian version is like '3-2'. New upstream version is '4'. Proper Ubuntu upload version should be?  I'm guessing 4-0ubuntu1
<lifeless> yes
<wasabi_> Thanks
<imbrandon> lifeless, did you get my query yesterday ?
<lifeless> imbrandon: thanks dude, yes I did
<imbrandon> cool, just checkin , np :)
<wasabi_> Man... searhorse has been breaking debuild's signing for awhile now.
<wasabi_> There a fix for this?
<pygi> wasabi, manual fix,yes
<wasabi_> And it is?
<pygi> to remove all references to seahorse from pgp.conf in .gnupg/
<wasabi_> blah.
<wasabi_> Was hoping there was a way to make it work right. ;)
<pygi> open the pgp.conf and just edit it :)
<pygi> well, it works right then? :P
<pygi> for other things, bother seahorse upstream :P
<bluefoxicy> sladen: I got a core dump trying to get espeak to say obscene things about golf
<jk-> hi all
<Keybuk> jk-: hi!
<sladen> bluefoxicy: better file a bug then.
<jk-> anyone have a link to documentation about policy for library version numbers? (ie, why libfoo1 rather than libfoo?)
<sladen> bluefoxicy: be sure to include the particular obscene phrase
<bluefoxicy> sladen:  it was an (attempted) quote by some dude
<Keybuk> jk-: http://www.debian.org/doc/debian-policy/
<Keybuk> jk-: specifically Section 8
<bluefoxicy> sladen:  I think ... it's ... a stack smash.
<jk-> Keybuk: cheers :)
<bluefoxicy> sladen:  try espeak -K1
<bluefoxicy> (yes, I know -K isn't an option)
<bluefoxicy> (and no this is probably not a (useful) security hole)
<sladen> https://launchpad.net/distros/ubuntu/+source/espeak/+filebug
<sladen> and I'm sure that TheMuso will look into fixing it
<sladen> or pass it onto the correct people
<TheMuso> sladen: What bug?
<Telroth_Plushie|> any devs on?
<sladen> TheMuso: bluefoxicy is working on filing a bug report that if you pipe "I think ... it's ... a stack smash." | espeak -K1, then espeak seg faults
<bluefoxicy> sladen:  yes, filing, I just want to make sure it's not me (I have at least a dozen bugs that were "oops i did something that caused this")
<bluefoxicy> https://launchpad.net/distros/ubuntu/+source/espeak/+bug/71719
<Ubugtu> Malone bug 71719 in espeak "espeak faults on invalid arguments" [Undecided,Unconfirmed]  
<sladen> TheMuso: see previous line, and line before that for the bug URL
<TheMuso> Well I am pretty sure that the primary author of espeak is a bug contact for the package, so he should see it.
<sladen> excellent :)
<TheMuso> Yep, he is.
<TheMuso> bluefoxicy: Thanks for putting it through the crunch. Twill very like be much better for that.
<bluefoxicy> I didn't crunch it, I typo'd trying to -k15 o.o
<bluefoxicy> it just happened to throw a fit
<bluefoxicy> these unix programs, man I tell you
<TheMuso> Right
<bluefoxicy> you give them one wrong parameter and it's like the end of the world
<bluefoxicy> take `rm -rf /tmp/core-utils-2.15` for example
<Telroth_Plushie|> bluefoxicy, yeah, i can't wait until they're like windows programs, which throw a fit even when you give them the right parameters :)
<bluefoxicy> if you mistakenly hit enter after that first '/'....
<Telroth_Plushie|> bluefoxicy, no
<Hobbsee> then you're silly
<Telroth_Plushie|> you'll get a permission error
<Telroth_Plushie|> because 1) root shell is BAD
<bluefoxicy> Telroth_Plushie|:  it will still (eventually) eat your home directory.
<Telroth_Plushie|> and there's no sudo
<TraceGreen> I compile my kernel myself, when boot, kernel would show loaded driver boot info. How can i set kernel not to show such info?
<Hobbsee> hmmm, there's a point
<Telroth_Plushie|> bluefoxicy, ah, correct
<bluefoxicy> Telroth_Plushie|:  rm -rf'ing root is not a big deal
<bluefoxicy> reinstall
<bluefoxicy> it's that it crosses into /home that's the problem
<Hobbsee> _ion: nice work :
<Hobbsee> )
<bluefoxicy> (or /var if you're running a server)
<Telroth_Plushie|> is there anyone here that can be bothered to put the logitech g15 drivers into edgy repos?
<Hobbsee> Telroth_Plushie|: why not get them into the kernel (if they're GPL)
<Telroth_Plushie|> they aren't kernel drivers
<Telroth_Plushie|> more like libraries for using the keyboard
<Telroth_Plushie|> (a server to manage the applets for the screen, etc)
<Hobbsee> ah
<Telroth_Plushie|> (on a side note, the media key support is already in the kernel/xorg drivers)
<Telroth_Plushie|> Hobbsee, anyone you could recommend me to talk to about getting said libraries/drivers into the official repos?
<Hobbsee> hmm....
<Hobbsee> no idea who the correct person might be
<crimsun> edgy's a lost cause; target feisty.
<Telroth_Plushie|> i'll settle for either repo.
<Telroth_Plushie|> ;)
<crimsun> you don't have much of a choice, I'm afraid. Only feisty's open for development.
<crimsun> if there are existing packages, you can get them into universe
<crimsun> from there, write main inclusion reports as necessary
<Telroth_Plushie|> i think feisty would be best.
<Telroth_Plushie|> how would i go about getting them added?
<crimsun> see #ubuntu-motu's topic
<Telroth_Plushie|> thanks.
<Keybuk> imbrandon: ping
<imbrandon> Keybuk, pong
<sharms_> anyone know the proper channels to push / help out with getting grub a graphical splash screen in feisty? https://lists.ubuntu.com/archives/ubuntu-art/2006-June/002050.html  and https://features.launchpad.net/distros/ubuntu/+spec/ubuntu-art-grub-splash are the relevant links, but I don't see much movement there
<Keybuk> imbrandon: 1000 lines of "I will not forget debian/copyright in my source packages"
<Hobbsee> haha
<Keybuk> on my desktop by the end of lunch, please
<imbrandon> oh shit
<imbrandon> kk
<Hobbsee> what'd you do that in, imbrandon?
<imbrandon> i wondered why it was rejected, fixing now
* imbrandon headdesks
<Hobbsee> obviously he didnt run lintian/linda thru it for sanity
<Keybuk> sharms_: we're pretty decided that we don't want a grub graphical splash, unless it's possible to keep the graphical mode through to usplash
<Keybuk> imbrandon: yeah, we can't put messages in rejects :-/
<imbrandon> no biggie, i'll fix it up now and reupload here in a few
<sharms_> Keybuk: yeah I know this isn't the right place to really discuss it, but seems to me if feisty is going all graphical, we don't have much to lose?
<imbrandon> Hobbsee, mirage ( a NEW package from Seveas )
<Hobbsee> ahhh
<ajmitch> hi Hobbsee 
<Keybuk> sharms_: it would cause an extra mode switch, so paradoxically make everything look more ugly
<imbrandon> crap, i just realized i think i left my phone charger in sunnyvale at the hotel
<Hobbsee> hey ajmitch 
<cge> sharms_, I think it would also have to not be Ubuntu-branded, as that would be awkward for users who are dual booting.
<sharms_> imbrandon: most hotels will mail them to you
<imbrandon> sharms , yea , i'll call them tomarrow
<Amaranth> sharms_: graphical splash breaks on a good number of systems
<Amaranth> err, graphical grub splash, i mean
<sharms_> Amaranth: wouldn't that be an issue for other distros like fedora and suse?  how do they get around it?
<Amaranth> afaik they punt on the issue
<Amaranth> they put in the splash broken systems be damned
<Amaranth> Seveas: didn't grub splash break for you?
<jwhitlark> slow night...
<imbrandon> jwhitlark, man i sooooooooo slept through the phone
<imbrandon> heh
<jwhitlark> imbrandon, no prob.  My sink backed up that day anyway.  You back home?
<imbrandon> yea , just getting settled back in
<jwhitlark> anyone heard anything interesting about iFolder?
<jwhitlark> imbrandon, so what did you do sunday?
<imbrandon> slept, caught up from the week before 
<imbrandon> lol
<imbrandon> there was a blog post about iFolder
<jwhitlark> on planet?
<imbrandon> on planet yea, it was ubuntu planet or debian planet
<jwhitlark> k, i'll look into it.  seems cool.
<jwhitlark> of course, it's by novell, so I'll have to check the license carefully...
<jwhitlark> lol
<imbrandon> heh
<jwhitlark> imbrandon, did that key signing work?  
<jwhitlark> imbrandon, nevermind, I'll figure out how to check.
<imbrandon> ahh i havent looked since i got home
<imbrandon> lemme find the slip of paper
<imbrandon> and i'll do it now
<imbrandon> i still need to do BenC's too sometime
<imbrandon> lol
<jwhitlark> no rush.  I'm not going to have anything to sign with it until later in the week...
<imbrandon> :)
<jwhitlark> FeistyFawn, are you the one who gave me the tutorial about preseed?
<jwhitlark> brb
<jwhitlark> FeistyFawn, are you there?
<jwhitlark> imbrandon, they still gonna call it greyskull?
<imbrandon> the MOTU council ? probably
<imbrandon> jwhitlark, FeistyFawn is one of Seveas's bots
<jwhitlark> heh, I'm going to have to go back and rewatch He-Man...
<imbrandon> lol
<imbrandon> you know there is #ubuntu-motu too correct ?
<jwhitlark> imbrandon,  *** FeistyFawn is Dennis Kaarsemaker (n=seveas@ubuntu/member/seveas)
<jwhitlark> hmm.
<jwhitlark> no, I didn't.
<imbrandon> yea dennis, e.g. Seveas , its one if his bots ( like ubotu and ubugtu ) :)
<jwhitlark> heh, just watching for him, or does it do tricks?
<imbrandon> that one is meerly for tab completion afaik
<sharms_> is it too late to get a spec in for adding history-search-backward and history-search-forward to the bash profile? maybe throw in a history-append shopt also?
<sharms_> https://features.launchpad.net/distros/ubuntu/+spec/bashimprovement
<sladen> sharms_: needs fleshing out
<sladen> sharms_: eg. what do those keys already do
<sladen> what does 'PROMPT_COMMAND' do
<sharms_> sladen: gotcha
<sladen> sharms_: what does 'histappend' do?
<sladen> is history-search-backward what you already get with Ctrl-R ?
<sladen> do all those four need doing, what happens if only the each of them individually?
<jk-> so... the cdbs doc says this:
<jk-> CFLAGS are for the user to customize. Setting CFLAGS shouldn't override other internal flags used in the package like -I. 
<jk-> and so, the cdbs stuff sets CFLAGS (to -g -O2) for all builds
<jk-> has anyone come up with a sane way to add required CFLAGS in the makefile ?
<arvind_> http://www.atworkonline.it/~bibe/ubuntu/custom-livecd.htm is there a way to edit the grub menu? There seems to be no file in the filesystem.squashfs
<sivang> morning
<Hobbsee> heya
<sivang> hi Hobbsee 
<hunger> When will the merging start in earnest for feisty?
<Hobbsee> hunger: people have been merging
<ttoine> Tonio_: ??
<Kream> Hi all
<gnomefreak> ok was apt backported to edgy from feisty?
<user__> on the ubuntu install cd there is a file called splash.rle how can one modify such file?
<jonh_wendell> which package(s) should i install in order to have printf, sprintf, (c functions) docs, manual pages?
<bddebian> Howdy
<jsgotangco> Hey
<bddebian> Heya jsgotangco
<Lathiat> jonh_wendell: manpages-dev
<jonh_wendell> Lathiat: thanks
<Eons> Hi there
<Mirv> rodarvus: concerning AcceleratedX, I'd very much like to see consideration about when to enable (not install, but enable) binary driver. it should not be done on eg. all ATI cards, because the binary driver does not even support older Radeons.
<rodarvus> Mirv, this is covered by accelerated-x, actually.
<Mirv> rodarvus: because many people are of the opinion that the binary drivers are Bad, I'd suggest a compromise where NVIDIA cards will have proprietary driver, while ATI cards open source, because ATI has more properly working open source drivers and 3D effects should work on the open source drivers too
<rodarvus> (and this specific case is mentioned on the documentation of this specification)
<Mirv> rodarvus: it's not really clear, but yes it's in drafting and good that you are aware of the issues.
<ogra> rodarvus, oh, btw, i tried to manually compile the new mesa and ati driver for my radeon 200M ... apparently it doesnt solve the problem ... (or i simply miss patches)
<Mirv> rodarvus: also one thing I would like to see mentioned, is the possibility to remove the binary-drivers-by-default in the future, so as we are not going ever and ever in the non-free direction
<rodarvus> "The ATI proprietary doesn't supports Composite, and thus, will only be enabled for users with boards that are not supported by the open source 'ati' video driver. For them, 3D acceleration will be enabled, but Composite will be explicitly disabled" (text extracted from the spec)
<Mirv> rodarvus: if Nouveau (open source 3D NVIDIA drivers) get good enough for desktop effects, they should be used as default in feisty+1 or feisty+2, even if the performance otherwise would not be 100% of closed dirvers
<rodarvus> I believe this is already quite clearly stated, but I'm clearing it up even more.
<rodarvus> Mirv, nouveau will be available (but obviously not by default) on Feisty
<rodarvus> and if it is stable enough, will be default on feisty+1
<Mirv> rodarvus: oh sorry, my brains missed that thing, there's so much stuff on the page
<rodarvus> (this was all discussed during the BoF sessions btw)
<rodarvus> but thanks for the feedback, anyway :)
<Mirv> rodarvus: yes, that's very good to know. in general you are going to get flames from the NVIDIA people when you switch back to the free driver, but you just have to bear it
<Mirv> rodarvus: there's a lot of concern about the non-free thing currently going on, and sabdfl's comments have not been clear/helpful enough either.
<Mirv> rodarvus: thanks for listening :)
<rodarvus> Mirv, no problem
<rodarvus> please take a look at https://wiki.ubuntu.com/BinaryDriverEducation too
<LaserJock> are there any spec reviewers around? I need a review of https://features.launchpad.net/distros/ubuntu/+spec/edubuntu-menus-completion
<Burgwork> rodarvus: telling people we are violating their freedom doesn;t really help, sorry :)
<rodarvus> we explain on this specification why this specific choice was made, and what else we are doing on this regard
<_ion> Wow, i hadn't heard of this Nouveau project before. Very exciting.
<rodarvus> LaserJock, reviewers are busily working on this very moment, actually
<rodarvus> not sure when they'll get the chance to review your spec, but hopefully soon
<ogra> pitti, thats the lib we're missing for pulse: http://0pointer.de/lennart/projects/libasyncns/
<Keybuk> wow
<Keybuk> no syncs today
<kmon_> errr... I know this is not really the place to ask, but I've read in a planet kde blog about uds-mtv that ati/amd is thinking on HOW to release specs for their graphics cards. Is that a rumour or is it real?
<Burgwork> kmon_: that comes from Keith Packard, one of the lead X hackers
<kmon_> so I imagine he has good sources of information...
<kmon_> I was thinking about selling my x1600 card... but I gess I could wait
<ajmitch> even if it happens, it'd be awhile before there were useful drivers
<ajmitch> hi BenC 
<BenC> ajmitch: hey
<kmon_> ajmitch: well... I've read that dave jones has 2D acc. code for the r5xx drivers, but can't release it due to a NDA
<kmon_> sorry... I meant dave airlies
<Arador> kmon_: could you paste the URL where you read that ?
<kmon_> Arador: http://airlied.livejournal.com/31180.html
<Arador> thanks!
<_ion> Hehe. http://www.whiprush.org/2006/11/from_the_cant_p.html
<gouchi> Hi
<gouchi> does the current Edgy kernel contain bcm4x patch for CM43XX PCI-E Support ?
<plugwash> are there any plans to merge gaim 2.0.0beta5 for feisty?
<Burgwork> gouchi: it contains bcm43xx
<gouchi> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-April/001814.html
<pygi> plugwash, won't gaim 2.0 be released during feisty cycle? :)
<gouchi> Burgwork : don't know when the patch has been published
<Burgwork> gaim 2. 0 was supposed to be released ages ao
<pygi> Burgwork, true
<pygi> they have some internal problems, as always
<minghua> strange to see a mailing list URL indicating it's from April 2007
<gouchi> and patch for 2.6.18 kernel : ftp://lwfinger.dynalias.org/patches/
<pygi> minghua, you mean you haven't heard about cool new invention? :P
<Mithrandir> minghua: why?  It's just a misconfigured mailman installation.
<minghua> your mean time machine?  of course I heard about it.  just need some time to adjust. :-P
<gouchi> minghua : yep that's why I don't know when the patch has been published
<plugwash> pygi i wouldn't bet on it, the gaim devs seem to like the freedom to keep breaking api/abi compatibility
<pygi> plugwash, you mean the main dev which acts like he's god given? :P
<minghua> Mithrandir: err... other than I don't manage many mailman lists and don't seem it often, no.
<plugwash> pygi i don't watch in enough detail to tell
<pygi> plugwash, but brb in a sec ^_^
<minghua> (I suspect a user MTA misconfiguration than mailman misconfiguration, though)
<plugwash> all i know is that moving from one gaim beta to the next usually means breakage for custom protocol plugins
<minghua> or did Mithrandir mean mailman can be configured to refuse mails from future date?
<Mithrandir> minghua: no, it's a misconfiguration of the archival plugin where it's set to use the time from the user's machine instead of when it passes through mailman
<minghua> Mithrandir: I see, thanks for explaining
* mario_ = pygi is back
<admin123> can I invoke ubiquity partitioner fromt he commandline?
<admin123> some docs on partman??
<sladen> admin123: perhaps you want to use gpartman directly?
<admin123> allow me to explain. I'm creating a recovery cd, for almost 500 ubuntu computers. I need to achive the following: - autopartition disks(perhaps some easy program for that can be easly automated) - mount the partition (ok i can write simple code that will do that) - restore the biggbackuptarbal -installgrub(cand this be done without chrooting in?)
<mario_> admin123: you should talk to sivang about that
<mario_> he has plans to implement *something* just not yet now ^_^
<Burgwork> admin123: why not use kickstart that the alternate installer
<mario_> feisty+1 or even +2
<fabbione> pitti: ping?
<pitti> fabbione: pong
<fabbione> pitti: any news about libvirt?
<sladen> admin123: as Burgwork says, if you're doing automated installs, us the existing infrastructure (kickstart/preseeding), you don't want the GUI to be getting in the way
<pitti> argh
* fabbione throws some candies at pitti
<admin123> sladen, kickstart, I assume it works with the livecd to? I made modifcations in the squashfs.filesystem etc..
<gicmo> hey hey pitti
<pitti> hi gicmo
<mjg59> pitti: Can I wave main inclusion stuff at you, or is now a bad time?
<pitti> mjg59: I'll have a discussion with keescook now, then I'm going to process the queue
<mjg59> pitti: Rocking, thanks
* pitti notes that compiz stuff is 100% broken on ppc
<mjg59> pitti: Good to know :)
<pitti> (just bitching)
<mjg59> It works fine on all the x86 I can get my hands on, but my only PPC is running breezy
* gicmo finds that compiz is much more usablet then beryl
<pitti> mjg59: so has the compiz vs. beryl question been decided?
<gicmo> and /me hides from the beryl hackers
<mjg59> pitti: Nope
<sladen> admin123: the best thing would probably be to make a package that does your modification/customisations and install that onto each machines that you admin
<mjg59> pitti: Is rodarvus around anywhere?
<pitti> should
<pitti> mjg59: probably in the meeting in the other room
<pitti> mjg59: shall I ask him to ping you when I see him?
<mjg59> pitti: Please
<pitti> willdo
<mjg59> pitti: Could do with talking to him about acceleratedx. It's still quite misleading in places.
<Burgwork> admin123: if you are using GNOME, you can edit the users session with sabayon and pessulus
<AlinuxOS> mjg59, pitti hello ;)
<AlinuxOS> how are you ? ;)
#ubuntu-devel 2006-11-15
<aquarius> What's the best way, from a script, to test whether I'm running on Ubuntu? For Debian I'd look for /etc/debian_version
<mjg59> lsb-version ought to tell you
<ogra> actually lsb_release :)
<ivoks> lsb_release -c
<ogra> i.e. lsb_release -is
<ivoks> or that :)
<ogra> -c will only show the codename :)
<aquarius> cool. When did that first appear in Ubuntu? Right from the beginning?
<ogra> yep
<aquarius> nice. So if it doesn't exist then I can assume I'm not on Ubuntu at all. Superb; that'll make the Jokosher install script work much more nicely :)
<ogra> debian has it as well ... so if you depend on the lsb stuff you can use it there too
* Keybuk finds it ironic that KDE has educational spelling applications
<ogra> they are multilingual :)
<Keybuk> they still have inappropriate Ks in their name
<Keybuk> klassroom
<_ion> Hehe.
<Keybuk> (surprisingly, that isn't one -- but it should be!)
<ivoks> koqueror :)
<minghua> maybe there spelling education apps ignore inappropriate K's, who knows :-P
<_ion> en_US, en_GB, en_KDE
<dsas> Does kde when translated in other applications still retain the 'K' thing?
<Riddell> dsas: tragically yes
<dsas> s/applications/languages
<Riddell> dsas: this even goes as far as adding the letter K to Welsh which never previously had it in their alphabet
<ogra> Riddell, any plans to change that ?
<_ion> riddell: :-D
<ogra> upstream i mean ...
<Keybuk> Riddell: ch would be the closest match
<dsas> :-D, that's funny
<minghua> Chinese don't use latin characters, so they show up as whatever is spelled in English
<Keybuk> chanchwyr
<ogra> konsole is even appropriate in german :)
<ivoks> in croatian, we leave it as is, cause adding K to names would be horror
<Riddell> ogra: most of the core developers have accepted that new programmes shouldn't have K's in them but a lot of newer developers (who are often the ones that bring in new apps) still think it's cool
<ogra> meh
<ogra> teach them :)
<Keybuk> Riddell: I could REJECT them <g>
<ogra> (or Keducate them ;) )
<plugwash> what is so bad about the k anyway?
<plugwash> it provides a nice branding for kde apps
<Burgwork> Riddell: wouldn't that be kool?
<aquarius> plugwash: knothing. :)
<ogra> heh
<ivoks> plugwash: it can't be translated
<Burgwork> plugwash: it kauses problems
<plugwash> ivoks why the hell are app names being translated in the first place?
<Mithrandir> ivoks: so?  Applikation knames karen't ktranslakted.
<ivoks> Mithrandir: kbut lit kgoes kbeyond kapplication knames :)
<Keybuk> KMithrandir: kallegedly kthey kare
<minghua> I think many languages do translate "eye of gnome"
* Keybuk krealises kthat khe's KDE kompliant
<ivoks> ok, it's not allways
<ivoks> there's aRts :)
<Mithrandir> Keybuk: kthey'kre ktransklakted?
<Keybuk> slomo: ping
<Keybuk> kping? :p
<ivoks> k:)
<Keybuk> slomo: and I know you're there, because you ruthlessly filed sync requests while I was processing them
<chris_j> set theme fear2
<Keybuk> FEAR THE THEME
<chris_j> save
<chris_j> dodgy keyboard (!)
<Mithrandir> you're still allowed to read what you're typing.
<Keybuk> kick chris_j
<Keybuk> grr, dodgy keyboard
<Keybuk> :p
<chris_j> i'm sorry i'll try to keep my keyboard related diarrhea to a minimum
<Keybuk> good man
* mnepton coats Keybukin chocolate and sea urchins
<Keybuk> for fun?
<mnepton> and profit
<Keybuk> giskard: ping
<imbrandon> Keybuk, did you get my "assignment" ? lol
<Keybuk> imbrandon: yes thanks ;)
<dholbach> Keybuk: he went to bed
<Keybuk> dholbach: shucks to be him
<dholbach> Keybuk: hm?
<Keybuk> telepathy-sharp => REJECT
<Keybuk> autoconf output in diff.gz, bad
<Keybuk> Listing ubuntu/feisty (NEW) 0/0
<Keybuk> \o/
<malcc> WINNAH!
<pygi> ^_^
<pygi> Keybuk, until soon ^_^
<pygi> (or whenever new libburn is out :P)
<malcc> Keybuk: 1, Soyuz: )
<malcc> 0
<Keybuk> malcc: "Let the archive software win"
<Keybuk> "keybuks don't lose your archive when they lose"
<Keybuk> oh, bah
<Keybuk> LA LA LA
<ajmitch> sigh, we can't have the NEW queue being empty
* ajmitch digs around for stuff to throw at NEW
* Keybuk tries that again with the RIGHT RELEASE
<LaserJock> can't we just dump REVU into NEW? ;-)
<Keybuk> I figure it was kind of a bug that it stuck :p
<Burgwork> ajmitch: authtool
<Burgwork> fds
<Keybuk> shouldn't be able to modify the edgy seeds after edgy has released :p
<ajmitch> Burgwork: not FDS
<ajmitch> Burgwork: I was just considering authtool though
<Burgwork> but that would keep Keybuk busy :)
<Burgwork> maybe infinity as well, with all the build breakage
<ajmitch> FDS would keep anyone busy
<ajmitch> including manufacturers of painkillers
<Keybuk> fds?
<imbrandon> hrm things are still autosyncing ? gnash dident sync yet
<ajmitch> fedora directory server
<imbrandon> fedora directory serv.....
<imbrandon> wasent sure if it was service or server :)
<Keybuk> imbrandon: ?
<ogra> ajmitch, authtool++ ... for EAC/S ...
<ajmitch> once we get free java stuff in, we can even package up the admin console
<Keybuk> imbrandon: no such source in Ubuntu
<imbrandon> Keybuk, http://packages.debian.org/unstable/utils/gnash
<imbrandon> shouldent it autosync even as NEW ?
<Keybuk> no
<Keybuk> a) there's no such thing as autosync
<imbrandon> ahhh ok, shit i've been waiting for that to sync
<Keybuk> b) even if there were, we'd consider NEW syncs differently to just updates
<imbrandon> ok so i need to file a sync request after build tests etc
<imbrandon> ok
<Keybuk> no
<imbrandon> ?
<Keybuk> it just needs me to get that far down the new-in-debian list
<Keybuk> I haven't even started on that list yet
<imbrandon> ahhhh ok
<ogra> :(
<ogra> cant you priorize it ? 
* ogra would like libasyncns for pulseaudio love
<Keybuk> ogra: no
<Keybuk> it requires lots of beer
<ogra> :'(
<imbrandon> lol @ ogra
<Keybuk> pulseaudio seemed to build ok?
<ogra> ok, so tomorrow then after i gave you lots of beer :P
<ogra> yep
<Keybuk> so why does pulse need that?
<ogra> i run it locally ... but i have to disable some stuff 
<ogra> s/have/had/
<ogra> avahi integration
<ogra> its currently build without ... so its fine 
<ogra> just do it if you get to it
<Keybuk> First, uninstallable packages:
<Keybuk>     * ndiswrapper-1.1 1.1.0-1 produces uninstallable binaries:
<Keybuk>           o ndiswrapper-utils (powerpc sparc) 
<Keybuk> -- 
<Keybuk> that's really quite impressive
<_ion> Hehe.
<Keybuk> oh
<Keybuk> edgy
<Keybuk> Colin hasn't updated britney yet
<imbrandon> heh
<imbrandon> dinner , bbiab
* mnepton covers Brandon's chair in baby oil
* jovans is away: Ich bin beschftigt
<ajmitch> mnepton: causing trouble again?
* jovans is back (gone 00:04:20)
<_ion> jovans: Thanks a lot for the contribution to the discussion. I really appreciate it.
<ogra> jovans, please turn off public away messages in ubuntu channels
<jovans> no prob
<ogra> thanks :)
<jovans> ;)
<jovans> can everybody tell how can i join the artwork team on ubuntu?
<jovans> i'd like to working on it
<ogra> jooin in launchpad and join the ubuntu-art mailinglist
<jovans> hn
<jovans> m
<jovans> https://launchpad.net/people/ubuntu-art/+login
<jovans> right?
<bhale> mjg59: your CompizOnFeisty stuff not only works, it absolutely rules
<bhale> mjg59: it blows away SLED imo
<bhale> mjg59: and the 37-tab beryl window into hell
<_ion> I have yet to try a recent compiz (i'm waiting for a working nvidia 9000-series driver, and can't be bothered to run xgl)  can its window decorator be configured to use borderless windows (except for the title bar, of course)? If not, would a patch be accepted to the Ubuntu version?
<fabbione> Keybuk: what was the right procedure to request a sync AND override ubuntu changes?
<Keybuk> fabbione: changelog and bullet-point list of the ubuntu changes
<Keybuk> (which, if you're lucky, the person put in the merge changelog anyway)
<_ion> Shadows are enough to distinguish one window from other, and with them fat borders become redundant IMHO.
<_ion> (With "patch", i don't mean that a 0px border would or should be the default)
<fabbione> Keybuk: do you want it in a bug or just here?
<Keybuk> fabbione: bug please
<Keybuk> I've closed the window
<Keybuk> pitti has a script to do most of it
<fabbione> Keybuk: sure
<jovans> now i had joind the artwork team
<ogra> congrats
<pygi> '
<pygi> ^_^
<jovans> ;)
<_ion> vv
<pygi> _ion, hey ho ^_^
<Hobbsee> hey all
<jovans> wiki is also created but tommorow i will finished my wiki site
<pygi> hey Hobbsee :)))
<jovans> so however i go sleeeepppping in my bed ;)
<jovans> good night at all
<pygi> jovans, you mean someone still sleeps? :P
<_ion> The bed is a good choice.
<jovans> hehe
<pygi> _ion, almost 3 am here :(
<_ion> pygi: almost 4 here.
<jovans> ok
<pygi> and a lot of work to do which has to be done ASAP
* Hobbsee wishes it was time for bed
* Hobbsee has something far more evil to do than sleep
<mjg59> bhale: The applet is just the one from Fedora
<mjg59> bhale: So they have all the credit for that
<mjg59> bhale: And the compiz code is just recent git, so again upstream get all the credit
<mjg59> bhale: I'll claim the fringe benefits for the integration, though :)
* Mithrandir tickles Hobbsee 
* Hobbsee tickles Mithrandir back
<Hobbsee> hey you!
* pygi uses anti-tickling spray
<Mithrandir> Hobbsee: hiya, how are you?
<Hobbsee> Mithrandir: i've got uni exams :(
<Mithrandir> Hobbsee: what kinds of classes?
<ajmitch> hello Mithrandir 
<Mithrandir> hiya Andrew.  Long flight?
<Hobbsee> Mithrandir: first year maths, elec, phys, and computing
<fabbione> iwj: are you going to do lvm2 merge from debian or do you want me to do it?
<ajmitch> yeah, plane to christchurch was delayed as well
<iwj> fabbione: I'll do it.
<fabbione> iwj: ok'
* Hobbsee attacks pygi with her Long Pointy Stick of DOOM!!!!!!!!!!!!!!!! (tm)
<seb128> mjg59: I tried beryl previous week and compiz today and compiz seems much slower on my laptop, do you know if that's expected? is there any setting to change to maybe reduce the effects and make it faster (and didn't activate the wobble effect)
<Mithrandir> Hobbsee: not that evil, then.
<iwj> Hopefully I'll be awake tomorrow.
<Hobbsee> pygi: you dont have a spray against that!
* ogra waits for fabbione to offer to do the gcompris merge ...
<Hobbsee> Mithrandir: maths? are you kidding?  i hate maths!
<mjg59> seb128: "Slower" in what way? The effects take longer to complete, or they're less smooth?
<pygi> Hobbsee, I do
<Hobbsee> the rest shouldnt be so bad
<seb128> mjg59: less smooth
<Mithrandir> Hobbsee: math is the foundation for a lot of other things, though.
<fabbione> iwj: we do have a small delta on clvm compared to debian because we use a different version of the redhat-cluster-suite and the latest one is DepWait on libvirt/linxen to enter main. If you need the latest binaries for building just let me know and i can put them somewhere for you.
<fabbione> iwj: or you can grab the redhat-cluster-suite sources from feisty
<iwj> Noted.
<Hobbsee> Mithrandir: true that
<mjg59> seb128: I don't have an obvious explanation
<mjg59> seb128: I suspect that more performance work has been done on beryl than on compiz right now, but...
<seb128> might be
<Mithrandir> compiz seems nice enough on my x40, which doesn't have much in the way of opengl power
<Lathiat> mjg59: im sure this is probably already reported but i had to install compiz-gnome after desktop-effects before it'd work
<seb128> what is the keybinding for the expos like feature?
<Mithrandir> ctrl-alt-arrowup
<mjg59> Lathiat: I think that's mentioned on the wiki
* Lathiat was going off the e-mail
<mjg59> Lathiat: I'm not quite sure what the right thing to do there is. compiz-gnome isn't a hard dependency.
<Lathiat> mjg59: well, the desktop-effects panel thign refuses to start without it?
<Lathiat> and isnt the desktop relatively useless withotu the window decorator?
<mjg59> Lathiat: desktop-effects will start fine without compiz-gnome
<mjg59> Lathiat: There's a need for /a/ decorator, and right now compiz-gnome is the only one
<mjg59> But it should probably be a virtual package of some sort
<Lathiat> mjg59: here it sat there for a bit, then exited say cant find "gtk-window-decorator" and "failed to apply effects"
<Lathiat> mjg59: hrm, right
<mjg59> Lathiat: Oh, I see what you mean
<seb128> mjg59: default effects look nice, that's not too many of them like beryl :)
<mjg59> seb128: Yeah, that was the aim
* ogra so wishes his ati crd would do *any* 3D :(
<Hobbsee> ogra: cubes are overated
<ogra> i know, but everybody here has them 
<ogra> i feel so left out
<pygi> ogra, not everybody have them
<pygi> some dont wanna use them :P
* StevenK has Beryl on his X40 too.
<pygi> StevenK, be shhh!
* StevenK smirks.
<seb128> k
<seb128> I'll use compiz when we get those libwnck patches applied
<mjg59> Are they not upstream yet?
<mjg59> Tch.
<seb128> mjg59: should I have a look at those or are you working on it?
<seb128> I know where the patches are
<seb128> and I already had a look
<seb128> no, upstreams want things done cleanly
<mjg59> Feel free to go ahead
<seb128> the patches use some things which are not in the spec
<mjg59> Yeah
<pitti> mjg59: rodarvus seems to have disappeared...
<seb128> and elijah would like to get the additions done to the spec first
<mjg59> pitti: No problem - I caught him earlier
<mjg59> pitti: Sorry for not letting you know!
<Hobbsee> hey pitti 
* pitti waves to Hobbsee
* Hobbsee waves back to pitti, and continues to run around in circles
<mjg59> seb128: In any case, we're going to have to do something about compiz's desire to provide workspaces and viewports
<seb128> right
<seb128> I think I'll just apply the libwnck patches
<ajmitch> Hobbsee: having fun?
<Hobbsee> ajmitch: kinda.  i dont like exams :(
<mjg59> seb128: Because right now you'll get both of the offered, which is a recipe for confusion
<ajmitch> Hobbsee: ok, you can fix up samba compilation for me then :)
<Hobbsee> ajmitch: nope...i'm almost off
<pygi> Hobbsee, exams again? :P
<ajmitch> Hobbsee: oh well, good luck :)
<Hobbsee> pygi: uh...
<StevenK> s/again/still/ I bet
<pygi> I wrote one today, first one that went good I'd say :P
<Hobbsee> ajmitch: thanks
<seb128> hum
<seb128> g-t has refresh issues when using compiz
<seb128> when maximized the bottom line is not displayed correctly
<StevenK> Ah ha.
<pygi> seb128, am I allowed to enable libburn in brasero in feisty cycle? :)
<seb128> pygi: I'm not maintaining brasero, maybe ask slomo, probably yeah ;)
<StevenK> mpt: Rev 9 of about-ubuntu is up, if you want to let me know what you think.
<pygi> seb128, I'll take over that maintainership. The package is very bad IHMO :P
<jdub> hey seb128 
<pygi> hey jdub 
<jdub> good morning * :-)
<pygi> jdub, right, morning in 3:31 AM :P
<ajmitch> hey jdub 
<ajmitch> pygi: weren't you wanting to have it enabled in brasero right before edgy release?
<pygi> ajmitch, yes, but we agreed not to do it
<pygi> ajmitch, because it'd 'cause too much bug reports in such a short time
<pygi> but since I'm essentially recreating Brasero package right now, I can as well enable libburn as well
<ajmitch> ie, the work I put in to try & update & clean the package
<pygi> ajmitch, yes, that ^_^
<pygi> but you did a very nice job with libburn, it even works now :P
<pygi> unlike first two initial uploads
<pygi> (not your fault tho)
<ajmitch> going to push it for main for feisty?
<pygi> ajmitch, the libburn? most probably, yes
<pygi> we'll see how the development of it goes :)
<imbrandon> pitti, !!
* pitti ducks and whistles innocently
<imbrandon> lol
<ajmitch> heh
<ajmitch> pitti: how's SF?
<pitti> I wasn't it!!
<imbrandon> :)
<imbrandon> hows all hands ?
<pitti> ajmitch: pretty rad!
<pitti> thanks to Spads we had a great walk around the city, and today I bought Alcatraz tickets
<pitti> (for visiting the cells from the *outside*, of course) :)
<imbrandon> lol
<pitti> imbrandon: many hands here indeed, and nice to get to know my colleagues
<imbrandon> are either you or keescook doing any MIR this week, or should i poke yall next week ?
<pitti> I did some today
<pitti> imbrandon: just put it in the queue
<imbrandon> ahh nice /me looks if libmtp got some love
* ajmitch checks the queue
<imbrandon> ok
<pitti> no, it didn't
<keescook> imbrandon: I just learned how to do MIRs today.  :)
<imbrandon> okies :)
<seb128> hey hey hey jdub
<pitti> imbrandon: libmtp? that got approved ages ago
<StevenK> pitti: I wonder if anyone is conspiring to lock you in. :-P
<imbrandon> keescook, :)
<ajmitch> pitti: libvirt approved, but xen-3.0 isn't reviewed? how does that work?
<pitti> ajmitch: ENOTIME
<pitti> going bottom-up
<ajmitch> heh ok
<ajmitch> it just depends on libxen3.0 though :)
<pitti> yeah, yeah, tomorrow
<ajmitch> no problem
<pitti> I really wanted to do the ffox/tbird security updates today
<ajmitch> I'm not the one needing it in main ASAP
<StevenK> There's a firefox security update?
<imbrandon> keescook, welcome to MIR hell :)
<ajmitch> since I just need it for virt-manager, which won't go into main yet
<StevenK> Oh, gasp.
<pygi> ajmitch, my bet on libburn in main is until we have something that uses it
<pitti> StevenK: 1.5.0.8
<pygi> ajmitch, for exameple if we get burning over LTSP bits done
* StevenK finally figures out what MIR is.
<pygi> example*
<Lathiat> MIR?
<imbrandon> main inclusion reports
* ajmitch sees libnss-ldap in the queue
<ajmitch> painful package, that one
<fernando> I was building the libvirt package =(
<imbrandon> ahh pitti , my mistake looks like you approved libmtp ( i just dident get to it in time for edgy )
<imbrandon> thanks
<imbrandon> :)
<ajmitch> fernando: sorry, I'd had it mostly ready for awhile, and it was needed for something else 
<fernando> ajmitch: what do you need?
<seb128> hey pitti
* pitti waves to seb128
<ajmitch> fernando: sorry?
<seb128> ping carlos
<fernando> somebody is building the virt-manager package?
<ajmitch> fernando: yes, I said I am
<ajmitch> hey zul 
<fernando> hehehe
<ajmitch> zul: you recovered the power supply?
<zul> muhahaha its alive
<ajmitch> zul: cool, if you build me a kernel I can test, I'll try & break my box tonight
<ajmitch> or tomorrow
<zul> ok
<ajmitch> whichever works :)
<zul> or the next day
<ajmitch> I'll have to restart stuff because of the wonders of dbus
<pitti> keescook: yeah!
<keescook> pitti: heheh
<keescook> ping: pitti
<ajmitch> hey keescook 
<keescook> hiya ajmitch
<keescook> we're having fun solving pitti's tab completion.  :)
* pitti hugs seb128, it wasn't a gtk bug after all *phew*
* seb128 hugs pitti back, *phew* too :)
<rcarr> Any thoughts on a versioning backup system for feisty? i.e. you have it watch folders with inotify and when a file is modified it makes a hidden backup with a timestamp in the filename
<rcarr> and then a GUI for people to regress files to earlier versions 
<rcarr> I have a basic working implementation in python, and was thinking of submitting a spec, but wanted to see if there was any interest 
<ivoks> rcarr: contact https://launchpad.net/people/ubuntu-backup
<rcarr> Ah, thank you 
<jovans> hi@all
<jovans> can everybody tell why in edgy are not more k7 kernels?
<jovans> only generic
<hunger> When will the linux-image-generic get updated to the new feisty kernels?
<Hobbsee> jovans: there's been a discussion on the ubuntu-devel mailing list, please look that up
<Hobbsee> hunger: presumably when l-r-m is done
<jovans> because i had used alwas this kernel i have an amd
<hunger> Hobbsee: Great!
<Hobbsee> jovans: it was found that there were almost no performance differences
<jovans> yes u are wright
<jovans> one more question. why cannot see a detailed startup when i boot my machine? I only see die ubuntu logo
<geser> I'm looking on the feisty release schedule. Is there a date set when universe freezes?
<bhale> geser: not any time soon
<bhale> geser: it will be some time between UpstreamVersionFreeze and Beta Freeze most likely
<Adri2000> I don't understand why in edgy the pppoeconf version has been incremented to ubuntu1 with just "Resynchronise with Debian." in the changelog. If it's a sync, there is no ubuntu change?
<StevenK> But it's not a sync. There is likely a changelog entry further down that details what changes have been made in Ubuntu.
<Adri2000> StevenK: ok, but the remaining ubuntu changes are not mentioned, shouldn't they be?
<Fujitsu> Adri2000: Until about half way through Edgy, they didn't have to be.
<Adri2000> ok
<Hobbsee> Adri2000: it's only recently that that's being forced.  and people can miss changes, etc, so it's better to check
<Adri2000> and now what's the exact policy about the changelog when merging with debian?
<geser> Adri2000: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000182.html
<Adri2000> grab-merge.sh writes in the changelog "Merge from debian unstable", that or "Merged with Debian." I think it doesn't matter? we just have to describe the ubuntu changes. And the scripts signs the changelog with "Ubuntu Merge-o-Matic", I should change that also?
<Adri2000> script*
<geser> yes, you should put your name in the changelog
<geser> I use dch -e to edit the changelog after a merge. It puts your name below it automagically.
<Adri2000> ok
<zul> hey
<Hobbsee> hey zul 
<sivang> hi all
<Adri2000> tfheen: here? why did you remove the dependency on modconf from pppoeconf?
<jovans> i want to know if the kernel-generic ist the right kernel i have installed on my machine. Is the gernel-generic for both architektures?
<Hobbsee> yes
<jovans> hm
<jovans> ok
<jovans> i have upgraded to fiesty
<jovans> feisty
<jovans> sorry
<jovans> what if me wonder is that my machine boot faster because privior i had edgy installed
<user_> using kickstart on the Alternate install CD fails when detecting keyboard, I tried several keyboards but they all fail!
<bddebian> Howdy
<Adri2000> hi bddebian
<bddebian> Hello Adri2000
<Adri2000> tfheen: ping me when you are here please, there are two ubuntu changes in pppoeconf that are not clear to me
<user_> helllo
<user_> using ubuntu LTS, kickstart, however it fails with detection keyboard. Is this know? I can't find anything on bts about this.
<sbalneav> user_: Probably the #ubuntu channel could help you with this.
<user_> sbalneav, i can't get in
<fiddy> regarding the plan for making Bertyl/Compiz the default window manager on system with 3d support. I don't really see how this is practical
<ivoks> i don't see how someone could said that ubuntu doesn't enable composite by default :)
* ivoks ducks :)
<sharms> anyone here with large scale php engineering experience that can point me to a resource on standards for creating seperate php files in a project?  As in I need to hire someone for php work, but I dont want them writing one big ass file of flat code, looking for acceptable large project standards
<MidMark> pitti: have you received my email about hal?
<MidMark> if you have time I can provide an ssh login to check out the problem with dvd mounting
<MidMark> pitti please contact me just to talk 1 minute
<MidMark> someone else experiencing this bug? Help?
<MidMark> https://launchpad.net/distros/ubuntu/+source/hal/+bug/14692
<Ubugtu> Malone bug 14692 in hal "hal detects written DVD as empty" [Medium,Confirmed]  
<imbrandon> Keybuk, ping
<imbrandon> Keybuk, can you manualy promote libmtp to main ( MIR approved by pitti ) i'm going to upload an amarok that builds against it as soon as you do
<sivang> hey imbrandon dude ;)
<pygi> sivang, hello
<sivang> pygi: hi Mario
<sivang> pygi: what's up?
<pygi> sivang, nothing much, just gave debdiff for Brasero to Mez
<pygi> the package was completely broken :)
<pygi> thanks to the almighty debian maintainer who cares so much for it :P
<sivang> pygi: right , goot to have him around then
<pygi> sivang, I'm talking sarcasm :P
<pygi> The Debian maintainer had everything screwed up
<sivang> pygi: I was referring to Mez ! :-)
* sivang hugs Mez 
<pygi> sivang, oh, that :P
* Mez hugs sivang back
<sivang> infinity: do you happen to have an ETA for when the prop. drivers for ati should hit feisty ?
<Mez> infinity, ping /
<sivang> pygi: backup config meta data class is now finished btw, I'm now working on integrating everything into the Backup object.
<imbrandon> sivang, heya
<pygi> sivang, very nice
<pitti> imbrandon: upload it now, then it will be promoted; not the other way round
<pitti> MidMark: in a meeting; just /msg me, I'll answer later
<imbrandon> pitti, ahh ok, last time ( with libnjb ) it was the other way arround, okies, uploading now
<pitti> MidMark: if you are 'Cimmo', I got it
<pitti> MidMark: but no time here at the conf
<MidMark> pitti: I'm Cimmo yes, then contact me when you are free or give me a date...
<MidMark> just to let you debug the problem
<Mez> pitti: ssh update in the works ?
<jdong> infinity: ping (about -backports building against -updates)... is it done yet / can it be done
<jdong> infinity: bah, I gotta run... direct any responses to imbrandon :)
* sivang didn't know there were canonical cloaks 
* jdong ducks and hides before he has a chance to WFT me :)
<imbrandon> sivang, there isnt , its where they are connecting from ( we all had them at UDS )
<imbrandon> notice it says @confrence/canonical/........
<pitti> MidMark: end of next week, when I'm back home, does that work for you?
<pitti> Mez: no?
<MidMark> pitti ok none a problem, but can I ask somethings very fast?
<MidMark> do you think it's a hal problem?
<pitti> MidMark: either a hal or a kernel bug, I'm not sure before debugging this
<MidMark> pitti ok contact me next week or I have to ping you?
<pitti> MidMark: I'll answer to your mail next week; what's a convenient day time span for you?
<sivang> pitti: till when the allhands is going?
<pitti> sivang: end of this week
<AlinuxOS> pitti, ;) hello!
<jdub> pitti: try to avoid fire while enjoying yourself to the max. :-)
<sivang> pitti: okay
<MidMark> pitti: I live in gmt+1 time  and you?
<sivang> jdub: which kinds of fire has he to avoid? :p
<imbrandon> jdub, !!!
<pitti> MidMark: exactly the same (Germany)
<Keybuk> sivang: the hot kind
* pitti hugs jdub
<pitti> jdub: too late, two days ago we broke a piece of burning wood with our hand :)
<MidMark> pitti: ok for me best time is around 12 to 14 o'clock, better not in the WE
<jdub> pitti: i just wet myself reading jamesh's blog
<jdub> thought i'd offer a warning ;-)
<sivang> jdub: oh my god
* sivang hopes jamesh's blog has good explenations for all of this.
<pygi> sivang, what's with his blog
<pitti> MidMark: that's good
<sivang> pygi: see what Keybuk and jdub said
<sivang> mnepton: Hey Kurt, shame I couldn't come to UDS as we could have met according to your cloak ;)
<MidMark> pitti: ok great, thanx a lot, I'm a little bored to not read dvd that I have burned :(
<pitti> MidMark: in the meantime, try to insert an audio CD and then the DVD
<pygi> MidMark, that's what you get when you use cdrecord :P
<MidMark> pitti: I can try, for now the only way is to boot with the dvd inside or add a second session
<MidMark> pygi: I use k3b
<pygi> MidMark, that uses cdrecord as backend^_^
<MidMark> pygi: also dvd-rw-tools
<pygi> MidMark, indeed =P
<mnepton> sivang: aye, i was at UDS. but that's over, and i'm now in SF.
<pygi> ergh, why everybody continues to mention UDS? :P
<pygi> stop that, you're making me sad :P
<MidMark> in my opinion it's a bad reading of sessions, don't know if is it hal or kernel or udev or who?
<sivang> mnepton: are you also catching fire like jamesh is? (http://blogs.gnome.org/view/jamesh/2006/11/15/0)
<pygi> MidMark, where do you experience bad reading of sessions?
<MidMark> in all dvd with one session and disk not closed
<MidMark> cd all ok, dvd with two or more sessions, ok, dvd closed ok
<pygi> MidMark, I'd still loosely tight it to cdrecord issues
<mnepton> sivang: "flame on!" is my middle name
<pygi> dvd+rw issues that is, since it's dvd
<MidMark> pygi: no dvd+-r and rw all kinds od dvds
<pygi> MidMark, I meant dvd+rw tools, not media :)
<sivang> mnepton: do you have any specs you're working on or were you just to have support team discussions and meetings?
<jamesh> sivang: I think there were only two people who caught fire
<sivang> jamesh: heh, who were they?
<jamesh> the rest were fine
* mpt wonders what happened to mnepton's K
<jamesh> I think it was me and mdy
<mnepton> sivang: yeah, i'm in charge of porting ActiveX and Windows Genuine Advantage to Ubuntu
<sivang> send him my regards :)
<sivang> mnepton: HA-HA-HA
<MidMark> pygi: mmm the worst thing is with Dapper I had no problem :(
<sivang> jamesh: to mdy, that is.
<mnepton> mpt: i have a couple different clients. this one is for public channels where i don't care about logging.
<pygi> MidMark, dunno really, I could test, but I'm doing all my burning throught libburn
* mnepton also uses this client for dumping maple syrup and scorpions into Seveas' pants
<sivang> mnepton: have you happend to hear from Irina/Boris btw? since I asked her to investigate the 22nd hour failure in the 24hr and contacted her again to see what'sup I havne't got a response.
<mnepton> sivang: have not heard anything, but i will let you know if i do.
<sivang> mnepton: I'm contemplating sendin another reminder email, although last time she noted she require more time. A dilemma
<MidMark> pygi: thanx for your interest, hope that pitti will understand the problem
<fabbione> madduck: ping?
<mnepton> MANAH MANAH!
<fdoving> mdz: ping? can you take a look at https://launchpad.net/bugs/69583 ? kopete icq connection fix (upstream changed the previous fix, new debdiff in comment 13).
<Ubugtu> Malone bug 69583 in kopete "SRU: kopete can't connect to ICQ. " [Low,Fix committed]  
<ogra> fdoving, i think someone from the KDE team would be a better ping target :)
<fdoving> ogra: they can't approve SRUs.
<fdoving> it's for edgy.
<madduck> fabbione: yessir
<madduck> fabbione: (did my contentless ping script not do anything?)
<fabbione> madduck: hey dude... 
<madduck> hi
<fabbione> madduck: not that i could see.. no
<fabbione> madduck: so i am merging mdadm right now
<Riddell> fdoving, (mdz): I'll look at that
<madduck> tfheen: it's very sporadic...
<madduck> fabbione: ok... have fun. :)
<madduck> tfheen: (contentless-ping i mean)
<fabbione> madduck: i am going to do an upload with a consistent delta, and if that's ok with you, next week we can hammer the delta down
<Riddell> fdoving: I've not been in a major rush with it since if they changed their protocol twice in a week don't want to upload if they're doing the same again, but I'll look at it now
<fabbione> madduck: yes. i have done already. it's not difficult
<madduck> fabbione: next week i'll be in singapore
<fabbione> madduck: ok.. 2 weeks?
<madduck> fabbione: i am on vac until 12/12
<madduck> 3
<fabbione> oh
<fabbione> sure
<fabbione> that's fine for me
<fabbione> there are changes in your scripts i am not sure i grok 100% and i would like to go trough them 
<madduck> fabbione: sure thing.
<madduck> however, i also plan to rewrite much of it post-etch.
<fabbione> madduck: so that i can reduce the delta and we can look at what we can push into your package
<madduck> but i suppose we must do it twice then. :)
<fabbione> madduck: that's ok with me
<fdoving> Riddell: ok, it was already approved for -proposed, by mdz. But 2h after he approved the debdiff, upstream improved the fix, so this is the new (and hopefully final) fix.
<madduck> or keep the delta until after the rewrite, then merge again and reduce?
<fabbione> yeah well the more we can get into your tree, the less i will need to sync later
<fabbione> sure
<madduck> true
<fabbione> either paths will work
<madduck> fabbione: which version are you syncing?
<madduck> 2.5.6-5 is current
<madduck> uploaded today
<fabbione> hmmm
<fabbione> 2.5.5-1 
<fabbione> ok.. i can just resync tomorrow
<madduck> that went into etch today
<madduck> changes are minor.
<fabbione> Keybuk: did MoM run properly against sid?
<madduck> fabbione: i uploaded it *today*
<fabbione> madduck: did you upload 2.5.6-1 before that?
<madduck> itn's not even in sid yet.
<madduck> nope.
<fabbione> meh
<fabbione> ok
<madduck> 2.5.5-1->2.5.6-5
<fabbione> Keybuk: nevermind
<fabbione> madduck: ok, than MoM will pick it up tomorrow
<fabbione> no big deal
<madduck> y9u could just work from svn...
<fabbione> madduck: i don't have enough resources to track all my upstream at that level
<fabbione> madduck: i need to rely on some tools like MoM'
<madduck> i would have thought hct...
<madduck> oh well.
<madduck> whatever MoM is.
* madduck is not up to date on how you guys do your stuff
<fabbione> http://merges.ubuntu.com/main.html
<fabbione> s/main.html//g
<madduck> i am also too busy with etch to read that. :)
<fabbione> madduck: yeah it's just a tool that tracks ubuntu <-> debian package deltas and help merging stuff
<fabbione> madduck: nothing too fancy
<fabbione> but you might notice that my name is on a few tons of packages :) just too many to track them all manually
<madduck> i am not arguing.
<madduck> but you're also the openssh person, right?
<madduck> i mean the one for debian with kamion, no?
<madduck> or do you not do openssh?
<fabbione> hmm no
<fabbione> i am not into openssh
<madduck> ok, never mind then.
<madduck> fabbione: if you have qs, send mail. i can read for the next weeks. better than IRC.
<madduck> and one q per mail, okay? :)
<madduck> think internet cafe and having to leave quickly
<fabbione> madduck: sure.. i am in no hurry
<mnepton> madduck: you could always choose the path of most resistance and talk to Theo directly. but i only sugest that if you're suicidal or working on an advanced degree in anthropology.
<madduck> mnepton: no. thanks.
<madduck> i am just curious about an aspect.
<madduck> i am writing logcheck rules
<madduck> and i see entries like this
<madduck> sshd[22039] : (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mta3.kpost.com
<madduck> if i log in and punch the wrong password, i get
<madduck> sshd[16974] : (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=wall.oerlikon.madduck.net  user=madduck
<madduck> so something is speaking to sshd and not giving a user name.
<madduck> sounds like the admin doesn't have to care about when that happens as there's no danger, huh?
<mdz> fdoving: I'm in back-to-back meetings this entire week, will look at it as soon as I can
<mdz> fdoving: try cjwatson@ubuntu.com as my backup
<fdoving> mdz: I will, thanks. Enjoy the meetings :)
* mnepton tootles off to call support customers
<zntneo> I know this isn't a support channel but i'm having problems with the apt version of acx-110 driver
<unfo> hi all, has ubuntu ever tried to buy out the www.ubuntu.org domain?
<unfo> people assume that since Ubuntu Linux is open source that it will be at www.ubuntu.org.
<unfo> who knows, perhaps they'll even be willing to donate the domain name away like the owner of www.firefox.com did for Firefox.
<LaserJock> I would guess that that has been thought of before
<unfo> LaserJock: i tried searching on google and google groups and found nothing.
<unfo> Although I'm sure it's been thought of, I wonder if anyone's ever tried to get the domain.
<Burgwork> I would widely assume yes, but that is really between canonical and whomever currently owns .org
<unfo> Burgwork: does ubuntu have a project affairs mailing list just like debian's debian-project list?
<Burgwork> unfo: not really
<unfo> :(
<bhale> unfo: what is your question?
<bhale> there is certainly places to pose a question of the right people.
<unfo> bhale: see 8 lines above :)
<bhale> meh.
<unfo> bhale: i think getting the www.ubuntu.org domain would be a valuable service to newbies.
<bhale> people have been getting there for 2 years now without any trouble
<unfo> Or at least getting a big ad banner at the top "Ubuntu Linux - the safer alternative." or something
<bhale> and if you are really a newbie you think everyything ends in ".com"
<unfo> bhale: good point about .com. hmmm.
<bhale> you could discuss it on ubuntu-sounder list
<bhale> im sure someone would shell out $20 for the domain if it made someone feel better
<unfo> bhale: the domain is taken.
<minghua> I think it's sounder@ list instead of ubuntu-sounder@?
<unfo> bhale: thank you.  I found that the topic has already been brought up:   http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html
<unfo> oops
<unfo>  http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html
<bhale> still missed it
<unfo> argh! I wish I could middle-click paste from Ctrl-C clipboard into irssi.
<unfo> it's http://archives.free.net.ph/message/20060321.132326.e393d80b.en.html
<bhale> I agree with Paul, with a slighly worse case of apathy
<LaserJock> bhale? apathetic? never ;-)
<fabbione> dholbach: ping?
<fabbione> ECHAN
* bhale hugs LaserJock 
#ubuntu-devel 2006-11-16
<Mithrandir> dholbach: please tell labyrinth upstream to use PKG_PROG_PKG_CONFIG rather than AC_CHECK_PROG; apart from that it looks good.
<ajmitch> hello Mithrandir 
<Mithrandir> hiya Andrew
<dholbach> Mithrandir: congratulations on getting cracking on the NEW queue
<dholbach> Mithrandir: WTF!?! What happened to tfheen?
<Mithrandir> dholbach: lucky me!
* dholbach gets confused
<Mithrandir> dholbach: haha. :-)
<Mithrandir> it's Mithrandir now; tfheen just hangs around
<dholbach> tfheen: SLACKER!
<infinity> tfheen's a jerk anyway.  Mithrandir's a more relaxed guy to deal with.
* Mithrandir ruffles infinity 
<imbrandon> heh
<imbrandon> heya fellas
<ajmitch> hi Hobbsee 
<ajmitch> imbrandon: when are you going to get those podcasts going?
<imbrandon> Mithrandir, can you manualy promote libmtp so amarok can get out of depwait on the buildd's ( pitti said upload THEN poke )
<imbrandon> ajmitch, hrm when me and whiprush and sladen get off our hineys
<imbrandon> lol
<imbrandon> hopefully this week
<LaserJock> ohhhh, podcasts :-)
<ajmitch> ah, a round tuit problem
<imbrandon> yup
<imbrandon> after that jokeosher showing at UDS i think i might try that this time round instead of audacity
<ajmitch> yeah, I've got to get into jokosher for some local radio stuff
<ajmitch> we've been using audacity
<Hobbsee> hey ajmitch 
<imbrandon> yea audacity is good , but clunky
<Mithrandir> imbrandon: let me see if I can manage that without breaking anything.
<imbrandon> hehe thanks
* _ion switched from software to hardware for multi-track recording. :-)
<ajmitch> Mithrandir: you have powers for queue prodding now as well?
<Hobbsee> hey Mithrandir 
<imbrandon> brb phone
<Burgwork> keescook: yay for having inkscape dev on staff!
* keescook dances
<Mithrandir> ajmitch: indeed, I do.
<Mithrandir> hiya Hobbsee 
<imbrandon> Mithrandir, once thats done soyuz should pick those back up for rebuild correct ?
<imbrandon> ( since they are in depwait now )
<Mithrandir> imbrandon: yes, iirc.
<imbrandon> k cool
<Mithrandir> imbrandon: there, promoted
<ajmitch> is libvirt promoted yet, or is it still blocked on xen?
<Mithrandir>    libvirt | 0.1.8-0ubuntu1 | feisty/universe | source
* fabbione would really need libvirt & co promoted
<ajmitch> fabbione: yeah, it's been reviewed & approved at least
<fabbione> Mithrandir: it's a B-D for redhat.-cluster-suite and approved by pitti
<fabbione> ajmitch: i know
<fabbione> ajmitch: i was right behind pitti to make sure ;)
<ajmitch> no pressure on pitti :)
* pitti pulls the knife out of his back
* ajmitch wishes we didn't have an old openldap - current samba svn doesn't build with it
<Keybuk> Mithrandir: when you promote things, make sure you edit the MIQueue wiki page and move the source to approved
<Mithrandir> Keybuk: already done.
<imbrandon> Mithrandir, Keybuk thanks guys
<Keybuk> is a mnepton different from a mneptok?
<ogra> one is wagging its tail, the other isnt ?
<Mithrandir> dholbach: why does telepathy-sharp include both a LICENSE and a COPYING file?
<dholbach> Mithrandir: I can't tell you - I didn't look at it.
<Mithrandir> dholbach: indeed.  I just imagined tht.
<Mithrandir> that, even
<Mithrandir> giskard: ^^ ?
<dholbach> Mithrandir: he might be in bed already :)
<Mithrandir> dholbach: he'll probably read scrollback
<dholbach> *nod*
<Keybuk> Mithrandir: they might be different
<Keybuk> some of the telepathy stuff is dual licenced
<Mithrandir> Keybuk: both looked like MIT to me, just different line breaks.
<ogra> seb128, checking for GNOME_SCREENSAVER_DIALOG... configure: error: Package requirements (libglade-2.0 >= 2.5.0
<ogra>         gtk+-2.0 >= 2.7.0
<ogra>         libgnomekbdui >= 0.1) were not met:
<ogra> No package 'libgnomekbdui' found
<ogra> do you have that packaged already ?
<seb128> ogra: no, I'll have a look at packaging it soon
<ogra> thanks
<ogra> i'll wait with g-s-s for it then
<seb128> k
<imbrandon> Keybuk, afaik they are both kurt, one he uses for official support, one for "goofing off" iirc
<Burgwork> umm, oops. How did this one slip by: ubuntu-artwork ships a cc-nc background
<jdong> gasp
<Hobbsee> a what?
<Burgwork> creative commons- non-commercial
<Hobbsee> oh right
<Burgwork> one of the biggest mistakes the CC made, IMHO
<dholbach> Burgwork: which file is under that copyright? where does it say that?
<ajmitch> Burgwork: that's worrying
<Burgwork> only one, just checked the copyright
<Burgwork> https://lists.ubuntu.com/archives/ubuntu-art/2006-November/003522.html
<Burgwork> /usr/share/doc/ubuntu-artwork/copyright
<dholbach> that's sharealike 2.5
<Burgwork> no, it is Non-Comm ShareAlike
<dholbach> in ubuntu-artwork
<Burgwork> which prevents selling of it
<elkbuntu> http://creativecommons.org/licenses/by-nc-sa/2.5/
<dholbach> that file is part of edgy-community-wallpapers
<Burgwork> right, but we are still shipping it as part of dapper in ubuntu-artwork
<Burgwork> so we need a quick relicensing 
<Burgwork> want me to take it up with the author?
<LaserJock> heh
<Burgwork> LaserJock: stop imaging baseball bats :)
<LaserJock> "can I, can I, please, please"
<elkbuntu> agreed, a sawn-off is more amusing
<Burgwork> a lot of artists use -nc because of this fear int eh art community about "commercial exploitation"
<Burgwork> I have quite a few debates with art teams for various games over it
<ajmitch> Burgwork: ie, they want only a few people to use it - rather silly
<jdub> commercially exploited by... ubuntu!
<ajmitch> jdub: those evil corporate vultures
<Burgwork> dholbach: hmm, you are right. At any rate, it might be a good idea to issue an update to dapper to fix it
<dholbach> Burgwork: I'll need to have a closer look
<dholbach> brb
<Burgwork> dholbach: shall I file a bug?
<dholbach> Burgwork: no, not necessary, thanks.
<Burgwork> sounds good
<imbrandon> umm afaik canonical dosent sell ubuntu, it sells support
<imbrandon> ( and the 1.50 for the edgy shipit covers the media , not the content , and is stated that way )
<Burgwork> imbrandon: read the license text
<imbrandon> i know what the CC non-comercial lic is
<Burgwork> "You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation."
<imbrandon> right and ubuntu does neither
<Burgwork> but there are lots of companies that do
<imbrandon> they support ubuntu, they dont sell it
<Burgwork> what if you sell an Ubuntu cd?
<LaserJock> imbrandon: but it's still not DFSG free
<imbrandon> LaserJock, we have LOTS of things that are not dfsg free
<imbrandon> we arent debian
<jdub> canonical sell ubuntu CDs via amazon
<ogra> and DVDs :)
<LaserJock> imbrandon: but it's still an important consideration
<mjg59> imbrandon: There should be nothing on the CDs that can't be sold
<jdub> NC is a plague
<imbrandon> amazon makes and sells those, its says so on the page
<mjg59> imbrandon: Because, well, people sell the CDs
<rmjb> and jdub throws a wrench
<Burgwork> imbrandon: the only thing we have that isn't DFSG-free, afaik, is the various CC licenses
<jdub> imbrandon: so they're magically allowed to break the NC?
<Mithrandir> Burgwork: and GFDL.
<Burgwork> and that
<imbrandon> i'm not saysing its not bad, but its not a ubuntu issue, that is amazons problem and anyone else that sells it, we should fix it yes, but as far as "ZOMG WE"RE BREAKING TEH LAW" is wrong
<jdub> NC == "fuck you and the horse you rode in on"
<elkbuntu> oh how i love watching licence compatability debates... popcorn anyone?
<mjg59> imbrandon: Dude, it is *entirely* our problem if we're providing things to people that we know are going to sell it
<Burgwork> imbrandon: if we are a original distributors of it, we should fix it
<mjg59> We even state that everything in main can be sold
<jdub> imbrandon: it's not breaking the law; it's breaking our promise to distributors such that they are breaking the terms of the license.
<imbrandon> Burgwork, i just said yes we should fix it, but its not zomg we are teh evil now
<mjg59> imbrandon: No, we explicitly say that everything in main and restricted can be sold.
<Burgwork> apparently it has been fixed in Edgy
<imbrandon> jdub, right, i totaly agree its no right, thats not my point
<mjg59> imbrandon: If it turns out that that's not true, but if someone gets into trouble because of the guarantee we made them, then we *are* evil
<jdub> but that is everyone else's point :-)
<imbrandon> mjg59, wow really, i've seen that implied but never in writing, i could be wrong
<jdub> Ubuntu: Linux for Human Jailbait
<mjg59> imbrandon: All application software in both main and restricted must meet the following requirements: Must allow redistribution. Your right to sell or give away the software alone or as part of an aggregate software distribution is important because: (etc)
<mjg59> http://www.ubuntu.com/ubuntu/licensing
<jdub> hey, that doesn't have "must not make baby jesus cry"
<elkbuntu> jdub, because that would rule out the consumption of kittens and puppies
<imbrandon> :) like i said i could have been wrong, my appologies, anyhow its our promis and should be fixed yes, but its not against the law as was first implied as i took it, thus my statements
<Burgwork> well, actually it is
<ajmitch> jdub: partly because large chunks of main would be affected
<jdub> ajmitch: haw haw.
<Burgwork> if you are not distributing it under the license, you are distributing it under standard copyright
<Burgwork> which leaves you sol
<jdub> imbrandon: breaking NC -> falls back to copyright -> can't distribute -> illegal -> meet my friend bubba
<octan> hi all.. 
<jdub> it's a short fall from freedom to the intimate company of a large bald man
<imbrandon> heh
<Burgwork> imbrandon: this is what SCO discovered and why they stopped trying to kill the GPL
<octan> the kernel. does it have support for the iptables "owner" modules henc ->iptables - m owner --cmd-owner name fooblah,, stuff ? do anyone know?
<jdub> darl mcbride, meet bubba mclubemeup
<imbrandon> lol
<fabbione> Mithrandir: did you already promote libvirt to main?
<Mithrandir> fabbione: no, but somebody else might have.
<mnepton> jdub: was that an offer? because i could probably change my return flight plans if Pia is going to be out of town ....
* mnepton disturbs mpt off the network
<jdub> mnepton: are you darl mcbride or bubba mclubemeup?
<jdub> I THINK NOT.
<fabbione> jdub: hey dude!
<mnepton> jdub: tease.
<jdub> yo fabbione!
<fabbione> jdub: my dog has no nose!
* mnepton goes looking for a full-head latex Darl McBride mask for jdub sodopossibilities
<kylem> yarr.
<mnepton> arr?
<jdub> fabbione: how does it smell?
<fabbione> jdub: TERRIBLE
<Keybuk> jdub: What's brown and sticky?
<jdub> a stick insect!
<Keybuk> a stick
<jdong> Keybuk: is that an artwork joke? :D
<Keybuk> jdong: no?
<Keybuk> should it be?
<johanbr> Why does update-manager accept both "--dist-upgrade" and "--dist-ugprade" ?
<jdong> idn, I'm not an artsy guy....
<Keybuk> me neither
<jdong> johanbr: LOL
<Keybuk> when it comes to art, I know what I like -- which is mostly those lovely greek statues, but that's about it
<jdong> wow, pbuilder just hates me today
<jdong> I'm getting the wackiest errors from it
<jdong> first, it's:
<jdong>  -> Considering  python (>= 2.4)
<jdong>    -> Trying python
<jdong>  -> Considering
<jdong>    -> Trying
<jdong> (gaim)
<johanbr> Yes, those geek statues are really... never mind.
<jdong> well, I'm glad that dependency was satisfied :D
<jdong> more concerning, 
<jdong>  -> Considering  libgnome2-dev (>=
<jdong> dpkg: --compare-versions bad relation
<jdong> can anyone with spare time confirm xchat-gnome fails in pbuilder with that libgnome2-dev error?
<Keybuk> johanbr: size isn't important
<johanbr> eh?
<jdong> johanbr: if apt-get would accept the latter, it'd save me about 15 retypes over the last month
<johanbr> jdong: That's what ctrl-t is for (most useless bash control sequence ever).
<jdong> johanbr: still, accepting one-letter swaps would be an awesome feature
<jdong> if it's unambiguous
<johanbr> I'm sure somewhere, someone has written a unix command called mr whose most common invocation is "mr -rf /".
* HrdwrBoB brb, registering mr.sf.net
<jdong> ah yes, the rough slasher
<_ion> % mr
<_ion> zsh: correct 'mr' to 'rm' [nyae] ? 
<Arrogance> do I enter ubuntu.com bugs into Launchpad too?
<LaserJock> yeah, using the ubuntu-website product
<Arrogance> thanks
<wasabi_> There any specific benefit in not including OCFS2 in the desktop kernel?
<wasabi_> Other than making it hard for me to try it out on my desktop. ;)
<unfo> hi all, why does gnome-app-install (the superb Add/Remove Programs... tool) take so much longer than aptitude to start up?
<LaserJock> it reads in a lot of data I suppose
<unfo> but doesn't it somehow cache the data?
<johanbr> Probably also because aptitude is written in C and g-a-i in Python.
<unfo> i should run it thru a python profiler.
<LaserJock> well, aptitude is ncurses
<LaserJock> I'd imagine that would help
<LaserJock> well, I believe it reads in .desktop files
<LaserJock> so I wonder if it reads those in when it loads
<Amaranth> g-a-i is IO bound
<Amaranth> it has to read a bunch of .desktop files
<minghua> aptitude is written in C++ just FYI
<_ion> One would think the data structure it forms by reading the .desktop files could be cached.
<jdub> http://biz.yahoo.com/bw/061115/20061115005870.html?.v=1 <-- BEST SENDMAIL NEWS EVER
<unfo> jdub: description?
<unfo> Amaranth: yeah... I see now it's opening numerous files from /usr/share/app-install/desktop and /usr/share/app-install/icons.
<unfo> it seems to be especially slow with opening the icons.
<unfo> i love strace -eopen.
<Amaranth> alacarte has the same problem
<Amaranth> but it's for loading icons since i get my .desktop stuff from gnome-menus
<unfo> couldn't gnome keep a big huge icon cache to hold all those icons?
<Amaranth> it does, sort of
<Amaranth> `strace -eopen alacarte` shows it loading a crap load of icons and a .mo file for every single thing in the menus :/
<Amaranth> oh, i apparently load every .desktop too, dang
<unfo> Amaranth: what cache is there?
<Amaranth> unfo: /usr/share/icons/Human/icon-theme.cache
<unfo> Amaranth: so why doesn't g-a-i seem to use it?
<Amaranth> it does
<Amaranth> it should, anyway
<Amaranth> as long as it's using gtk.IconTheme
<pygi> morning
<sivang> mornig all
<mdke> morning sivang 
<sivang> hey mdke 
<sivang> mdke: back from UDS?
<mdke> no, I didn't go to UDS
<mdke> sadly
<sivang> ah I see, same here /me hugs mdke 
* mdke hugs sivang back
<Q-FUNK> what would you guys do with bug #2620 ? it dates back from Breezy and the user cannot seem to be bothered with upgrading.
<Ubugtu> Malone bug 2620 in cups-pdf "cups-pdf broken after upgrade to Breezy" [Medium,Needs info]  http://launchpad.net/bugs/2620
<ivoks> Q-FUNK: cups-pdf works the way we don't like it
<Q-FUNK> ivoks: not since edgy.
<ivoks> Q-FUNK: right
<ivoks> Q-FUNK: so, you want backport?
<sivang> hi ivoks 
<ivoks> hi sivang 
<sivang> ivoks: had good time on the plane? :)
<ivoks> sivang: plane?
<Q-FUNK> I suppose that a backport to dapper could work.  anything older wouldn't really make sense.  even then, that doesn't resolve this old breezy bug.
<ivoks> Q-FUNK: this bug is caused by missing min12xxw binary
<sivang> ivoks: I think you had plans to play with hubackup while on your way back from UDS , sorry if I confused you with another guy
<ivoks> Q-FUNK: ubuntu-desktop package depends on min12xxw
<ivoks> sivang: hehe no, i wasn't at UDS
<sivang> oh dear, then whom did I talk about it to? :)
<Q-FUNK> ivoks: ah. hadn't spotted that bit in his log.
<ivoks> sivang: :)
<ivoks> Q-FUNK: reporter didn't answer for more than a year
<ivoks> eh...
<Adri2000> Mithrandir: here?
<seanh> Just following up on the recent announcement of a ubuntu-backup dev team, it said we could drop the devs a line in this room, I'm supporting a user who wants to backup stuff, is HUBackup fully working for basic backups to external HD or CD/DVD?
<seanh> (I have tried it, didn't seem to work for me)
<seanh> I seem to be able to make .dar files with hubackup, but hurestore doesn't launch, on edgy. Also when making the backuo, after verifying it, the only button to press is 'Cancel', there's no 'Finish' button. I'm sure that's already known though.
<seanh> Ah I see the hurestore crashes on startup bug is already in launchpad
<seanh> Looks like hub isn't quite usable yet, I wonder what the best, simple GUI backup utility for external HDs and CD/DVDs in Edgy is then?
<bddebian> Howdy
* sivang has to go through aweful u-devel backlog, so many threads which are really bug reports/support requests
<Seveas> sivang, thankfully #ubuntu-devel will be a moderated list $soon 
<Mez> tfheen, ping
<tfheen> Mez: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<Mez> tfhenn: ping regarding prevu reject
<Mithrandir> Mez: if you talk to this client instead you might have a chance of reaching me. :-P
<Mez> Mithrandir, lol /me forgets peoples different aliases Mithrandir 
<Mez> Mithrandir, where do these copyright/licence things need to go? 
<Mithrandir> in the source files and in debian/copyright.
<Mez> ok, they're in debian/copyright
<Mithrandir> not in the package you uploaded; it didn't have a debian/copyright at all
<Mez> Mithrandir, wtf? are you sure/ 
<Mez> Mithrandir, it's there at my end
<Mez> http://rafb.net/paste/results/cjqZDu64.html
<sivang> Mez: prevu? what's that?
<Mez> sivang, http://launchpad.net/products/prevu
<sivang> Seveas: indeed, but how can we make sure important people how are neither approved for universe/main will be able to participte in development discussions? through the -discuss list?
<sivang> Mez: ah, nice
* sivang has been reading over http://www.sun.com/2004-0907/feature/ . Impressive.
<Mez> Mithrandir, and http://rafb.net/paste/results/2RLoXp73.html
<Mez> Mithrandir, surely somethings b0rked somewhere ?
<jdong> sivang: roll your own crack I guess :D
<Mez> Mithrandir, or do you want GPL Notices added to the source aswell ?
<Mithrandir> Mez: none of the files from the upstream tarball has any kind of copyright information.
* Mez blames jdong for that
<jdong> hehe
<jdong> :)
<Mithrandir> apparently, there's a debian/copyright there; I'm unsure how I overlooked that.
<Mithrandir> though, it doesn't matter as long as the files are unlicenced.
* jdong shifts blame back on mez
<jdong> (the one who split out debian-dir)
<Mez> jdong: to be fair - I added the copyright stuff to the debian dir ;)
<jdong> :D
<Mez> you just didnt licence the files
<Mez> jdong, are you happy for it to be GPL'd ?
* jdong goes and grabs some GPL templates
<jdong> Mez: sure thing
<jdong> Mez: you do it then :D
<jdong> Mez: you wanna incorporate the new dev changes too?
<Mez> if they're there I will
<jdong> Mez: pushed them like 30 seconds ago
<Mez> Mithrandir, soyuz doesnt keep the old .orig.tar.gz does it ?
<jdong> is there any cheap way of making a deb out of a pretend root with the installed files
<jdong> sort of like what dpkg-buildpackage does near its final steps?
<Mez> jdong, man dh_builddeb
<Mez> s/dh_builddeb/dpkg-deb/
<jdong> ooh
<Mez> Mithrandir, pushed a copy that should hopefully satisfy you
<Mez> Is there any reason that noone's changed ubuntu's lintian yet to say that the ubuntu distros arent bad distro names
<Mez> or to not get the "nmu should be mentioned in changelog" when we have a 0ubuntu*
<Mez> Mithrandir, I uploaded the new prevu, but dont have ANYTTHING back from soyuz yet
<Mithrandir> Mez: it's in NEW
<Mez> Mithrandir, cool - it just ddnt send any emails telling me that
<Mithrandir>   129513 | S- | prevu                | 1:0.4.1bzr45-0ubuntu | 25 minutes
<Mithrandir>          | * prevu/1:0.4.1bzr45-0ubuntu1 Component: main Section: devel
<Mez> ooh, sexy scripts ;)
<infinity> Not really. :)
<Mez> infinity, it looks funkeh ;)
<Mez> though the override file needs to be changed
<infinity> Among other things, yes.
<sivang> infinity: do you have any idea when the prop. ati driver will work again in feisty? ;)
<mjg59> Hopefully never
<mjg59> It'd solve all sorts of problems
<sivang> mjg59: hehe
<sivang> but it does seem to be faster for me, on 2d as well.
<jdong> sivang: yeah it is
<jdong> sivang: and much much less video tearing too with xv
<jdong> mjg59: pretty please? :D
<mjg59> jdong: If it works it works, but I'm afraid I have absolutely no interest in non-free drivers except in so far as they break things that otherwise work :)
<jdong> mjg59: please have some heart for those with radeons that aren't supported with any other drivers :)
<jdong> mjg59: the newest fglrx release has resolved a lot of headaches for us unblessed folk
<mjg59> What? Vesa will drive all of them.
<slomo_> is there a reason why our glibc 2.5 has __GLIBC_MINOR__ == 4?
<mjg59> Less than optimally.
<jdong> mjg59: far less than optimally
<jdong> mjg59: vesa cuts my battery life in half and doesn't even deliver adequate 2D performance for desktop tasks
<mjg59> Sorry, I have no sympathy whatsoever for people who end up with hardware we can't drive
<mjg59> If someone's paid to care, then fair enough
<mjg59> I'm not :)
<sivang> mjg59: when I bought this laptop there were yet not nvidia enabled lenovos, we beg you :)
<jdong> mjg59: yes, but is it really too much to ask for a newer fglrx version in lrm?
<mjg59> As far as I know, pretty much the entire Lenovo range is available with Intel graphics
<sivang> well, Mark has an radeon as well, so we're gonna get it eventually , won't be better sooner then later? :p
<mjg59> From my point of view, it's quite easy. If you'll give me enough money to drink away the memories, I'll deal with fglrx. Otherwise, it gets left to someone who's on staff and doesn't have as much freedom in choosing which bits of the distribution to work on :)
<Seveas> mjg59, heh -- the joys of not being paid ;)
<jdong> :)
<mjg59> Oh, I'm paid, just not for anything related to Ubuntu...
<mjg59> Until three weeks time, anyway. Then I'm not paid.
<sivang> mjg59: what are you doing for a living?
* sivang is curious where mjg59 works
<mjg59> I'm a PhD student
<nixternal> amen!
<sivang> mjg59: in biology right?
<mjg59> Yup
<sivang> majoring in, that is
<sivang> mjg59: pretty damn cool
<mjg59> We don't have major/minor here
* AlinuxOS thanks mjg59 for "ka" font support ;)
<sivang> mjg59: my brother started a B.Sc in it a month ago
<azeem> mjg59: will you finish your PhD in three weeks, or will just not be paid anymore after that?
<mjg59> azeem: Just paid no more
<mjg59> Several months left yet, at least
<azeem> :-/
<nixternal> jeesh, im starting to feel stoopid around all of these super smart PhD people in biology, lasers, chemistry, physics, and groove
<sivang> guys, I'm not sure mjg59 will see it eye to eye that you're hoping for him to have to work for canonical on flgrx to get paid ;)
<AlinuxOS> mjg59, so coding is just a passion right ? :)
<azeem> an ex-gf of mine currently writes up her PhD in micro-biology, and she hasn't been paid since summer either
<azeem> and has to deal with the job centres as well
<mjg59> Well, I do a mixture of computational and experimental work
<sivang> mjg59: you anyway close to computational biology?
<mjg59> I do computational analysis and then experiments to validate predictions
<sivang> mjg59: what field of life forms?
<mjg59> Fruitflies
<azeem> <mjg59> Perl is lovely
<azeem> <mjg59> Perl lets me do almost no work and get a PhD for it
<mjg59> Yeah
<mjg59> Turns out I need to care about the flies as well
<mjg59> Flies aren't lovely
<azeem> :)
<sivang> mjg59: does it help you reduce amounts of experiment by simulations?
<azeem> did you get rid of that strange lab collegue?
<mjg59> sivang: Not really
<sivang> mjg59: ah
<mjg59> sivang: I look for patterns in DNA, and then test whether they mean anything
<mjg59> azeem: She ran out of funding and left
<azeem> yay
<sivang> mjg59: cool, seem slike perl was destined to become the de-facto for doing such stuff, isn't it?
<seanh> I think there should ba an ubuntu-research project, help people make PhD proposals etc. that involve developing for ubuntu. Get governments to fund ubuntu development by funding PhDs.
* sivang knows about at least a dozen of projects in each uni in .IL using perl in bio-informatics courses / research
<azeem> seanh: which parts of Ubuntu are truely rocket science?
<mjg59> Perl is good at parsing text. Bioinformatics is mostly text.
<sivang> none , but using evolutionary algorithms for kernel scheduling might be :)
<_ion> Gattaca
<seanh> We'll keep away from the rocket science department for now. But for example, developing a new bookmarks system for epiphany, including user testing and analysis in the development cycle, that sort of thing
<mjg59> seanh: PhDs have to involve research and developing new knowledge, not just application of existing work
<_ion> seanh: Is it going to be based on Meta Tracker, btw?
<jdong> random question
<seanh> mjg59 - yeah, you'd have to research and develop a new way of doing web bookmarks, through hacking on epiphany
<jdong> hypothetically speaking, if I want to update to a 2.6.18 kernel in edgy, how much trouble would it be to patch 2.6.18 onto Edgy's kernel?
<seanh> _ion - dunno. I wanted to do chronological bookmarks, blend bookmarks and history together, and use thumgnails like f-pot does
<seanh> I saw some academic research about displaying search engine results as thumbnails instead of just excerpts from the text, they did experiments to show that people could browse faster that way
<_ion> Now that you mentioned f-spot, there's this proposition for it, too: http://bugzilla.gnome.org/show_bug.cgi?id=350728
<azeem> seanh: this looks more like a SoC project or master thesis than a 3-year PhD to me
<Ubugtu> Gnome bug 350728 in General "Use Meta Tracker as the indexer + the metadata DB" [Enhancement,Unconfirmed]  
<ternkoe> hi
<ternkoe> ubuntu quite heavy on old machines?
<ternkoe> like say a PIII 450 256MB
<seanh> azeem - yeah maybe
<dsas> seanh: I think the firefox or ephiphany devs have the bookmarks + history planned somewhere already.
<seanh> azeem - still, I thinl the idea of encouraging people who are going to do research degrees to try and do it with ubuntu
<azeem> so you mean something which is really primarily useful to Ubuntu, but no other FLOSS projects?
<azeem> I guess that will be hard to find
<seanh> dsas - yeah there's a page about it on the epiphany wiki, don't think they've decided what to do yet, lack of developers. Anyway, even if they are developing a solution, doesn't stop someone else from developing something radically different, right? And if you can get a university to fund you to do it...
<seanh> azeem - no, i didn't mean it should be useful to ubuntu and not other projects
<azeem> then why do it in the context of Ubuntu?
<seanh> azeem - why not? But I guess your're right, it might be more of a project for the FSF or someone look that promoting free software
<robertj> can someone please close the ethical-info spec so we can get something less-nebulous, less-inflamatory, and more-productive in it's stead?
<LaserJock> robertj: you want to use that name?
<robertj> Not really
<robertj> Ethical is not the right title IMO
<robertj> LicensingAwareness perhaps?
<LaserJock> well, I suppose a person with the proper LP privileges could do it
<LaserJock> but I sorta don't see the point
<zul> besides dont you have gwhatisitname?
<robertj> LaserJock: its a 4 months old spec that is still New, was declined in paris, it should be closed
<LaserJock> well, I don't know that we really do that
<robertj> I'd love to see some real actually useful specs, like having some way to show appropriate symbols when installing 3rd party packages, but I think the whole spec carrys too much baggage
<pygi> siretart, yay ^_^ k3b now searches for cdrskin as alternative to wodim in Debian :)
<pygi> siretart, not too great, but that's good progress considering no one heard about cdrskin since about two months ago :P
<pygi> hey pitti 
<pitti> hi pygi 
<pygi> pitti: long time no see ^_^
<pygi> pitti: and so much nice things happened ^_^
<pitti> pygi: rock on!
<ajmitch> hey pitti, pygi 
<pygi> pitti: in theory, whatever you can do with cdrecord regarding cd burning, you can do the same using libburn
<pygi> pitti: -multi, -tao, all that implemented ^_^
<pitti> hi ajmitch!
<pygi> hello ajmitch 
<slomo_> pygi: good work :)
<zul> hey pitti 
<pitti> pygi: that's awesome!
<pygi> slomo_: thanks, but still a lot ahead of us ^_^
<pitti> pygi: do app developers want to use it already? or in the future?
<pitti> pygi: like n-cd-burner and such?
<pygi> pitti: Brasero already has a libburn backend, will enable by default for feisty (I will do so :P)
* pitti waves to zul
<zul> pitti: back home yet?
<pygi> pingar: n-c-b dudes aren't responding, but IHMO I'll prepare a patch and throw it at them :)
<pitti> zul: no, hanging out in San Francisco with the other Canonical guys and girls
<zul> ah
<pygi> pitti: Gnomebaker's next release will probably support libburn as well
<pitti> cool
<pygi> pitti: trying to contact Xfburn people to use libburn
<pygi> but It's still not ready for prime time, a lot more work coming ^_^
<pitti> such as DVD support?
<pygi> pitti: yes, but we aren't working only on libburn
<pygi> pitti: libisofs must be extended, cdrskin to work even closer as cdrecord does, and write genisofs (compatibility layer for mkisofs)
<pygi> pitti: cdrskin already assures so you can use libburn on any burning app which can change backends without changing code
<pygi> pitti: k3b searches for cdrskin as replacement to wodim in Debian package 
<pygi> for now, later on, one should just drop wodim
<pygi> slomo_: o right, you are here ^_^ You won't eat me too much if I enable libburn by  default, no? :P
<slomo_> pygi: no, that's perfect :) didn't i tell you before edgy release that it would be nice to have it enabled for feisty? :)
<pygi> slomo_: yes, you have ^_^
<pygi> slomo_: anyway, soon will be a release of new libburn with all those cool new features, and we'll work to release brasero 0.5.90 (or 0.5.91?) which will support it
<slomo_> pygi: now only the other part of the world has to be converted ;) do you think it would be possible to replace cdrecord everywhere with libburn/cdrskin for feisty?
<pygi> also Brasero 0.5.90/91 will be the first one where it'll actually be easy to disable any cdrkit/wodim/bla usage =)
<pygi> slomo_: please no, don't do that.
<pygi> slomo_: general call for a lot of testing, pushing it, etc...yes, ofcourse
<slomo_> pygi: don't worry, i won't :)
<pygi> slomo_: but I wanna wait for the release where we'll actually also be able to mimic all mkisofs features, and where we'll fix at least a bit of potential issues
<pygi> slomo_: feisty+1 will almost definetely go that way, if only I could get ahold of that damn set of rainbow books =)
<pygi> definitely*
<pygi> slomo_: we are working as hard as we can, count that only 3 devs exist
<pygi> and only me and Thomas can actually work on low-level stuff
<pygi> and we did such magnificient progress in so little time
<pygi> slomo_: my initial estimate was 2 years for -tao and -multi
<pygi> slomo_: go figure ^_^
<slomo_> :)
* pygi knows he's always bothering with libburn/etc but oh well ^_^
<pygi> slomo_: if you know whoever that is willing to read a lot of specs, is capable and willing to implement stuff in libisofs please redirect to me ^_^
<pygi> slomo_: kinda stuffed with all the happenings in libburn right now ^_^
<pygi> heh, constantly same bugs about cdrecord/dvd+rw tools coming to my mail :-/
<pitti> ajmitch: is xen-3.0 a supportable package, in general?
<ajmitch> pitti: yes
<pygi> slomo_: I was thinking on hacking GB to use cdrskin instead of cdrecord for feisty, but I gave up :P
<pygi> I wouldn't allow that to hit archive =)
<pitti> I never touched it, but I'm supposed to handle the MIR
<ajmitch> pitti: I've got to head out soon, but ask whatever questions you want :)
<zul> hmm someone mentioned xen-3.0?
<pitti> zul: I'm at looking on the MIR ATM
<zul> ah
<pitti> do we have a good contact to upstream?
<pitti> how active is it?
<pitti> any insanities in the package/code?
<zul> upstream is pretty active
<zul> no real insanities but we dont really have a good contact upstream
<pitti> zul: what's the perspective of integrating the dom0 kernel into our main kernel source?
<zul> pitti: pretty good for 2.6.20
<pitti> I figure that the package will be pretty useless without a kernel
<pitti> we just need it in main as a build-dep
<zul> it would but some of fabbione's clustering stuff depends on libvirt
<pitti> right
<pitti> I'm in favor of supporting it if we will eventually get the kernels into main, too
<zul> we will, im pretty confident that our kernel will work with the xen crack by 2.6.20
<ajmitch> zul: with paravirt ops?
<zul> yep
<ajmitch> will that allow working alongside vmware yet, or is that for feisty+1?
<zul> vmware and xen should both be using paravirt
<Mithrandir> ajmitch: paravirt should allow coexistence
<ajmitch> pitti: I regularly read the xen mailing lists, so I can easily find people to contact
<ajmitch> Mithrandir: that's great, my poor amd64 is too old for hardware virt :)
<Mithrandir> ajmitch: mine too.. and it's an x2 4400+
<ajmitch> 4200+ for me
<ajmitch> got it a few months too early
<Mithrandir> I might replacy my 3000+, though.
<Mithrandir> replace, even
<Mithrandir> especially if I manage to pillage a mainboard and cpu from somewhere.
* ajmitch had to setup AD from scratch again last night, eval copy of windows expired
<ajmitch> so at least I've got a fresh start to do some hacking on 
<fabbione> madduck: you around?
* pitti wonders why xon-docs-3.0 is completely empty
<pitti> s/xon/xen/
* ajmitch points fingers randomly
<pitti> oh, the amd64 package is empty, the i386 one has stuff
<ajmitch> interesting
<pitti> this should be arch:all
<fabbione> that's the way to go!
<Mithrandir> pitti: amd64 dudes don't need no docs!
<pitti> RTFC!!!11!
<Mithrandir> UTSL, rather
<zul> meh..
* ajmitch looks for mdadm bugs already filed
<infinity> ajmitch: Check -changes
<fabbione> ajmitch: i already fixed it
<ajmitch> infinity: yeah, saw it
* pitti is pretty overwhelmed by this huge thing, and relies on ajmitch's and zul's verdict
<ajmitch> I'm having other issues
<fabbione> ajmitch: and if i get a bug for that, i am going to castrate you
<ajmitch> like timeouts at boot
<infinity> fabbione: Though, the first init script in postinst failed for me too.
<infinity> fabbione: I had to stop it before it could start.
<fabbione> infinity: yeah that's what i fixed it
<ajmitch> having to start lvm from busybox, etc
<fabbione> s/it/
<infinity> fabbione: No, you fixed the second init script.
<infinity> The REALLY broken one. :)
<fabbione> infinity: uh i only saw one error dist-upgrading
<Mez> anyone here have any experience with postfix?
<lamont> Mez: a little
<pitti> a bit
<fabbione> ajmitch: timeouts at boot?
<_ion> Some.
* pitti defers to lamont
<fabbione> ajmitch: be more specific
<infinity> lamont: Just a tad?
<lamont> infinity: yeah
<lamont> Mez: sup?
<Mez> anyone wanna tell me how to get saslauthd working?
<infinity> Mez: bindmounts
<lamont> that's not a postfix question... that's a sasl question
<ajmitch> fabbione: it took ~3 minutes before the raid 5 started, after that it went to waiting for root filesystem
<pitti> however, ISTR having trouble with this, too
<Mez> infinity, I know that, but my bind mount I had isnt working
<lamont> there's a reason that postfix doesn't autoconfigure sasl :-(
<fabbione> ajmitch: make sure your mdadm.conf is valid and that you update your initramgs
<fabbione> initramfs
<lamont> Mez: what version of libsasl2?
<infinity> lamont: I could help you make that go.  I've walked enough people through it on -server in the last 6 months that I have it down to a science.
<ajmitch> both are valid & up to date
<fabbione> ajmitch: and that's known to work and be done automatically in edgy. I still can't fully test feisty
<_ion> mez: I have in main.cf: broken_sasl_auth_clients = yes, smtpd_sasl_auth_enable = yes, smtpd_sasl_authenticated_header = yes, and in /etc/postfix/sasl/smtpd.conf: pwcheck_method:saslauthd, mech_list:plain login
<Mez> 2.1.19.dfsg1-0.1ubuntu2
<infinity> lamont: Ironic, given that I don't use either postifx or sasl.
<ajmitch> fabbione: I'll refresh the initramfs again & try tonight
<Mez> _ion, I have similar to that :P
<fabbione> ajmitch: in any case if you are on feisty, that behaviour will change once Keybuk will move mdadm admin stuff into udev
<lamont> somewhere around 2.1.19, things changed and you need to copy the config from /etc/postfix/sasl into /usr/lib/sasl (or whatever the library package's path is...)
<Mez> infinity, wanna walk me through ?
<lamont> Mez: yeah.
<lamont> Mez: was it working before?
<ajmitch> fabbione: yes, this was a feisty upgrade, so I was expecting at least some trouble somewhere
<ajmitch> back later
<lamont> ln /etc/postfix/sasl/* /usr/lib/sasl2 would be the fix if it _was_ working
<Mez> lamont, I had to set up a bind mount... but I rebooted and the bind mount's gone (though there is a bind mount in /etc/fstab)
<Treenaks> lamont: scary
<lamont> infinity: I'd love to walk through it with you late next week
<lamont> Treenaks: they split the modules and config into separate callbacks
<Treenaks> lamont: config in /usr is still scary :)
<lamont> oh, it's wrong
<lamont> that's why the directory is there..
<lamont> fixed in 2.3.4-2, fwiw
<lamont> which I'll upload shortly. :-)
<infinity> lamont: Cool, make a play date with my PA.
* pitti larts ajmitch
<lamont> infinity: which clare is that? :-)
<Mez> hmm
<pitti> ajmitch: http://tinyurl.com/y6u9py -> 54 critical/blocker/major bugs in upstream
* lamont is figuring on "over thanksgiving"
<Mez> It's working now that I've started it manually
<pitti> ajmitch: but the MIR page says 'no critical bugs'
<fabbione> -              log_problem "no $*"
<fabbione> +              log_dev 0 $1 "no $*"
<Mez> I spoke too soon
<infinity> lamont: Claire McMartin. :)
<fabbione> infinity: ^^
<zul> pitti: the xen-3.0.2 in the url doesnt apply
<fabbione> does anybody know where libvirt is? it was supposed to be promoted to main yesterday
<fabbione> but it's still in universe?
<Mithrandir>    libvirt | 0.1.8-0ubuntu1 | feisty/universe | source
<Mithrandir> fabbione: it's in the approved-but-not-yet-promoted queue
<infinity> I nominate Mithrandir to promote it, since he's our newest lackey.
<Mithrandir> I can be bribed with beer.
<infinity> Or threat of physical violence?
<pitti> fabbione: ok, I mentioned in the xen-3.0 MIR that libs are fine for main
<Mithrandir> that's intimidation, not bribery.
<infinity> Meh.  Six of one, half-dozen of the other.
<ajmitch> pitti: er, thanks :)
<fabbione> Mithrandir: ok thanks
<fabbione> pitti: perfect. i don't need more than that
<fabbione> pitti: the rest can really stay in universe
<pitti> ajmitch: I think I have to gradually get used to this; and as long as the kernel is in universe, it doesn't matter much anyway
<Mez> why do bind mounts just fecking dissapear ?
<infinity> Are you bindmounting it before /var/run gets mounted on top?
<AlinuxOS> People hello, is there some photos of your recent meeting somewhere ?
<infinity> AlinuxOS: We're still working on filtering out allthe nude ones.
<AlinuxOS> infinity, :DDD
<AlinuxOS> haha
<Mez> infinity, unless it's doing the fstab backwards, then no
<zul> there is some people i dont want to see naked so good
<Mez> wait
<Mez> oh... infinity how the heck do i get it to mount AFTER /var/run is created?
<Mez> poopsicles
<Treenaks> Mez: in the init script? 8)
<AlinuxOS> infinity, I suppose you are talking about girls that have partecipated in the meeting :D
<jdong> infinity: ping
<pygi> hello jdong 
<jdong> ello pygi
<pygi> jdong: what's dapper status? saw you posted on bug report again :)
<jdong> pygi: I don't remember if I sent it thru my builder or not (maybe I did it 5 times already and forgot)
<jdong> tell ya what, I'll run it right now again :D
<pygi> jdong: good, thanks ^_^
<Mez> how would I just un-chroot saslauthd
<pygi> jdong: but we need to know does buildd builds against -updates ^_^
<jdong> pygi: hence quick ping to infinity :)
<jdong> pygi:  -> Considering  libgtk2.0-dev (>= 2.10.0)
<jdong> pygi: that needs to go down to 2.8.something
<pygi> jdong: right, that even, and gnome-vfs =)
<pygi> jdong: it can't go that :-/
<jdong> pygi: aww poo :(
<pygi> jdong: 2.10 is right dep
* sivang just adores germen beers, holding a bottle of Beck's in one hand
<jdong> pygi: it won't work with 2.8  anymore?
<pygi> jdong: you could try, it should work
<pygi> jdong: but don't make me fix bugs then
<jdong> pygi: heh it's backports :)
<pygi> jdong: yes, but people complain about that ^_^
<jdong> pygi: yeah people do complain :)
<pygi> jdong: just leave gnome-vfs as 2.14.2 which is in dapper-updates. 2.14.1 causes some major problems
<jdong> pygi: I won't touch that :)
<pygi> jdong: thank ^_^
<jdong> pygi: and configure has a safegard against that too :D
<pygi> jdong: I've learned not to trust autotools =)
<Mithrandir> fabbione: you don't want the -bin or python libvirts, right?
<fabbione> Mithrandir: i only need libvirt and -dev
<fabbione> Mithrandir: at least AFAIK
<fabbione> nd they are B-D for rcs
<fabbione> rcs = redhat-cluster-suite
<fabbione> if we need more for runtime i will ask for promotion later
<infinity> fabbione: libvirt depends on libxen
<fabbione> infinity: yes and pitti is doing libxen MIR
<infinity> Yeah.  Ish. :)
<Mithrandir> infinity: pitti's happy with libxen, but not the hypahvisor
<jdong> pygi: how far down can I take libnautilus-burn-dev?
<jdong> (if at all :D)
<jdong> >=2.16.0; dapper = 2.14.{1,3}
<pygi> jdong: uh, what's the current version and where you wanna take it? 
<bhale> jdong: you are asking for trouble if you do
<pygi> jdong: uh, uh :-/
<infinity> Mithrandir: So we're going to maintain this fiction of a supported source package whose binaries we don't support? I love that. :)
<jdong> pygi: well, it looks like we've hit a dead end then :)
<Mithrandir> infinity: la, la, la, la. :-)
<bhale> jdong: api changed not so long ago, deprecated stuff was removed i think, banshee old versions dont work with it
<pygi> jdong: I mean, you can try to go to 2.14.x
<pygi> jdong: I'm just really really really not sure it'll work
<pygi> jdong: because 2.16 broke backward compatibility which sucks!
<bhale> pygi: yes exactly
<jdong> pygi: so you're saying to telling pbuilder to --force-version and see if it works . ok kthxbye la la la la la
<jdong> :D
<pygi> jdong: it won't build, no way. I remembered it broke compatibility ^_^
<jdong> pygi: ok :)
<jdong> pygi: that's what I was expecting anyway :)
<pygi> jdong: so no new brasero for dapper folks :-/
<jdong> pygi: sadly the old backports version of brasero is probably still the best burning app in GNOME :D
<pygi> jdong: I know
<jdong> btw, when will gnome's bluetooth stack actually exist?
<pygi> jdong: I have some problems with that ... sadly Luke (Gnomebaker) has less and less time for it ... especially since he got a daughter
<jdong> pygi: configure is not amused by me tweaking the build deps :D
<jdong> so there goes that
<pygi> jdong: configure can be talked to "pass over the truth" :)
<pygi> jdong: but it still won't work IHMO ^_^
<jdong> pygi: I've learned that ./configure doesn't joke when it comes to build deps
<jdong> :D
<jdong> and where's mr. mythtv... he's supposed to be bugging me by now :D
<pygi> jdong: I've learned that configure can be tricked ^_^
<jdong> pygi: I've learned that far worse things arise from tricking ./configure than pbuilder-satisfydeps
<Ng> jdong: chutt?
<pygi> jdong: true ^_^
<jdong> oh yeah I think he's in #ubuntu-motu
* jdong remembers not to walk in there until he is bored :)
<Mithrandir> fabbione: libvirt promoted
<pygi> jdong: I'm currently being amused by cdwrite list ^_^
<fabbione> Mithrandir: thanks dude
<pygi> jdong: a lot of problems reported which we have in ubuntu, and all other distros have ^_^
<jdong> :)
<jdong> anyone have any experience syncing windows mobile 5 devices? :D
<pygi> jdong: no =)
<jdong> I think I need a svn build of synce to stand any chance :D
<Mithrandir> xen promoted too.
<Mez> W00T I GOT IT WORKING
<Mez> darn caps
<pygi> where did slomo go? :P
<Mez> Mithrandir, anything else on the new package ?
<pygi> I wanted to bug him, ergh :P
<fabbione> Mithrandir: danke...
<Ng> jdong: I tried it a couple of years ago and it was far too much pain at that stage to be worth doing regularly
<Mez> pygi: Last Seen Quit Msg: Read error: 110 (Connection timed out
<Mithrandir> Mez: haven't looked at it yet.
<Mez> lol
<Mez> cp /usr/share/common-licences/GPL-2 COPYING ;)
<jdong> Ng: kidding, it's far too much hassle
* jdong got a WM5-based smartphone
<jdong> couldn't resist it :D
<pygi> slomo_ is back ^_^
<pygi> slomo_: permission to bug? :)
<slomo_> pygi: sure
<pygi> slomo_: a lot of distros, cdwrite mailing list, etc...getting a lot of bug reports constantly which our users also experience
<pygi> it's really getting out of hand ... I've just wished that Joerg is a bit more polite
<pygi> he has some valid concerns about linux kernel, but he's too histerical
<pygi> if only he could explain points, then all could be solved, cdrecord and kernel related
<pygi> (ok, the messy code cannot be fixed, since I doubt even he can read it)
<zul> eject /dev/cdrom
<zul> damn
<jdong> zul: eject: unable to eject, last error: Inappropriate ioctl for device
<jdong> :)
<pygi> jdong: that's when you don't use libburn to eject device ^_^
<jdong> pygi: pfft :)
<Treenaks> Who's peer and why is he resetting all those connections? :P
<sivang> Treenaks: my thought exactly :)
<Treenaks> wb.. ?
<jdong> oops, that's what that button in ettercap does :D
<Treenaks> jdong: tcpkill.. oops!
<jdong> :)
<jdong> Treenaks: you have no idea how many times I've said that in a serious context :D
<jdong> Treenaks: eventually I learned not to play with ettercap at all :)
<Treenaks> jdong: remind me not to hire you as a network admin ;)
<Mez> nooone here has an ISPTAG do they ?
<Mithrandir> Mez: I'm not sure giving out http://bazaar.launchpad.net/~ubuntu-backporters/prevu/dev as "downloaded from" is very useful, but that's actually more of a LP problem than anything.
<Mithrandir> Mez: I'll discuss that with the other archive team members and we'll work something out
<jdong> Mez: heh, bzr export time I guess... :)
<Treenaks> Mez: ISPTAG?
<jdong> Mithrandir: it's too bad launchpad doesn't have a file release mechanism :-/
<Mez> Treenaks, http://www.nominet.org.uk/tag/
<Mithrandir> jdong: yeah; it might have one day though.
<Mithrandir> oh well, lunch here now
<Treenaks> Mez: No, I don't :)
* Mez dreads to think the amount of space used on librarian
<jdong> Mez: shall I just bzr export and publish to SF.net?
<Eons> what are the plans for gnome 2.18? 
<Mez> Lets see if it's ACCEPTED first ?
<Eons> there is a list of new features, something like this?
<jdong> Mez: mmmkay
<jdong> on the launchpad note, it's probably a better plan to use like bzr-webdir
<jdong> which can export the tarball of an inventory
* Mez cries all over the keyboard
* jdong chuckles when he recalls the planet.u.c posts about 3rd party repos
<Burgwork> Eons: upstream is preparing such. see live.gnome.org/TwoPointSeventeen
<Adri2000> Mithrandir: !
<_ion> jdong: :-)
<Adri2000> Mithrandir: not here? :(
<jdong> Adri2000: he said lunch :)
<jdong> Adri2000: and apparently he's joined the 'I hate contentless pings' club
<Adri2000> ok :p
<slomo_> Mithrandir: ping? if you have some seconds, can you please promote libxml-{dom,regexp}-perl to main? thanks :)
<pygi> slomo_: any reactions? :P
<slomo_> pygi: on? :) you only wrote that it's impossible to talk with joerg... sorry if i missed something :/
<pygi> slomo_: and I wrote about so much bugs ^_^
<Eons> Burgwork: thank you! that was exactly what i needed
<Mithrandir> Adri2000: I never respond to contentless pings.
<Adri2000> :)
<Adri2000> Mithrandir: I'm merging pppoeconf, first do you agree or do you prefer to do it?
<Mithrandir> Adri2000: please do
<Adri2000> ok, so my question is about an ubuntu change you made, you removed the dependency on modconf
<Burgwork> Eons: I live to please
<Adri2000> Mithrandir: "to get this installable again" why exactly it didn't work?
<Mithrandir> Adri2000: modconf's not in main
<Adri2000> ahhh
<Adri2000> ok Mithrandir, thank you.
<Mithrandir> np
<Gargoyle> Greetings. Can anyone cast an eye over my saslauthd config files to check I didn't make a mistake before I write a bug report to the ubuntu-users list?
<pygi> Gargoyle: why would you write bug reports to mailing lists?!
<pygi> Gargoyle: you really think someone can track that? :)
<Gargoyle> because thats what it says in the package info!
<pygi> Gargoyle: it surely doesn't :P
<Gargoyle> Bugs: mailto:ubuntu-users@lists.ubuntu.com
<pygi> or it's a bug of some kind =)
<pygi> lol ^_^
<Gargoyle> it does!
<pygi> Gargoyle: just file bug against malone/that source package
<Gargoyle> he he
<Gargoyle> eh?
<LaserJock> Gargoyle: I think that is used for automatic bug reporting tools perhaps
<LaserJock> Gargoyle: the place to report  bugs is on our bug tracking system
<LaserJock> Gargoyle: try  http://bugs.ubuntu.com
<geser> doesn't reportbug react to the Bugs: header?
<LaserJock> yeah, I think so
<Gargoyle> My first bug report!
<Gargoyle> I hope it's helpful and not just a fubar on my side!
<Mithrandir> Riddell: you probably want to seed or make something depend on opensc in order for it to be promoted.
<Kano> hi, on a debian system you usually have got: /etc/X11/default-display-manager, where is the file on ubuntu edgy
<infinity> Kano: update-alternatives --display x-window-manager
<LaserJock> Kano: I have it in the same place
<infinity> Kano: Which is true of Debian as well.
<infinity> Oh, wait, display-manager.
<infinity> Brain fart.
<infinity> Yeah, I have an /etc/X11/default-display-manager on Ubuntu too.
<Kano> not on a pure edgy install
<Kano> whats the ubuntu way to parse the used display-manager?
<Ng> I have that file and this was a fresh edgy install
<Kano> i just installed it. alternative amd64 iso
<Kano> i have kbuntu and ubuntu amd64 installed with alternative iso, missing on both
<infinity> gdm's postinstis meant to create it.
<infinity> (And I assume kdm does the same)
<Kano> so someone should be able to tell me how to parse it
<HrdwrBoB> update-alternatives --display x-window-manager
<Kano> all i can say it is not there...
<infinity> HrdwrBoB: Wrong thing.
<infinity> HrdwrBoB: I had the same brain fart, mind you.
<Kano> thats no window manager
<HrdwrBoB> oh.. heh
* HrdwrBoB reads up
<infinity> Kano: dpkg-reconfigure gdm, and see if it shows up.
<Mithrandir> slomo_: done
<Kano> infinity: it shows up for gdm, but not for kdm
<Kano> when you use reconfigure with gdm you see a grep error that this file is missing and a new file is written
<Kano> no error with kdm
<Kano> you broke it i would say...
<infinity> "you"
<infinity> File bugs, then.
<infinity> Please.
<Kano> infinity: nope
<fabbione> infinity, BenC_: do we have LRM for .19-6 ?
<Kano> i just wanted to adopt my nvidia+fglrx script for ubuntu, will not use it for long time
<infinity> fabbione: No LRM until PPC's kernel builds.
<Kano> will just check for kdm,gdm or xdm in that order but i dislike that a bit
<fabbione> infinity: ok
<Mithrandir> slomo_: liferea is ready for promotion, but not seeded.  Please seed.
<Burgwork> Mithrandir: are we seeding liferea to the default desktop?
<Mithrandir> Burgwork: I'd be fine with it, but it's not my decision, I'm merely doing promotions to main
<Burgwork> Mithrandir: no, just wondering, so I can report it
<Mithrandir> ah
<Mithrandir> argh, I'm a muppet.
<Mithrandir> zul: I need a MIR for libvncserver for xen.
<infinity> Wow, a day into archive admin, and you're already publically admitting to muppetry.
<Mithrandir> infinity: I'm a quick learner.  Learnt from the best, you know.
<Mithrandir> best muppets, that is.
<Mithrandir> ooh, inkscape now wants loudmouth.  That looks promising
#ubuntu-devel 2006-11-17
<infinity> Mithrandir: The jabber thing?  Why does my vector graphics editor want a jabber interface?
<Kano> dpkg-divert --list|grep kside.png|cut -f7 -d' '
<Kano> ok, sowas auch noch...
<Burgwork> infinity: it uses jabber to do collaboration
<_ion> It would be cooler if it used telepathy instead of loudmouth directly.
<Burgwork> telepathy didn't exist when the inkscape people started inkboard
<Mithrandir> infinity: sharing is good
<Mithrandir> keescook: you just won the contest on who gets to write a MIR for loudmouth.  Or make inkscape not depend on loudmouth.
<Robot101> they should go back and fix it :D
<keescook> Mithrandir: yahoo
<Robot101> telepathy-gabble needs a MIR for loudmouth anyway
<Burgwork> Robot101: what about non-Linux builds?
<keescook> Mithrandir: actually, I think they were thinking of not using loudmouth any more.  (some other lib instead?  I'll need to go check with them.)
<Mithrandir> Robot101: telepathy-gabble | 0.4.5-0ubuntu1 | feisty/universe | source, amd64, i386, ia64, powerpc, sparc
<Robot101> Mithrandir: feisty's meant to get some telepathy loving in main
<Mithrandir> Robot101: yeah, but it doesn't need the MIR atm.
<keescook> wait, I can't write the MIR if I do the audit too, can I?  :)
<infinity> keescook: Sure you can, an MIR is a statement of fact, not opinion.
<infinity> (In theory)
<keescook> infinity: ah, okay.  fair enough.  :)
<Mithrandir> keescook: nice try, though
<Kano> why had ubuntu a /etc/debian_version file?
<Kano> has
<infinity> Kano: So 3rd party apps/scripts that look for it don't freak out.
<infinity> Kano: (Many look for it to see if the system is "debianish", then take decisions based on that)
<Kano> i is 100 sure that that file is on every ubuntu or just edgy
<Mithrandir> Kano: it's on all ubuntu version released.
<infinity> (And always reads "testing/unstable")
<Mithrandir> lamont: should we disable cdb support in postfix or get tinycdb into main?
<Kano> infinity: ok, i checked for lsb-relase for ubuntu usually
<infinity> Kano: Yes, as do I.
<Kano> i miss awk on ubuntu and bash ;)
<infinity> Err, they're both there.
<Kano> sure but not preinstalled
<infinity> bash is Essential:yes, and mawk is Priority:required.
<Mithrandir> err, they are
<infinity> So, yes, preinstalled.
<Kano> so i had to fix serveral things
<infinity> You'd have a deeply upset system without them, I suspect.
<Kano> like the ati-installer uses echo -e, == and pushd/popd
<Kano> you have to patch that out first to use it
<Mithrandir> it probably assumes that /bin/sh is bash
<Kano> thats it
<infinity> Kano: The ATI installer needs to be fixed to be !/bin/bash
<infinity> Kano: Tell upstream.
<Kano> i did
<infinity> (Or run it as "bash ati...run")
<Kano> and i wrote my own installer
<Kano> infinity: not that esay
<infinity> Sure it is.
<Kano> nope
<sivang> giskard: ping
<sivang> giskard: actually unpind, will talk to you tomorrow
<sivang> night all
<pygi> night sivang 
<Kano> [ "$(readlink /bin/sh)" = "dash" ]  && sed -i 's/==/=/;s/pushd/cd/;s/popd//;s/echo\s\+-e/printf "%b\n"/' packages/Ubuntu/ati-packager.sh
<Kano> that was needed
<Kano> otherwise no packages are created
<Kano> when you use --buildpkg Ubuntu/edgy
<Kano> i just finished changes for nvidia+fglrx
<Kano> http://kanotix.com/files/install-fglrx-debian.sh
<Kano> http://kanotix.com/files/install-nvidia-debian.sh
<Kano> if someone finds problems let me know
<Kano> i am usually on that server just not that channel
<Kano> bye
<madduck> fabbione: lovely commit message. maybe you could mention or point to the Debian bug it refers to? Or is this a problem I don't know yet?
<_ion> How about this for a problem? The nvidia script seems to throw files around the filesystem without dpkg knowing about it.
<fabbione> madduck: oh i just wanted to show you the diff
<fabbione> madduck: one sec that i need to re-deb-diff it
<fabbione> it's one line change
<fabbione> madduck: and i didn't check debian bts
<fabbione> so i don't know if there is a bug open for it
<fabbione> people here almost larted me for breaking their upgrades
<madduck> can i see the diff?
<fabbione> madduck: yes.. one sec please
<fabbione> <fabbione> madduck: one sec that i need to re-deb-diff it'
<madduck> sorry. :)
<fabbione> madduck: see /msg
<fabbione> basically i see no point to fail if we have no configured raids
<fabbione> it might be normal
<fabbione> madduck: i also found other upgrading issues from 2.4.* to 2.5
<fabbione> madduck: but i can't really debug it so far from the machine
<Mithrandir> seb128: libnet-dbus-perl which system-tools-backends now needs a whole stack of new modules (libxml-twig-perl, libxml-xpath-perl, libunicode-map8-perl, libxml-handler-yawriter-perl, libxml-sax-machines-perl); any idea what we should do about that?
<seb128> Mithrandir: get them to main?
<Mithrandir> seb128: sure, just get me approved MIR. :-)
<seb128> Mithrandir: I know the right guy to get those :p
<Mithrandir> ah, he's around now.  He wasn't earlier.
<Mithrandir> enjoy. :-)
<orkid> to upgrade to feisty, just change the repos (and use update-manager?)
<seb128> yep
<seb128> not sure if that's a good idea to update yet though
<orkid> i realize it's near the beginning of development.
<madduck> fabbione: please just tell me what the problems are. i know where to look quite well by now, having involuntarily maintained it for 4 months.
<orkid> tx
<fabbione> madduck: dude.. i can't reboot or downgrade that machine from where i am... i was confident that it was going to be ok and upgraded. so when i am back next week i will be able to tell you more
<Kano> another thing: why is module-assistant not in main?
<Kano> it is very usefull
<pygi> Kano: you cant go around saying why random FOO isn't in Main? :P
<Kano> thats a major tool
<Mithrandir> Kano: no, it's not.
<Mithrandir> we ship precompiled kernel modules instead.
<Kano> you need m-a prepare to be able to compile modules
<Mithrandir> no, you don't
<madduck> fabbione: sorry, i am not trying to be pushy. i am just surprised. caught off guard.
<Kano> at least thats the most easy way
<fabbione> madduck: don't worry.. i need to look at it because it's scary message and i was surprised too. I just can't do anything here. I don't have test equipment to play with
<Mithrandir> Kano: that's irrelevant as long as the user never needs to compile modules by hand.
<keescook> hmpf.  Inkscape 0.45 won't be using libloudmouth.  :P
<Kano> sure and you only provide one version of fglrx and nvidia drivers (ok+ legacy) in your rep.
<infinity> Kano: And we should provide more than that, why?
<Kano> infinity: because nvidia needs 2 legacy drivers soon for example and you need one legacy (8.28.8) and latest to support all ati chips
<infinity> Kano: Catering to the ricer crowd who looks for the sweet spot to get an extra 3fps out of a specific video game isn't really our deal. :)
<infinity> Kano: The fglrx legacy issue is a non-issue, IMO, as the cards they dropped have free 3D support.
<infinity> Kano: As for the nvidia "need 2 legacy drivers soon" thing, do you have a reference for me to look at?
<infinity> (I admit, I've not been reading such news in the last couple of weeks)
<infinity> Kano: I'll only maintain an fglrx legacy package if upstream does.  They've not committed to doing so (like nvidia did), they just dropped support.
<Kano> infinity: 96xx series will be the legacy driver for gefore 2mx till gf4200, so basically every dx7/8 card which is not already a legacy one
<infinity> Kano: Distributing a binary blob to users with no promise of updates/support is not high on my list of "bright things to do".
<Kano> infinity: well i do that always with a script
<Kano> for kanotix
<Kano> which supports ubuntu now too
<infinity> Err, and your script magically fixes security holes in old fglrx releases? :)
<Mithrandir> Kano: good for you, then.  We won't.
<infinity> I'm not talking baout my maintenance overhead, I'm talking about us not shipping obsolete and unsupprted code.
<TheK> Kano, does this driver really WORK usefull with such old chips? there are several comments about problems with GF3
<Kano> TheK: 9626 works
<Kano> which is needed for composite
<Kano> install-nvidia-debian.sh -c
<Kano> -c is for composite
<TheK> and they cut now above 4200? strange position.. I guess, MX4000 still supported? ;)
<Kano> 9742 has no support for those cards
<Kano> butthat driver is needed for geforce 8800 series
<TheK> http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9742/README/appendix-a.html that file still lists all? lol?
<Kano> TheK: the readme is incorrect
<TheK> :(
<Kano> this driver needs 5200 and above
<Mithrandir> Riddell: you or some other kubuntu person probably wants to write a MIR for gsmlib
<infinity> 9742 is still listed as a beta driver.  NVIDIA quite frequently limits the PCI ID list on beta drivers.
<Kano> TheK: you can try it
<Kano> mount --bind /bin/bash
<infinity> I'm quite convinced they don't intend to maintain 3 branches of the driver.  2 is bad enough.
<Kano> ./install-nvidia-debian.sh -cv 9742
<Kano> umount /bin/bash
<Riddell> Mithrandir: aye
<TheK> Kano, to lazy to boot my system with gf2mx ;)
<Kano> mount --bind /bin/bash /bin/sh
<Kano> of course
<Kano> TheK: you will get no screen..
<infinity> Kano: Why on earth are you using mount to do that?
<infinity> Kano: That's vile.
<Kano> when you use -c then you get composite suport
<Kano> infinity: no need for a symlink
<infinity> Kano: "bash <script-that-needs-it>"
<TheK> infinity, on Windows the 97xx-Series is for 8800 ONLY
* ogra shades his eyes 
<TheK> afaik it doesn't even support GF7 there...
<Kano> infinity: i dont like to do that, it is not my script that needs bash, it is the nvidia-isntaller in it. i dont like to change that for this beta
<infinity> TheK: For now, yes.  That happens on most new product releases.
<Mithrandir> Kano: I fail to see how this conversation is relevant to Ubuntu development, so maybe you should take it elsewhere.
<infinity> Kano: So call the installer with bash from inside your script.
<Kano> well you should know how many nvidia packages you need ;)
<Kano> infinity: does not work, it is inside a script inside, would have to patch that
<TheK> one day we have nvidia-glx-gf1, -gf2, -gf3, -gf4.. and so on? ;)
<infinity> TheK: No, we'll drop support for older cards when upstream does.
<infinity> Upstream's not going to maintain/support 3 branches, and neither will we.
<_ion> kano: Your nvidia script seems to install stuff around the filesystem without dpkg knowing about it.
<ajmitch> by that point we'll probably have free nvidia drivers for those older cards anyway
<infinity> We can't provide support for binary-only drivers without upstream's commitment to them.
<Kano> _ion: thats correct, but nvidia-installer --uninstall works very well
<TheK> ajmitch, are they making progress now?
<_ion> Evil.
<ajmitch> however, still not too relevant
<Kano> the fglrx script uses packages
<ajmitch> TheK: yes they are, I might package up the nouveau ddx & drm bits for people to play with
<fabbione> ajmitch: i was able to see some errors on mdadm. i will look at them next week
<fabbione> ajmitch:  i can't do testing from where i am now
<ajmitch> fabbione: alright
<ajmitch> I can't test until tonight either
<Mithrandir> pitti: could we have a MIR for gnome-mount?
<Kano> bye
<Mithrandir> seb128: could you either seed or make something depend on industrial-cursor-theme if you actually want it in main?
<Keybuk> pitti: and could we remove the Recommends: cryptsetup :p
<pitti> Keybuk: uploaded
<lamont> Mithrandir: re cdb - I don't really care - the cdb folks would feel it belongs in main, of course.
<lamont> the nice part is that it's actually upstream that added cdb support, so sucking it into main would be good
<Mithrandir> lamont: any chance of me convincing you to write a MIR?
<lamont> sigh.  OK.  might be next weekend though
<lamont> unless you need it sooner
<infinity> Take your time.
<infinity> It's not like anyone uses postfix anyway.
<lamont> infinity: heh
<lamont> but postfix is better than prefix, because it came later...
<Kano> just a tiny addon, the bash hack is not required anymore, added a little replacement (there was == in a subscript)
<_ion> Should we care?
<pygi> _ion: release soon, this release will need so much testing :)
<_ion> Cool.
<pygi> hey bddebian 
<pygi> _ion: probably somewhere next week, 4 more tasks on TODO
<bddebian> hI pygi
<pygi> _ion: debian k3b package now searches for cdrskin as replacement for wodim
<Mithrandir> pitti: g-m promoted
* pitti hugs Mithrandir 
<_ion> pygi: Nice.
<pygi> _ion: for now ... yes ^_^
<pygi> _ion: later --> drop wodim :)
<_ion> pygi: And finally make k3b use libburn directly? :-)
<pygi> _ion: that's third step. Second is to make k3b use cdrskin by default ^_^
<pygi> _ion: for that third step, I need to talk with Sebastian
<pygi> _ion: anyway, time to sleep
<pygi> _ion: important exam which I'll fail today 
<_ion> What exam?
<pygi> _ion: statistics ^_^
<_ion> Good luck for the statistics exam which you'll fail today. :-)
<pygi> _ion: thanks :P And the thing is that I'm preety sure that if I fail this exam I failed uni ^_^
<pygi> but yea, good luck to me :)
<pygi> night now :)
<_ion> gnite.
<psusi> anyone know much about this new ext resize feature and the resize inode?
* psusi is trying to figure out why defrag is screwing the resize inode
<psusi> didn't Theodore Ts'o used to hang here?  he seems to have written some of the code for handling it in e2fsprogs
<jk-> ahoy
<bluefoxicy> so bored
<Keybuk> aww
<jk-> is there any policy on where non-native libaries/headers are to be installed?
<Keybuk> headers go in /usr/include
<Keybuk> libraries normally in /usr/lib
<jk-> Keybuk: yep, but it only makes sense to put native ones there..
<Keybuk> how do you have a non-native library?
<jk-> eg, for cross-compiling
<Keybuk> /usr/lib/arch-linux type thing for that
<jk-> and /usr/include/arch-linux ?
* jk- notices that there isn't a /usr/include/arch-linux directory currently
<Keybuk> where arch-linux is the config.guess output
<jk-> yep
<Keybuk> e.g. /usr/lib/i386-linux-gnu, /usr/lib/i486-linux-gnu
<Keybuk> etc.
<jk-> so just do the same thing for includes ?
<Keybuk> something like that
<jk-> smeet, ok.
<jk-> cheers.
<Ng> hey Keybuk 
<Keybuk> hey Ng!
<Keybuk> how's it going!
<Keybuk> long time no see!
<Ng> Keybuk: hehe. python hates me ;)
<Keybuk> Python hates everyone, it's goth
<Ng> hah, typically, right as I typed that, i realised what I was doing wrong
<Ng> so I can start using my own nonsense now \o/
<Keybuk> what did you write?
<Ng> I think I mentioned it t'other day, it just puts 4 vte widgets in a window, to maximise screen space on my teeny laptop
<Keybuk> ahh
<Ng> so nothing that devilspie and gnome-terminal couldn't do, but I wanted to learn some python and remind myself about gtk
<Keybuk> I just press F11 twice
<Keybuk> Metacity does the right thing
<Keybuk> uh, four times
<Ng> sure, that fullscreens a single terminal, but I lose panels behind it and it's just one terminal. this is 4 arranged in a grid
<Ng> but anyway, it's all quite trivial ;)
* Ng looks for somewhere to get food
<Keybuk> ah
<Keybuk> for me F11 just opens a single terminal
<Keybuk> if I press it four times, I get four terminals arranged in a grid on my desktop
<Keybuk> yay placement
<Ng> oh, iswym. yeah I do that now and metacity mostly gets it right, but there's all that space wasted on window decoration ;)
<_ion> One of the things i love about window shadows is the fact that you can use 0px window borders and still distinguish overlapping windows from each other perfectly.
* Keybuk will try compiz when it obeys his keyboard shortcuts
<Keybuk> and my workspace layout
<Ng> I'm waiting for the crackful configuration to go away ;)
<Keybuk> you can get rid of the wobbling and cube
<Ng> and I do every time I try it, plus I have to ditch the blur plugin or it is unusably slow on this laptop, but the configuration is annoying and emerald is insane
<_ion> Sounds like you've been using the beryl fork. I'm not using compiz nor beryl until nvidia releases a 9000 series driver that actually works, but i've heard compiz should have a less insane config UI than beryl has.
<Ng> hey mnepton 
<mnepton> heya Ng
<mnepton> what're you up to? poker in the lobby tonight. about to head down for a smoke and some cards.
<Ng> mnepton: I'm being highly anti-social and attempting to ditch this cold
<jk-> sharing is caring
<jk-> :)
<Mez> people still at MTV then /
<_ion> The newest innovation: germ sharing in Patient2Patient networks.
<siretart> pygi: in debian, dvd+rw-tools suggests cdrskin
<AWOSLappy> I was referred here by #ubuntu.
<AWOSLappy> http://paste.ubuntu-nl.org/32266/
<AWOSLappy> When the error comes up, it stops for about five minutes with
<AWOSLappy> '/sbin/modprobe': Premature exit      or something along those lines, I don't remember the exact wording
<AWOSLappy> And ever since this error happens on bootup my touchpad and external PS/2 mouse no longer work.
<crimsun> line 19 references an old kernel. Can you reproduce this with 6.06.1?
<AWOSLappy> I have 6.06.1
<crimsun> you're not using the latest kernel, however, according to the OOPS
<AWOSLappy> Well I don't have Edgy (6.10), I have Dapper LTS (6.06.1)
<AWOSLappy> Shall I get Feisty?
<crimsun> I'm referring to 2.6.15-27
<AWOSLappy> I will apt-get update and apt-get upgrade
<crimsun> dist-upgrade instead of upgrade, please.
<AWOSLappy> !
<AWOSLappy> no!
<AWOSLappy>  /dev/hda3  5.5G  5.1G  78M    99%  /
<AWOSLappy> ^ I have no disk space
<AWOSLappy> I can barely upgrade
<AWOSLappy> and since the *STUPID* NFS doesn't work I can't back up either
<crimsun> do you have a live cd?
<AWOSLappy> of Dapper.
<AWOSLappy> not of Edgy.
<AWOSLappy> and besides, can bcm43xx be started on the live CD?
<crimsun> that's fine, then, as long as you have it at the location where the machine is located physically.
<AWOSLappy> Ubuntu, Kubuntu or Xubuntu?  I have all three
<crimsun> doesn't really matter; they share the same kernel
<AWOSLappy> Okay I am staring at the 6.06 LTS disc right now
<AWOSLappy> but it has 2.6.15-23 too
<crimsun> I would remove linux-image-2.6.15-23-386 and dist-upgrade to linux-image-2.6.15-27-386
<AWOSLappy> !
<AWOSLappy> can you even DO that without touching anything else?
<crimsun> sure, it will remove linux-restricted-modules-2.6.15-23-386 and assorted metapackages, but you should be interested more in getting that new l-i (and possibly l-r-m) than anything else
<AWOSLappy> so what do I do in apt/sources.list?
<crimsun> if it fubars, boot from the live cd, chroot into your install partition, remove linux-image-2.6.15-27-386, and reinstall linux-image-2.6.15-23-386 (and possibly linux-restricted-modules-2.6.15-23-386) from the CD
<crimsun> don't touch sources.list(5)
<AWOSLappy> Ah okay.
<AWOSLappy> okay not touching
<AWOSLappy> Holy moly!
<AWOSLappy> requires 83M of disk space
<AWOSLappy> I have 78
<crimsun> and that's why you remove linux-image-2.6.15-23-386 first, since it will remove linux-restricted-modules-2.6.15-23-386, too, clearing more than 78 MB
<AWOSLappy> ah
<Ng> AWOSLappy: check /var/cache/apt/archives/ too, you may have old debs in there
<AWOSLappy> Wow.
<AWOSLappy> only requires 246kB now :)
<AWOSLappy> Ng, that would be apt-get clean right?
<Ng> yeah
<AWOSLappy> Okay it sas
<AWOSLappy> s/sas/says/
<AWOSLappy> You are running a kernel (version 2.6.15-23-386) and attempting to remove the same version.
<AWOSLappy> This is a potentially dangerous action.
<AWOSLappy> Not only will /boot/vmlinuz-2.6.15-23-386 be removed, making it impossible to boot it, (you will have to take action to change your boot loader to boot a new kernel), it will also remove all modules under the directory /lib/modules/2.6.15-23-386.
<AWOSLappy> Just having a copy of the kernel image is not enough, you will have to replace the modules too.
<AWOSLappy> I repeat, this is very dangerous.  If at all in doubt, answer no.  If you know exactly what you are doing, and are prepared to hose your system, then answer Yes.
<AWOSLappy> Remove the running kernel image (not recommended) [No] ?
<AWOSLappy> What do I do crimsun?
<AWOSLappy> crimsun?  hello?
<crimsun> how much additional space do you gain when you ``apt-get clean''?
<crimsun> (I'm busy atm.)
<AWOSLappy> I don't know
<AWOSLappy> Remove the running kernel image (not recommended) [No] ?
<Mez> Keybuk, did you ever save a copy of that patch i made for signkey.pl ?
<Keybuk> Mez: no, probably not -- why?
<Mez> cause i lost it ;
<Mez> and want a copy ;)
<Keybuk> ahh
<Keybuk> no, I don't
<Mez> :(
<Mez> Keybuk, do you have the email still describing it ?
<crimsun> AWOSLappy: answer No, then, and find out how much space you gain (if any)
<AWOSLappy> okay
<AWOSLappy> Hmm.
<AWOSLappy> I'm at 42M now
<Keybuk> Mez: doubt it
<AWOSLappy> after the download
<crimsun> AWOSLappy: let's migrate this to #ubuntu, please, since it's not Feisty development-related.
<AWOSLappy> okay.
<Mez> Keybuk, thought not :P
<Mez> Keybuk, anyways, when you back in brum so I can arrange a keysigning with you ;)
<Keybuk> Mez: don't tend to keep e-mail much, and I haven't done much with signkey
<Keybuk> Mez: sunday
<Mez> up for a drink monday then ?
<slomo_> infinity: please give-back tomboy on !x86 and gmime2.2 on x86, thanks :) should build now that libxml-*-perl is in main :)
<Keybuk> slomo_: I can say with some amount of certainty that adam is *not* around right now :p
<Burgundavia> Keybuk: have you filled my inbox just to make me cry when I try and parse them for UWN or just for the malicious pleasure of it?
<Keybuk> Burgundavia: hmm?
<Burgundavia> all the new stuff from Debina
<Keybuk> can't avoid it
<Keybuk> the mails go when they're accepted from NEW
<Keybuk> so the usual "suppress the sync mails" thing doesn't work
* Mez wishes there was a way to cram patches down upstreams throats
<Burgundavia> Keybuk: yep, anyway, this makes next weeks UWN a wee bit more interesting
<Keybuk> heh
<Keybuk> summary "we're syncing from Debian"
<Keybuk> so not *that* interesting
<Burgundavia> but all of that is stuff that is completely new in Ubuntu, correct?
<Mez> Keybuk, and yet you didnt sync kde-style-klearlook
<Keybuk> Mez: I didn't?
<Mez> it wasnt in my inbox ;)
<Keybuk> oh, it probably wanted to override a package or something
<slomo_> Keybuk: ok, good to know :) if you have some seconds please do it ;)
<Keybuk> slomo_: I have no seconds
<Keybuk> and I have no beer
<Mez> Keybuk, it provides a binary package already provided by the source package kde-klearlook in ubuntu
<Keybuk> I need to rectify at least one of these ;P
<Mez> but i wanna get rid of that source package and replace it with the debian one
<Keybuk> Mez: does the one in ubuntu have XubuntuY in its version?
<Mez> Keybuk, yes -
<Keybuk> hmm, it doesn't show up in new-source
<Mez> Keybuk, is there a way todrop the kde-klearlook package from the archives ?
<Keybuk> kde-style-klearlook # shipped in klearlook
<Keybuk> ahh
<Keybuk> Mez: can I override the changes?
<Mez> Keybuk, kill the klearlook source package and just grab the kde-style-klearlook source package from debian
<Mez> there is a bug requesting that ;)
<Keybuk> Mez: what's your lp id?
<Mez> bug 61289
<Ubugtu> Malone bug 61289 in klearlook "Please sync kde-style-klearlook 0.9.9.2-1 from Debian" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61289
<Mez> Keybuk, it's mez
<Keybuk> Will remove the following packages from feisty:
<Keybuk>  klearlook | 0.9.7-0ubuntu2 | source
<Keybuk> ------------------- Reason -------------------
<Keybuk> (keybuk) RoM obsoleted by kde-style-klearlook
<Keybuk> ----------------------------------------------
<Mez> RoM 
<Mez> ?
<Keybuk> Request-of-Maintainer
<Mez> ah, cool :D
<Mez> cheers, and if you can ping me when the sync is done I can kill off the bug
<Keybuk> [Updating]  kde-style-klearlook (0 [Ubuntu]  < 0.9.9.2-2 [Debian] )
<Keybuk>  * Trying to add kde-style-klearlook...
<Keybuk>   - <kde-style-klearlook_0.9.9.2.orig.tar.gz: downloading from http://ftp.debian.org/debian/>
<Keybuk>   - <kde-style-klearlook_0.9.9.2-2.diff.gz: downloading from http://ftp.debian.org/debian/>
<Keybuk>   - <kde-style-klearlook_0.9.9.2-2.dsc: downloading from http://ftp.debian.org/debian/>
<Keybuk> iwj: kde-style-klearlook [universe]  -> kde-style-klearlook_0.9.7-0ubuntu2 [universe] .
<Keybuk> in NEW
<Keybuk>          | * kde-style-klearlook/0.9.9.2-2 Component: universe Section: kde
<Keybuk> accepted
<Keybuk> all done
<Mez> cool, noe judy goyys esit got iy
<Mez> o_O
<Keybuk> ?!
<Mez> cool, now just gotta wait for it 
<Mez> (displaced fingers on kb)
<Keybuk> ~2 hour
<Hobbsee> Mez: put down the grog.  it's bad for you
<Keybuk> source will go in at 0803 UTC
<Keybuk> binaries may make it for 0903 UTC if the buildds are bored
* Mez puts down the grog and gets out the vodka
<Keybuk> which means the earliest in the archive is ~0940 UTC
<Mez> Keybuk, now all I gotta do is wait for tfheen to poke prevu out of new and my day's hacking is done
<Keybuk> heh
<Keybuk> he'll be bored of it soon enough
<Keybuk> he's still in the first few days of ubuntu-archive powers, so it's still exciting
<Hobbsee> Mez: that's included in grog :P
<Mez> Keybuk, i'm sure, but... so picky about the licence ;)
<Keybuk> heh
<Keybuk> damned right too
<Keybuk> I think he's probably strictest, followed by me, followed by Colin and then adam as the loosest
<Keybuk> anyway, drink then bed
<Keybuk> nite
* Mez doesnt wanna think about adam as loose
<pygi> good morning folks
<PecisDarbs> I have question for devs - what is libburn effort and where i can find more information about it?
<Zdra> PecisDarbs: google ;-)
<PecisDarbs> I already found it - #ubuntu-burning
<zul> hey
<hunger> Hmmm.... why doesn't feisty's session bus pick up files in ~/.local/share/dbus-1/services?
* hunger thinks the dbus 1.0 rc3 release note states that services may be defined in that directory.
<sjoerd> hunger: iirc that was added later
<hunger> sjoerd: Later than 1.0?
<sjoerd> hrm, no your right.. It's there since RC3
<hunger> sjoerd: I got dbus 1.0.0-1ubuntu1 installed on feisty and the directory seems to be ignored.
<hunger> sjoerd: /etc/dbus-1/session.conf does list /usr/share/dbus-1/services only.
<sjoerd> ah that should be replaced by <standard_session_servicedirs/> probably
* hunger shivers reading the dbus spec.
<hunger> That thing is full of FIXME: and still went "stable"!
<mruiz> ping Mithrandir 
<bddebian> Howdy
<sbalneav> Trying to test some compatibility on LTSP with Intel graphics.  Does anyone know if you can buy an Intel 3d graphics card as an actual stick-it-in-the-machine card, or does intel only do onboard?
<Seveas> sbalneav, at UDS someone told me that intel now has at least one stick-it-in-the-machine card
<Amaranth> i don't think it's publicly available yet
<sbalneav> grmble.
<sbalneav> Thanks anyway.  Mobo's are cheap enough, so I suppose I can just buy a different mobo.
<sivang> crimsun: ping
* Adri2000 hates Ctrl+Q
<sivang> people are waking up in san fran ;)
<Adri2000> Mithrandir: could you take a look at the merged pppoeconf please? I will give you a link when you are here
<Mithrandir> Adri2000: why not give me the link when I'm not here? :-P
<Adri2000> hehe ^^ wait one sec
<Keybuk> ogra: 
<Keybuk> Will remove the following packages from feisty:
<Keybuk> ltsp-utils |     0.25-1 | source
<Keybuk> ------------------- Reason -------------------
<Keybuk> (keybuk) RoM
<Keybuk> ----------------------------------------------
<Adri2000> Mithrandir: here: http://adrishost.homeip.net/~adri2000/ubuntu/pppoeconf/
* ogra hugs Keybuk 
<Mithrandir> Adri2000: I'll take a look.
<Adri2000> Mithrandir: and builds fine in a feisty pbuilder
<Adri2000> thanks
<Mirv> is the importing of new debian packages (previously unexisting) started yet? or is it ongoing all the time?
<giftnudel> hi sivang :)
<sivang> giftnudel: Hi Martin!
<sivang> giftnudel: what's up? :)
<giftnudel> sivang: nothing, just saying hello ;)
<giftnudel> sivang: i'm currently learning the python debugger so I will be faster in the future (hopefully)
<sivang> giftnudel: cool, I'm sorry I haven't responded to your emails yet, I was busy dealing with real life.
<sivang> giftnudel: ah, what do you want to debug ? ;)
<giftnudel> oh, I will be busy in the next weeks too, but still, as long as you answer sometime, it doesn't really matter
<sivang> giftnudel: okay, cool, I just don't want to delay your contributions with my lack of response :)
<giftnudel> sivang: hubackup, i'm trying to fix bug 72015
<Ubugtu> Malone bug 72015 in hubackup "Cannot back up more than 4GB to a FAT32 partition" [Undecided,In progress]  http://launchpad.net/bugs/72015
<giftnudel> so I'll see where I can implement that, and for this I want to see what information is available at what stage
<giftnudel> sivang: oh, I have registered a branch in launchpad: http://bazaar.launchpad.net/~martin-bergner/hubackup/mbergner--devel since I had space problems with my other branch
<netG> hi
<netG> Is there any way to downgrade from feisty to edgy?
<netG> I've changed entry in sources.list then apt-get update
<Treenaks> netG: no, downgrading is not supported/easy
<netG> ahhhhrrg
<netG> so I have to reinstall from edgy CD... ;-(
<sivang> giftnudel: okay, so are you waiting for me to finish the backup/restore stuff before you can continue fixing bug 72015 ?
<Ubugtu> Malone bug 72015 in hubackup "Cannot back up more than 4GB to a FAT32 partition" [Undecided,In progress]  http://launchpad.net/bugs/72015
<giftnudel> sivang: no, not really, I have to find out a way to find out what partition and therefore fstype  a given path belongs to
<giftnudel> sivang: I don't have to wait for you, this could be done in parallel I guess
<sivang> giftnudel: right, it does sound so, btw, I think we can fetch this info from hal no?
<giftnudel> sivang: yes, but how? I mean, I could look at the path and go up on level and see if it matches any mountpoint in hal, but this would fail if there were two things mounted on the same mountpoint
<giftnudel> it would work though
<giftnudel> sivang: I think I'll write a function which does exactly that: Find out what device/partition a mountpoint belongs to and return all the information from hal we have about it, this will be handful in other places, too
<giftnudel> ah, what mountpoint a path belongs too, rather
<sivang> giftnudel: indeed
<sivang> giftnudel: but yest, make it the other way around as you just noted , e.g. detect which file system a path lies underneath, and then find out what type of file system it is
<sivang> giftnudel: cool about the approach, as it will be useful in other places ofcoure.
<giftnudel> sivang: this is exactly the thing that is missing in BackupEngine to do a on the fly slice size detection ;)
<sivang> giftnudel: hmm, maybe, but you could already do on the fly slice size detection using the utility function in fsMisc.py no?
<sivang> (that detects free space on a file system path)
* sivang finds the function's name
<sivang> giftnudel: ah, that's fsMisc.free_space(path)
<sivang> giftnudel: then you could use the free space to set up the slice size, IIRC I already did on the fly slice detection for the CDs through using DeviceInfo.py
<Treenaks> what if something else is also writing at the same time?
<Treenaks> sivang: then your 'free space' estimate is off
<sivang> Treenaks: you are asked to close running programs before doing a backup ;-) but this is unrelated to the on the fly slice size detection, this is yet another system wide problem from programs that need to know available space on the system for future or in progress processing.
<sivang> for instance, consider nautilus moving a file from one location to another, and in the target location at some point available space is out.
<giftnudel> sivang: yes, i will look at that, but I need to go now
<Keybuk> mjg59: ping?
<mjg59> Keybuk: Hi
<Keybuk> mjg59: few issues with compiz ...
<mjg59> Sure
<Keybuk> switching appears to lose windows
<mjg59> "switching"?
<Keybuk> it doesn't appear to obey any of my metacity preferences, like keyboard shortcuts, or window behaviour
<Keybuk> mjg59: between metacity and compiz
<Keybuk> and most annoyingly, it doesn't obey my workspace layout
<mjg59> Windows will be moved because of the workspace/viewport distinction
<mjg59> All the preferences work fine here
<Keybuk> I can't move windows with the Super key
<mjg59> Does it work if you set that in the window preferences?
<mjg59> If not, it's a general bug rather than a preferences bug
<Keybuk> the window preferences dialog appears to be empty
<mjg59> Your system sounds somehow screwed
<Keybuk> Windows-Tab doesn't appear to switch windows
<Keybuk> Windows-Arrow-Keys don't move workspaces
<mjg59> Your system is *definitely* screwed
<Keybuk> it's just a feisty system
<mjg59> Oh, wait
<mjg59> Windows-tab?
<mjg59> Hm.
<mjg59> Does alt-tab work?
<Keybuk> mjg59: yes, I changed the keyboard shortcuts
<Keybuk> alt-tab appears to work
<mjg59> Ok, that's something, at least
<sivang> I can't even try this due to lack of the prop. drivers for feisty , the troubles of the rich ;)
<Keybuk> mjg59: the workspace layout is lost too
<Keybuk> the pager still shows 4x3
<mjg59> Keybuk: You still have 4x3 workspaces
<Keybuk> but the window manager behaves as if I only have 4 in one row
<mjg59> No, those are viewports
<Keybuk> ?
<mjg59> You can tell by the way windows can spread across more than one
<mjg59> They're entirely separate concepts. Each workspace can have more than one viewport.
<Keybuk> how do I move to the workspace/viewport above and below?
<mjg59> Click on the workspace applet.
<mjg59> This is waiting on libwnck patches
<Keybuk> can't I just have a big 4x3 workspace with 12 viewpoints?
<mjg59> No
<Keybuk> that sucks
<mjg59> Yes
<Keybuk> it appears consistent ... no dialog box has anything in it
<wasabi> Heh. So I'm not the only person who changes it to WIndows-tab
<Keybuk> and I'm not getting highlights in menus either
<mjg59> Ok, so something is clearly desperately unhappy there
<Keybuk> the utter lack of respect for existing preferences is a major bug
<mjg59> It doesn't have an utter lack of respect for existing preferences
<Keybuk> it does
<mjg59> No, it doesn't
<Keybuk> it's clearly not looking at any of the metacity preferences I set
<Keybuk> utterly clearly ignoring them
<mjg59> It works fine with all the metacity preferences /I/ set
<Keybuk> keyboard shortcuts I removed have come back
<Keybuk> keyboard shortcuts I changed have been reverted
<Keybuk> in fact, I can't see a single preference it's obeying
<wasabi> You did load the gconf module, right?
<Keybuk> except, maybe, focus-follows-mouse
<Keybuk> wasabi: ?
<mjg59> wasabi: It's impossible not to in this setup
<Keybuk> acs compiz gconf shows no packages?
<wasabi> Ahh.
<Keybuk> mjg59: this box was installed fresh with edgy when it released, and then updated to feisty
<Keybuk> so it's nowhere near unusual or customised
<mjg59> Keybuk: I'm not saying it's not a real issue, I'm saying it's not a general issue.
<Keybuk> just my usual changes to the keyboard shortcuts and window dialog
<Keybuk> F11 doesn't open a terminal either
<Keybuk> so it's ignoring that shortcut
<mjg59> That's not a window manager shortcut, surely?
<Mithrandir> it doesn't respect f1 to open a terminal here either.
<Keybuk> it's in the Keyboard Shortcuts dialog
<Keybuk> and handled by metacity
<mjg59> Ok. In that case, I suspect it's just missing functionality.
<Keybuk> it's not obeying my "Close Window" shortcut
<Keybuk> I change that to Super-F4 from Alt-F4
<Keybuk> compiz is only reacting to Alt-F4
<Mithrandir> Keybuk: what does gconftool-2 -g /apps/compiz/general/allscreens/options/close_window_key
<Mithrandir> say?
<Keybuk> <Alt>F4
<Keybuk> /apps/metacity/window_keybindings/close = <Mod4>F4
<Mithrandir> can you change it to Super and see if it works?
<Mithrandir> or Mod4
<Keybuk> yes, that works
<mjg59> Metacity madness.
<Keybuk> but the keyboard shortcuts dialog changes the metacity one
<mjg59> Oh, I see
<Keybuk> mjg59: what's this got to do with metacity?
<mjg59> Sorry, I misread compiz as metacity
<Keybuk> metacity is behaving correctly.
<Keybuk> :)
<Adri2000> Mithrandir: pppoeconf? :)
<mjg59> Oh, gross.
<mjg59> gnome-keybinding-properties writes directly into metacity's preferences.
<Keybuk> arguably, all of those should be /desktop/gnome/keybindings or something
<mjg59> Yes.
<Mithrandir> Adri2000: meeting
<Keybuk> /desktop/gnome/window_manager_behaviour too for the Windows preferences
<Keybuk> ?
<Mithrandir> would upstream kill us if we just did that?
<mjg59> Talk it over with upstream first
<mjg59> Bear in mind that you'd need to migrate settings over
<Keybuk> we'd need to have someone do that work
<mjg59> The alternative is just to change the references in compiz and have it use the metacity keys
<Keybuk> the main guys we're likely to have for bling development work are the beryl guys
<Keybuk> so it may be easier to just get beryl to read/write gconf properly
<mjg59> Beryl explicitly removed gconf support
<Keybuk> we can make them explicitly put it back :)
<mjg59> Ha
<mjg59> This is going to be a ~20 line patch to compiz
<Keybuk> can you do that patch?
<mjg59> A monkey with a missing arm could do that patch
<Keybuk> cool, if you could do that, that'd be great
<mjg59> I'm at work right now, so don't have a fesity box
<mjg59> I'll try to give you a diff in a few minutes
<_MMA_> I thought the Beryl guys said they removed gconf support so they could make it DE independent? At UDS they mentioned at their "stable" release would have support for reading your keybindings. I thought thats what was going to happen?
<mjg59> Removing the primary configuration store from gconf isn't acceptable from a managability perspective
<mjg59> It means tools like Sabayon become much less useful
<_MMA_> yes.
<_MMA_> You could get one of the guys over here now probably. DBO or someone.
<Treenaks> also.. the config modules in compiz _are_ optional and interchangeable, afaik..
<Treenaks> so there's not much of a point in _removing_ gconf support..
<_ion> Indeed.
<mnepton> TGIF
<mnepton> thank god i farted.
<ogra> how great you arent in the distro meeting
<Treenaks> ogra: so fart for him a bit :P
<ogra> :P
<Treenaks> (fart by proxy?)
<jdub> mjg59: red hat are doing the work for compiz/metacity settings integration
<jdub> *please god bring ubuntu back from the beryl brink*
* Treenaks is supports jdub
<Treenaks> uhr
<Treenaks> s/is//
<mc44> jdub: but. its *community*
* Treenaks hands mc44 a nondescript brown ticking package and runs away
<jdub> mc44: as is compiz, but with higher standards.
<mc44> jdub: yes, sorry that wasn't a serious argument :)
* Treenaks cries about dosbox in feisty.. somehow mouse support is Broken
<ogra> Treenaks==MOTU, dosbox==universe ;)
<Treenaks> ogra: sure, but I think it's upstream
<_ion> dosbox==universe, therefore universe==dosbox?
<Treenaks> _ion: apt-get install command,com
<Burgwork> jdub: I really don;t see how beryl is going to match the spec, so I am not worried
<mnepton> jdub: you obviously have not been smoking enough crack recently. please rectify.
<Treenaks> mnepton: I think the beryl people smoked it all
* mnepton weeps gently
<Burgwork> Treenaks: you don;t tell support people there is no crack to smoke. It causes them to lose hope
<Treenaks> Burgwork: they have their own special stash
<Burgwork> true
<Treenaks> Burgwork: with added valium
<mc44> they dont need crack anymore, they have flaming board karate
<Treenaks> "Imagine it's a customer"
<mnepton> a what now?
<mnepton> what is this "customer" you speak of?
<Treenaks> mnepton: client? supportee?
<mnepton> oooooh! those!
<Treenaks> supportee.. I like that word.. nice and generic :)
* mnepton hugs SpamAssassin
<ogra> the voice coming out of your phone usually ;)
<Treenaks> ogra: Oh HIM! :P
<Treenaks> ogra: (no, not http://en.wikipedia.org/wiki/HIM_%28band%29)
<mnepton> ogra: the voices usually just tell me to burn things.
<mc44> mnepton: now they tell you to punch burning things, much better
<ogra> mnepton, and break them later with your bare hand ?
<mnepton> ogra: or bury them after post-immolation sodomization. but perhaps i have said too much ....
<ogra> *g*
<Treenaks> mnepton: I won't tell anyone.. if you won't
<mnepton> Treenaks: my home address is ....
<mc44> mnepton: oh dont worry simon told everyone your address already
<mnepton> mc44: just remember, i like it rough. that's why i accepted Canonical's offer.
* mc44 irrigates mnepton colonically
<zul> mnepton: offer for what?
* Treenaks pokes at his kernel bug
<zul> mnepton: oh hey kurt nevermind
<mjg59> jdub: They may well be, but none of it's released
<jdub> mjg59: hrm, i thought it was
<jdub> mjg59: talk to ssp about it
<crimsun> sivang: pong
<sivang> crimsun: there was some issue with flahplugin-nonfree
<crimsun> yes, I've already committed the fix
<crimsun> I won't upload the fix until Bart releases the fix for the debconf issue, however, which is coming in 9.0.21.55.3
<sivang> crimsun: who is Bart and what sort of debconf issue is this? :)
<crimsun> Bart is the Debian maintainer
<sivang> ah, for debconf I assume?
<crimsun> the debconf issue is bug 398726
<crimsun> Debian 398726
<Ubugtu> Debian bug 398726 in flashplugin-nonfree "flashplugin-nonfree: dpkg-reconfigure fails" [Grave,Open]  http://bugs.debian.org/398726
<sivang> crimsun: I see, I didn't actually understand why --force-overwrite didn't solve it
<crimsun> well, our specific issue on upgrades is due to the fact that /usr/lib/mozilla-firefox points to /usr/lib/firefox, so since the maintainer script attempts to install into both locations (presuming both are distinct), it bombs after installing into /usr/lib/mozilla-firefox/plugins
<lifeless> ogra: ping
<sivang> crimsun: ah, I see
#ubuntu-devel 2006-11-18
<imbrandon> jono: ping
<jdub> jordi: ping
<jdub> however unlikely
<pygi> sivang: ping?
<what_if> does anyone know a fix for garbled graphics when installing on a PC with a newer  Nvidia card ?
<Burgundavia> what_if: please use #ubuntu, as this is not a support channel
<what_if> Burgundavia: well, they have no idea and there is no bug report for this problem 
<what_if> also tried ubuntu-bugs to no avail 
<Burgundavia> then file it. This is a not an escalation channel if #ubuntu cannot help you
<Burgundavia> and #ubuntu-bugs is not a support channel either
<what_if> Burgundavia: gotcha 
<Burgundavia> what_if: I would try the fourms or the mailing list
<what_if> Burgundavia: will do 
<what_if> Thank you
<Burgundavia> no worries
* Mez -> bed
<sivang> pygi: pong
<Adri2000> Mithrandir: ping, have you found some time to review pppoeconf?
<bddebian> Howdy
<xst> Can anyone here explain if bug #58721 is being ignored or if there is actually being worked on a solution? All Matrox owners are currently stuck with a complete showstopper of a bug (broken X). No developer seems to participate/listen on the (large) thread on launchpad: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-mga/+bug/58721
<Ubugtu> Malone bug 58721 in xserver-xorg-video-mga "Edgy upgrade breaks multiple Matrox cards" [Unknown,Unconfirmed]  http://launchpad.net/bugs/58721
<jdong> xst: I'm not a developer... but from what it seems ou guys need xserver-xorg-video-mga >= 1.4.2, right?
<xst> jdong: Yes, something like that. I have not tried to install it on the way described on launchpad (as it is kind of a hack IMHO) but apparently it will fix some issues
<jdong> xst: I'm replying to the bug report with an Edgy-compiled package... one sec
<jdong> xst: replied
<jdong> xst: once we have a potential fix, it's much easier to poke the devs :D
<jdong> xst: I think it's quite honestly a case of no developer has this particular video card.... :(
<xst> Great! Thanks alot!
<xst> Do you know if the developers are following the "popularity" of the bugs and fix most "popular" bugs fist? (I was wondering this, as the bug apparently was being ignored despite of the "high importance" tag)
<jdong> xst: well , the developers are aware of all the bugs out there... trust me.. they are
<jdong> xst: they tend only to reply to the ones they know a solution to
<jdong> xst: and there's PLENTY of those to keep them busy :)
<crimsun> jdong: (you may wish to consider testing the current feisty flashplugin-nonfree as a {dapper,edgy}-backports candidate)
<jdong> crimsun: you mean it actually doesn't bork on configure anymore? :D
<jdong> crimsun: I gotta say, seeing that error sent chills up my spine :)
<crimsun> jdong: those're fixed, correct
<jdong> crimsun: cool :) gonna put that in my queue
<jdong> Seveas: having fun? :D
<jdong> Seveas: stop clicking that kill button on ettercap
<mc44> jdong: thats be the script kiddies in #ubuntu
<jdong> :)
<ulaas> hi xinerama and gnometerminal
<ulaas> they dont like each other now
<ulaas> or do they?
<dsas> ulaas: I think there's a bug on gnome-terminal about that, yes.
<ulaas> and i am damn sure it was working before
<ulaas> uh and i have uograded to 9629 nvidia
<ulaas> maybe related
<ulaas> does restricted-modules have anyting to do with ipw3945?
<Seveas> jdong, pok
<Adri2000> Mithrandir: ping :s
<Adri2000> or maybe someone else can check my pppoeconf merge, volunteers? :)
<geser> Adri2000: have you tried the ubuntu-main-sponsors team already?
<Adri2000> no, but it's good idea, I'm going to file a bug
<niktaris> hi, can I add the keyboard indicator to the gnome panel via the command line ?
<Adri2000> geser: can I confirm the bug?
<Adri2000> bug 72370
<Ubugtu> Malone bug 72370 in pppoeconf "[Merge]  pppoeconf 1.12ubuntu1" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72370
<geser> Adri2000: I leave mine merge bugs unconfirmed
<Adri2000> ok
#ubuntu-devel 2006-11-19
<jdong> Seveas: return poke
<jdong> crimsun: flash9 is perfect in Edgy, gave the go-ahead for it already... Also testing it on Dapper and appears to work too
<jdong> crimsun: is it ok to backport to Dapper also?
<jdong> it's a blast :D
<jdong> oops wrong window
<crimsun> jdong: I ran some rudimentary tests in 6.06.1 and 6.10, and both seemed ok, before I mentioned it to you, so if you're fine with them, I have no further qualms.
<jdong> crimsun: what's the default DEBCONF_FRONTEND in Dapper?
<jdong> crimsun: in my debootstrapped chroot it defaults to noninteractive which obviously doesn't work :D
<jdong> crimsun: hopefully update-manager uses an interactive one by default?
<crimsun> I believe it's non-
<jdong> :-/
<jdong> that's a bit shaky....
<crimsun> you could recommend people reconfigure debconf first
<jdong> crimsun: true
<jdong> crimsun: I expect flash users to have java anyway, which needs an interactive debconf too :D
* Fujitsu knows a lot of people who have Flash but not Java... I only have Java because I need it for my TAFE course.
<dsas> jdong: That'd probably be a bad guess.
<jdong> :-/
<jdong> well... I don't want 200 bug tickets on flashplugin failing on postinst (again)
<crimsun> that's easily avoidable if, when you mention the backports being available, you mention that debconf may need to be reconfigured prior
<jdong> ok
<crimsun> (not that many people will notice such a mention, but...)
<jdong> crimsun: well, the UWN should reach a few and I'll also keep forum staff on alert
<jdong> hopefully between those two that's enough coverage
<crimsun> as long as it's done in blazing, garish letters
<_ion> Yay, my system failed to boot after upgrading to feisty. :-) It was simple to fix, though: bug 72387
<Ubugtu> Malone bug 72387 in lvm-common "Incorrect dependency in initramfs script, system fails to boot. Patch attached" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72387
<minghua> _ion: you are my hero.  I'll test your patch soon
<zOrK> hey, I am doing an easy-ndiswrapper script, is anyone insterested on help me?
<highvoltage> zOrK: that's a question for #ubuntu
<zOrK> no man,  I am provramming an easy-ndiswrapper program
<zOrK> *programming
<zOrK> I've read in launchpad.net that they are needing one
<highvoltage> zOrK: aah, sorry, misread you there.
<zOrK> it's ok
<zOrK> highvoltage, does ubuntu recognizes all the wireless cards without even took ndiswrapper?
<highvoltage> zOrK: it recognises a large variety of cards, I've used mostly Intel cards (ipw2100, ipw2200, ipw3945) and they all work out the box on ubuntu.
<zOrK> ok
<zOrK> without use ndiswrapper, right?
<highvoltage> yes, without ndiswrapper.
<highvoltage> I would never buy hardware that would require ndiswrapper :)
<zOrK> thanks.. do you know where can I find a list of wireless cards which are not regoznied by the kernel?
<highvoltage> I think there's a page on the ubuntu wiki with a full list, perhaps try a search on that.
<highvoltage> zOrK: https://wiki.ubuntu.com/?action=fullsearch&context=180&value=wireless&titlesearch=Titles
<zOrK> thanks
<highvoltage> zOrK: this looks like what you're looking for: https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported
<zOrK> sweet.
<zOrK> thanks
<zOrK> would you like to program it with me ?
<zOrK> there are not much time
<zOrK> Works "out of the box"
<zOrK> what does that exactly mean ?
<highvoltage> heh, that's my #1 problem as well. your best bet is probably to ping the ubuntu-devel mailing list and make a call for contributions.
<highvoltage> zOrK: it means that I install Ubuntu and my card works without me having to touch a config file or install any additional software.
<zOrK> ok
<zOrK> you've been helpful tonight
<zOrK> thanks
<highvoltage> :)
<mdke_> I can use comments in debian/rules right? with compat 5
<mdke_> and while lines are ignored alright?
<mdke_> s/while/white
<giskard> mdke_, yes, but this is not a feature of debhelper5
<mdke_> giskard: so it's a feature of an earlier version?
<giskard> mdke_, i guess blank lines and # comments are supported from debhelper0
<mdke_> giskard: ah good. Thanks for your help.
<pygi> sivang: ping
<ulaas> i want to go feisty. changing edgy repos to feisty is enough?
<jsgmobile> Pretty much, yes
<ulaas> then i do a dist-upgrade or the usual apt-get upgrade?
<Hobbsee> ulaas: dist-upgrade.  please see the /topic 
<giskard> hello pygi 
<pygi> hey giskard, how are you?
<pygi> <pygi> hey giskard, how are you?
<pygi> in case you havent seen :P
<tormod> ulaas, we might help you in #ubuntu+1 :)
<mdke_> can anyone tell me what I'm doing wrong under the section entitled "Ubuntu documents", the bash script isn't working as I thought it would. http://paste.ubuntu-nl.org/32736/
<tormod> mdke_, is it ubuntu/dir/* or ubuntu/$$dir/* ?
<mdke_> tormod: aha, nice catch. I suspect however that that isn't the only error, lemme try fixing that
<tormod> mdke, the same for generic/dir/*
<mdke_> yeah, it still doesn't like it. Error is:
<mdke_> /bin/sh: Syntax error: end of file unexpected (expecting "done")
<mdke_> tormod: yep, changed that now, thanks. Still the same error tho
<Hobbsee> mdke_: does 53. 	done need to be done; \ like the others?
* Hobbsee isnt good with such things, just taking a guess
<mdke_> Hobbsee: I don't think so, that was one of the things I didn't change since it last worked
<Hobbsee> ah
<Hobbsee> like i say, i know close to nothing about such things :P
<gnomefreak> did ian stop maintaining FF?
<tormod> mdke_, check for trailing spaces after \ (just guessing)
<mdke_> tormod: double aha, I think that's it
<mdke_> tormod: yep. Thanks!
<mdke_> ok, next problem. I need to exclude certain types of files from the "for x in ubuntu/$$dir/*" line, such as files ending in ".sh" and ".pot". How can I do that? Apologies if it is veering off topic
* mdke_ bbl - if anyone leaves me a reply, please hilight me and I'll pick it uP!
<bddebian> Howdy
<sivang> pygi: pong
<highvoltage> someone contacted me and he wants to host an official Ubuntu mirror, who is the right people I should put him in touch with? elmo or Znarl?
<Seveas> highvoltage, #ubuntu-mirrors (and tell the person to have patience, admins are busy)
<highvoltage> Seveas: ok :)
<highvoltage> Seveas: thanks
<_TomB> how do you rebuild a deb package after you've edited some stuff
<pygi> _TomB: #ubuntu-motu, and "debuild -S -sa"
<_TomB> thanks
<Thigied_Asourer> hallo!
<Thigied_Asourer> hm, jemand da?
<popey> is it try that the *386 kernels dont have support for SMP? and the generic kernels have to be used?
<_ion> fabbione: Hi. Have you noticed bug 72387?
<Ubugtu> Malone bug 72387 in lvm-common "Incorrect dependency in initramfs script, system fails to boot. Patch attached" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72387
<jordi> jdub: pong?
<jdub> jordi: hi!
<jdub> jordi: do you know where the scan of mako on the mataro newspaper is?
<jordi> jdub: hm hm
<jordi> no, qgil might know?
<ph8> hi all, I don't seem to have /lib32/libfl.a
<ph8> does anyone here have it on their 64-bit system? if so would you mind telling me which package i need to get to get it!
<ph8> i've got flex libraries in /lib
<ph8> but i'm after the 32-bit equivalent
#ubuntu-devel 2007-11-14
<elmo> ok,s eriously
<elmo> how  on earth do you restore a 'Stopped' printer with the new gutsy printer UI?
<elmo> I ended up going through the web ui, the gnome one was so devestatingly unintuitive
<Hobbsee> elmo: cant be done.  too many options there already.
<seb128> elmo: second tab, first option?
<seb128> elmo: it's a checkbox though which doesn't look intuitive at all
<elmo> oh, blah
<elmo> seb128: right, thanks.  that would have been it
<siretart> there used to be a enable(1) command as well, IIRC
 * seb128 dislikes this new UI too
 * ogra wholehartedly agrees
<bddebian> Heya
<Keybuk> I like the new UI about as much as I like ritual disembowelment
<seb128> pitti: any gut felling about sg3-utils?
<fabbione> seb128: they are good :)
<seb128> the new libgpod version use it to do a scsi inquiry on the new ipods
<seb128> which would mean main promotion
 * cjwatson_ would like to ask the same question about libsmbios, for the sake of Dell systems
<seb128> I'm wondering if that would be worth trying to do without the libsgutils1
<cjwatson> dellWirelessCtl seems to make network-manager a lot happier
<cjwatson> (or rather hal)
<fabbione> seb128: in my experience they are pretty good.. i used them as Suggests: for multipath-tools for a while because I didn't want to go through the pain of MIR
<fabbione> seb128: and they had a smaller and more specific user target
<fabbione> but if it's required for iPod stuff, then it changes and MIR is worth it
<seb128> fabbione: ok, thanks, I'll do a MIR then ;-)
<PriceChild> Keybuk, Hey, I'm packaging gizmod3.4 for universe, and upstream's provided a udev file he's like included http://gizmod.svn.sourceforge.net/viewvc/gizmod/dist/debian/gizmod.udev?view=markup (other packaging there is half mine, all old and irrelevant) I know nothing about udev and someone suggested I talk to you about this.
<Keybuk> PriceChild: well, the udev file is bogus
<Keybuk> event is already handled by our default rules
<Keybuk> quite why he wants them owned by group "admin" I have no idea
<PriceChild> Keybuk, mind if i invite him in...?
<Keybuk> sure
<Keybuk> DOKO!
<Keybuk> DEBUG:root:python-distutils-extra: ubuntu is 1.91ubuntu3
<Keybuk> DEBUG:root:python-distutils-extra: debian is 1.91ubuntu3
<Keybuk> DEBUG:root:python-distutils-extra: base is 1.90 (1.91 wanted)
<Keybuk> ...
<Keybuk> can anyone see what happened here? :P
<Keybuk> elmo: I thought the Debian archive prevented that?
<elmo> prevented what?
<doko> Keybuk: I'll have a look, but python-distutils-extra wasn't my invention
<flithm> PriceChild: hey I just got your email
<Keybuk> doko: I'm not blaming you, Sebastian Heinlein <glatzor@ubuntu.com> uploaded it- just alerting you because it's python-*
<elmo> Keybuk: I don't reject stuff with 'ubuntu' in the version, if that's what you mean, I looked at it, but it would have caused a lot of rejections of existing packages
<Keybuk> elmo: ah, ok
<pitti> seb128: hm, I never heard about this thing
<Keybuk> (this really screws up MoM :p)
<PriceChild> Cool flithm, keybuk's here if we can figure out how we can do what you want to do?
<flithm> cool
<flithm> Keybuk: so adding a udev rule into the deb isn't a good idea?
<Keybuk> flithm: that udev rule isn't a good idea
<Keybuk> udev rules in debs are ok
<Keybuk> just that rule is wrong Wrong WRONG! :p
<flithm> Keybuk: okay, so what's the best thing to do... my original idea was to create a separate group that allows read access to /dev/input/event* and then add the current user to that group.   Ultimately I think that'd be better.
<flithm> but do you have any ideas?
<Keybuk> flithm: what does your program do?
<Keybuk> I assume it doesn't work when X is running?
<flithm> Keybuk: it does.  It allows scripting of input events, and supports all sorts of input devices.  Ie use a usb dial, or foot switch to change virtual desktops, or scroll firefox, that kind of thing.
<Keybuk> flithm: is it only intended to be run under X?
<flithm> Keybuk: no it's meant to run under both X and console
<flithm> but most people run it under X
<Riddell> bdmurray: able to test bug 17595?
<ubotu> Launchpad bug 17595 in hwdb-client "failure to parse xorg output leads to a hung gui." [Undecided,Fix committed] https://launchpad.net/bugs/17595
<Keybuk> flithm: ACLs are probably the best solution
<flithm> Keybuk: you mean posix file system ACLs?  or some sort of crazy udev thing I'm not aware of.  If you mean file system stuff that's really not a good.  They'll need to be reset every time the user restarts udev
<Keybuk> nobody restarts udev :p
<flithm> Keybuk: when you restart your computer you do
<pitti> seb128: so, I have used evolution for 20 minutes now, and wrote down a list of usability things which make it inefficient for me
<Keybuk> current plan is to deprecate "access to particular devices" groups
<Keybuk> especially things like plugdev
<seb128> pitti: excellent ;-)
<pitti> seb128: where do you think should I discuss this? create upstream bugs for each item?
<Keybuk> and instead set ACLs on the devices for the individual users that can use them
<Keybuk> e.g. "the set of users currently logged in on a console"
<seb128> pitti: can you copy it somewhere for me so I can tell you what is already known, etc
<flithm> Keybuk: nice that sounds ideal... how are the acls made to be permanent?  some sort of script that runs after udev starts?
<Keybuk> flithm: HAL/udev/DeviceKit will set them
<bdmurray> Riddell: there are a couple of more people on the SRU team now
<bdmurray> but I'll do that one
<flithm> Keybuk:  right now I am just hoping to find a way to let users install gizmod without having to manually create a udev rule.  Whatever the best method is, I'm all for it... if it's udev or ACLs, no matter to me.  Is it possible to get the deb file to set the current user to have read / write perm to dev/input/event*?
<Keybuk> flithm: in the short term, a "gizmod" group would probably suffice
<pitti> seb128: I created https://wiki.ubuntu.com/MartinPitt/EvolutionMailUsability
<seb128> pitti: thanks
<flithm> Keybuk: yeah I just looked and it appears as if ubuntu defaults to having ACLs turned off on the root partition anyway... so for now is creating a group, adding the current user, and applying a udev rule that uses the group gonna be okay?
<Riddell> bdmurray: ooh?  who's new?
<pitti> seb128: it can be summarized as 'keyboard shortcuts suck' and 'not enough space for email content (smaller fonts)'
<seb128> pitti: what is the smaller fonts about? text inside the preview area? or widgets?
<Keybuk> flithm: /dev is its own tmpfs
<seb128> pitti: about "no easy way to switch between a large mail list, and a small list and viewing the email in a large window", enter and ctrl-W?
<Keybuk> flithm: as long as it's a unique group, and not abusing the admin group, it's ok
<pitti> seb128: the control elements are ok, and I guess if evo would have the two modes between "select email from a list" and 'view email in large window' the font size doesn't matter so much
<bdmurray> Riddell: pedro and ogasawara
<pitti> seb128: let me try
<Riddell> bdmurray: groovy
<pitti> seb128: yeah, I think that will do
<seb128> pitti: "does not remember changed column width; date uses 1/3 of the width, and is mostly empty, and space for subject is too small; changing this permanently is impossible"? are you sure
<flithm> Keybuk: cool... yeah a unique group is best, I just didn't know how to put that into the deb build script
<pitti> seb128: I tried it several times
<Keybuk> flithm: addgroup --system in your postinst
<flithm> PriceChild: do you know how to add a group and add a user to that group in the build scripts?
<seb128> pitti: it doesn't share the settings between boxes so you have to do it once for every single box which is grrrr, but then it should be ok
<pitti> seb128: I'll remove the view mode item from the list then, thanks for the hint
<seb128> box = folder
<flithm> Keybuk: cool thanks
<pitti> seb128: ah, indeed; that's it
<pitti> seb128: modifying that, too
<seb128> pitti: note that pressing "space" do "scroll to the bottom of mail and jump to next unread mail (different folder if all the mails in the current one are read) then"
<seb128> pitti: so theorically you just have to keep pressing space to read everything
<pitti> seb128: right; I think this could be subsumed under the 'cannot reorder folders' point then
<seb128> s/to the bottom/jump a page/ rather
<pitti> seb128: I don't always read all the mails in a folder to get to the next one, though
<seb128> thanks for the list, there is some valid points there
<seb128> the "one key without modified" thing is unlikely to be changed, the other ones are mostly valid ones I think
<pitti> seb128: updated the list
 * seb128 hugs pitti
<pitti> seb128: I think the default bindings are ok and Gnomeish
<pitti> seb128: but I'd like to configure my own, with the option of not using modifier keys
<seb128> right, that's basically down to "evolution still use bonobo instead of GTK"
<seb128> once it'll use GTK modifying the menu keybindings will work like in any other GNOME application
<pitti> seb128: let me add some proposals how these things could be addressed
<PriceChild> flithm, not yet but I will in a little I'm sure ;) So we're still using some sort of udev?
<pitti> seb128: page updated
<flithm> PriceChild: yeah Keybuk suggested it's the best short term solution... but we can't abuse the admin group
<PriceChild> flithm, ok so get the udev file sorted and I'll get it going. (I don't think we can get the user automatically added to the gizmod group, but perhaps we could provide some sort of hint that it should be done somewhere)
<flithm> PriceChild: okay sounds good, I'll post up a new udev file... let's go with the "gizmod" group?
<seb128> pitti: do you have a way to trigger the 100% CPU usage?
<pitti> seb128: unfortunately not
<nakeee> there is a bug, in gdm 2.20 when ipv6 enabled and you are on ipv4
<pitti> seb128: when I have, I'll create a proper bug report; don't worry about it for now
<nakeee> the get host addr call fails
<seb128> pitti: ok, same for the trash not working? ;-)
<nakeee> should I create a bug report about it?
<pitti> seb128: well, that still happens
<seb128> nakeee: I think there is a bug in launchpad about that
<PriceChild> flithm, cool. Little busy atm but should be able to work on it in a short while. Will check svn for new udev file
<seb128> pitti: what do you try to do and what happens?
<flithm> PriceChild: I'll send you a message, i gotta take care of a few things first too
<seb128> pitti: do you try to press delete with mails in the trash selected?
<pitti> seb128: I deleted a few mails with the Delete key, they land in "Trash"
<pitti> seb128: right-click on Trash, "Empty trash", doesn't work
<pitti> seb128: neither does the menu item in "File"
<seb128> hum, k, weird
<seb128> any error on the command lineÂ§?
<nakeee> seb128,  I created a patch that seems to fix it
<nakeee> seb128, do you know where the bug is? I can't find it..
<nakeee> it's funny I reported that bug in debian on gdm 2.18
<seb128> nakeee: no, just read some comment about that in the thousand of desktop mails I get every week
<nakeee> I don't see it, oh well on the worst case it will be another double bug
<seb128> nakeee: let me have a look
<seb128> way to much bugs there :(
<seb128> nakeee: in fact I think that was the current comments on https://bugs.edge.launchpad.net/gdm/+bug/75254
<ubotu> Launchpad bug 75254 in gdm "XDMCP not working in ipv6, gdm should be compiled with --enable-ipv6=yes" [Low,Fix released]
<bddebian> Too many bugs period :-(
<pitti> seb128: no, nothing on command line
<nakeee> seb128, yea that from 2.18 I reported it then and they fixed it
<nakeee> seb128, it reappeared in 2.20:)
<seb128> nakeee: could you open a bug upstream rather if you have an account on bugzilla?
<seb128> nakeee: otherwise we will just act as a gateway and forward your comments and upstream comments which creates extra work and doesn't bring lot of value
<nakeee> why does no one make a bugzilla that support openid..
<pitti> ArneGoetje: can I leave the ttf-arphic-uming merge to you?
<seb128> mjg59: could you try to send GNOME patches you work on upstream? that would avoid us rant like the gnome-power-manager one on planet gnome
<mjg59> seb128: I've already replied to Richard. To the best of my knowledge, all the others have been Ubuntu-specific integration.
<seb128> mjg59: right, there is very few patches not sent upstream he just picked on specific example
<mjg59> That one was an oversight - I wrote it against a development version and thought it had already been fixed upstream
<seb128> ok
<seb128> I mentioned it because we also have a bunch of gnome-control-center patches you wrote which have not been sent upstream (the synaptic one)
<mjg59> Yes, that's not mergable
<seb128> arguably they are not upstream material but GNOME guys like to have those in bugzilla anyway so they know what distros are doing and can comment
<mjg59> I'd really rather that didn't go to bugzilla - it'll just encoruage other people to ship it
<mjg59> At which point it becomes much harder to fix it properly
<seb128> alright
<mjg59> I'm working on this with X upstream
<seb128> mjg59: maybe you could blog respond to the post since you are also on planet gnome? All the distros have quite some patches and some not sent upstream for whatever reason would be nice to point there ;-) I'll do post after diner maybe if you don't
<seb128> anyway dinner time for now
<mjg59> seb128: I've commented on the post
<seb128> not sure many people read the comment but right
<seb128> thanks
<Keybuk> env AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic  1935.23s user 303.32s system 95% cpu 39:03.72 total
<Keybuk> oh, that's just taking the piss
<Keybuk> my laptop took close to 4 hours to build the exact same kernel image
<giskard> oboe@oboe-laptop:~$ aumix
<giskard> The program 'aumix' can be found in the following packages:
<giskard>  * aumix
<giskard>  * aumix-gtk
<giskard> Try: sudo apt-get install <selected package>
<giskard> bash: aumix: command not found
<giskard> this is a impressive feature
<Keybuk> jcastro: don't suppose you can remember whether the newest items in an RSS feed are at the top or at the bottom? :p
<jcastro> top usually
<Keybuk> wow
<Keybuk> Google didn't respond ... my first reaction was to check my internet connection
<ion_> Heh
<amitk> Keybuk: get Intel to send you one of their software development platforms. Rumor is that they do one flavour in 17 minutes
<YokoZar> jcastro: sup
<jcastro> YokoZar: hi!
<YokoZar> jcastro: so, let's talk team formation.  The first step is pointing me to a good wiki template
<YokoZar> Actually, I do need to get the BetterIntegratedWineSpec ready for review too
<jcastro> YokoZar: gimme 5 minutes, gotta shift gears to get you all set.
<jcastro> YokoZar: see pm
<YokoZar> By the way, Valve tells us that at least 10 thousand Steam users are using Wine at this point.  They just started a new survey, so there'll be more accurate data in a week or so.
 * ajmitch wonders how many WoW players are using wine :)
<YokoZar> ajmitch: I would guess at least 30k, given that WoW is about 3x as popular (3 million monthly users for Steam, I think there are about 9 million WoW players)
<jcastro> YokoZar: are you getting my pm's?
<YokoZar> In IRC?  no.
<jcastro> is there an #ubuntu-wine or something where we could do this?
<YokoZar> Yes, join it
<jcastro> cool
<mdke> has anyone used the gutsy installerfor a thinkpad t43? It seems to hang at the partition stage - gparted also just keeps scanning for devices continuously and I can't find /dev/hda or /dev/sda in order to try fdisk
<mdke> ah, gparted has finished now with "no devices detected"
<mdke> if anyone can give me a tip for debugging I'd be grateful. Otherwise I'll file a bug
<norsetto> !support | mdke
<ubotu> mdke: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
<elmo> *giggle*
 * mdke slaps elmo 
<mdke> ok, tail -> legs
<elmo> well.. I was about to try and help you, but if you're going to be like that...
 * mdke hugs elmo
<elmo> mdke: well, I was kinda lieing, I'm probably not all that useful; but check dmesg for any mention of 'ata' 'sda' or 'ide', case insensitively?
<mdke> elmo: yes,ata
<elmo> pastebin?
<soren> ajmitch: You've put yourself as maintainer of libvirt rather than motu or core-dev.. Does that mean that I can just tell you to go update it, or will you now claim it was a mistake? :)
<mathiaz> doko: Are you planning to merge nfs-utils soon ?
<ajmitch> soren: that pre-dates the general (required) practice of using the teams as maintainers
<ajmitch> it's already been updated by others anyway
<soren> ajmitch: Alright. Should I change the maintainer, then?
<ajmitch> if you wish
<ajmitch> since I haven't touched it for awhile
<soren> ajmitch: Will do.
<keescook> archive admins: I've sub'd you to 160454.  I'd like to get wider testing for the pcre update before rolling it out for real.  Can you approve the dapper/edgy/feisty/gutsy-proposed uploads?
<keescook> cjwatson: ^^ if you're still awake.
<soren> keescook: Er.. It's a security update, isn't it?
<keescook> soren: yes, but I'm putting it into -proposed first to get more testing.
<soren> That bad, huh?
<keescook> it's a major version upgrade, so ... yeah.
<soren> erk.
<keescook> on the plus side, it's ABI compatible.
<keescook> all my testing shows it as happy, but I just want To Be Sure.
<ajmitch> it'd cause some issues if it weren't
<keescook> understatement of the year.  ;)
<ajmitch> soren: I understand you're going to do a bit with libvirt & co then?
<soren> ajmitch: I might :)
<soren> ajmitch: Someone will. I'm doing it right now.
<ajmitch> right, I saw the ad
<soren> ajmitch: Ah, I was just about to mention that.
<ajmitch> 'virtualisation specialist' seems to cover a bit more than virtualisation there :)
<Nafallo> :-)
<cjwatson> keescook: awake but buried in other stuff and probably best not to get sidetracked or I'll never get to sleep ...
<cjwatson> (sorry)
<keescook> cjwatson: okay, no problem.
<cjwatson> mdke: fwiw it's not gparted any more, hasn't been since feisty
<ajmitch> though I see there's a subsequent server developer position that seems to cover much of the same
<Mithrandir> keescook: I'm not here, but I'll poke at it for you anyway.
<keescook> Mithrandir: heh, thanks.
<Mithrandir> keescook: we don't really have a policy for how to do those kinds of things.  Want to make up a policy here and now?
<keescook> Mithrandir: sure... closest to this has been the firefox updates (new origs) and the mozilla 1.5 dapper update (new major version)
<Mithrandir> "If a security update includes major version updates, it should, if possible, go to -proposed first for testing.  Any upload by a security team member to -proposed for a security vulnerability it will get accepted immediately without ack from -sru in a similar fashion to regular security fixes being installed into -updates without further ado"?
<keescook> Mithrandir: sure, that reads well.  Should I add that to the SRU or the SUP wiki?
<soren> Mithrandir: s/vulnerability it will/vulnerability will/
<Mithrandir> soren: sure.  I was just typoing it out over a lossy and slow SSH link.
<Keybuk> http://patches.ubuntu.com/patches.xml
<Keybuk> ^ \o/ that actually seems to be working
<soren> Keybuk: Ooh! Shiny!
<Mithrandir> keescook: sure.  And mail -devel, I suppose
<Keybuk> except the links are wrong, oops
<soren> Keybuk: Well... except that the links don't work?
<soren> Keybuk: :)
<Keybuk> and they're in the wrong order
<soren> Keybuk: Would it be much extra work to add an rss feed of atomic/ubuntu ?
<Keybuk> soren: the plan is to have an rss feed of most things
<Keybuk> though I need to know what things to put *in* the rss feed ;-)
<Keybuk> ie. what to link to
<soren> Keybuk: Well, in the case of the atomic patches that's straightforward, right?
<soren> Or am I missing some detail here?
<Keybuk> well
<Keybuk> by-release/atomic is I guess
<Keybuk> the rss feed should probably be per-package though, not global, right?
<soren> Hm... Per package would probably also be useful, but I actually meant global.
<soren> It would be like the hardy-changes rss feed Seveas maintains, only better.
<Seveas> so I can finally get rid of it? :)
<Keybuk> we already have pretty much that in ubuntu-patches@lists.ubuntu.com
<Keybuk> :p
<soren> Keybuk: That doesn't send out the atomic diffs, does it? It sends what's in by-release/ubuntu ?
<slangasek> email2rss2email
<Keybuk> soren: sends out atomic diffs except at -1 time
<soren> Keybuk: Oh. I just picked a random e-mail from that list and it said it contained the diffs from the base Debian version, but now that I look more closely that is indeed only in case of an ubuntu1 revision. That's *exactly* what I was looking for.
<Keybuk> what's a good name for such things
<Keybuk> "subscriptions" sounds wrong
<Keybuk> syndicate! :p
<soren> Er.. In which contexT?
<Keybuk> just a name for the python program
<soren> Ah.
<ivoks> pysub :)
<soren> wibble.py?
<soren> patchfeed.py?
<Mithrandir> keescook: accepted.all accepted.
 * keescook hugs Mithrandir
<Mithrandir> keescook: happy to help, hopefully it all works out fine.
 * keescook holds on to his hat
<Mithrandir> and with that, I'm off to bed.
<LaserJock> _MMA_: ping
<_MMA_> LaserJock: Yo
<LaserJock> _MMA_: got it :-)
<_MMA_> w00t!! Hooray for UPS! :D
<Keybuk> http://patches.ubuntu.com/patches.xml
<Keybuk> ^ there, that should work better
<Keybuk> (note: sample data :p)
<Keybuk> there's also http://patches.ubuntu.com/by-release/atomic/patches.xml now
<Keybuk> for comparison
<soren> Rock!
<Keybuk> oops
 * Keybuk stops spamming the Debian PTS
<Keybuk> la la la
<Keybuk> http://patches.ubuntu.com/by-release/atomic/ubuntu/d/dpkg/patches.xml
<Keybuk> ^ per-package rss feeds
 * Keybuk taps the data centre
<Keybuk> err, hawlo?
<Keybuk> elmo: DISPATCH WAR ROCKET AJAX
<elmo> Keybuk: err?
<Keybuk> it's back :)
 * Spads throws a rock on Keybuk 
<elmo> yahuh
<soren> Keybuk: You're still just testing this with a few packages, correct?
<Keybuk> yup
<soren> Keybuk: Ok.
<Keybuk> http://patches.ubuntu.com/by-release/ubuntu/a/apt/patches.xml
<Keybuk> ^ by-package ubuntu->debian packages.xml
#ubuntu-devel 2007-11-15
<doko> mathiaz: I have "some" merges outstanding, so please go ahead with anything (just drop me here please)
<superm1_> is there a summary of the build chain changes and ramifications of these changes for hardy anywhere?
<superm1_> because it appears that builds have added "-fvisibility=hidden -fvisibility-inlines-hidden" and caused a few FTBFS's on a few of my uploads
<cjwatson> superm1_: there are *plans* to change default gcc options, but AFAIK they haven't been implemented yet
<cjwatson> I suspect the changes are in fact in one of your build-deps, perhaps pkg-config files?
<superm1_> cjwatson, hm interesting.  i wonder how those snuck in then
<superm1_> i'll have to poke a little closer in a local pbuilder then
<soren> cjwatson: Well, we switched to gcc-4.2, which meant a few things changed.
<cjwatson> ok, true, the compiler defaults might be different, but you'd see that locally as well
<soren> point
<soren> superm1: http://gcc.gnu.org/gcc-4.2/changes.html says something about C++ visibility changes.
<superm1_> soren, do you know offhand what revision of gcc we were on before?
<cjwatson> 4.1
<cjwatson> specifically 4.1.2
<superm1_> ah okay i see then
<superm1_> i'm going to have to poke upstream a bit about this then
<TheMuso> c
<TheMuso> ugh wrong tab
<ion_> d
<amitk> e
 * Hobbsee waves
<mpt> imbrandon, siretart, hi, I notice you're involved with ubuntuwire.com
<mpt> Have you been keeping track of <https://wiki.ubuntu.com/QATeam/Specs/DeveloperWeatherReport>?
<ajmitch> and there are a number of existing tools for universe that are now linked from qa.ubuntuwire.com
<imbrandon> mpt: somewhat yes
<imbrandon> mpt: it should be trivial to do that with qa.ubuntuwire.com honestly
<imbrandon> well most of it
<imbrandon> mpt: getting stgraber to work with us on some of the qa pages might be interesting too, just havent found the time to email her
<cjwatson> stgraber looked male when I saw him in Cambridge
<imbrandon> with a name like "StÃ©phane" i assumed female but ive been very very wrong in the past
 * Hobbsee resists the urge to comment
<cjwatson> imbrandon: it's a masculine name in French
<imbrandon> ahh see , very very wrong again :)
<cjwatson> StÃ©phanie would be female
<imbrandon> ahh
<LaserJock> imbrandon: I did the same thing
<ajmitch> Hobbsee: why? :)
<imbrandon> i hate assuming gender online anyhow, not that it matters either way imho
<cjwatson> true
<Hobbsee> ajmitch: well, "i expected you to be big and curvy" is coming to mind, but i've *no* idea why that might be... :)
<imbrandon> i hate to ask
<ajmitch> Hobbsee: hehe :)
<Hobbsee> ajmitch: unfortunately, i lose all respect for people when they start hitting on me, at their second phrase.
<ajmitch> no need to ask why, there
<imbrandon> yea the whole "zomg pics or your a guy" thing :)
<Hobbsee> imbrandon: worse than that :)
 * ajmitch wonders how much of the developer weather report stuff has been implemented now
<imbrandon> anyhow my appolgies for the gender mistake stgraber ( if you read the backlog )
<StevenK> imbrandon: Tip: Do not assume gender with European names
<imbrandon> ajmitch: actualy looks like just some parsing and such would be needed to make it 100%
<imbrandon> 2 days worth of scripting maybe
<ajmitch> imbrandon: the 'just' is what takes time
<imbrandon> heh yea
 * Fujitsu thinks we need a DeveloperWeatherReportDevelopmentWeatherReport.
<ajmitch> reading the spec, the suggestions are that screen-scraping isn't really suitable
<ajmitch> especially if you were doing it everytime the page was hit
<imbrandon> ajmitch: yea its not BUT to get-r-done then file bugs and fix along the way ( kinda like lpusers.py )
<cjwatson> we may have to screen-scrape to start with, but it should move away from that; and any necessary screen-scraping should be done asynchronously, not per page load
<imbrandon> nah i would say a 1 or 2 time a day update
<imbrandon> yea
<cjwatson> Ubuntu days are one hour long
<ajmitch> cjwatson: with the number of resources to pull from, I don't think it'd be possible to do it per page load
<imbrandon> :)
<cjwatson> ajmitch: quite so
<cjwatson> (I'm serious with the hour thing. Around releases is when we need this sort of thing most, and 12 hour latencies are way too long then.)
<imbrandon> next question is since i'm out numbered on the UW team 3 to 1 on php vs python i guess we're going python with it ?
<Fujitsu> PHP is EvilÂ®
<ajmitch> it depends on who is going to be doing this work, and where it'd be
<imbrandon> cjwatson: well nearer it release it would be trivial to update the refresh times
<Hobbsee> cjwatson: just implement it in LP, and watch it all break :)
<Fujitsu> cjwatson: Even an hour is annoying at times.
<Hobbsee> but hey, at least it's instant!
<Fujitsu> Hobbsee: It won't break; they have code review.
<Fujitsu> [insert eye-rolling here]
<cjwatson> Fujitsu: if it's anything to do with the archive, frequencies shorter than an hour are largely pointless
<Hobbsee> cjwatson: unapproved queue.
<StevenK> I recall saying that to cprov at UDS.
<Fujitsu> I'm thinking bugs and stuff, but true.
<Fujitsu> StevenK: What?
<StevenK> "Why do you try and rebuild DEPWAIT every ten minutes?"
<imbrandon> ajmitch: i would say we atleaste start something on qa.ubuntuwire.com/{weatherreport} ? and if it needs to be moved that shouldent be much of an issue
<Fujitsu> Aha.
<imbrandon> ajmitch: since its in place ~now~
<ajmitch> imbrandon: alright
<Fujitsu> Isn't there already somebody working on it?
<cjwatson> Hobbsee: ok, anything after the publisher then
<Hobbsee> cjwatson: yes, then i agree with you :)
<StevenK> Fujitsu: I think pitti and I convinced him that an hour or a bit more would be more suitable.
<cjwatson> Fujitsu: certainly somebody on Henrik's team was due to be working on it, IIRC Leann
<Fujitsu> StevenK: Thankyou.
<Fujitsu> cjwatson: That's what I thought.
<cjwatson> ogasawara: ^--
<ajmitch> cjwatson: so it'd be unnecessary duplication if we were to develop something?
<cjwatson> well, it'd be nice to at least talk to the person assigned to it ;-)
<imbrandon> or should we rope Leann to see what she has done and where and help
<imbrandon> right
<ajmitch> given that we already have a few tools for universe :)
<imbrandon> brb mt dew time
<ajmitch> I thought you'd kicked that habit
<cjwatson> there are lots of bits to that job, so it shouldn't necessarily have to be just one person for the whole lot, I'd have thought
<imbrandon> cjwatson: yea thats my thoughts too
<imbrandon> even the current qa.uw.c page is bits from all over
<imbrandon> anyone know the Leann's $time-of-day ? guess i could look on LP
<cjwatson> BTW the bugs URLs on qa.uw.c should be bugs.launchpad.net rather than launchpad.net really
<ogasawara> I'm here :)
<cjwatson> (both work at the moment)
<StevenK> imbrandon: She's GMT-7
<ogasawara> cjwatson: was just about to ping you about the developer-weather-report
<ajmitch> ah, hello ogasawara
<imbrandon> easy nuff to fix, the site is in bzr , i'll make the change once i grab a dew
<imbrandon> heya ogasawara
<cjwatson> ogasawara: hmm, I wonder why Henrik isn't the approver. Maybe a holdover from Seville
<StevenK> ogasawara: Hey! How was your flight back?
<cjwatson> I think I'll punt it in his direction
<ogasawara> cjwatson: probably, so who do I go to for review and approval?
<ogasawara> StevenK: flight back was good.  it's nice to be home
<cjwatson> *clicketyclick* Approver:    Henrik Nilsen Omma
<StevenK> ogasawara: Agreed.
<cjwatson> ^- him :)
<ogasawara> cjwatson: ok thanks
<TheMuso> cjwatson: I see that there is no document on the wiki for the bootloader review spec yet. I have found out what starts the at-spi registry daemon, and have found where in Ubiquity you start gnome-settings-daemon et al. The accessibility scripts for casper will also need to be altered, to work with the only-ubiquity option.
<TheMuso> cjwatson: Since the spec isn't up, where do you want me to document all of this?
<cjwatson> TheMuso: it's still on a piece of paper on my desk, can you wait a bit?
<TheMuso> cjwatson: Certainly.
<cjwatson> I should have it done once I finish $customer_project and performance reviews
<imbrandon> ogasawara: ok so i guess its down to we have qa.uw.c and would love to either a) help you with ubuntu-weather-report or b) ummm yea we should get togather and drum something up so we dont have to dupe efforts
<imbrandon> that and i'm sure you would welcome some help :)
<ogasawara> imbrandon: I welcome all the help I can get :)
<TheMuso> cjwatson: I'm subscribed to the blueprint anyway, but thought you may have had it in a digital format somewhere...
<ogasawara> imbrandon: https://wiki.ubuntu.com/QATeam/Specs/DeveloperWeatherReport
<cjwatson> TheMuso: sadly not yet due to Broadcom pain at UDS
<ogasawara> imbrandon: that's all the info from UDS
<TheMuso> cjwatson: Understandable. I'll wait, and add when the chance allows.
<cjwatson> thanks, I'll try to remember to let you know
<cjwatson> though if you're subscribed to the LP spec I think it should notify you
<TheMuso> cjwatson: No problem, I'll see changes to the spec anyway.
<TheMuso> Considering all other specs I'm subscribed to have notified me, I think there will be nothing to worry about.
 * Hobbsee despams ubuntu-devel again.
<Keybuk> (gdb) printf "%d\n", siginfo._sifields._sigchld.si_status >> 8
<Keybuk> 17
<Keybuk> gnargh
<Keybuk> NOW WHY ARE YOU PUTTING THE SIGNAL THERE YOU FUCKER?!
 * StevenK waits for his ears to stop ringing
<stgraber> imbrandon: :)
<Keybuk> I hate the kernel
<Keybuk> I really, really, do
 * desrt switches Keybuk to decaf
<Fujitsu> Thankyou desrt.
<StevenK> Bwaha
 * TheMuso wonders why some of the folks from Canonical who are based in the UK are up so late/early.
 * Keybuk amends his "Cool testing techniques in Upstart" presentation slides to include the percentage of KERNEL code that's covered by them too
<StevenK> TheMuso: "Jetlag"
<TheMuso> StevenK: Thats one thought that crossed my mind, but I am not entirely convinced thats the whole story. :p
<StevenK> TheMuso: "Commitment" ? :-)
 * Fujitsu thought the usual excuse was `dedication' or `commitment', yes.
 * StevenK sighs.
<StevenK> Helix, have you people not heard of $(MAKE) -C ?
<dholbach> good morning
<LaserJock> morning dholbach
<dholbach> hey LaserJock
<warp10> Hi all!
<pitti> Good morning
<Hobbsee> guten tag pitti, wie gehts?
<pitti> Hobbsee: prima, danke! *umarm*
<Hobbsee> pitti: :D
<StevenK> Gasp. I think I understood that
<Hobbsee> pitti: * umarm * zu Ihnen auch
<pitti> Hobbsee: "Du"! I always hear a cracking in the back when someone calls me "Sie" :)
<Hobbsee> pitti: hehe :)
<Hobbsee> pitti: unless you're multiple people's worth, which is what i used, yes
<pitti> Hobbsee: no, it's grammatically correct; "Sie" is not just plural (that would be "sie"), it's the polite addressing between adults who don't know each other very well
<Hobbsee> pitti: must be just me hugging you and dholbach.
<Hobbsee> pitti: indeed. i didn't use Sie :).  Although i was going to hug you singularly, not you plural.
<pitti> Hobbsee: you used "Ihnen" :)
<Hobbsee> i thought that was plural du.
<Hobbsee> or plural you's.  i wasnt aware that there was a formal and non-formal form of ihnen.
<Hobbsee> (or, ihr)
<StevenK> Way cool. German Semantics
<Hobbsee> StevenK: yeah.  nad they say english is screwed.
<Hobbsee> StevenK: we dont have 4+ forms of the word "you".
<Keybuk> traditionally, we do
<StevenK> German generally doesn't steal words from English and subsume them.
<Keybuk> we just eliminated them because we bought foreign printing presses
<Hobbsee> Keybuk: thank goodness for that
<Hobbsee> er, technically 4 versions of the same word, based on how you're using it.
<StevenK> English can do the same with tenses and such
<Keybuk> you, ye, Ã¾ou, Ã¾ee
<Keybuk> iirc
<StevenK> See also 'resent'
<Hobbsee> didn't think it was every word, though :)
 * Hobbsee just remembers the important parts of german - like, how to curse people in it :P
<Keybuk> ironically, the four forms of "you" are coming back into fashion
<Keybuk> mostly for effect
 * Hobbsee hasnt seen them
<Hobbsee> maybe being isolated has it's advantages.
<Keybuk> you've obviously seen "you"
<Keybuk> the generic one
<Hobbsee> i meant the rest.  you're feeling pedantic today, i see :P
<Keybuk> you've probably also seen the informal pair
<Keybuk> "holier than thou"
<Keybuk> "spake until thee"
<Keybuk> ye is rarer, e.g. "hear ye, hear ye"
<Hobbsee> "smite thou with a stick, until thee GTFO".  ja.
<StevenK> Does 'thine' also fit in that mold?
<Keybuk> thine is to thou as mine is to me
<StevenK> Fairy nuff
 * Hobbsee now recalls hating english.
<Keybuk> thou, thee, thy, thine
<StevenK> Only now, you say?
<Keybuk> ye, you, your, yours
<Keybuk> I, me, my, mine
<Hobbsee> StevenK: heh.  i thought you knew about our english courses.
<mdke> cjwatson: right. I mean I tried gparted too
<Keybuk> interestingly the english formal "you" has the same prone-to-plurality problem as the german formal "sie"
 * StevenK sobs as he straces python
<mdke> cjwatson: it doesn't seem to be an installer issue at all, Ubuntu just doesn't recognise my hard drive...
<pitti> Keybuk: do you think there is any sense in merging initscripts? we now carry patches (nfs-utils) which only adjust the dependency to initscripts for our old version number
 * dholbach just fixed http://people.ubuntu.com/~dholbach/sponsoring/ again - the "responsible" section should finally be fixed
<superm1_> hi dholbach
<dholbach> hey superm1
<dholbach> how's it going?
<superm1_> very sleepless.  since UDS, i've had very little time to rest
<dholbach> superm1_: I hope it won't be long until you can get back to a more normal schedule again?
<superm1_> dholbach, well its the end of the term, so this is how it would be getting either way with projects and such needing to wrap up
<superm1_> so another 2 or 3 weeks :)
<dholbach> ugh
<superm1_> dholbach, i was going to ask you, at UDS when you were talking about packaging, you were deleting entire words in your terminal really fast.  How were you doing that?
<dholbach> slomo, asac, calc, doko_, pitti, asac, server guys (kees, soren_): there are a bunch of reviews for you on http://people.ubuntu.com/~dholbach/sponsoring/
<pitti> dholbach: ah, noted; thanks
<dholbach> superm1_: alt-backspace?
<superm1_> dholbach, ah is that it!?
<superm1_> very cool
<slomo> dholbach: will take a look later, thanks
<dholbach> superm1_: nice :)
 * dholbach hugs slomo and pitti
<dholbach> you guys ROCK
<superm1_> while pitti is in here, there is an SRU I uploaded during UDS that is still waiting to be released into proposed, can you do that?
<superm1_> for mythtv on gutsy
<MacSlow> Greetings everybody!
<pitti> hey MacSlow
<MacSlow> Tag pitti
<MacSlow> pitti, the article you posted to the list about usability is indeed a good read
<pitti> thanks
<MacSlow> pitti, some of the severe issue stated there are not directly in the control of distro people though... but rather upstream... mostly Xorg
<pitti> MacSlow: I wonder whether we can do something about the compiz flickering, though, with the solution he mentioned in that article
<pitti> I noticed the flickering, too, and indeed it spoils the experience a bit
<MacSlow> that's why "we" should help getting more capable coding-hands involved into Xorg-work
<pitti> (and this is a brand new laptop, no ancient hardware, etc.)
<pitti> MacSlow: right, I understand
<pitti> MacSlow: but there are some low-hanging fruit which we should pick for hardy, I think
<MacSlow> if flickering means no-sync-to-vblank... then we'll have to wait for some stuff to land in Xorg
<pitti> Interestingly I have exactly the same feeling about wasted panel space, I always merge the two panels, too
<MacSlow> pitti, yes... the order of shutting down processes on logout... make compiz exit last so compositing stays alive as long as possible
<pitti> if this is a more widespread phenomenon we should ponder changing it by default maybe
<pitti> yeah, or that
<Burgundavia> jcastro: https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00147.html
<prem> hi
<prem> I am trying to create a small application..so that I can display it under System---menu (along with Logout / Shutdown /AboutUbuntu) buttons.. I gave Categories=GNOME;GTK;Core; ...But still I can see my application under the menu..
<prem> what can be the reason..can anybody guide in this..
<prem> how can I make my application to display there under System menu..
<Burgundavia> prem: this is really an upstream issue. I would ask on #gnome-hackers on GIMPnet
<prem> Burgundavia: oooh..I asked in gnome-dev before..but they people told its impossible to add anything there..But in our Ubuntu..we have "About Ubuntu" option added..So I thougth I would ask here to our people..
<Burgundavia> prem: I think the system menu is hard coded
<Burgundavia> however, I am certain upstream would accept patches to make that not so
<Burgundavia> I should clarify that
<Burgundavia> you can add stuff to the admin and preferences submenus
<Amaranth> 'About Ubuntu' is a patch to the panel code
<prem> ooh..with gnome-panel ...
<prem> and one more thing..is it possible to display the "system tray icon " of the update manager as a super user..?I can see it in my panel only as a normal user..is there any specific settings for that to view as a super user also..
<dholbach> slangasek, TheMuso, siretart, lool, asac, calc, doko_, asac, server people (kees, soren): I just subscribed you to a bunch of bugs: http://people.ubuntu.com/~dholbach/sponsoring/ - thanks :-)
<siretart> dholbach: k. thanks
<dholbach> thanks siretart :)
<siretart> dholbach: how often is http://people.ubuntu.com/~dholbach/sponsoring/ updated?
<TheMuso> dholbach: np. Will take a look.
<dholbach> siretart: every 30 minutes
<soren> Could someone with archive admin powers give the binaries from gtk-vnc some love?
<dholbach> seb128: ^ did you convince soren to become part of the desktop team? :-)
<soren> :p
<seb128> soren: doing it
<soren> virt-manager needs it :)
 * soren hugs seb128 
<seb128> soren: done, will be available for the next publisher run
<soren> seb128: Excellent! Thanks a bunch!
<seb128> soren: you're welcome
<Amaranth> seb128: Are you a person to talk to if I want the emerald-themes package from feisty pulled into hardy? It got removed in gutsy and shouldn't have been
<seb128> Amaranth: no, you simply need a MOTU to upload it to hardy for you
<Amaranth> Well, I could do that :P
<seb128> easy then ;-)
<Amaranth> I figured since it was already in the archive it would be easy to just pull in
<Amaranth> Since nothing has changed
<soren> I'm looking at bug 130836. It adds some openoffice icons to apache for directory indices. The text in debian/copyright will read: "These icons are trademarks of Pete Harlow. Permission to use and/or modify these images is granted for the identification and promotion of the OpenDocument Format (ISO 26300 and any later version published by OASIS or ISO) provided you acknowledge me, Pete Harlow, if someone asks."  Is that an acceptable license?
<ubotu> Launchpad bug 130836 in apache2 "Specify OpenDocument icon(s) in Apache2 configuration" [Wishlist,Triaged] https://launchpad.net/bugs/130836
<soren> It's funny how you feel more and more confident about most things the more you do them. The more I deal with licenses and such, I get more confused and less confident.
<Burgundavia> soren: at a quick reading, and IANAL, but that looks non-free
<Burgundavia> the license restricts use
<soren> Yes, it does.
<Burgundavia> ask the original author to relicense under the apache license and get them upstream
<Mithrandir> soren: as Burgundavia says: not free.  The licence also fails to grant redistribution rights (for both modified and unmodified icons)
<soren> Mithrandir: Alright.
<soren> Burgundavia, Mithrandir: Thanks.
<mvo> doko_: do you mind if I take the tar merge?
<doko_> mvo: please go ahead; not sure if that's still necessary (build using gcc-snapshot should give a hint)
<mvo> doko_: I just tested it and it seems like a small patch is still required, I will mail it to debian once I verified it
<doko_> hrm, I forwarded that to bdale ...
<mvo> doko_: http://paste.ubuntu.com/2001/ <- that one should fix it without the need for -fgnu89-inline, what do you think?
<doko_> mvo: sure, this should work as well
<mvo> thanks
<mvo> doko_: I had a brief look at curl and it seems like libcurl-gnutls does not build the sftp support. it seems that building it is ok now because libssl2 does link against libgcrypt (instead of libopenssl) in the default build. if you don't object I would like to enable sftp in libcurl-gnutls as well
<Kmos> is hardy still auto-syncing with debian ?
<Hobbsee> yes
<Hobbsee> (as per the schedule)
<Kmos> ah ok =)
<Kmos> thjx
<Kmos> thx
<siretart> pitti: is multiverse auto-synced as well? - or is that limited to universe?
<pitti> siretart: multiverse isn't autosynced
<pitti> hey siretart
<siretart> hey pitti!
<siretart> pitti: may I ask why not?
<pitti> siretart: not sure, but sync-source -a doesn't do it
<pitti> siretart: I might be able to convince it with some extra options, let me ask the elder archive masters :)
<siretart> pitti: yes, that would be great, thanks!
<siretart> else we would have to use mdt or something and would file sync requests semi-automatically, which cannot be in the interest of ubuntu-archive
<pitti> right
<Hobbsee> siretart: i'ts been done before.  *sigh*
<Hobbsee> siretart: but yes, if you want to tsay alive....
<siretart> Hobbsee: I'm not sure what you are referring to (Kmos?) - but I'm sure you understand what I meant to say
<Hobbsee> siretart: oh, indeed.
<pitti> siretart: so yes, it seems to be possible; I'll do that tomorrow on my archive day
<siretart> pitti: thanks
<Kmos> there is a mail-transport-agent (debian) in ubuntu?
<StevenK> mail-transport-agent is a virtual package
<Kmos> but it exists in ubuntu ?
<StevenK> Yes
<Kmos> ah thx.. that's to fix another bug open :)
<pitti> mvo: gnome-app-install is the only main package which depends on python-gtkhtml2 (which in turn keeps the ancient libgtkhtml2 in main); do you know about any plans to port this to 3.18?
<mvo> pitti: let me have a look
<seb128> pitti: libgtkhtml2 != gtkhtml3.n
<pitti> seb128: it's not just a newer API?
<seb128> no, those are totally different libs and don't have the same purpose
<mvo> I don't think there are python bindings
<pitti> seb128: well, both are HTML rendering engines
<seb128> I think one does editing and not the other one
<seb128> gtkhtml is what evolution uses
<seb128> when you read or compose mails
<pitti> seb128: ok
<seb128> libgtkhtml is a rendering one
<pitti> seb128: ok, so we should only aim to get rid of gtkhtml3.8 then
<seb128> yes
<mvo> pitti: the best I can offer is to port to pymozembed (if it works now - it was broken for ages)
<pitti> seb128: (which is only used by gnome-sharp2)
<seb128> that one is deprecated in favor or gtkhtml3.14 (standard version update due to ABI change)
<seb128> right
<seb128> maybe slomo knows about that?
<slomo_> one moment
<seb128> slomo: gnome-sharp2 still Depends on gtkhtml3.8, any plan to port it to gtkhtml3.14?
<pitti> mvo: well, don't worry for now; screem and gimp use the library, too (not the python bindings)
<mvo> aha, ok
<slomo_> impossible to port to gkhtml3.14 without breaking API/ABI, so no... but upstream plans to add a new gnome-desktop-sharp with contains for example a gtkhtml3.14 binding
<slomo_> only problem are then all the apps the use the old binding but once a) gnome-desktop-sharp is released and b) apps are ported it can simply be disabled from gnome-sharp
<pitti> hm, in main the users of gnome-sharp2 are f-spot, tomboy, and (still) beagle; I wonder whether they actually need the gtkhtml bindings
<slomo_> pitti: they don't... monodoc-browser needs it though (so it can be moved to universe)
<pitti> slomo_: I see; hm, doesn't help much, though, since it's still a build depends
<slomo_> pitti: we could of course create a gnome-sharp2-universe package ;)
<pitti> slomo_: yeah, with hacks like that
<ogra> fspot might need it to generate the websites in the gallery function
<ogra> mjg59, dont take all the blame on you for the brightness key patch ... i discussed it with hughsie on IRC one or two months ago (alongside with all the GINT/GUINT fuckup) i clearly missed to file an extra upstream bug about it but he cant say he wasnt aware at all
<slomo_> ogra: i might be, i don't know much about f-spot ;) at least it uses gtkhtml-sharp for something while the others dont
<ogra> was just a guess :)
<ogra> woah,  evolution --force-shutdown in gutsy kills my panels
<StevenK> It's a feature
<ogra> heh
<ogra> it didnt do any harm, just looks weird
<elmo> hmm.  'Image resolution is out of bounds'.  thanks gimp
<StevenK> elmo: Ouch. How large is that image?
<Hobbsee> elmo: how does one get the default country mirror changed?
<elmo> Hobbsee: talk to mirrors@ubuntu.com - but bring some evidence, as it's often not at all clear what the best choice for a country is
<Hobbsee> elmo: right, OK
<Hobbsee> elmo: thanks
<elmo> StevenK: 1024x685 (sic)
<seb128> elmo: the evolution and panel bug is known and fixed upstream already (maybe also in gutsy-proposed, not sure now)
<elmo> seb128: blink?
<StevenK> Blink. You'd think GIMP could handle that.
<StevenK> seb128: You missed. You want ogra
<seb128> elmo: sorry, that was for ogra
<elmo> ah, right
<seb128> StevenK: right
<ogra> seb128, ah, thanks ...
<seb128> StevenK: BTW could you have a look to the gimp merge? ;-)
<ogra> its not *that* important, doesnt do any harm ... just looks a bit weird ...
<StevenK> seb128: Sure. After I wake up
<seb128> StevenK: "what up", in what timezone are you now? ;-)
<ogra> (if you hav ot use --force-shutdown thats not good anyway :) )
<seb128> "wake up"
<Hobbsee> seb128: he's in steve's special timezone.
<StevenK> seb128: I've been in Australia/Sydney since I got back, so nyah. :-P
<Treenaks> "his own happy time zone"
 * Hobbsee is on HST.
<StevenK> Hobbsee: And crack
 * StevenK hides
<Hobbsee> hush.  we don't discuss our crack supplies in publically logged channels.
<nakeee> how do I remove patch I added?
<nakeee> I made a typo and I want to upload a different one instead
<persia> nakeee: To where was the patch uploaded?
<norsetto> nakee: you mean on launchpad? There is a menu on the left
<nakeee> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/162678
<ubotu> Launchpad bug 162678 in gdm "Ipv6 enabled gdm can't get host correctly in ipv4" [Undecided,New]
<persia> nakeee: Just edit the patch, and delete the attachment.  Add another comment with the fixed patch.
<nakeee> thanks
<persia> nakeee: Just for reference, if your patch gets uploaded to the archives, it needs a new revision, rather than just an updated patch.  It's always best when you can catch them early.  Thanks for helping :)
<gaspa> norsetto: for something like that ( #162881 )  there's the need to attach a build log, or something more specific?
<gaspa> ( i mean... for a merge that involve a security bugfix )
<seb128> bug #162881
<ubotu> Launchpad bug 162881 in python-django "sync version 0.96.1-1 from Debian unstable" [Undecided,In progress] https://launchpad.net/bugs/162881
<gaspa> seb128: thanks. ;)
<seb128> you're welcome
<norsetto> gaspa: that bug is a sync right?
<gaspa> i think so.
<norsetto> gaspa: then I don't get your question, security fixes for the +1 release are like all other fixes, or I misundertood your question?
<gaspa> ok. this answer my question.
<gaspa> norsetto: the question was if a bugfix has more control also when involved in a sync process..
<gaspa> s/has/need
<norsetto> gaspa: for the stable release they are different, you know : https://wiki.ubuntu.com/SecurityUpdateProcedures already I guess
<gaspa> yes, i saw it.
<norsetto> gaspa: oh, you mean if we need to record it somewhere else?
<gaspa> no. no.. .you already answered....
<norsetto> gaspa: ok
<pitti> seb128: can I nag you again about moving some gnome -proposed to -updates?
<seb128> pitti: sure, I didn't do the daily batch yet ;-)
<seb128> doing it now
 * pitti hugs seb128, merci
 * seb128 hugs pitti back, de rien
<asac> anyone has a minute to NEW xulrunner-1.9-gnome-support? (just a new binary)
<seb128> asac: doing it
 * asac hugs seb128 
 * seb128 hugs asac back
<pitti> tepsipakki, bryce: do you know whether mesa can now build with something less ancient than gcc 3.4?
<pitti> (same question to all about grub)
<seb128> asac: accepted
<asac> great ...
 * asac back to holiday ;)
<tepsipakki> pitti: well, debian doesn't have those limitations, but 4.2 revealed a bug with hppa
<tepsipakki> FTBFS due to ICE
<seb128> asac: enjoy!
 * pitti mutters something about maintaining old cruft only due to unsupported arches with about 2 users
<tepsipakki> pitti: that bug is now worked around with mesa...-2 ;)
<tepsipakki> gcc 3.4 is used for amd64, i386, lpia...
<pitti> tepsipakki: in 7.0.2-1ubuntu2? or in 7.0.2-2 in Debian?
<tepsipakki> pitti: the latter
<tepsipakki> so it's a merge candidate
<pitti> ah, awesome
<tepsipakki> lpia was added to the gcc-3.4 list in gutsy..
<tepsipakki> maybe Mithrandir knows better
<IntuitiveNipple> Does anyone know of a tool/script that can take two sorted text lists, and output them side-by-side so that where they match, the entries appear on the same line of the output?
<pitti> IntuitiveNipple: diff -y?
<IntuitiveNipple> diff -y -d doesn't manage it unfortunately... I've just seen List::Compare on CPAN so I'll try that, else I'll write a quick C prog for it
<IntuitiveNipple> I'm trying to compare the Ubuntu kernel config with a gentoo config, to see if the differences could cause a kernel panic on Gutsy that Gentoo doesn't see
<pitti> eww, C is propably the least appropriate language for that... python or perl are much easier
<zul> IntuitiveNipple: meld?
<pitti> IntuitiveNipple: hm, but comparing those should work just fine with diff -u <(sort gentooconfig) <(sort ubuntuconfig) ?
<nemo_work> IntuitiveNipple: I'm really shocked there's not a diff setting you can't get to do that
<IntuitiveNipple> the lines don't match up enough, so i need a one-2-one compare
<IntuitiveNipple> I've been messing with diff for 10 minutes but it can't get it
 * IntuitiveNipple goes to check meld
<nemo_work> curious. I must have different inputs
<nemo_work> tossed a gvim -d comparison up, and seemed just fine.  perhaps you're asking it to be a bit too clever :)
<nemo_work> can't massage the files in your diff tool?
<IntuitiveNipple> Although they are sorted, there's lots of differences in entries (some in one not in the other, visa versa)
<nemo_work> IntuitiveNipple: riight, I used as input two lists of compiz plugins
<nemo_work> still seemed fine *shrug*
<IntuitiveNipple> It's always the easy things that end up being the annoyances :)
<cjwatson> IntuitiveNipple: is "join -a 1 -a 2 -o '1.1 2.1' file1 file2" remotely close to what you want
<cjwatson> ?
<IntuitiveNipple> um um um
<cjwatson> probably not ideal
<nemo_work> cjwatson: that's a nifty trick
 * nemo_work files it away for reference
<cjwatson> IntuitiveNipple: you could try comm(1) too
<pitti> IntuitiveNipple: (or using diff with -w to ignore whitespace)
<IntuitiveNipple> clever *!^&
<IntuitiveNipple> Now all I need to do is work out how to improve the output of that - thanks cjwatson
<IntuitiveNipple> pitti: All whitespace already long gone, and all comments removed
<cjwatson> IntuitiveNipple: combine(1) in moreutils might be useful too
<IntuitiveNipple> lol... what's that saying about never one around when you want one, then they all come at once?
<cjwatson> (and has friendlier syntax)
<cjwatson> there's loads of stuff in coreutils that people forget about, and moreutils needs to be more widely used
<IntuitiveNipple> yeah, my head is hurting trying to understand join's FORMAT
<cjwatson> I was actually wondering whether we should put moreutils in standard
<Mithrandir> cjwatson: doit. :-)
<IntuitiveNipple> See, that's the thing about Linux, you *know* there's a tool in there someplace that'll do what you want for some trivial task, but it'll take you an hour to track it down!
<nemo_work> IntuitiveNipple: or you ask in #bash ;)
<IntuitiveNipple> Ahh, I was thinking of doing a bash script... handy with them :)
<IntuitiveNipple> OK, this did it nice enough to be readable "join -a 1 -a 2 -o '1.1 2.1' config-gentoo config-gutsy | sed -e 's/^\( CONFIG.*\)/\t\t\t\1/' config.join"
<IntuitiveNipple> Thanks cjwatson, I can get on now
<nemo_work> IntuitiveNipple: say, um, given what it seems you were wanting to do...
<IntuitiveNipple> uh-oh
<nemo_work> IntuitiveNipple: couldn't you have just iterated through file X and grepped for matching lines in file Y?
<nemo_work> as a bash one-liner?
<nemo_work> seems it would have avoided cleaning the configs, too
<IntuitiveNipple> I guess, I was thinking of it, but I try to be elegant to my own detriment sometimes!
<nemo_work> hm
<nemo_work> writing a C program is more elegant than a bash loop? :)
<IntuitiveNipple> meld is the same as diff, doesn't output what I want
<IntuitiveNipple> nemo_work: It'd have ended up washing the dishes, too :)
<IntuitiveNipple> I have a core template for basic C progs ready to roll, just plug in the args config and the 'work' function and its done
<pitti> hey, forwarding sudo patches to upstream actually works :) it already got committed to cvs after just one day \o/
<cjwatson> nemo_work: if it's just matching lines, then 'combine file1 and file2' is probably a lot easier :-)
<cjwatson> (I couldn't tell from IntuitiveNipple's question exactly what he was trying to achieve)
<IntuitiveNipple> get the matching entries in two different kernel config files to line up side-by-side
<cjwatson> yes, but I wasn't sure whether it was important also to display the non-matching entries
<IntuitiveNipple> yes, everything needs to be there... it was not so much a diff as an 'aligned compare' based purely on the CONFIG_XXX match
<IntuitiveNipple> I suppose the ideal result would have been three fields:  CONFIG_KEY FILE1_VAL FILE2_VAL
<nemo_work> IntuitiveNipple: you know, this join command seems like it can handle that too :)
<IntuitiveNipple> not quite - it can't handle "CONFIG_KEY=X" and "CONFIG_KEY is not set" as the same 'line' because of the field delimiter
<nemo_work> oh. doesn't take arbitrary delimitter eh
<nemo_work> guess you could filter through a sed first :)
<IntuitiveNipple> If you could see the size of my sed expression! And to cap it all the bug-reporter has just reported that, "oh, I reinstalled and it works now, it might be caused by Lilo, going to install it now and test" !
<pitti> seb128: I am about to move pidgin-otr to main; do you think we should just put it straight into desktop?
<seb128> pitti: if it's in main, why not
<seb128> pitti: why do you promote it?
<pitti> seb128: it was approved a long time ago, and now MagicFab reminded me about it
<pitti> seb128: and it sounds pretty useful
<pitti> seb128: (would you be up for a quick test, BTW? I tested it a while ago, but I'd like to see the current version)
<seb128> sure
<seb128> makes sense to add it to desktop if it's in main imho
<pitti> that's what I thought (it's tiny)
<geser> does MoM track now experimental?
<acidBURN> is there a way to adjust the cpu speed (AMD) in Xubuntu as there is in Kubuntu
<Riddell> acidBURN: #xubuntu
<acidBURN> they seem to be a sleep
<Lutin> the ubuntu changes in fltk seem to have been fixed in debian some time ago. any reason not to sync it ? (would like to make sure before requesting a sync)
<pwnguin> question about bug 54816
<ubotu> Launchpad bug 54816 in ubuntu "Edgy should include 'bioapi' to support fingerprint readers" [Wishlist,Confirmed] https://launchpad.net/bugs/54816
<pwnguin> this guy wants to work on this blueprint -- but I think it would be worthwhile to have the technical council review the design
<Keybuk> cjwatson: isn't moreutils combine exactly like coreutils comm ?
<Keybuk> ah, no, reading the manpage it's a bit more flexible
<Chipzz> uh
 * Chipzz looks puzzled
<Chipzz> I was just browsing svn.gnome.org
<Chipzz> and at the bottom of the page it states "Hosted by Canonical"
<Chipzz> I thought RedHat hosted the gnome servers?
<elmo> Chipzz: we host a couple of gnome servers
<Chipzz> apparently :)
<elmo> Chipzz: svn is one, the other is, some i18n site.  erm, progress.gnome.org I think?
<Chipzz> when did that happen? (just curious)
<elmo> Chipzz: quite a while ago, we've been hosting progress for like a year and a half maybe?
<Chipzz> well doesn't matter much anyway :)
<Chipzz> I was just a little surprised :)
<warp10> Hi all!
<LaserJock> elmo: and plans to host a Debian machine? I noticed that Xandros sponsors one and I thought that was kinda cool
<LaserJock> downstream giving back kind of thing
<elmo> LaserJock: AFAIK Debian's never asked, but I imagine if they did, it'd certainly be possible
<elmo> (usual disclaimer: I can't speak authoratitively for Canoncial on these (or any) matters)
<LaserJock> sure
<syp|> https://bugzilla.mozilla.org/show_bug.cgi?id=402742#c25 <-- would it make sense to include these gnome libraries in ia32-libs?
<ubotu> Mozilla bug 402742 in ImageLib "nightlies on Ubuntu 7.10 x64 do not show stock icons" [Major,New]
<Kopfgeldjaeger> n8
<Riddell> siretart: why is libgpg-error in /lib not /usr/lib?
<siretart> Riddell: because cryptsetup needs it there
<Riddell> siretart: hmm, but now /usr/lib/libgpgme.la expects libgpg-error.la in /lib
<siretart> *sigh*
<siretart> can't we just drop these funky .la files?
<siretart> Riddell: does rebuilding libgpgme fix that?
<Riddell> siretart: let me try
<siretart> Riddell: btw, StevenK did the fighting against libtool here, you might want to hear his opinion
<pwnguin> yikes. irssi netsplit detector fails
<pwnguin> keescook: the full situation is thinkfinger wants to store fingerprint data in $HOME
<keescook> pwnguin: hm.  best I can see is to make sure there's a mode 700 .directory for it.
<keescook> sounds like it's similar to .ssh secret keys, etc
<pwnguin> i suppose so
<pwnguin> keescook: is a directory nessecary?
<slangasek> creating a subdir is usually helpful for preventing accidents
<slangasek> i.e., getting the umask wrong when copying the files
<pwnguin> of course, they're also considering acls
<pwnguin> also, are the possible negatives to enabling acls by default?
<pwnguin> (in fstab)
 * keescook defers to installer gurus
<pwnguin> I'd like to be able to get thinkfinger to work out of the box, but there's a host of integration issues
<keescook> using a directory is filesystem-portable...
<pwnguin> right
<slangasek> one of the problems with enabling acls, AFAIK, is that they're not preserved by backups
<pwnguin> hmm
<elmo> last time I tried enabling ACLs and using them extensively (beagle), i ended up with FS corruption
<pwnguin> nice
<Fujitsu> Ouch
<elmo> of course, presumably I was just unlucky and they're not that generically broken :)
<elmo> but it happened three times before I ran away screaming
<elmo> (it was always recoverable with fsck)
<pwnguin> is acls broke or is beagle?
<Fujitsu> Am I missing something crucial, or is the python-django merge on http://merges.ubuntu.com/universe.html listed incorrectly? That base version is bogus, and it's listing the new version in experimental.
<elmo> pwnguin: who knows, could have been hardware or anything.  it was a long time ago
<pwnguin> the one point about $HOME that was brought up is home mount via NFS
<slangasek> if beagle manages to put your fs in a state that requires recovery, that'd be an fs bug (or lower), not a beagle bug
<pwnguin> fair enough
<wasabi> geeze... so all teh X apps moved back into large packages.
#ubuntu-devel 2007-11-16
 * Hobbsee waves
<LaserJock> hi Hobbsee
<Hobbsee> LaserJock!
<LordKow> is there an easier way to check on accepted new/update packages (not in repos yet) than using the mailing lists?
<Hobbsee> hardy-changes?
<Hobbsee> although that's a mailing list, it's probably the easiest way
<ajmitch> there was an rss feed of it
<LordKow> ah okay
<LordKow> building new totem with the ubuntu patches. i think the launchpad integration will work properly but i will find out shortly :P
<LordKow> sad that my laptop has almost 2x more processing power than my desktop and my desktop is 2x old-school opterons
<LordKow> hm build depends for totem seem to be out of date
<LordKow> make: dh_iconcache: Command not found
<StevenK> LordKow: That isn't a Build-Depends issue. Change that command to dh_icons
<LordKow> ah okay, well totem is still out of date then ;)
<LordKow> yea i forgot about the switchover
 * Hobbsee didnt know dh_iconcache got taken out already.
<LordKow> what was used before dh_iconcache? debian changelog says "use dh_iconcache" for one of the updates
<Hobbsee> nothing, iirc.
<Hobbsee> then ubuntu implemented dh_iconcache, and then debian eventually implemented dh_icons, so we're switching to that, as it's better anyway
<LordKow> new version of debhelper was merged today, probably removed dh_iconcache
<Hobbsee> hum.  then our rebuild tests will bail out.
<LordKow> that will help filter out dh_iconcache from packages a lot quicker, maintainers wont be able to build the package unless they fix it :)
<Hobbsee> for everything that still has dh_iconcache
<Hobbsee> ubuntu has no maintainers, per se.
<LordKow> update the packages...?
<emgent> heya people
<LordKow> Hobbsee, let me rephrase "the ubuntu maintainers". debian should take care of most of it
<LordKow> however i doubt all of the packages will be updated before upstream merge freeze
<Hobbsee> the ones that make it onto mom will be.
<Hobbsee> as in, merge-o-matic
<Hobbsee> however, the ones after...they'd be a good newcomer candidate.
<LordKow> ah i always wondered what does the merging, i figured it was automatic
<Hobbsee> there are tools which help, but it's all manual.
<Hobbsee> see merges.ubuntu.com/universe.html
<LordKow> i suppose there would be insane amounts of breakage if we let upstream merging be done automatically
<LordKow> probably with dependencies more than anything else
<Hobbsee> yeah.  i dont trust the merge-o-matic stuff that much :)
<Hobbsee> occasionally it comes out with absolute crack.
<Hobbsee> like, starting tarball sizes of 5mb from ubuntu, 5mb from debian.  resulting diff:  15mb.
<LordKow> lol
<Hobbsee> feel free to get involved, if you like
<LordKow> well im quite busy with school stuff but hopefully I'll be able to squeeze out a few package updates than can get sponsored
<LordKow> *that
<Hobbsee> dear compiz, please stop falling over, kthxbye.
<Hobbsee> no, this apparently *isnt* compiz.
<Hobbsee> yes it is.
<Hobbsee> any buildd admins around?
<Hobbsee> lamont: maybe?
<lamont> Hobbsee: I'm hiding.
<lamont> since I need to figure out why your ppa build didn't like you
<Hobbsee> lamont: can you boost the priorities of firefox-3.0 please?  https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=firefox-3.0&build_state=all
<Hobbsee> lamont: "soyuz is on crack" is an acceptable answer.
<Hobbsee> lamont: i'll give you longer before asking about the other, if you bump the prio of that firefox.  how's that?  :)
<lamont> can't bump hppa or ia64.
<lamont> others set to 10000
<Hobbsee> excellent, thanks.
<lamont> ia64 bumped too.
<lamont> hppa kinda needs a working java to build xulrunner, so um.. sucks to be us
<lamont> interesting.  greasemonkey script failed me
<Hobbsee> yeah
<Hobbsee> hah
<lamont> there
 * lamont applied a *=100 filter
<Hobbsee> :)
<LordKow> i hate it when i make a stupid mistake and spend 2 hours waiting for a package to compile and have it fail in the end simply because i forgot to update the .dsc after i made changes :-/
<bddebian> I know that feeling
<Hobbsee> ccache ftw!
<LordKow> dont have the disk space :(
<LordKow> "Totem Movie Player 2.21.2" yay
<Hobbsee> mdz: er...https://bugs.edge.launchpad.net/ubuntu/+source/landscape-client/+bug/163030 might be something you're interested in.
<ubotu> Launchpad bug 163030 in landscape-client "Against Ubuntu Promise" [Undecided,New]
<Hobbsee> looks like you were teh uploader.
 * tonyyarusso subscribes
<tonyyarusso> Launchpad and Landscape being proprietary are pretty high up on the list of things that irk me with Ubuntu atm.
<warp10> Hi all!
<dholbach> good morning
<Hobbsee> guten morgen, dholbach
<dholbach> hey Hobbsee
<\sh> slangasek, bug #161193 commented...I could be wrong, please check :)
<ubotu> Launchpad bug 161193 in xclass "[MoM Merge] xclass 0.9.2-3ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/161193
<slangasek> \sh: why would there be problems upgrading from dapper?
<slangasek> \sh: my analysis showed there were zero overlapping files between the two packages
<pitti> Good morning
<geser> Hi pitti
<warp10> pitti: Hi boss!
<pitti> hey geser, hey warp10
<pitti> warp10: /me != boss :)
<warp10> pitti: :D
<seb128> is there any known toolchain issue on amd64?
<mhb> hi pitti
<seb128> hum, in fact not amd64 specific
<seb128> there is quite some packages I synced from Debian which ftbfs on "undefined reference to `ceil'"
<seb128> but they built correctly in Debian
<seb128> "undefined reference to `floorf'" also in the log
<pitti> hey mhb, how are you?
<mhb> pitti: I'm having an exam in 4 hours, so a bit nervous, but fine otherwise ... and how are you? I have noticed you've completed the r-m-rewrite spec, the DB idea sounds quite nice
<pitti> mhb: oh, good luck with your exam then! I'm quite good, grinding through the large heap of work that UDS created :)
<mhb> pitti: by the way, my account on r-m-hackers is about to expire. I guess it'd be nice of you to renew it for some time, provided you still want my help :o)
<pitti> mhb: oh, sure
<pitti> mhb: how's that?
<mhb> pitti: https://edge.launchpad.net/~restricted-manager-hackers I guess through the Members link from here
<\sh> slangasek, ok...so I think we change the merge to a sync...and we are clean
<Treenaks> hmm.... bug 163042
<ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Undecided,New] https://launchpad.net/bugs/163042
<seb128> doko_: around?
<mhb> pitti: by the way, the wiki page is not really clear on how the UI abstraction will be handled ... are we going to provide a fixed number of abstract dialogs (like ConfirmDialog, FirmwareSelectDialog) for the handlers? If so, how many and which?
<lool> seb128: Do you have an example package?
<pitti> mhb: yes, all the workflow, dialog types, etc should be in the abstract UI; implementations should not do any decisions nor workflow
<seb128> lool: nautilus-cd-burner
<seb128> lool: include math.h makes no difference, that's weird
<lool> seb128: It sounds from your description that -lm is missing, but historically ld in Debian/Ubuntu would add it automatically
<lool> Perhaps it's stricter now
<seb128> well, it used to work and work on Debian
<seb128> whatever was added -lm should keep doing so ;-)
<seb128> doko_: ^
<seb128> did anything change in the toolchain that could make that -lm is not used on build now?
<lool> seb128: We have a CVS snapshot of 2.18.1 while Debian has 2.18
<seb128> lool: cvs of what?
<lool> binutils
<seb128> ah
<lool> But yeah, doesn't sound like a change we should do in Ubuntu first
<seb128> I'll wait for a reply from doko
<Treenaks> Are there Security/samba people? People are seeing dead nmbd's after the latest Samba security upgrade (bug 163042)
<ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/163042
<\sh> dear developers, we have a problem with security regarding dapper and a very vital package named ethereal (or newer name wireshark)
<\sh> in dapper we have ethereal 0.99.0 which is the last release under the name ethereal and all future releases are named wireshark
<lool> seb128: I got some build logs with this error as well now :)
<\sh> now we have some security flaws in 0.99.0 which are fixed in 0.99.2...the problem with that, there is no real way to fix those security issues in 0.99.0 without diffing 0.99.0 to 0.99.2 and carry a very big patch with us... (rational: they are changing not only the project name, no they are changing as well some prefixes of variables from ETH_ (for ethereal) to WS_ (for wireshark))
<seb128> lool: from Debian or Ubuntu?
<lool> seb128: Ubuntu
<seb128> ok
<\sh> so, what do you think is the best way to fix this package...it's vital and for sysadmins and network people important.
<pitti> \sh: I don't really think we can give a good answer to this; it's universe for a reason, and if you rely on anything in an universe as old as dapper's, you have a major problem (likewise with clamav, php apps, etc.)
<pitti> \sh: if it is feasible to put the latest wireshark into dapper and name it 'ethereal' to avoid NEW packages, we can talk about this, though
<pitti> but if it breaks any behaviour, config files, etc., then the only remaining option that I see is a backport
<\sh> pitti, well, for any other release it's easy to backport the fixes...but for dapper, it's special because of the change of the project
<pitti> \sh: so merely changing the package name doesn't work?
<pitti> it also changes config file names/paths, etc/
<pitti> ?
<\sh> pitti, I'll have to check other files to answer this question, but reading the source for the important parts, I wonder if they didn't even change names of config files or something else
<pitti> \sh: quite likely if they are that thorough
<pitti> \sh: however, patching that might be significantly easier than trying to backport all the security fixes
<\sh> pitti, I tryed to bump only the files which are affected, but they really do indeep changes, as I said, changing struct names from ETH_ to WS_ etc. which gives me a real headache
<Fujitsu> Ewww.
<\sh> as an example btw: http://anonsvn.wireshark.org/viewvc/viewvc.py/releases/wireshark-0.99.2/epan/dissectors/packet-gsm_a.h?view=diff&r1=18755&r2=17982&diff_format=h
<torkel> \sh: you can't just do s/WS_/ETH_/g to trim the diff?
<\sh> torkel, that's something I'm trying to do now
<lool> slangasek: Is there a technical page which the changes in JeOS WRT to e.g. a server install?  I guess less packages installed and a different kernel flavor, but I'm not even sure
<\sh>  oh I'M really doomed...let's do the easy things first...feisty and edgy
<lool> Hmm http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=python-gobject-doc&version=hardy&arch=all lists djpig as contact address; I guess he might not want to be contacted for packages.ubuntu.com; do I file a ticket for IS?  Or a launchpad bug against some team?
<dholbach> lool: he takes care of that page
<dholbach> (iirc)
<lool> dholbach: Oh ok; fine then, thanks
<dholbach> np
<dholbach> although I think we should have that functionality in LP :)
<mdz> Hobbsee: thanks for bringing my attention to it; I've clarified in the bug
<Hobbsee> mdz: you're welcome.  now i just have to find the bug #, to see what you said :)
<mdz> Hobbsee: bug 163030
<ubotu> Launchpad bug 163030 in landscape-client "Against Ubuntu Promise" [Undecided,Invalid] https://launchpad.net/bugs/163030
<Hobbsee> thanks
<Hobbsee> mdz: ahh, so you sneakily avoid the issue of the *client*.
<Hobbsee> er, the host.
<Fujitsu> Hobbsee: Of course.
<Fujitsu> Server, you mean?
<Hobbsee> yes.  *that's* the word i was looking for.
<Fujitsu> Heh.
<Hobbsee> i swear, the idea of exams on saturdays screws up my brain.
 * Fujitsu had his last exam a few hours ago, so hah!
<mdz> Hobbsee: Landscape is a web service which can be used in conjunction with a client.  The client is part of Ubuntu and free software.  The service is something which is offered for a fee.
<Hobbsee> mdz: okay, i didn't realise my brain was *that* broken.  i knew that, i really did :)
<mdz> Hobbsee: is there anything unclear about it?  I don't think the press release got into this level of detail
<Hobbsee> mdz: no, it's clear.  it's just my brain on crack, due to these damned exams.
<highvoltage> since there's some talk on landscape, where can I ask for the testers support? the landscape interface pointed me to landscape-devel@lists.canonical.com, but posting there is only for members.
<mdz> Fujitsu: any questions about landscape?
<Hobbsee> mdz: you ask that, and he'll say "Will you open source it, and if so, when?"
<Hobbsee> :)
 * Fujitsu doubts it.
<Fujitsu> mdz: The client is entirely useless without the service, presumably?
<mdz> Fujitsu: it's designed to be used with our implementation, though the protocol is open and could presumably be used with other software if someone implemented it
<Fujitsu> mdz: Aha, thankyou for clarifying that.
<mdz> but the service isn't offered for free, any more than telephone support is
<Fujitsu> Right, and that is reasonable.
<Fujitsu> Hobbsee: I'm not against *any* Canonical projects being non-free, just essential deficient stuff like LP.
<Hobbsee> Fujitsu: heh.  heh.  heh.
<seb128> Fujitsu: maybe not the right chan to troll? ;-)
 * Hobbsee does not comment, as mdz is around.
<Hobbsee> seb128: it was related to previous discussion
<seb128> Hobbsee: well calling LP deficient is still somewhat trollish
<Hobbsee> seb128: tell me that when you *don't* have chinstrap access.
<seb128> Hobbsee: I don't have chinstrap access
<Hobbsee> oh?  i thought you did, to log into drescher to do archive admin stuff?
<Hobbsee> or have they changed the machines?
<Fujitsu> seb128: How is it trollish?
<seb128> Hobbsee: you didn't ask me if I have access, you asked me to tell you I don't have access which I did ;-)
<Fujitsu> Haha.
 * Hobbsee gives seb128 a penalty card.  LYING!
<seb128> Fujitsu: you might not like launchpad it doesn't make it deficient
<Hobbsee> seb128: you missed the "when" in there.
<seb128> Hobbsee: indeed ;-)
<Hobbsee> seb128: :)
<Hobbsee> seb128: it's deficient when it's bugs stop me from doing ubuntu stuff.
<seb128> like what?
<Fujitsu> Right, there are a annoying bugs, so it is deficient.
<Hobbsee> archive admin, for one.
<Hobbsee> various other things as well
<Fujitsu> Erm, -a
<Mithrandir> software is buggy, news at 11.
 * Mithrandir hides.
<seb128> Fujitsu: you can call everything deficient using that criterium
<Fujitsu> Mithrandir: Software is taking a long time to get unbuggy, even with 35 devs.
<Hobbsee> Fujitsu: no, annoying bugs != deficient.  missing critical features == deficient.
<seb128> Hobbsee: that's called bugged and Ubuntu is as deficient as launchpad
<Hobbsee> seb128: i can fix one, and not the other :)
<Hobbsee> but oh well.
<seb128> what make you start this troll again?
 * Hobbsee throws a thunderbolt at Mithrandir :)
<seb128> I think launchpad not being opensource yet has already been discussed
<seb128> is there a point to start again on the ubuntu chan?
<seb128> that's rather OT for Ubuntu
<Fujitsu> seb128: It was relevant to the previous discussion.
<Hobbsee> seb128: if you must know, it was discussions on landscape, and mdz asking if we wanted clarification on that.  that, is of course partially non-free, which led to the comment about it being acceptable for canonical to have propriatory stuff.  would you like a pastebin?
<seb128> Fujitsu: I was not there for the discussion apparently, still calling LP deficient is trollish
<Hobbsee> and this isnt?  :)
<seb128> Hobbsee: no thanks, I would just like to not have yet another discussion about LP having some bugs and being closed source there, that has been discussed enough and I don't think the discussion will bring us anything
<mdz> Fujitsu: Launchpad will be open source, though the matter of when is complex
<Hobbsee> mdz: and how much
<Hobbsee> but, you're right, i have better things to do.
<Fujitsu> mdz: I know, and I've read the reasons that have been cited, and I find them somewhat reasonable.
<mdz> Hobbsee: I don't think there is any question about how much
<mdz> there's no third-party IP in it as far as I'm aware
<Fujitsu> mdz: Isn't there? I was sure that previous versions of the policy mentioned that Soyuz would remain non-free, as it will always be a service sold to other distros.
<mdz> Fujitsu: I'm happy to discuss this, but please take it to #launchpad
<mdz> seb128 is right
<Fujitsu> mdz: True, this has drifted well offtopic now.
<doko_> seb128: -lm isn't added automatically for C, just for C++
<seb128> doko_: the same package built in gutsy and debian, something is the toolchain changed
<seb128> doko_: did -lm used to be added for C?
<doko_> seb128: maybe another library was linked against -lm before?
<seb128> yeah, might be, I'm just trying to figure which one ;-)
<seb128> mvo: you should send this toshset change to Debian or do a QA upload there and ask for syncing ;-)
<mvo> seb128: I send the patch upstream already
<seb128> mvo: ah ok, I looked to the BTS only
<mvo> seb128: hm, at least it should be sent, I got no reply from debian bts yet
<dholbach> MOTU Q&A session in #ubuntu-classroom now
<pitti> tepsipakki: hm, I thought mesa 7.0.2-2ubuntu1 wouldn't need gcc-3.4 any more? it still uses it on i386/amd64/lpia?
<tepsipakki> right, I didn't drop those yet, need to get a confirmation from the kernel guys..
<tepsipakki> pitti: or do you think we could drop them right away?
<pitti> tepsipakki: no, if you need soem confirmation, please get it
<pitti> tepsipakki: I just thought that was already settled after our conversation from yesterday
 * pitti hugs tepsipakki, thanks
 * tepsipakki hugs pitti back
<Hobbsee> cjwatson_: ping @ ubuntu-devel ML question
<directhex|bsp> cjwatson_, did you read my review of current ps3 linux distributions?
<DktrKranz> pitti, could you please have a look at bug 103489? It has already uploaded and needs to be accepted.
<ubotu> Launchpad bug 103489 in ggz-gtk-games "[SRU] [can-not-install] file overwrite error" [Medium,Confirmed] https://launchpad.net/bugs/103489
<pitti> DktrKranz: I'll get to that today (SRU run is still on my plan)
<DktrKranz> pitti: thanks
<cjwatson_> directhex|bsp: no?
<cjwatson_> Hobbsee: pong
<Hobbsee> cjwatson: ubuntu-devel@l.u.c is moderated by if you're a part of ubuntu-dev or not.  how does it get this list of who's in ubuntu-dev?  namely, do new MOTU's get added manually to the whitelist, or does it do some launchpad foo?
<directhex|bsp> cjwatson, http://gaming.hexus.net/content/item.php?item=10273 - nobody did very well
<cjwatson> Hobbsee: that's a good question and not one where I know the answer. elmo ought to know
<Hobbsee> cjwatson: surely not!  you're supposed to know everything :)
<Mithrandir> Hobbsee: it's synced automagically, I believe.
<pochu> add me to ~motu and I'll test :-)
<Hobbsee> Mithrandir: in which case, why does norsetto keep getting moderated?
<cjwatson> directhex|bsp: OK, I've repaired (and continue to be in the process of repairing) some of your issues for Ubuntu, but haven't spent the time to produce custom versions of Xubuntu 7.10
<Mithrandir> Hobbsee: is he sending from an address associated with his LP account?
<directhex|bsp> cjwatson, all the problems stated were on ubuntu also, it was just a bit slower due to gnome's extra memory requirements. network, resolution, etc
<Hobbsee> Mithrandir: come on launchpad.  dont time out.   load the page.  good launchpad.
<Hobbsee> Mithrandir: it's his third confirmed email, yes.
<Mithrandir> Hobbsee: hm, then I defer to cjwatson's advice to talk to our sysadmins who might be able to shed some light on the issue.
<cjwatson> directhex|bsp: FWIW: current custom Ubuntu 7.10 CDs (not in the obvious place, but there's a link from the obvious place) document the video mode stuff in the CD boot loader message, the networking thing is a hal bug that I think I've mostly fixed and just need to QA properly, I'm not sure why Gnash isn't automatically offered but maybe that's a Xubuntu thing?
<Hobbsee> Mithrandir: fair enough
<Hobbsee> elmo: ping, and i promise i wont start ranting again :)
<directhex|bsp> cjwatson, i may look at the question again when 8.04 is stable (by then, maybe the fedora lot will have pulled their thumbs out of their arses and stuck otheros.bld on the install media, so i can consider it for comparison)
<cjwatson> directhex|bsp: I do agree that we haven't spent enough time on it, and I posted a call for development help recently
<directhex|bsp> cjwatson, yes, i read it, hence making you aware of my article
<directhex|bsp> cjwatson, if it makes you feel any better, nobody else was any better overall
 * cjwatson nods
<directhex|bsp> frankly, some of the issues i found on all three distros were baffling.
<seb128> so guys, we (desktop team, but there is nothing desktop specific there) want to start using some sort of tags in the patches
<seb128> to have informations like the corresponding ubuntu bug number, the upstream one, a description of the patch, etc
<seb128> does anybody has an opinion on the format that should take and the naming?
<\sh> keescook, bug #132915 -> feisty and edgy debdiffs attached, dapper is not going to be fixed...
<ubotu> Launchpad bug 132915 in wireshark "WireShark versions prior to 0.99.6 vulnerability" [High,In progress] https://launchpad.net/bugs/132915
<seb128> I was thinking to something like
<seb128> ubuntulog: http://launchpad.net/bugs/nnnnnn
 * seb128 slaps the completion
<seb128>  Ubuntu: http://launchpad.net/bugs/nnnnnn
<seb128>  GNOME: http://bugzilla.gnome.org/nnnnnn
<seb128> Description: what the change is doing
<seb128> do we want those standardized so they can be automatically listed by some tools maybe, etc?
<Fujitsu> seb128: As in dpatch patches?
<seb128> Fujitsu: nothing dpatch specific, as in any patch system you want to use, simple-patchsys, quilt, dpatch
<Fujitsu> But that sort, right.
<seb128> everything we store in debian/patches
<seb128> and which theorically should be send upstream and documented
<seb128> we should also have a tag to indicate that a change is distribution specific (customization for example)
<pitti> seb128: I'd do s/GNOME/Upstream/
<pitti> seb128: and perhaps add Debian:
<seb128> pitti: I was pondering if we should get a tag by bug tracker or just an upstream one
<seb128> pitti: like to list all the bugzilla.gnome.org bugs
<seb128> pitti: but that would be easy enough to do using upstream and filtering on bugzilla.gnome.org then
<pitti> seb128: I wouldn't define more tags than necessary
<seb128> ok
<pitti> seb128: yeah, that's what I was thinking, you can filter on teh bug tracker host name
<seb128> so Ubuntu, Debian, Upstream
<seb128> and Ubuntu-specific
<pitti> seb128: FYI, the Debian kernel guys do something similar
<seb128> and Description
<pitti> seb128: technically, Debian is just an upstream too, but since it is so exceptionally important for us that might justify a separate tag
<pitti> seb128: otherwise I like it
<seb128> pitti: right, but it's a special upstream, and that means we can use the same tagging on Debian
<pitti> right
<seb128> I'll mail ubuntu-devel about the suggestions, thank you for the comments
<Robot101> has some big backlog of security updates just been unplugged?
<Robot101> there have been like 100 in the past 2-3 days
<pitti> dholbach: why did you do a gutsy-wallpapers upload to hardy? I thought that was obsolete?
<dholbach> pitti: so it's installable in parallel with ubuntu-wallpapers
<pitti> ah, I see
<cjwatson> Robot101: last week and the week before, the security team were at conferences in Massachusetts
<cjwatson> Robot101: so I expect that it's "get back home, work on CVEs"
<\sh> more openldap security fun....:(
<Skiessi> when nvidia-glx-new gets updated to work with the newest xserver-xorg-core?
<dholbach> pitti: ubuntu-gdm-themes uploaded
<dholbach> pitti: ubuntu-artwork should depends on ubuntu-gdm-themes and ubuntu-wallpapers now too
<pitti> dholbach: accepted
<dholbach> pitti: thanks A LOT
 * dholbach hugs super-pitti
<pitti> no problem :)
 * pitti hugs dholback
<dholbach> :-)
 * pitti kicks out a whole lot of old crap from -proposed; yay, back to sanity!
<pochu> doko: I've done your mono merge, hope you don't mind.
<pitti> mvo: what will happen with bug 47044? there's still an outstanding question
<ubotu> Launchpad bug 47044 in apt "apt cant work with disable proxy" [Medium,Fix committed] https://launchpad.net/bugs/47044
<pitti> and it needs verification
<pitti> and it's sitting there for 290 days already
<mvo> pitti: sorry, I look at it and answer your question
 * pitti hugs mvo, thanks
<pitti> bdmurray, mvo, ogasawara: main SRUs in -proposed which are more than half a year old and did not get any testing feedback from reporters are a good candidate for removal from -proposed IMHO; do you agree?
<pitti> bdmurray, mvo, ogasawara: (I already cleaned up all the universe stuff)
<pitti> common sense applied, of course
<ogasawara> pitti: sounds reasonable to me
<pitti> mvo: FYI, you have some verification bug mail for update-manager{,-core} now
<mvo> pitti: in my inbox?
<mvo> pitti: let me check
<pitti> (not that urgent, but a gentle reminder)
<mvo> pitti: I can't do the verification for #47044 myself, but I will update the report to follow the new verification steps guidelines
<pitti> mvo: thanks
<pitti> mvo: also, if you test the actual -proposed package yourself, that's still a valuable piece of feedback at least forme
<pitti> s/forme/for me/
<bddebian> Heya
<lamont> dear bip.  please quit dying. kthxbye
<mvo> pitti: #47044 updated
<pitti> mvo: aaaah, that makes sense
<pitti> mvo: I programmed Python for too long :)
<pitti> incidentally that's the very same trap that StevenK and I fell into recently
 * pitti â hasn't touched C++ for > 5 years :(
<pitti> mvo: so, verification should be easy now
 * pitti hugs mvo
<mvo> pitti: cheers, what are the other outstanding ones for u-m?
<pitti> http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
<pitti> bug  #109216 and bug #109290
<ubotu> Launchpad bug 109216 in update-manager "upgrade not possible with 0.45.3" [Undecided,Fix committed] https://launchpad.net/bugs/109216
<ubotu> Launchpad bug 109290 in update-manager "update-manager core should support proposed updates" [Medium,Fix committed] https://launchpad.net/bugs/109290
<pitti> mvo: those are all of your's, I think
<pitti> mvo: in a few hours the page should be much smaller, BTW
<mvo> pitti: thanks, checking
<slangasek> lool: you may want to ask soren about that (differences between JeOS and server); there's also a tentative seed for it now
<frafu> Hello, I am new to patching and am currently stuck. Here is my problem: On launchpad there is a project written in C called mousetweaks. Release 0.2.6 has been published and in the meantime a typo has been fixed in launchpad. I downloaded the unified diff to patch the debian source package I am trying to build. But when I try to apply the dpatch that I created from the diff, it tells me that it does not find the file.
<slangasek> \sh_away: will you retitle the xclass bug to a sync request, or do you want me to just take it from here?
<frafu> Could anybody please help?
<pochu> frafu: use 'patch -pX <your_patch.dpatch', where X is a number
<pochu> frafu: btw #ubuntu-motu is a better place for that question :)
<pitti> frafu: https://wiki.ubuntu.com/MOTU/School/PatchingSources should help you
<\sh> re
<frafu> I thought to use dpatch, and there are 2 patches that I have to apply. Will I be able to use -pX in the debian rules file?
<frafu> pochu: why is the number of dirs dires to strip wrong? What can I do to get a patch that works from the root dir of the package without indicating a -pX ?
<cjwatson_> surely for a typo it would be less effort just to edit the source directly rather than spending ages messing with a patch system
<cjwatson> patch systems are worthwhile if you have fairly substantial numbers of fairly long-lived patches against upstream
<cjwatson> but for a simple typo backported from upstream, it isn't worth it
<pwnguin> patch systems are wierd. there's already a diff.gz
<pwnguin> and now you want to hide more inside that?
<cjwatson> I understand why people end up using them for, as I said, fairly substantial numbers of fairly long-lived patcheds
<cjwatson> gah
<cjwatson> ()(although I would
<cjwatson> (although I would prefer to replace that with better infrastructure, long-term)
<pwnguin> i wonder how git's working out for joey hess
<frafu> In fact,there is a second more complicated patch to apply; it gives me the same error.
<frafu> I have prepared a page with more info, if someone can have a look:
<frafu> http://paste.ubuntu-nl.org/44761/
<frafu> Is there a way to create the patch so that no -pX is necessary?
<cjwatson> dpatch should supply the -pX itself
<cjwatson> are you trying to apply the patch by hand here?
<cjwatson> (in any case, I still think dpatch is overkill in your case and you are making a rod for your own back)
<cjwatson> oh, I think I see your problem, anyway
<frafu> yes, with 'dpatch apply-all' to test the patch
<cjwatson> dpatch probably tries -p1 first and there is a ChangeLog at the root
<cjwatson> don't use that dpatch patch-template business
<cjwatson> instead, use dpatch-edit-patch
<frafu> Could you please tell me shortly how to use dpatch-edit-patch? Can I feed the diff from launchpad to dpatch-edit-patch?
<cjwatson> so you do 'dpatch-edit-patch fix_typo_in_po_de'
<cjwatson> it will give you a shell
<cjwatson> in an unpacked copy of the source package
<cjwatson> you apply the patch to that tree, and exit; it will deal with generating the .dpatch file and putting it in the right place
<cjwatson> btw, this is all in the URL pitti gave you earlier. Have you read through that?
<cjwatson> if not, please do so, and then go to #ubuntu-motu if you have further problems
<frafu> cjwatson:  thanks. I will try what you suggested and read pitti's link
<IntuitiveNipple> Anyone got suggestions as to what I should look for. Whilst booting UML Gutsy it mounts root but during init reports "findfs: Unable to resolve 'UUID=XXXX' " for the / and /home, mountpoint+mount report failure, and from the maintenance shell there's no /dev/ubd* or /dev/disk/by-uuid/
<ogra> looks like it doesnt wait long enought for the devices
<ogra> (just a guess)
<dajhorn> IntuitiveNipple: (You'll get plonked by asking support questions here).  Gutsy broke UUID handling on many of my servers.  Try it LABEL instead.
<IntuitiveNipple> I'm trying to ensure we have a working UML... this looks to be the last part of the puzzle
<IntuitiveNipple> Nope, LABEL doesn't help. It looks as if no 'disk' nodes are being created
<IntuitiveNipple> Ahhh... would it help to have udev installed?
<pitti> tepsipakki, bryce: all the x client packages on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt (source and binary demotion) can be kicked out of the archive entirely, right?
<bryce> pitti, yes that's correct.  I'm not sure why -elographics is on that list, but everything else is now maintained in other packages
<dajhorn> Where can I go to watch vmware-server foodfight that is happening?  Ticket activity is happening without commentary.
<desertc> Greetings, could I get your opinion on this question:
<desertc> http://ubuntuforums.org/showthread.php?t=614769
<cjwatson> desertc: you might want to say what it's about so that not everyone has to visit the URL to find out
<desertc> I hate to fill the channel with a cut and paste.
<cjwatson> summarise
<cjwatson> you certainly shouldn't cut and paste it
<desertc> That is what I did on the link...
<jdong> desertc: you are asking a support question in that thread
<cjwatson> there are 235 people in this channel with hundreds of different interests
<ogra> desertc, you miss the difference between the gutsy-security and gusy-updates repos
<jdong> desertc: as ogra just said, disable gutsy-updates and only enable gutsy-security in the Software Sources Manager
<jdong> or /etc/apt/sources.list
<cjwatson> when posting a link, you need to say briefly what it's about in order that the people who are interested can look, rather than everyone
<ogra> desertc, what you want is to disable gutsy-updates ... that way you*ll only get critical fixes
<jdong> cjwatson: his thread asks if there is a way to only get Security updates rather than Recommended Updates too
<desertc> jdong: Yes, exactly!  So, in doing so, will there be any issue with the security updates expecting a "recommended" update being in place?
<ogra> yeah, without having to read the forum it would have been easier and saved some ram in my 60+ tabs firefox win
<jdong> (and yes, desertc, it'd be nice if you can give one-line summaries without forcing people to click a link)
<jdong> desertc: no. they are designed to be independent of each other
<desertc> jdong: I will keep this in mind for future communications.
<cjwatson> jdong: sure, I wanted him to tell me ;-)
<cjwatson> or, well, tell us
<desertc> jdong: Thank you very much.  I really appreciate the advice.
<cjwatson> desertc: jdong's *nearly* right
<cjwatson> desertc: -security doesn't require -updates, but -updates may require -security
<cjwatson> desertc: indeed, packages in -security are normally pushed into -updates as well
<desertc> Good luck with your endeavors to bring Free Software to human beings, all.
<cjwatson> so to all intents and purposes -security is a subset of -updates
<jdong> as always cjwatson knows best :)
<jdong> "If so, then I may simply leave the Update Manager service off and wait until the next version within 6 months. The Linux OS is hardened enough that I would feel confident doing so."
<jdong> urgh he left
<jdong> was just gonna tell him that's not a good assumption to make
<cjwatson> tell him in the forums
<jdong> yep just did
<jdong> cjwatson: quick question of curiousity, there's often backports that I reject because they b-d on a newer version of a library that isn't strictly necessary (i.e. used to force a build against the newer version in the development distro)... I'm wondering if we can work out some kind of procedure for handling these
<jdong> i.e. either loosening the dep in Universe, or a trivial source-change backport
<jdong> which ever is easier on you guys :)
<cjwatson> jdong: loosening the build-dep can cause some problems down the line, particularly if an architecture is behind; I'd rather have somebody who cares about backports in core-dev so that they can do source-change uploads when necessary
 * cjwatson -> dinner
<jdong> cjwatson: ok, good point, there's a few members that are in core-dev so that route sounds good for now; thanks for your time
<SEJeff> Would I be correct in assuming someone from Canonical is aware of the fact that security.ubuntu.com is returning 403 when trying to download samba updates?
<pipegeek> weeeeeird
<elmo> SEJeff: yes, the update causes a regression, the 403 is deliberate.  a fixed package is being worked on
<SEJeff> elmo, ok good. Just making sure
<dajhorn> elmo: For how much time was the dud package available?
<pipegeek> I mentioned what I thought to be a bug in compiz-fusion in here a while ago---when the system was under load while compiz was running, x would crash within a few minutes (I've been testing with some trivial mencoder task)
<elmo> dajhorn: I don't know offhand, sorry
<pipegeek> Turns out that's not accurate; it only happens when there's a cpu-intensive task *running in yakuake*.
<dajhorn> elmo: Np.  (My dev boxes got it.) *shrug*
<pipegeek> Just wanted to say that "aloud".  Off to launchpad
<pipegeek> Sweet!  And the bug already exists!
<pipegeek> :D
<pipegeek> and has since feisty :-\
<jdong> if people don't mind me asking.... how did this samba regression happen?
<pipegeek> errgh, sorry for giving you strace of my brain
<pipegeek> ta ta
<jdong> it seems to be a crash-on-start or crash-on-trivial-usecase
<jdong> was the update not verified on these two releases?
<Lutin> is there a good reason not to sync fltk ? (just asking because a debian package that fixes the ubuntu changes was released a month ago, but didn't get synced)
<Kmos> Lutin: http://packages.qa.debian.org/f/fltk.html -> this one? it's removed
<Lutin> Kmos: fltk1.1 actually
<Kmos> ah :)
<cjwatson> dajhorn: about 11 hours
<dajhorn> cjwatson: Ty.
<cjwatson> SEJeff: for the record you can always assume that 403 from security.u.c means "busted package, we're working on it"
<SEJeff> cjwatson, ok. Just wanted to make sure someone was aware of it
<cjwatson> it is part of the procedure for dealing with such breakage and there is no other situation in which that happens
<cjwatson> (short of wildly implausible bugs)
<SEJeff> cjwatson, Isn't that what qa is for?
<cjwatson> SEJeff: of course, but there is always a need for a fallback
<cjwatson> SEJeff: by their nature, security updates cannot be QAed as widely as normal updates, and sometimes things go wrong; even then, sometimes things slip through the net
<SEJeff> cjwatson, I figured Canonical had an automated testing suite. Not to dog on you or anything... but things like the xorg update debacle in Feisty are unacceptable for a distro this big.
<SEJeff> Keep up the good work
<slangasek> SEJeff: Samba upstream and Red Hat have the same bug in their security update
<jdong> I made a comment on the bug report (bug #163042) about this...
<ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Critical,In progress] https://launchpad.net/bugs/163042
<jdong> am I correct in understanding that on Dapper applying this patch results in Samba not starting at all?
<cjwatson> SEJeff: this procedure was put in place after the X update problems in Dapper (which I suspect may be what you mean)
<SEJeff> cjwatson, yes. Ok good
<SEJeff> Get the distros mixed up. Have played with it since Warty
<cjwatson> and in general we significantly tightened procedures after that
<cjwatson> one item slipping through the net does not mean that the procedures suck. obviously we review each failure to see how we could have avoided it
<slangasek> SEJeff: for the issue that's affecting feisty and gutsy, that is; for the bug that's specific to dapper/edgy, that's our fault, but there's not much sense in making a fixed package available that fixes that problem without also fixing the smbfs problem, for which we're still waiting on upstream...
<SEJeff> bugs are inevitable. It isn't anyone's fault as it is just part of the game.
<slangasek> bugs may be inevitable on the whole, but that's not a reason for us to not take responsibility for them :)
<keescook> jdong: no, it didn't show up in Dapper testing.  it takes a specific configuration.
<jdong> keescook: ah, ok, that's good to hear
<minghua> jdong: May I poke you again for bug 160361?
<ubotu> Launchpad bug 160361 in gutsy-backports "Please backport scim-hangul 0.3.1-1ubuntu1 from hardy" [Undecided,New] https://launchpad.net/bugs/160361
<jdong> minghua: ah sure lemme take a look at that
<jdong> minghua: taken care of, sorry for the long delay
<minghua> jdong: Thanks!
<Mez> er, what the ****
<Mez> Err http://security.ubuntu.com gutsy-security/main libsmbclient 3.0.26a-1ubuntu2.1
<Mez>   403 Forbidden
<slangasek> Mez: a security update that was pulled due to an undetected regression; see above
<Mez> slangasek, can't see above
<slangasek> ok, then see bug #163042 :)
<ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Critical,In progress] https://launchpad.net/bugs/163042
<cjwatson> Mez: 403 from the archive always means "broken update, we are working on it, no need to tell us"
<Mez> cjwatson, cool, thanks... not actually come across it before... but I guess thats caus eI usually run the dev versions :d
<Mez> think this is the longest I've stayed on the current release1
<Mez> o_O Hobbsee is part of ubuntu-archive?
<Mez> uber :D
<nenolod> hi.
<nenolod> oh, already reported.
<nenolod> :P
<somerville32> lol
<somerville32> A lot of noise of this
<somerville32> s/of/from
<emgent> heya people :)
<puzzud> puzzud: Hey guys, it appears some samba files were uploaded/created today that I can not access... are the file permissions correct with:  http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient_3.0.26a-1ubuntu2.1_i386.deb  ?
<drarem> so i have glade and anujta, is that all i need for gtkmm or is there another recommended route to go?  I want to make cross-compatible applications (using the ftp lib stuff) and a nice gui
<cjwatson> puzzud: the update was broken and has been withdrawn deliberately to avoid breaking more people's stable systems; a fix is being worked on
<drarem> in glade, how do you resize those controls??
<puzzud> cjwatson: do you think it will take long?
<cjwatson> puzzud: I cannot give you a time estimate, but it's being worked on pretty hard
<cjwatson> puzzud: the version you have is fine though; the security problem was "just" a denial of service and not believed to be exploitable, so don't panic
* puzzud changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not suppocation development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<puzzud> o shit
<puzzud> sorry
<keescook> puzzud: new versions should be available in about 3 hours, I'd guess.
* puzzud changed the topic of #ubuntu-devel to: The topic for #ubuntu-devel is: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<puzzud> thx keescook, my kubuntu system is now in a sort of mixed chaotic state with dependencies on the broken samba
<jdstrand> puzzud: updates have been uploaded and are currently building
* cjwatson changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<Chipzz> heh
<Chipzz> is this normal?
<Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/smbclient_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
<Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
<Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-common_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
<puzzud> Chipzz: yea
<Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
<puzzud> Chipzz: fixes are being worked on a broken update
<keescook> puzzud: you should be able to force downgrades   apt-get install samba=3.0.22-1ubuntu4.2 etc
<keescook> (e.g. for edgy)
<cjwatson> Chipzz: discussed about ten or fifteen lines above your question
<puzzud> maybe I should change the topic again and put the samba info in there ;)
* cjwatson changed the topic of #ubuntu-devel to: Archive: OPEN | samba security update is broken and  deliberately 403 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
* cjwatson changed the topic of #ubuntu-devel to: Archive: OPEN | samba security update is broken and deliberately 403 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<puzzud> hehe
<Chipzz> cjwatson: just outside of my what was visible on my screen apparently ;)
<cjwatson> when it's something that might be considered commonly visible, a little use of scrollback wouldn't go amiss
 * Chipzz pleeds guilty
<somerville32> Wouldn't it be a good idea to put debootstrap for hardy in the ubuntu developer team PPA?
<somerville32> That way instead of downloading it manually, developers can add it to their sources list and always have the most up to date copy
<jdong> somerville32: I could've sworn I backported debootstrap from hardy to gutsy already....
<LaserJock> yeah, generally it's backported
<jdong> debootstrap | 1.0.7~gutsy1 | gutsy-backports | source, all
<somerville32> I guess I did it before it was backported
<cjwatson> I also backported it to dapper+edgy+feisty this evening
<cjwatson> so people can pin it from -backports
<jdong> awesome, thanks cjwatson :)
<LaserJock> keescook: are USNs sent out after a fix has been released?
<keescook> LaserJock: yes -- there are some automated systems that expect to be able to download the mentioned files, etc.
<LaserJock> keescook: so is there any good way of seeing security TODO stuff for Universe at this time? without grubbing around a lot
<LaserJock> Fujitsu might know
<LaserJock> keescook: and is all security for Main apps handled by Canonical?
<Fujitsu> LaserJock: Hi. There's no easy way to see it, because LP is braindead. There's no way to search on a security flag, and no way to search a subscriber's bug list by component.
<LaserJock> Fujitsu: so there's really no way to have a list of CVEs for Universe?
<Fujitsu> You can search a project/distro/distroseries for a subscriber's bugs by component, but then you need to perform 6 separate searches, and a number of the bugs will be displayed a large number of times, due to another LP bug.
<Fujitsu> LaserJock: You *can* search for bugs with CVEs linked, but that's not all of them.
<Fujitsu> And we haven't got anywhere near all of them filed... because LP's CVE tracking features are braindead.
<LaserJock> hmm, that's a bit ... suboptimal :-)
<LaserJock> what's done for Main?
<Fujitsu> ubuntu-security gets emailed about all security bugs, I guess.
<Fujitsu> But non-Canonical people can't be on ubuntu-security, so we will never be emailed about universe bugs.
<LaserJock> hmmm, again suboptimal for Universe
<LaserJock> can we get any data from Debian?
<Fujitsu> Slightly, yes.
<Fujitsu> That's what I was working on last night.
<Fujitsu> I've attacked their security tracker so that it tracks feisty/gutsy/hardy too.
<LaserJock> ok
<Fujitsu> LaserJock: Wanting to help with getting universe slightly less completely insecure and dangerous?
<LaserJock> not sure yet
<LaserJock> I'm actually more interested in some Main packages
<LaserJock> but maybe :-)
<sistpoty> Fujitsu: btw.: who can upload to security pockets for universe nowadays?
<Fujitsu> sistpoty: keescook.
<Fujitsu> As well as jdstrand and infinity, I guess.
<sistpoty> Fujitsu: ah... does that hinder current security updates?
<Fujitsu> Not so much normally, but with UDS and AllHands there is a fairly large backlog.
<keescook> LaserJock: I haven't found a good way to look a subscription AND universe package lists.  :(
<keescook> LaserJock: Canonical is committed to fixing issues in main, but help is always appreciated.  :)  There is a lot of work to be done.
<LaserJock> keescook: but how does one help if they are a community dev?
<Fujitsu> LaserJock: Find a bug, attach a debdiff. Same as universe.
<keescook> LaserJock: I'm hoping (next week if I can managed it) to publish the ubuntu CVE tracker in a more searchable form.  LP's handling of CVEs isn't quite ready for useful reports yet.
<Fujitsu> Or a lot of debdiffs, as we now have a lot of releases.
<LaserJock> can I see the bugs?
<Fujitsu> Unless they're embargoed.
<Fujitsu> Which not many are.
<keescook> LaserJock: as Fujitsu says.
<Fujitsu> keescook: We have a CVE tracker?
<Kopfgeldjaeger> n8
<Fujitsu> LP's is useless, and feature requests to make it useful have been open for 2.5 years.
<keescook> Fujitsu: here'
<keescook> erk
<keescook> LaserJock: here's the URL I use: http://tinyurl.com/2gjo2q
<keescook> Fujitsu: yeah, it's in a bzr tree: http://people.ubuntu.com/~pitti/bzr/ubuntu-cve/
<LaserJock> keescook: yikes, that's quite a list
<Fujitsu> keescook: What do you think of trying to take some data from Debian's security-tracker?
<LaserJock> obviously some are more important than others :-)
<Fujitsu> They maintain a list of NFUs, etc, which would be nice to share.
<keescook> Fujitsu: we already try to share.  What I'm hoping to do is publish sort of a "merged view"
<Fujitsu> keescook: I didn't know that existed.
<keescook> kind of like MoM but for security updates.
<Fujitsu> keescook: That would be really great. If you want any help, I'd be glad to, as it's probably better than hacking up the secure-testing code to do Ubuntu releases too.
<keescook> Fujitsu: right, my first step was to actually examine the secure-testing code.  I wanted to work as closely as possible to their svn, but it's not optimized for note-taking and lots of packages/releases.  The debian kernel-sec tracker's layout was better for that.
<keescook> so I ended up modelling it after that.
<Fujitsu> keescook: Is there another branch somewhere, or have you just not commited updates for a couple of months.
<Fujitsu> *?
<keescook> Fujitsu: I think the working directory isn't being updated, but if you "bzr branch" from it, it should have very recent commits
<Fujitsu> keescook: Ah, right, pushes don't update the working copy.
<keescook> One piece of code that didn't get finished in the re-arch is the changelog parser.  Then it can warn about or assist in closing CVEs where a changelog entry is found.
<Fujitsu> keescook: Does it scan *-changes?
<keescook> Fujitsu: the prior code actually browsed the changelog tree on the archive, and spidered the Debian changelog URLs.  it's a bit heavy.  :P
<Fujitsu> ... ouch.
<Fujitsu> I guess it works if it runs in the DC, though.
<Amon_Re> Hey peeps
 * Amon_Re is looking for any good instructions on building .deb files
<Fujitsu> Amon_Re: -> #ubuntu-motu (see /topic)
<jpatrick> !packaging > Amon_Re
<Amon_Re> thx mates ;)
<Lutin> keescook: just wanted to make sure : do you have changes to dsniff planned (in hardy) ? otherwise, I'll request a sync
<keescook> Lutin: nothing from me, if the ubuntu changes are in Debian, yeah, for for a sync.
<Lutin> keescook: ok
<Burgundavia> LaserJock: you finished your PHD yet? Do we need to stage an intervention?
 * Fujitsu notes that this unstable/development release is actually unstable for him.
<cjwatson> keescook: btw, I'll try to get to the openssh thing soon and get it fixed in hardy
<cjwatson> I'd rather do it by upgrading wholesale to 4.7 though
#ubuntu-devel 2007-11-17
<LaserJock> Burgundavia: bahhh, leave me alone ;-)
<keescook> cjwatson: cool, thanks.
<Fujitsu> keescook: In ubuntu-cve, what do you do about CVEs in universe packages at the moment?
<keescook> Fujitsu: currently we just document them, and marked the "needs-triage"
<keescook> (but this is why I want to changelog scanner running again -- the universe CVEs are getting out of date)
<Fujitsu> keescook: Do you attach package references to them? (sorry, still checking it out, X died on me a couple of times)
<keescook> Fujitsu: yes, we assign the CVE to packages.
<keescook> (the "new CVE" process is codified in the "check_cves" script in the root dir of the tree)
<Fujitsu> I would explore, but I fear the working copy in ~pitti is woefully out of date.
<keescook> it basically display information about the CVE, and then prompts for package name, etc, then spawns and editor after populating the new CVE file
<Fujitsu> Aha.
<keescook> Fujitsu: the bzr tree is okay, so a local "bzr branch" of it should be fine.
<Fujitsu> keescook: Right, I'm doing that now; it just takes a while.
<keescook> true.  The "README" in the root dir is good too.
<Fujitsu> (and -intel being really unstable and occasionally hard-locking at the moment doesn't help)
<keescook> (let me go see if I can convince the working tree to update...)
<Fujitsu> A bzr up in ~pitti/bzr/ubuntu-cve should do it.
<Fujitsu> Hm, maybe a co.
<Fujitsu> If rookery even has a recent enough bzr, that is...
<keescook> woo, it worked.
<Fujitsu> Aha, thanks.
<keescook> if people want to start helping with the tracking, I'll likely move it to a bzr tree on LP
<Fujitsu> I'll definitely be going through it regularly and filing bugs for universe stuff, and hopefully getting some if it fixed.
<keescook> Fujitsu: cool; one of the other script I was hoping to write was an auto-LP-bug-opener
<Fujitsu> keescook: That would be good.
<Fujitsu> Yay, checkout finished.
<keescook> I figure it'd look up the CVE, check for the pkg, and if it's not there, open a new bug.  with python-launchpad-bugs it should be pretty straight forward.
<keescook> heh
<Fujitsu> keescook: I presume you would know this if anybody did: is there a way to apt-get source something like `sourcepackage/release'?
<keescook> Fujitsu: if there is, I haven't found it.  I tend to use sbuild+LVM and do the apt-get sources inside the chroots
<keescook> schroot -c dapper "apt-get source ...."
<Fujitsu> Ah.
<Fujitsu> Yep.
<Fujitsu> keescook: DNE is for stuff that just isn't packaged, NOT FOR US is stuff that will never be?
<keescook> Fujitsu: there is a bit of confusion there, but basically, yes.
<keescook> jdstrand was making the distinction, but I haven't tended to.
<keescook> NFU would be for totally alien things (cisco, microsoft, etc), DNE for random php CMSs, etc
<Fujitsu> I can see it might be useful at times.
<Fujitsu> Yep.
<Fujitsu> That's what I thought.
<keescook> Fujitsu: I've updated the README a bit to clarify
<keescook> (haven't pushed yet)
<Fujitsu> keescook: Thanks.
<emgent> heya keescook ^^
<keescook> hi emgent !
<emgent> all good ? :)
<keescook> emgent: I need another 10 hours a day.  I'll have to move to Jupiter or something.  :)
<emgent> ehhehe
<lamont> keescook: net connectivity will be very laggy from there.
<Fujitsu> lamont: Just a bit.
<keescook> lamont: crap, good point.  radiation I can deal with.  latency, though.... no way.
<Fujitsu> keescook: Are we manually tracking things synced into Hardy at the moment?
<keescook> Fujitsu: yeah, there's nothing automatic in the CVE tracker at this point.
<lamont> keescook: someone was talking in church a few years back about "what's important" based on his getting a job offer to an island off the coast of south america.  My singular question when he started the discussion (to myself, not out loud) was "How fat is the pipe???"
<Fujitsu> keescook: And autosyncs aren't logged anywhere. Joy.
<keescook> lamont: hehe. when I was comparing climates when moving away from Chicago, "is there any technology?" was the first question after climate.  Pago Pago was right out.  :)
<lamont> exactly
<Fujitsu> keescook: What's the correct status if a release already has the fix? (not in SECURITY, but RELEASE)
<keescook> Fujitsu: if it's in hardy, it's the "devel" release, in which case I tend to mark things as "not-affected" if they were okay when I got there, or "release ($VERSION)" if I had to apply fixes
<keescook> if it's an earlier release and the CVE is just out of date or wrong, I would mark it not-affected
 * desrt allows google to convince him that "kees" is a valid nickname for people named cornelius
<Fujitsu> keescook: OK. (there's very little documentation on what the statuses are for...)
<keescook> heh
<keescook> Fujitsu: valid point, I can add a section for that.
<slangasek> desrt: even though neither google translate nor babelfish substantiates the claim that "kees" is a Dutch word for "horn"? :)
 * keescook is confused now
 * desrt too
<Fujitsu> keescook: Is the upstream_blah field meant to contain the fixed version?
<keescook> Fujitsu: yeah, look in the retired/ tree for recent CVEs.
<Fujitsu> Good point.
<slangasek> keescook: by me, or by something security-ish?
<keescook> slangasek: by you.  where is the "horn" claim from?
<slangasek> keescook: one of the google hits I found when I was looking for it said that etymologically, "kees" is a nickname for "Cornelius" because it's a Dutch word meaning horn (where "cornelius" < Lat. CORNUS, horn (of an animal))
<slangasek> but then I couldn't find anyone that agreed this is what "Kees" meant in Dutch :)
<keescook> slangasek: bizarre.
<keescook> google of "kees cornelius" shows all sorts of people with stuff in ()'s.  :P
<keescook> http://en.wikipedia.org/wiki/Dutch_name
<slangasek> yes, but all that proves is that you've compromised google. and wikipedia.
<keescook> slangasek: *rofl* if only.
<keescook> (is there a "blame" view in wikipedia?)
<slangasek> not AFAIK :)
<keescook> sweet.  then you'll never find n0tk33s's strategic edits!
<Fujitsu> Heh.
<BBHoss> anybody here know how to get ObjC code to compile on 7.10?
<BBHoss> i keep getting an error that cc1obj cant be found
<minghua> BBHoss: Do you have gobjc package installed?
 * Hobbsee waves
<keescook> heya Hobbsee
<BBHoss> lemme check
<Hobbsee> keescook!
<BBHoss> apparently not :)
<BBHoss> cool thank minghua
<jdstrand> Fujitsu, kees: wrt NFU and DNE, I have basically said that NFU is for something that will/cannot be used in/on Ubuntu (eg Cisco IOS), but DNE is something that could actually run on Ubuntu (ie php apps), but isn't in the archive
<jdstrand> but like kees said, it's really pretty loose and means the same thing in the end
<Fujitsu> jdstrand: That makes sense.
<slangasek> not-for-exist
<keescook> jdstrand: I'm add a section on "status"
<jdstrand> keescook: cool
<jdstrand> Fujitsu, keescook: I have on my TODO list to somehow check upstream_pkg against devel, and warn if it looks like it is fixed in devel (kinda like we do with retired)
<jdstrand> it'd slow things down though, so would likely need to be a separate script or option
<jdstrand> (I haven't worked out much beyond getting it on my todo list ;)
<keescook> jdstrand: ooh, yeah, that's another good way to find stuff.  frequently the changelog for such things will just say "New upstream release" without mentioning CVEs.
 * keescook adds a TODO file
<Fujitsu> jdstrand: That sounds good.
 * jdstrand hopes keescook doesn't get too crazy with that TODO file
<slangasek> cjwatson: did we have specific text to include for the update-grub ucf template?  this wasn't preserved in the gobby session
<slangasek> keescook: or maybe you remember?
<keescook> slangasek: oh... did we specify something like that?
<slangasek> keescook: well, there was some reason we didn't want to use the standard ucf text, but perhaps the replacement text wasn't fully specified :)
<keescook> slangasek: I don't think it came up, but since I'm not familiar with ucf, not everything made sense
<emgent> keescook, do you have tomcat ?
<keescook> emgent: "have", as in, installed?  I don't, no.
<emgent> uhm ok. np.
<keescook> but there is tomcat5 and tomcat5.5 in the archive.
<emgent> yes i saw
<emgent> but i found bug in tomcat 6.0
<keescook> ah, cool.  Yeah, that software has a lot of CVEs against it.
<emgent> I think in earlier versions too.
<emgent> it's a stupid XSS
<keescook> I think the other CVEs are mostly XSS too: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tomcat
<emgent> yes i'm in :P
<emgent> oh it's old uhm..
<emgent> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2449
<ubotu> Multiple cross-site scripting (XSS) vulnerabilities in certain JSP files in the examples web application in Apache Tomcat 4.0.0 through 4.0.6, 4.1.0 through 4.1.36, 5.0.0 through 5.0.30, 5.5.0 through 5.5.24, and 6.0.0 through 6.0.13 allow remote attackers to inject arbitrary web script or HTML via the portion of the URI after the ';' character, as demonstrated by a URI containing a "snp/snoop.jsp;" sequence. (http://cve.mitre.org/cgi-bin/cvename.cgi?
<emgent> poor tomcat :)
<keescook> heh
<Hobbsee> Mez: unfortunately, only by name at the moment.
<tonyyarusso> siretart: Under "Outstanding issues" on https://wiki.ubuntu.com/EncryptedFilesystems, would it make sense to have passphrase/key management available from multiple places?  For instance, it relates to partitions, so you should be able to do it in GParted, but it's also a password/encryption key management task, so it would seem to also make sense to have stuff in Seahorse.
<flake> using glade, how do i resize a button or other control on the window 'form' ?
<flake> oh i guess I add panes to the window and place/resize controls in there?
 * Hobbsee notes this is not a gtk help channel.
<flake> otay then..  where is it
<flake> and then.. how do you develop, what tools?  Qt?
<Hobbsee> for the kde stuff, yes.
<Hobbsee> for the gnome stuff, it's gtk.
<flake> i can see the panes in this Konversation app
<flake> ok
<flake> gnome apps work on kde, can kde apps work on gnome?
<LaserJock> sure
<LaserJock> why wouldn't they?
<Hobbsee> works fine here.
<Chipzz> flake: there are a number of gtk+ help channels on irc.gimp.org; among which #gtk+ and #pygtk
<pabs3> where can I find out about the magical juice that makes Ubuntu JeOS good for VMWare appliances?
<warp10> Hi all!
<_jm> Anybody who could run a quick GTK+ test program for me real quick? I'm experiencing a very weird bug, but it's so severe I want to ensure it's not a problem with my system.
<_jm> For some reason, using the U+FF5E character causes many CJK characters to stop displaying in GTK+. C version at http://pastebin.ca/778083 , Python version at http://pastebin.ca/778084
<_jm> Figured it was best to ask somebody to confirm this, rather than posting a bug and getting lots of "works for me".
<pasic> hi guys
<pasic> i tryed to access samba packages to upgrade/install but them cannot readable at security.ubuntu.comn
<pasic> -n
<pasic> is it normal, or mistake?
<_jm> <title> samba security update is broken and deliberately 403
<_jm> They found a problem with it after it was pushed out, so marked it forbidden to stop people from downloading it
<pasic> ok:) thx
<pasic> what time about when accessible again?
<_jm> Likely when the problem is fixed, and a new version pushed out.
<pasic> LOL just seen up line :P
<pasic> ok, thx ...
<jjones> security.ubuntu.com repository files inaccessible.. who do we tell?
<jjones> files at  http://security.ubuntu.com/ubuntu/pool/main/s/samba/ with "Last Modified" dates of 16-Nov-2007 have permissions set wrong
<lamont> jjones: see http://bugs.launchpad.net/bugs/163116
<ubotu> Launchpad bug 163116 in samba "libsmbclient: upgrade fails with error 403" [Undecided,In progress]
 * lamont sleeps
<jjones> ahhh.. wish I had spotted that on my own, thanks lamont. I'll pass the info along to others on Kubuntu IRC.
<lamont> jjones: generally speaking, if the file is 403, you _REALLY_ don't want it.  it has been totally intentional both times I've seen it.
<lamont> (as in it's bad enough that it's better to have all these questions than to let people download it...)
<jjones> The kubuntu irc seems to be more aware of it now too..  7 hours ago I got nothing.
<mdke> mjg59: around by any chance?
 * Hobbsee waves
<mdke> hi Hobbsee
<Kmos> * There's a session about how to properly read Stack traces in #ubuntu-classroom *
<\sh> moins
<\sh> slangasek, thx for taking care of xclass...
<jpatrick> doesn't the ubuntu font has accents?
<Chipzz> jpatrick: there is no such thing as the ubuntu font?
<jpatrick> ubuntu title font
<Chipzz> what on earth are you referring to? :P
<jpatrick> ttf-ubuntu-title
<Chipzz> heh
<Chipzz> anyway, you could probably take a look using something like gucharmap or something
<Chipzz> although I believe it does substitution for missing characters
<Chipzz> wow
<Chipzz> that font does look pretty small
<Chipzz> Get:1 http://archive.ubuntu.com gutsy/universe ttf-ubuntu-title 0.1-1 [9858B]
<Chipzz> very much possible it in fact does not have accents
<ogra> it doesnt have accents ....
<ogra> it was done by an australian (who doesnt use accents) focused on the ubuntu string (which doesnt have accents either)
<ogra> feel free to submit patches for accents ;)
<Hobbsee> bah.  who needs accents, anyway... </australian>
<jpatrick> ogra: and how could I do that?
<ogra> jpatrick, modify it, file a bug, attach a diff for the modifications you do to the source
<jpatrick> ogra: there appears to be a ttf-ubuntu at http://wiki.ubuntu.com/CatalanTeam/Grafisme with accents
<ogra> that should be included then
<ogra> jpatrick, hey, thanks :)
<jpatrick> ogra: don't mention it
<ogra> anything wrong ?
<jpatrick> nope
<ogra> :)
<jpatrick> just saying "bitte" :)
<ogra> ah :) gut
<ogra> hab ich falsch verstanden :)
<Skiessi> why nvidia-glx doesn't get updated to work with xserver-xorg-core?
<Skiessi> http://packages.debian.org/sid/nvidia-glx they have it already in debian :o
<Skiessi> or should I go talk about hardy in #ubuntu?
<Skiessi> oh they've restarted #ubuntu+1, I'll ask there
<cjwatson> slangasek: I haven't gone through all my notes yet, but I'm not sure we specified text
<cjwatson> I often tend to leave that up to the implementor in specs anyway ...
<kaleh> hello. how to set the path for a particular forlder, so as to run binaries from it?
<kaleh> do i have to use the setenv command?
<cjwatson> kaleh: please use #ubuntu or https://answers.launchpad.net/ubuntu
<kaleh> sure
<IntuitiveNipple> cjwatson: Am I correct that you're a bit of an installer wiz?
<jdong> IntuitiveNipple: that's an understatement :)
<IntuitiveNipple> hehehe... just I have a quick question. I'm creating automated scripts to build  Ubuntu User Mode Linux file systems and wondering if mkaing use of the installer logics might be a good way to go. Curerntly I'm doing deboostrap followed by a bunch of manual writes to various config files.
<Chipzz> IntuitiveNipple: depending on what you need to do you could also use debconf preseeding
<IntuitiveNipple> I was wondering if I could customize the server/alternate CD installer scripts or if that would be overkill!
<IntuitiveNipple> Chipzz: yeah, that's what I've been looking at. I'm trying to make it create an image that is identical to what the installers might create, to make prevent support issues because of differences in initial configuration
<cjwatson> IntuitiveNipple: it ought to be possible, although getting the right kernel in place could be a little tricky
<cjwatson> but you can do arbitrary stuff in preseed/late_command scripts, so ...
<cjwatson> an automated d-i install is certainly where I'd start
<IntuitiveNipple> I'm wanting to not put the kernel in, obviously. I just want to take it from the deboostrap packages point
<IntuitiveNipple> The UML kernel is a binary on the host, and once the script has built it, and deboostrap has run, it copies the kernel modules into place.
<IntuitiveNipple> OK, from what has been said it sounds like the way to go.
<cjwatson> IntuitiveNipple: try preseeding base-installer/kernel/image to 'none' for that, although you'll probably also have to go to a bit of effort to avoid installing a bootloader
<cjwatson> but it should all be possible
<cjwatson> (it's "debootstrap" BTW)
<IntuitiveNipple> lol... no it's 'spulling mistaks'
<jdong> deboostrap is used on Oct 31.
<attunix> How do I make my own X Windowing System?
<Chipzz> attunix: 1) please read the topic; this question is off-topic here; 2) your question is poorly formulated (ambiguous) and 3) supposing you think X itself is crap and you want to write something from scratch; don't. You're most likely looking at the output of top, thinking "OMG X eats a lot of memory! That must be inefficient!" and be terribly wrong about it
<attunix> Chipzz: 1) I know this is not an application development room, and it is on-topic, since I would like to attempt to implement this on an Ubuntu system. 2) I'll try to restate my question 3) I don't want to redesign X. GNOME runs on X. KDE runs on X. I want a windowing system like those two (more examples: XFCE, blackbox, etc.) and not make my own x-like thing.
<attunix> I mean windowing manager
<Chipzz> the fact that you want to implement it on an ubuntu topic still doesn't make your question on-topic ;)
<cjwatson> if you wanted to write your own window manager, you would need to start by reading the ICCCM specification
<Chipzz> s/ topic//
<attunix> ok
<cjwatson> but it is NOT for the faint of heart or for anyone who needs to ask questions along the way ...
 * Chipzz agrees
<Mez> why is it so damned hard to find someone to sponsor a package to debian (It's not like it's even a new package, it's just an update to a current package that I've mainained for about a year now!)
<Chipzz> attunix: btw, are you sure you want to implement a wm, or do you want to implement a desktop environment?
<attunix> Chipzz: what's the difference?
<Chipzz> a wm just draws the borders around windows. a DE consists of a wm plus other things (like a file manager and a panel)
<attunix> Chipzz: a windowing manager.
<Chipzz> you could argue that both the file manager and the panel are optional, and use something like gdeskltes instead
<Chipzz> *gdesklets
<slangasek> Mez: because your package has "nonfree" in the name ;)
<Mez> slangasek, true ;)
<Chipzz> attunix: btw, there are already a lot of wm's out there; have you tried all of them? a good place to start would be freshmeat (let me look up the link for you)
<attunix> ok, thanks :)
<Chipzz> attunix: http://freshmeat.net/browse/56/ may be a good place to start
<Mez> slangasek, *sighs* why I decided to maintain rar I don't know
<Chipzz> 153 projects found :P
<Mithrandir> Mez: then give it away?
 * Chipzz frowns; why does freshmeat consider cedega a wm? :P
<Mez> Mithrandir, I'm happy to do it, but not being a DD is a PITA
<Mez> cause finding sponsors is a Pain
 * Nafallo looks back and forth on Mez and Mithrandir a couple of times
<Nafallo> seems hard ;-)
<Mithrandir> Nafallo: no, I'm not going to sponsor random packages in Debian.
<Nafallo> :-)
<Mez> Mithrandir, I was assuming that you wont sponsor unless you've worked with me from the start with it
<Mez> however, I've had 2 sponsors dissapear on me so far - so need a new one
<Mez> (infinity was one of them!)
<Mithrandir> Mez: in this case, it's more that I'm spending little enough time on Debian that pretending to be your sponsor isn't something I want to do.
<Mez> Mithrandir, It's no problem, I know that you have a lot of things to do... hence why I didn't ask
<Mez> I know quite a few DDs in here, but a lot of them are either too busy, dont want to sponsor a non-free package, or wouldnt go for something that they havent walked through from the start with
 * Mithrandir nods.
<Mez> that's at least the reason why infinity stopped sponsoring me (the time issues)
<Mez> though it'd be nice if I could get NM sponsorship based on rar - make my life easier :D
<jdong> hmm can a driver evaluate bug #157867 for SRU?
<ubotu> Launchpad bug 157867 in pbuilder "pdebuild-internal broken when XSBC-Orig-Maintainer used because of faulty sed command" [Undecided,Fix released] https://launchpad.net/bugs/157867
<jdong> the patch is trivial
<jdong> and the debdiff I attached to the bug is already in SRU-ish format
<gnomefreak> when the ubuntu installer asks to import settings that doesnt include bookmarks and such right?
<Viper550> just wondering, is it possible to make a text-based install which is as fast as the graphical install?
<LaserJock> Viper550: depending on the hardware that's already done :-)
<Viper550> I mean, using the different method the live CD uses, I know for a fact that it doesn't use debian-installer in the Live CD installer.
<LaserJock> yeah sure
<LaserJock> I was just teasing
<LaserJock> I had an old computer that I tried a LiveCD install on
<LaserJock> and it was slower than the Alt disk
<LaserJock> it's certainly possible to make a text-based installer use a squashfs system like the LiveCD does
<Viper550> yeah
<Viper550> They truly need to do that, debian-installer is slow.
<Viper550> Think I should blueprint that idea?
<wasabi> Eh. I like d-i
<wasabi> I really dislike the livecd method of installing. =)
<LaserJock> Viper550: I would think a blueprint has already be created to cover that
<wasabi> d-i can be done over the network, etc.
<wasabi> since it uses apt to retrieve packages
<Viper550> I mean, have it "emulate" the process and UI of the installer, but make it use the Squashfs style system
<wasabi> Yeah. Discard the best parts? Psssh.
<LaserJock> a quite common request is to have the LiveCD have an option that installs without booting into the live system first
<Viper550> that'll add ANOTHER CD to the batch, we'd have Live CD, Alternate installer, and then the "advanced installer"
<Viper550> also
<wasabi> I really like how it is now.
<wasabi> LiveCD for UIish desktop people, d-i for people who want something more low level/customizable.
<Viper550> On Sabayon, if you're wondering how they handle launching the installer without the full desktop, they just load the installer through Fluxbox.
<wasabi> I wouldn't mind having a d-i frontend that used X.
<wasabi> But I must have d-i. ;)
<Viper550> they do have a d-i frontend with X
<LaserJock> Viper550: I think people have thrown around the idea of going lighter than fluxbox
<Viper550> openbox?
<LaserJock> no WM at all
<wasabi> We have a d-i X frontend that WORKS?
<Viper550> yeah.
<wasabi> News to me. I remember that being the original idea.
<wasabi> But nobody ever finishing it
<Viper550> http://www.cyberciti.biz/tips/wp-content/uploads/2006/08/debian-testing-gui-installer-paritition-disks-2.png final version uses a Clearlooks theme though
<Viper550> It's not default on Etch though, you have to type "guiinstall" at the boot prompt to use it
<wasabi> Oh, neato.
<Viper550> I have been wanting Ubuntu to maybe add that though
<Viper550> http://alioth.debian.org/~fjp-guest/tmp/g-i_new_banner_progress.png here's another shot but with the theme
<wasabi> I really like d-i. There's some rough parts of it, sure... but I like how easy it is to customize.
<wasabi> I have in a few instances added my own content to it.
<wasabi> The hackyness involved in using debconf for complex UI layout sucks.
<Viper550> What I wanted was maybe a text-based d-i "clone", emulates it exactly (maybe even using debconf), but copies files instead of installing packages.
<wasabi> why?
<wasabi> instaling packages is little more than copying fies.
<wasabi> And any other overhead should actually just be fixable.
<Viper550> but with debian-installer, it's gotta go through this "complex ritual" of configuring them and all that too.
<wasabi> It's not done on the LiveCD because you can't boot into packages/ ANd with a full desktop you can't fit a package of everything.
<Viper550> compress it?
<wasabi> It's already out of psace.
<wasabi> Lots of packages have postinst scripts that do nothing. Thouse should be fixed.
<wasabi> Lots of them that do things repeatidly, we have dpkg triggers now
<wasabi> THere's the slight CPU overhead of decompressing the files.
<wasabi> BUt you do sort of have that with the LiveCD too, since it's squashed
<wasabi> Hmm. In fact, makes me wonder if it's really the case that the d-i shouldn't be possibly made FASTER than the LiveCD. Reading a single .deb from a CD is no doubt faster than reading thousands of files individual.
<wasabi> seeking on a CD is not good.
<luk__> s/guiinstall/installgui/
<jdong> wasabi: the livecd is compressed way harder than .deb packages...
<jdong> AFAIK squashfs uses gzip level 9 basically
<wasabi> ahh
<wasabi> WHy can't data.tar.gz be done that way?
<jdong> the main overhead with ubiquity is that of the live environment to begin with
<jdong> unpackaging .debs definitely is more IO intensive than what ubiquity does.
<wasabi> Mind explaining how?
<jdong> there are still postinsts that do real work
<wasabi> Sure.
<jdong> while that would be "cached" on a liveinstall
<jdong> because the results of the postinst scripts would be saved essentially.
<wasabi> Of course.
<jdong> not to mention temp files are written, dpkg databases are written, dependencies are resolved, and so on in a dpkg based install
<wasabi> Heh. okay. ;)
<jdong> I don't think d-i can ever become faster than a copy-the-files based install method... it can probably get very close though
#ubuntu-devel 2007-11-18
<cjwatson> LaserJock: we already have a way to launch the installer without going into the desktop, even though it's hidden. Boot with the 'only-ubiquity' boot option
<LaserJock> cjwatson: what does that do?
<LaserJock> I remember there being discussion about it
<cjwatson> wasabi: you can argue against a text-based UI for ubiquity if you like, but it's mostly already done ...
<LaserJock> does it start X and then run ubiquity without any WM?
<cjwatson> LaserJock: starts X, metacity, gnome-settings-daemon, and ubiquity
<LaserJock> ah, so you still have metacity
<cjwatson> it needs a WM, but not the full desktop furniture
<LaserJock> right
<cjwatson> ubiquity uses dialog boxes - you can't do that without a WM
<LaserJock> right
<LaserJock> what does that do for the RAM requirements?
<wasabi> cjwatson: What are the plans regarding d-i?
<wasabi> I'd be very sore if d-i vanished.
<cjwatson> wasabi: data.tar.gz can't achieve the same level of compression as squashfs because the blocks can't possibly be as big: squashfs blocks can span multiple packages
<cjwatson> wasabi: d-i isn't going away, don't worry
<cjwatson> LaserJock: knocks a good chunk off, but I don't have the numbers to hand
<cjwatson> we may well switch to that by default in hardy
<cjwatson> and the d-i X frontend has never been good enough for my satisfaction, which is why we don't build or ship it
<cjwatson> (though I put a lot of work into it myself in the early days)
<wasabi> Yeah, I remember that.
<StevenK> cjwatson: What's lacking that doesn't make it good enough?
<cjwatson> StevenK: plugins for all the complex UI
<cjwatson> like the partitioner
<StevenK> Oh, right. It's in X, but still uses the horrible menu partitioner. Ew.
<cjwatson> the facilities are there (er, mostly; there's still a little bit of libd-i and anna work that needs to be done), but nobody's sat down and written code to make it better than the generated UI
<wasabi> That's generally something which is simply lacking mostly in debconf
<cjwatson> wasabi: no
<wasabi> Good integration with task specific UI
<cjwatson> that's simply not true
<wasabi> Oh
<wasabi> ?
<cjwatson> cdebconf supports plugins
<cjwatson> I wrote the code
<wasabi> plugins for specific UI modules for specific toolkits?
<cjwatson> yes
<wasabi> Huh. So what is lacking in it then?
<cjwatson> somebody actually writing the plugins
<wasabi> Why the push for ubiquity instead of that?
<wasabi> Simply because of the LiveCD requirements?
<cjwatson> partly that it was much harder to do the plugins in d-i than the way ubiquity does it, and partly because we needed to be able to ship an installable live CD for other reasons
<cjwatson> being able to ship just a live CD instead of install+live cuts Canonical's shipit costs down to a third of what they were ...
<cjwatson> and there was the speed thing too
<wasabi> Yeah.
<wasabi> So, wonder if there could be an optimization in d-i to use preexisting package source instead of actually doing the work? :)
<cjwatson> "preexisting package source"?
<wasabi> "oh, you're trying to install foo.deb, how about I just grab these files from /, put them in the right place, and pretend you did install foo.deb"
<cjwatson> somebody wrote a live-installer udeb for d-i in Debian
<wasabi> What I like about d-i is the ability for me to build my own pieces in it. I do it for large installations.
<wasabi> Custom installers for different organizations, that integrate their own UI pieces, and/or apt soruces and package lists.
<cjwatson> it doesn't really belong at the level of installing individual .debs though; you won't get a meaningful speedup out of that
<wasabi> Usually netbooted, etc.
<cjwatson> sure, that's a large chunk of the reason we support d-i
<cjwatson> ubiquity's a great desktop installer but I don't expect it ever to be customisable on the fly to the same extent
<cjwatson> effort on converting more packages over to triggers would be appreciated
<cjwatson> a lot of that will be fixed in Debian as soon as triggers get merged there
<cjwatson> Joey is champing at the bit to delete huge wodges of debhelper
<StevenK> I can't wait for texlive to get trigger support. That would make upgrades even faster.
<cjwatson> I will probably slow them down a bit again with man-db ;-)
 * StevenK chuckles
<cjwatson> (but doing so fixes an ancient bug so I think it's worthwhile)
<StevenK> That's the manual pages encoding one, right?
<ion_> Also enhancing linux-imagesâ trigger support would be nice.
<cjwatson> StevenK: no, having the database updated automatically after package installation so that apropos and whatis work immediately
<StevenK> Ahh
<cjwatson> encoding is nearly all fixed now
 * StevenK notices the time and runs off to lunch with his sister in law
<cjwatson> modulo a few bugs (fixed upstream) you can use UTF-8 manual pages
<cjwatson> need to get the exact layout agreed though
 * cjwatson -> bed
<ion_> Btw, the version of openssl in gutsy-{security,updates} is greater than the version in hardy.
<emgent> heya
<beewee> Can anybode tell me whether the browsers in K/Xubuntu send K/Xubuntu or just "Ubuntu" inside the HTTP_USER_AGENT? Nobdody in #ubuntu and #ubuntu-de was able to answer this :/
<beewee> *anybody
<persia> beewee: I don't know offhand, but I suspect you'll do well to either check the source or with https://answers.launchpad.net/ubuntu/
<beewee> ok, I created a question in launchpad
<persia> beewee: Thanks.  Sometimes it takes a while to get a response, but that's the best escalation point when #ubuntu doesn't know.  Frequently the developers don't know offhand either, and are working on other things.
<beewee> ok :)
<shodges> hey, does anyone know of good documentation for packaging a *new* project? The packaging guide on the wiki seems to imply that you are repackaging an existing project...?
<IntuitiveNipple> lol yeah, it is a bit mean like that isn't it!
<persia> shodges: How do you mean a "New" project?
<shodges> well, i'd like to build a deb package for a project i've been working on, but instead of using checkinstall i want to do it properly, so i learn how to package at the same time
<IntuitiveNipple> There's one in the 6.10 Wiki, showing how to create a package from scratch, based on simple 'hello' example: https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/basic-scratch.html
<persia> IntuitiveNipple: That's a good resource, but it's a little out of date.
<persia> shodges: https://wiki.ubuntu.com/PackagingGuide/Basic tries to cover new packaging.  Is there something else you think is missing there?
<IntuitiveNipple> persia: no kidding... trying to find anything was hard though, so have to make do
<shodges> IntuitiveNipple, persia, thanks i've got that guide in front of me at the moment. The problem i'm having is it seems to imply i want to "apt-source" my project from the repos, but its not there because i made it from scratch
<persia> shodges: Aha!  Thanks for pointing that out.  I'll update the docs to be more clear.  If you have a tar.gz, and you rename it to an .orig.tar.gz, you can proceed: the apt-get source hello is only to grab an example.
<IntuitiveNipple> Yes, that was my issue when I started with packaging. It all assumes someone else created the code
<IntuitiveNipple> It would be good to have a link-out to actually creating a new package from original source-code
<persia> IntuitiveNipple: Do you mean including instructions on how to generate an orig.tar.gz from a source tree?
<IntuitiveNipple> I wanted to know things like, best-practice in naming directories, common directories to use ( for things like po, etc.,)
<shodges> ah ok, i'll give that a try, thanks. just for clarification, i should tar up my code and rename it to *.orig.tar.gz, in the same dir structure that the guide instructs?
<IntuitiveNipple> persia: If that requires more than just a simply tar -cxf package.tar.gx ./package-1.0   then yes
<IntuitiveNipple> I wanted to create a project template directory I could use as the basis for creating a new ubuntu/debian packages at will... that'd be cool
<persia> IntuitiveNipple: That's about it.  I tend to prefer 'tar czf mypackage_1.0.orig.tar.gz ./mypackage-1.0`. :)
<IntuitiveNipple> so it'd have the debian/ directory and templates of control changelog and all other required files ready to go
<IntuitiveNipple> Spelling it all out is the important thing, because so much of existing docs assumes you understand the nuances of packaging in many ways.
<IntuitiveNipple> like the po issue I had, for example.
<persia> IntuitiveNipple: There's a package called dh-make that includes templates for most things.
<IntuitiveNipple> ahhh see? nuance!
<shodges> IntuitiveNipple, persia, i used dh-make to build my template debian dir, glad to hear i'm not going in the wrong direction :)
<persia> shodges: You'll want to wrap your code so that the tarball expands with a single top-level directory, and calling the build rules from that directory builds the software.
<persia> shodges: You will want to not put debian/ in your orig.tar.gz, to make things easier if the software later also gets distributed in other distributions.
<shodges> ok, makes sense
<persia> IntuitiveNipple: If you have more suggestions for dh-make, I'd recommend submitting patches.  The more that can be easy to learn, the better.
<IntuitiveNipple> I seem to recall using dh_make for the debian bits.
<IntuitiveNipple> persia: My main issue was just lack of clear documentation on creating a brand new source project and packaging.
<persia> IntuitiveNipple: Hrm.  The lack of documentation on making a brand new project (which would later be packaged) seems separable to me, but it would be nice to have something.  I'm adding the bit about generating an orig.tar.gz from scratch to the packaging guide now.
<IntuitiveNipple> Thanks.
<persia> IntuitiveNipple: I've never actually created a project from scratch: I don't suppose you'd be willing to author a first draft for that document?
<IntuitiveNipple> Yes, a separate recommendation on best-practice in creating a new software project that will not cause issues with debian packaging later, along with the pros and cons of the various patch-management systems, would be ideal
<persia> Just basic things like supporting a variable to tell it where to install (for /usr vs. /usr/local), and putting everything in a source tree, and not including debian/, and copyright/licensing for everything, and source for everything, etc.
<IntuitiveNipple> persia: I could try, but I'm not sure myself, thats part of the problem! For internationalisation there's all the po stuff. I'm still trying to understand that. Then there's gnome-specific stuff like the glade file (where best to put it/them), having a ./src/ directory, when to use a separate ./include/ directory. How to integrate with what autoconf requires!
<persia> IntuitiveNipple: Right,  It's lots of stuff.  I'd suggest putting a big WIP on the top of the page, but if you can get enough started that others contribute, soon we'll have a good reference.
<IntuitiveNipple> I end up actually not bothering to package my stuff because I end up wasting time trying to get the packaging sorted out
<IntuitiveNipple> I've been flowcharting the entire process, including every patch system, in order to understand it
<persia> IntuitiveNipple: That seems a bit extreme.  There's so many different ways to package, that trying to map it all is a huge effort.  Personally, I tend to focus on the couple I know well, and only learn more when I'm working on a package that requires it.
<IntuitiveNipple> Well, I'm writing an automated packaging tool for myself so when I'm bug-hunting, actually providing the fixed package debdiff becomes trivial! You saw what happened with my KVM/QEMU packaging :)
<IntuitiveNipple> So the flow chart is proving extremely useful because it captures every possible path and makes it easy for me to check my understanding with people who know, simply by showing them the flowchart
<persia> IntuitiveNipple: Interesting.  As you get closer to completion, I'd like to see the tool.  There's definitely a gap between checkinstall (easy and produces broken packages) and dh_make (requires lots of understanding, and tries to do too much).
<IntuitiveNipple> I was debating whether to write it for Eclipse (where I do all my development) or Gnome (so it can be used by others) I've decided on gnome so I'm working up the GUI now. I can then have a python back-end that can also link into Eclipse
<IntuitiveNipple> persia: If you're willing to review/amend the .dia document I use then I'm sure it could be quite bullet-proof
<persia> IntuitiveNipple: I'm swamped now.  If you email it to me, I'll take a look when I can, but I suspect you'd do as well to push a couple more revs first (depending on your update rate).  Also, I can't promise complete understanding: I just learned about another packaging tool last week.
<IntuitiveNipple> persia: Yes, I can imagine. I know the feeling well :)
<persia> shodges: Does the addition of the tar call in  https://wiki.ubuntu.com/PackagingGuide/Basic help, or is it still unclear?
<IntuitiveNipple> Once I get my new web-app front-end up and running it'll be online
<soc> hi
<soc> looks like breakage arrived today :-)
<soc> i get /dev/null: permission denied, does someone have an idea?
<shodges> persia, the tar call addition clarifies what you both have explained - just one thing, should the command say "tar -zcf hello-2.1.1.tar.gz hello-2.1.1" ?
<shodges> it currently says "tar xzf ..."
<persia> shodges: I always use "czf", but it the order doesn't matter, so it could be "zcf".
 * persia thought that was fixed before the URL announcement, but was perhaps too slow
<shodges> cool, good to know
<persia> shodges: Thanks for the feedback.  Good luck with packaging.  If you have questions, I'd suggest asking in #ubuntu-motu, as this channel is usually much busier with developer coordination during the week.
<shodges> thats great, thanks for your help - i'll switch to ubuntu-motu next time
<IntuitiveNipple> while I think about it. Does anyone have any ideas as to what could be keeping a loop-mount busy after chroot-ing into it, or running a chroot shell?
<IntuitiveNipple> I've created an automated script that builds  UML Ubuntu file-systems, but after it has run "sudo chroot ./root apt-get install ubuntu-minimal" umount reports it is still busy, although lsof doesn't show anything using it.
<persia> IntuitiveNipple: It may be that you've started a daemon?
 * Spads suspects dbus
<Spads> that's what always holds my chroots open
<IntuitiveNipple> Spads: really?
<Spads> IntuitiveNipple: statistically, yeah.  You can check yourself though
<persia> IntuitiveNipple: You might want to look at schroot: I think there's a patch to that that kills everything when closing the chroot.
<IntuitiveNipple> hmmm, I saw mention in my searches of avahi having a chroot helper but stopping avahi didn't help. I can't really stop dbus :)
<Spads> do an lsof
<IntuitiveNipple> persia: Thanks, that might help, although it would be good to know what is managing to hold it busy and yet not show up
<IntuitiveNipple> Spads: Thats the thing, lsof shows nothing at all
<IntuitiveNipple> I've tried stracing it too, so far no luck
<Spads> there's a +c0 trick you can do that I never had fully explained to me
<IntuitiveNipple> with lsof?
<Spads> yeah
<Spads> lsof +c0 | grep /my/chroot/path
<Spads> or something
<Spads> you'll want to kill stderr
 * Spads vanishes
<IntuitiveNipple> " +c w     This  option  defines  the  maximum  number  of  initial characters of the name"
<IntuitiveNipple> " If w is zero (â0â), all command characters supplied to lsof by the UNIX dialect will be printed."
<IntuitiveNipple> Suggestions for a trivial package to install using apt-get to test this chroot issue - my mind has gone blank!
<persia> IntuitiveNipple: hello
<IntuitiveNipple> lol
<IntuitiveNipple> doh
<IntuitiveNipple> grrr, now I can't get it to fail!
<Lutin> fabbione: would you mind testing linuxtv-dvb-apps 1.1.1-3 from debian and see if it works for you ?
<seb128> Lutin: the checkinstall changes look like things that should be sent to debian, could you do that since you did the package update?
<Protheus> Hi all
<Protheus> I am looking for ubuntu PS3 development channel. does anyone know its name?
<persia> Protheus: https://help.ubuntu.com/community/InternetRelayChat has the channel list.  You might try the powerpc channel.
<persia> Protheus: Also, it's the weekend in many places, so the developers may not be around.
<Protheus> Thx persia ...
<fabbione> Lutin: yes i do because my media box is "stable" and i just disconnected 3 hours ago to mount the new fornitures for the living room that will arrive this week :)
<Lutin> fabbione: ok :)
<fabbione> if you asked yesterday i might have done it
<fabbione> also.. what is the problem that needs testing?
<fabbione> the merge or what?
<fabbione> because IIRC the only delta was the DK DVB-T channels I added
<Lutin> fabbione: yeah, that's it. there are also frequencies for dk in the debian package, but quite different from yours
<Lutin> so I wanted to know if that worked, so that we can sync
<fabbione> do you have a diff handy? mine were "guessed" and did work..
<fabbione> the ones from Debian might be better
<fabbione> anyway just sync.. we can always fix it later
<Lutin> ok
<fabbione> it's in universe AFAIR.. right?
<Lutin> fabbione: indeed
<fabbione> Lutin: take the ones from Debian. They are good and better than mine
<Lutin> fabbione: ok
<fabbione> ++# Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp
<fabbione> mine was "sniffing" on dk-Copenhagen .. you don't want to know how ;)
<Lutin> lol :)
<Protheus> can someone point me to a linux kernel source packe? I cannot find the package ... I don't know what do look after.
<pochu> Protheus: linux-image-*
<Protheus> lol. I did a new approach ... and go through the linux-kernel package ... there it was in the dependencies .... linux-source is it.
<jdong> is there any way to extend the sudo password cache for a particular terminal session?
<Protheus> hmmm ... I think this is a global setting.
<jpatrick> jdong: -v extends to 15 minutes (or whatever the timeout is set as in sudoers)
<jdong> interesting....
<jdong> I'm looking for something for a continually-pbuildering shell
<jdong> because pbuilder invokes sudo to become root and that almost always yields an annoying password prompt
<jpatrick> sudo -s?
<jdong> jpatrick: is it really safe to be fetching and mangling source archives as root :-/
<jdong> </paranoia>
<jpatrick> err, probably not
<so1> hi
<so1> does someone know why pulseaudio needs an internet connection to work?
<superm1> during the debian autosync, do NEW packages (that are in the debian archive but not in Ubuntu) automatically come?
<Kmos> superm1: if they're at unstable (main), they'll come
<Kmos> for example:
<Kmos> !info vodovod hardy
<Kmos> is a new one =)
<ubotu> vodovod: lead the water from the house to the storage tank. In component universe, is optional. Version 1.10-1 (hardy), package size 419 kB, installed size 916 kB
<geser> superm1: "automatically" as in an archive admins needs to start a script
<superm1> geser, okay just making sure i didn't need to requestsync it.  there is no urgency to it right now, so whenever they run said script and grab it will be fine
<saman> are there any Ubuntu open projects and how do we join
<ivoks> ubuntu open projects?
<ivoks> ubuntu is an open project :)
<Le-Chuck_ITA> Hi there, may I draw your attention to bug #132583? It seems to have a one-line fix
<ubotu> Launchpad bug 132583 in openoffice.org "python-uno can't be imported" [Low,Confirmed] https://launchpad.net/bugs/132583
<Le-Chuck_ITA> and it's low priority, but it really breaks an important part of openoffice
<somerville32> Le-Chuck_ITA, Did you provide a patch?
<Le-Chuck_ITA> the quick way
<Le-Chuck_ITA> there's a path missing from ld.so.conf, so the patch is to create a single-line file in /etc/ld.so.conf.d
<Le-Chuck_ITA> I wrote that in a comment but didn't create a debdiff
<Le-Chuck_ITA> somerville32: ping :)
<somerville32> Le-Chuck_ITA, Ok. I'm sure someone will get to it. :)
<somerville32> Thanks for the help!
<somerville32> You might mark it triaged btw
<Le-Chuck_ITA> I didn't do anything actually, the merit is due to other commenters
<Le-Chuck_ITA> but will mark it as triaged
<Le-Chuck_ITA> it's already triaged! :) so my task ends here
<Le-Chuck_ITA> thanks and bye
#ubuntu-devel 2008-11-10
<NCommander> Man, Freenode been glitchy
<ScottK> You say that like it's news.
<NCommander> ScottK, I remember freenode when it was steady as a rock
<ScottK> NCommander: Do you have some time to try and verify a security patch for me (It's C, so I'm hopeless)?
<jdong> NCommander: yeah yeah and you walked in 15 feet of snow uphill and downhill everyday to school in the next city....
<ScottK> jdong: You got it wrong, "Up hill both ways".
<NCommander> jdong, no, I took a bus
<NCommander> ScottK, define verify
<jdong> NCommander: verify (v. trans. InfoSec): "Yeah, I think most of ~/ is still there AFAICT..."
<jdong> *ducks*
<ScottK> NCommander: Upstream produced a new upstream release that has both a working exploit test and a very invasive fix.
<NCommander> Ok
<ScottK> NCommander: Upstream gave a hint on how to shortcut avoiding the problem in a less invasive way
<ScottK> NCommander: Debian maintainer has produced a patch that he thinks is good, but upstream doesn't have time to deal with confirming it works.
<ScottK> I'm looking for some independent verification.
<NCommander> So, why not install package, run verification test?
<ScottK> You've looked at the code before so I thought of you.
<ScottK> I'd have to understand Perl to run the test.
<ScottK> That and I'm currently busy trying to understand why cmake seems broken in Jaunty.
<ScottK> I guess that's a no then.
<ScottK> Tries again.
<ScottK> I guess that's a no then.
<NCommander> ScottK, sorry, my laptop froze
<NCommander> ScottK, sure, I can be convinced to test it
<ScottK> OK.  I'll email you some stuff.  You'll want libspf2 from Jaunty and Hardy.  What address.
<ScottK> NCommander: ^^
<NCommander> sonicmctails@gmail.com
<ScottK> NCommander: Forwarded you the upstream hint and the proposed patch.
<NCommander> is the patch in jaunty or the new upstream?
<ScottK> The patch is against 1.2.5 (in Dapper -> Hardy).
<ScottK> The new upstream is in Jaunty/Intrepid-security.
<ScottK> The test is in the new upstream.
 * NCommander grabs the jaunty source package
<ScottK> If the package is vulnerable, the test will cause a segfault.
<ScottK> NCommander: Be sure to grab the -security version.
<NCommander> ScottK,   libspf2-2: Depends: glibc-private but it is not installable
<ScottK> That adds the patch that made it possible to get to this problem (fix one vulnerability and expose another latent one |o/)
<NCommander> *ahem*
<ScottK> ?
<NCommander> Trying to install on jaunty
<NCommander> Package is broken
<ScottK> Weird.  Installs on Intrepid.
<ScottK> Same package.
<NCommander> :-P
<NCommander> Yeah
<NCommander> its broken on jaunty
<ScottK> OK.  Separate issue.  I'll look at that.
<NCommander> ok, I figured out how to run the test suite against various versions of the package :-)
<ScottK> Great.
<NCommander> I'll test the jaunty package (assuming it compiles)
<ScottK> Try the hardy-security version against it and see.
<NCommander> I need to have a known working negetive
<ScottK> Right.
<NCommander> argh
<NCommander> damn it
<NCommander> I actually have to install the library
 * NCommander breaks pbuilder out
<NCommander> argh
<NCommander> the test suite needs a non-packaged perl module it seems
<ScottK> Upstream runs Gentoo, so who knows.
 * NCommander whacks head
<NCommander> bah
<NCommander> Getting this test suite to run is a ****
 * NCommander upgrades perl base
<NCommander> ok
<NCommander> confirmed that the version in jaunty does not suffer the buffer overflow
<NCommander> argh
<NCommander> t/11_overflows.......dubious
<NCommander> 	Test returned status 0 (wstat 11, 0xb)
<NCommander> DIED. FAILED tests 3-5
<NCommander> 	Failed 3/5 tests, 40.00% okay
<NCommander> ScottK, ^
<NCommander> (that being said, the test suite might be a false postive, I had to kick it to actually compile )
<ScottK> That's Jaunty?
<NCommander> Hardy security
<ScottK> OK.  I'm fairly certain that one isn't vulnerable.  More than one person who knows the code verified that.
<ScottK> Ah.  Hardy Security.  Sorry
<NCommander> yeah
<NCommander> it segfaulted
<ScottK> I'd expect Hardy Security to fail.
<ScottK> That's the indication it's vulnerable.
<NCommander> it got through 2/3 tests however
<ScottK> The patch in Hardy security I think is tested for in that same test.
<NCommander> root@blacksteel:~/libspf2-1.2.5.dfsg/perl# perl t/11_overflows.t
<NCommander> 1..5
<NCommander> ok 1 - use Mail::SPF_XS;
<NCommander> ok 2 - parse_cidr did not run off start of data
<NCommander> Segmentation fault
<ScottK> I think that's right.  I suspect the one in hardy-release would fail 2
<NCommander> so now what?
<NCommander> libspf has two rdepends
<NCommander> It might just be worth doing a backport
<ScottK> So the question is does the patch I emailed you fix it?
<NCommander> oh
<NCommander> I thought the patch was applied already
<ScottK> No.
<ScottK> I emailed you patch #2 that hopefully finishes fixing it.
<NCommander> Lets find out
<NCommander> t/11_overflows.......ok
<NCommander> WOOOO!
<cody-somerville> NCommander, chillax :P
<NCommander> chillax?
<ScottK> NCommander: So it works.  Would you view it as sane?
<NCommander> Yes, expect it makes a blank patch file as well
<NCommander> 51_actually-keep-track-of-max_var_len.dpatch - empty
<NCommander> 52 - has the real patch
<ScottK> expect/except?
<NCommander> *except :-P
<ScottK> OK.
<ScottK> NCommander: Thanks.  I'll work on -security debdiffs then.
<NCommander> \o/
<ScottK> NCommander: Any thoughts on where glibc-private in Jaunty comes from?
<NCommander> no idea
<NCommander> it might just need a binary rebuild
<ScottK> Tried that.  No luck.
<ScottK> It picks that up from somewhere.
<NCommander> apt-cache doesn't know what it is
<ScottK> It doesn't exist.
<NCommander> its in none of the shlibs files I have
 * NCommander pokes LP
<NCommander> ScottK, I'm semi-stumped
<ScottK> NCommander: I dunno the relevancy, but glibc in Intrepid defines a large number of symbols in GLIBC_PRIVATE that seem to be gone in Jaunty.
<NCommander> bug in glibc?
 * NCommander debates downgrading to intrepid
<ScottK> NCommander: I was thinking more planned change we need to figure out how to work with.
<NCommander> ??
<ScottK> Looking at debian/changelog this symbol thing was on purpose.
<ScottK> Not sure if it's relevant to the problem at hand or not.
<NCommander> where is doko when you need him
<glaksmono> hello
<ScottK> NCommander: Thanks.  -security debdiffs are done.
<NCommander> yay
 * ScottK goes and sleeps.
<\sh> moins
<\sh> NCommander: welcome on board of the MOTU ship :)
<NCommander> \sh, thanks :-)
<NCommander> \sh, do you know who the resident grub guy is on Ubuntu?
<\sh> NCommander: nope...sorry...
<NCommander> cjwatson, I'd like to talk to you on adding splash images for grub
<wgrant> NCommander: Not by default, I hope.
<NCommander> wgrant, ?
<wgrant> NCommander: It was, I believe, decided that yet another mode change wasn't necessary.
<pitti> Good morning
<NCommander> wgrant, mode change?
 * NCommander notes our current grub does properly support splashimages, and those work just fine
<wgrant> NCommander: Splash image == graphical mode == mode switch == flickering == baaad
<wgrant> Morning pitti.
<NCommander> fair enough
<NCommander> morning Pici
 * NCommander hit head
<NCommander> pitti,
<wgrant> Flickering and slowness and other stuff, probably.
<pitti> wgrant: pong
<wgrant> It's not accidental that we lack a splash image, at any rate.
<wgrant> pitti: See bug #293318/
<ubottu> Launchpad bug 293318 in gnome-settings-daemon "gnome-settings-daemon leaks memory" [High,In progress] https://launchpad.net/bugs/293318
<wgrant> I think it's that one.
<wgrant> Yes it is.
<tjaalton> fedora removed their grub splash image
<NCommander> They did?
<tjaalton> for the same reason
 * NCommander notes Debian still has one
<pitti> wgrant: I got the bug mail, yes
<NCommander> wgrant, I can find that leak
<wgrant> NCommander: Huh?
<tjaalton> now they don't even show the menu anymore, unless there's another boot option available (like windows)
<NCommander> the memory leak
<wgrant> tjaalton: That's what we do, isn't it?
<tjaalton> wgrant: yes
<wgrant> NCommander: I've even fixed it upstream...
<NCommander> oh
<NCommander> nm
 * NCommander hadn't finished reading the bug :-)
<wgrant> NCommander: Why do you want a GRUB splash?
<NCommander> Brainstorm #21, and my mom freaked when she saw it when I installed Ubuntu on her PC
<wgrant> Surely it's no more scary than watching a POST.
<NCommander> At least no computer I've owned in a few years shows a text based PoST
<NCommander> ... PSOT
<NCommander> ... POST!
<NCommander> on mine, I get Sony VIAO -> grub -> usplash
<tjaalton> just get rid of windows and you're saved
 * NCommander gets the grub countdown
<tjaalton> no grub menu anymore
<NCommander> yes, I know
<Treenaks> On my eee I get grub (very short) -> usplash
<Treenaks> \o/ bios quickboot
<tjaalton> NCommander: oh, yet another "idea" I can close?-)
<NCommander> tjaalton, if you must ;-)
<tjaalton> ah, fedora didn't actually remove the splash, but it's not shown unless the menu is
 * NCommander notes thats how itlled is on Ubuntu as well if a splash is insta
<pitti> wgrant: did you sent the two g-s-d input patches upstream? There aren't any patch headers or gnome bz refs
<wgrant> pitti: The upstream-relevant parts are upstream.
<pitti> wgrant: ah, nice; thanks
<wgrant> I didn't add patch headers because the patches were already there.
<pitti> wgrant: I added the bug ref for 293318 to the changelog; does 08_extra_touchpad_options.patch correspond to a bug report, too?
<wgrant> pitti: They're both for that bug, though 08_extra_touchpad_options.patch is more of an additional defense.
<pitti> ok, thanks!
<wgrant> No, thank you.
<wgrant> tjaalton: Are any other distros going to be sharing our pain in the immediate future?
<pitti> fedora isn't yet?
<pitti> wgrant: I assume "pain" == "input hotplug"? :-)
<wgrant> pitti: Input hotplug for everything, yes.
<dholbach> good morning
<tjaalton> wgrant: fedora is
<tjaalton> at least
<tjaalton> and when lenny is released I bet debian will follow
<wgrant> tjaalton: Hmm, I wonder how they dealt with g-s-d...
<wgrant> From what I could see they hadn't.
<pitti> wgrant: nothing on http://daniel.holba.ch/harvest/handler.py?pkg=gnome-settings-daemon ?
<tjaalton> wgrant: what in particular?
<wgrant> pitti: No...
<wgrant> tjaalton: Mouse settings (most annoyingly right/left-handedness) don't persist when you hotplug devices.
<wgrant> Some keyboard stuff doesn't work at all, but that's another less important story.
<tjaalton> wgrant: okei
<tjaalton> uh
<tjaalton> "okay"
<pitti> slangasek: did you see the response in bug 236830? seems there is still a bug there?
<ubottu> Launchpad bug 236830 in samba "cifs does not support kerberos authentication" [Medium,Fix committed] https://launchpad.net/bugs/236830
<SYDN> è°ç¥éæ64çJAVA é£éä¸è½½
<RAOF> Indeed.
<SYDN> where
<wgrant> I agree with RAOF.
<RAOF> Aha.  Sorry.
<RAOF> Google tells me that you want to download Java.
<RAOF> SYDN: You want the "sun-java6-jre" package.
<SYDN> oh
<iulian> There is a #ubuntu-cn channel though.
 * iulian wonders why he didn't join there.
<pitti> mvo: good morning
<pitti> mvo: I checked the hardy SRUs, and it seems that bug 220890 is the only one which holds up -updates propagation of 3 hardy-proposed uploads
<ubottu> Launchpad bug 220890 in python-apt "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,In progress] https://launchpad.net/bugs/220890
<pitti> mvo: anything we can do about it? or is it not a regression, and we can copy and keep the bug open?
<mvo> pitti: I look into it now, sorry that it got put on hold during intrepid
<NCommander> Ugh, that one
 * NCommander puts that on the Ports todo tracker
<slangasek> superm1: ok, changed in bzr, thanks
<slangasek> pitti: 236830> the only issue I see at the end of the bug log was user error, which EtienneG addressed?
<pitti> slangasek: ahh, I read it as "that's what the package should ship"
<mvo> NCommander: what is the url for this?
<pitti> slangasek: ok, so that's basically "didn't get any feedback" then
<NCommander> mvo, right now, I'm just going to note it on the kernelportspage
 * NCommander kicks the spacebar
<slangasek> pitti: ah, so it is; I guess we should kick people for testing :/
<NCommander> But at least w.r.t. to powerpc, I've been working w/ a bunch of other people to make sure PowerPC is a top-notch port again
<emgent> good morning
<NCommander> mvo, I think I can probably fix this bug in Jaunty
<NCommander> (the ports one)
<mvo> NCommander: I check it out now and let you know what I find, I thought I fixed it already :/
<NCommander> I thought it was broken on Intrepid
<NCommander> mvo, are you a ports user?
<mvo> no, that i part of the problem
<NCommander> install lpia on something w/ a CD then
<NCommander> Its considered a port on LP
<mvo> right, good idea
<NCommander> I have those occasionally :-)
<pitti> mvo: I'm ready to accept update-manager for intrepid-proposed, unless you have some more changes stacked up?
<mvo> pitti: is the other one in -updates now?
<pitti> mvo: yes, I copied it this morning
<mvo> excellent!
<mvo> nothing pending currently
<pitti> mvo: good; accepted then
<kirkland> mvo: pitti: I have a debdiff coming shortly for update-notifier for Jaunty;  adds an update-motd hook such that update notifications are appended to the MOTD
<NCommander> pitti, what is binary NEWed?
<mvo> kirkland: nice, I will merge it when its ready
<soren> Is anyone else unfortunate enough to have to deal with the wl wifi driver?
<NCommander> soren, yes, I have
<soren> I find there's a huuuuge difference between the latency of my network connections when I use that and when I use ndiswrapper (which used to be my only option).
<NCommander> pitti, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/mtd-utils/+bug/294428
 * soren runs a simple benchmark
<ubottu> Launchpad bug 294428 in mtd-utils "mtd-utils build fail" [Undecided,Fix committed]
<soren> NCommander: Is it horribly laggy for you as well?
<pitti> NCommander: a package which hasn't been built before must be checked by the archive admins, and is held in a queue for that before being published to the archive
<NCommander> soren, my current machine doesn't have wl, but in my experience, yes
<NCommander> pitti, ah, I see. I enabled proposed on my intrepid box, and checked it, so now what :-)?
<pitti> NCommander: if it works, then it's good for copying to intrepid-updates, and closing the bug
<geser> pitti: Hi. Please give-back vim on i386. Thanks.
<NCommander> It works to the extent I can test it (I don't have anythign attached to this PC I can forgot jffs2, but the tools, and the help for the tools work)
<soren> NCommander: http://people.ubuntu.com/~soren/wlstats.txt <---- No fun at all
<pitti> geser: it's built already
<geser> pitti: https://launchpad.net/ubuntu/jaunty/+source/vim/+builds shows a FTBFS for i386
<pitti> geser: indeed, seems my script is broken
 * pitti fixes it for s/intrepid/jaunty/
<pitti> given back
 * soren wonders why he didn't see the e-mail about that build failure... :/
<wgrant> How does one get posting privileges revoked from -devel-discuss?
<slangasek> mail -devel-discuss-owner, I guess?
<cody-somerville> wgrant, is there a particular reason you ask? :P
<wgrant> They're not doing a very good job of making developers want to read it.
<ogra> that's why it's called -discuss :)
<ogra> for actual development there is ubuntu-devel
<wgrant> I mean, I thought I directed some serious torrents of hate at Launchpad, but that just doesn't compare...
<Hobbsee> wgrant: hmm, I wonder who has powers over that list
<Hobbsee> oh, wow.  It's getting even better.
<NCommander> What list?
<wgrant> -devel-discuss
<Hobbsee> NCommander: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-November/006221.html and that general thread (and other useless wastes of bytes on that list)
<Hobbsee> NCommander: oh, and those sorts of posts are normal for that guy, too.
<NCommander> WTF is the difference between devel-discuss and -devel
<wgrant> One has ******** on it.
<Hobbsee> NCommander: devel == sane.  has developers on it, and is moderated so you don't get that kind of rubbish.
<liw> NCommander, one is discussion about developement, one is discussion about discussion about development?
<NCommander> Hobbsee, semi-moderated, developers are whitelisted
<Hobbsee> NCommander: -devel-discuss: users speaking to developers...Or, now, as the case may be, lots of hate mail, which most people ignore, and occasional developer discussions, which a few people follow.
<NCommander> who do I get in contact if I want a mailing list
<Hobbsee> NCommander: well, yeah.  But the developers aren't expected to behave badly.
<Hobbsee> NCommander: depends.  What for?
 * NCommander would like an ubuntu-ports list <g>
<Hobbsee> NCommander: do you want to use listadmin on it?
<NCommander> listadmin?
 * NCommander knows listsrv, but not listadmin
<Hobbsee> NCommander: http://debaday.debian.net/2007/09/12/listadmin-command-line-mailman-moderator-queue-manipulation/
<NCommander> Probably
 * NCommander would whitelist developers of course
<Hobbsee> NCommander: if you do, you can't use the launchpad lists, you'll need to get a list on lists.ubuntu.com (and I think you'll need to speak to jcastro about it)
<NCommander> jcastro, ^
<Heller_Barde> what program is this volume OSD of ubuntu part of?
<liw> it's probably night for jcastro
<wgrant> Heller_Barde: gnome-settings-daemon, I believe.
<Heller_Barde> ah. and where can i find out how the shortcut is bound to it?
<wgrant> Heller_Barde: What do you mean?
<Heller_Barde> or does gnome-settings-daemon capture shortcuts itself?
<wgrant> It does.
<Heller_Barde> ah
<Heller_Barde> i don't use gnome and actually dont want to but nothing else is able to look appropriately aesthetic :(
<Heller_Barde> oh well
<hyperair> bah the two-stage rsync mirroring script from ubuntu is useless on slow internet connections
<hyperair> rsync the debs first, then the indexes. sounds like the perfect idea. but then it takes so goddamn long to rsync the debs that the indexes have updated by then =.=
<wgrant> hyperair: You're not meant to mirror the archive on dialup.
<hyperair> wgrant: i'm not on dialup damnit
<hyperair> wgrant: this is a university connection
<mvo> pitti: I looked into #220890 and AFAICT the remaining issue is that source code is not recognized as "offical" on powerpc but binary deb lines are. so it should be ok for -update (and I will push another one afterwards that fixes the source lines)
<pitti> mvo: ok, thank you
<sebner> pitti: is your list for coping stuff from -proposed to -updated already empty (for intrepid)?
<pitti> sebner: yes; see http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
<sebner> pitti: intrepid has 2 packages with 7 days ;D
<pitti> sebner: but not verified one
<pitti> s
<sebner> pitti: what has to happen to make it verified?
<pitti> sebner: test that the package in -proposed still works as usual, and that it fixes the bug, and give written confirmation of that in the bug
<sebner> pitti: my package (audacious) has over 5 users can confirm that the update in -proposed fixes the issue ;)
<pitti> sebner: ah, then nobody from motu-sru set the verification-done tag apparently; please do so then
<sebner> pitti: done
<pitti> thanks
<sebner> pitti: np, thank you your copying then :D
<tkamppeter> pitti, hi
<tkamppeter> what is missing to get the CUPS SRU released?
<pitti> tkamppeter: testing and being 7 days in -proposed
<tkamppeter> pitti, did not know that there is a "minimum 7 days" condition. All bugs related to pstopdf are answered and the answers suggest that the problems which I have addressed with pstopdf are really solved.
<pitti> tkamppeter: right, except for the 'prints garbage on samsung' for splix
<pitti> but we can keep that open and still move to -updates
 * ogra grumbles at asac ... my mobile phone is suddenly not detected as USB HDD anymore ... grrr
 * mvo thinks that asac probably sneaked int ogra house just to play that trick on him
 * ogra tries to get the pictures off the camera with bluetooth instead
<ogra> mvo, he doesnt go that far south for playing tricks i bet :)
<liw> ogra, perhaps he has agents everywhere?
<ogra> haha
<liw> he is, after all, a manager ;)
<mvo> ogra: you never know, he is on vac, maybe that is part of his vacationfun ;)
 * mvo stops being silly
<tkamppeter> pitti, and the AppArmor thingy with the network protocols I can confirm. The problem appears (I have 6 network printers) on the machine where I did not update to -proposed and does not appear with the -proposed package.
<pitti> tkamppeter: can you please say so in the bug, for having a written track of testing?
<tkamppeter> pitti, done.
<tkamppeter> pitti, the garbarge printing which you observer with SpliX now is most probably a problem of SpliX itself. Therefore I need you to do tests with the LSB packages from OpenPrinting. The test on 2.0.0rc2 can reveal whether there is perhaps a bug in the Ubuntu packaging. The test of the 1.1.1 version can show whether the 2.x generation of SpliX introduced a new bug.
<pitti> tkamppeter: ah, ok; I'll do that
<tkamppeter> pitti, I have modified the OpenPrinting packaging last week so that these drivers can coexist with the ones coming from the distros.
<tkamppeter> So you do not need to uninstall any package.
<wgrant> mvo: Does do-release-upgrade do the xorg.conf inputdevice mangling too?
<ogra> wgrant, what mangling ?
<wgrant> ogra: We comment out inputdevices on upgrades to let input-hotplug work its magic.
<ogra> xorg will ignore keyboard and mose settings from the file if not forced
<wgrant> No it won't...
<ogra> thats inside xorg afaik
<wgrant> Really new xservers will ignore kbd and mouse entries, as evdev needs to grab them.
<ogra> there was a setting i dont remember you have to add to the xorg.conf to make it use these entries
<wgrant> AutoAddDevices, yes.
<ogra> right
<wgrant> But that's not what I'm talking about here.
<ogra> else it will use evdev by default
<ogra> and ignore the xorg.conf entries for keyboard and mouse
<wgrant> I know, but this is somewhat separate.
<ogra> for other input devices it depends on the driever ...
<ogra> i.e. wacom will only use hal if yu copy the .fdi in place, else xorg.conf should be used
<wgrant> And lots of them will break horribly, which is why we now comment them out on upgrades.
<ogra> really?
 * ogra wasnt aware we touch xorg.conf at all
<wgrant> As of late Intrepid we do.
<ogra> hmm
<tkamppeter> pitti, I have investigated bug 293883 now and it is an evince bug, so it does not block the SRU release of CUPS. pstopdf was not the culprit there.
<ubottu> Launchpad bug 293883 in evince "8.10 Printed PDF missing parts / corrupt" [Medium,Confirmed] https://launchpad.net/bugs/293883
<cjwatson> NCommander: we tried it before and it broke some people's hardware, so I'm not all that interested in trying it again TBH
<NCommander> Works for me
 * NCommander deletes the idea from his brain
<mok0> rm -rf /sys/brain/idea
<mvo> wgrant: yes
<NCommander> mok0, file not found
<wgrant> mvo: Hmm, OK, I have a report from somebody that it didn't.
<mok0> hehe
<wgrant> But perhaps not fully trustworthy.
<mvo> wgrant: it writes out a log what its doing
<mvo> wgrant: please ask the reporter about the stuff in /var/log/dist-uprade/*
<mvo> wgrant: is there a LP bug for it?
<wgrant> mvo: There isn't. I'll ask for logs.
<mvo> thanks
<hyperair> late intrepid touches xorg.conf?
<wgrant> hyperair: Since late in the Intrepid release cycle, the dist-upgrader touches xorg.conf.
<hyperair> oh
<hyperair> what does it do
<wgrant> Comments out inputdevices.
<pitti> slangasek: I ported your hal patch 99_new-kernel-rfkill-interface.patch as best as I could to new hal upstream; but since I don't get any observable lshal change when flipping the killswitch either with your old nor with my ported patch, I can't really test it; can you?
<slangasek> pitti: I guess that's for jaunty?  I'm afraid I can't test that very easily; but the main point would be whether NM detects the status change, I guess?
<pitti> slangasek: yes, for jaunty
<pitti> slangasek: well, NM doesn't do anything if I change the killswitch
<slangasek> hmm
<slangasek> not with either version?
<pitti> but didn't do that in intrepid either
<pitti> that's why I can't test the ported patch
<slangasek> hrm
<StevenK> slangasek: Bit early, isn't it?
<slangasek> pitti: this is on a system with Intel wireless?
<slangasek> StevenK: ?
<StevenK> slangasek: It's 4am in LA
<pitti> slangasek: yes, iwl3945 with dell killswitch
<slangasek> pitti: do you have /sys/class/net/$dev/device/rfkill?
<slangasek> StevenK: yep, right in the middle of my Monday shift
<slangasek> pitti: (you're running the Intrepid kernel, right?)
<pitti> slangasek: intrepid kernel> yes
<pitti> slangasek: /sys/class/net/wlan0/device/rfkill/rfkill0/state
<pitti> slangasek: I can put the new consolekit and hal into my intrepid PPA, if that would help you
<slangasek> pitti: that would be better
<slangasek> I'm still puzzled that it doesn't work for you, though
<slangasek> for me, the nm-applet icon reflects the state change within a few seconds
<pitti> well, the killswitch itself works
<pitti> in the sense of that it blocks wifi
<pitti> but NM doesn't react to that
<slangasek> hmm
<slangasek> then I guess my patch is screwed up somehow, even though IWFM :/
<pitti> slangasek: someone else on the upstream bug confirmed that it works
<pitti> seems hw specific
<slangasek> yeah, I saw
<slangasek> but I don't understand /why/ i would be hw-specific
<pitti> slangasek: if you change the killswitch, do you see something in lshal flip state?
<pitti> slangasek: both uploaded and building now
<slangasek> pitti: lshal changes> no; though apparently if I'm lucky, I can hard-lock my laptop in the process
<slangasek> pitti: but I guess calling 'hal-ystem-killswitch-get-power' directly should show the output?
<slangasek> +s
<pitti> w$ sudo ./hal-system-killswitch-get-power
<pitti> .: 10: hal-functions: not found
<pitti> bah
<slangasek> doh
<pitti> but it's there... ?!?
<Nafallo> anyone know if we have support for Intel 4500MHD?
<Treenaks> Nafallo: what is it?
<Treenaks> Nafallo: a CPU?
<Nafallo> Treenaks: some kind of new graphics thing.
<Nafallo> I think :-P
<Nafallo> Intel Graphics Media Accelerator 4500MHD DVMT (Dynamic Video Memory Technology)
<Nafallo> yea. new GMA.
<asac> ogra: so you want to use your phone as HDD and not 3G device ;)?
<ogra> asac, well, it used to show up as HDD when i plugged it in with cable ...
<ogra> but BT works fine for pulling off files
<ogra> my phone has a 2G micro SD card i use as data storage from time to time
<asac> ogra: when did USB stopp working?
<ogra> no idea, i just pluged it in for the first time after an aeon
<ogra> i dont think i even tried it in intrepid at all before
<ogra> it used to show up as HDD in hardy iirc
<asac> ogok
<ogra> ogok ?
<liw> I wouldn't mind using my phone as a storage device, too, in order to move files to the memory card
<asac> ogra: do you have different modes?
<asac> (on the phone)
<ogra> its in usb storage mode by default ...
<liw> (but I'm happy to shuffle the memory card around for now)
<ogra> one sec, doorbell, brb
<asac> ogra: maybe it was the airprime driver?
<asac> (that one was dumbed in intrepid afaik)
<mvo> cjwatson: do you happen to know if we use the wget udeb still these days? it got added by fabio in the feisty days and I was wondering if we should keep this change around or not
<cjwatson> mvo: I think Fabio might have wanted it for system-integrity-check maybe? nothing in d-i itself uses it
<mvo> cjwatson: yes, that looks right
<mvo> thanks!
<cjwatson> mvo: that said, I don't see anything in system-integrity-check that relies on it
<cjwatson> oh, no, Depends: wget-udeb. WTF
<cjwatson> fabbione: why was busybox's wget not good enough?
<cjwatson> fabbione: it doesn't seem as if system-integrity-check uses any features not in busybox's wget
 * NCommander laughs evilly
<slangasek> jordi: yuck, why is there a lib64asound2-plugins?  Is there really a use case for 64-bit alsa support on 32-bit installs?
<directhex> NCommander, evil laughter? that can only mean added mono! ;)
<NCommander> slangasek, offhand, I'm going to guess for compiler biarch sanity
<slangasek> huh?
 * NCommander shakes head
<NCommander> Wow, I'm loosing it
<NCommander> just ignore me
<NCommander> directhex, actually, debhelper 7 was backported (thank you slangasek)
<NCommander> That unblocks at least 10, maybe more backports
<directhex> NCommander, version?
<NCommander> hardy-backports
<directhex> i meant actual package ver
<NCommander> directhex, the one from intrepid, 7.0.13ubuntu1
<pitti> StevenK: what's the rationale for your pilot-link patch 30_3_arg_open.dpatch? no patch headers, no bug refs, no rationale in changelog :(
<fabbione> cjwatson: at the time, it was not good for https. We started doing all the stuff to https and the whole thing was stalled on lack of time
<cjwatson> oh, right
<pitti> StevenK: oh, nevermind, got it
<cjwatson> mvo: ^- above is still the case
<fabbione> cjwatson: not sure if wget in busybox does https now.. nor if ubuntu cares about s-i-c. I gave it to the server team a while ago.. no idea if they have done anything about it
<cjwatson> I don't think anyone cares very much about s-i-c any more, but wget doesn't do https and that seems like a valid use case
<cjwatson> busybox wget that is
<fabbione> cjwatson: ok. I personally don't think i care nor i have time to do s-i-c. Might worth discussing it again with the server team and free resources at the datacenter since there is a server side for it
<pitti> StevenK: did you send it to an upstream ML? I don't find an upstream bug tracker
<fabbione> cjwatson: the code is still in bzr somewhere public I believe. anyway the last releae in the archive had everything that was in bzr anyway
<mvo> cjwatson, fabbione: right, thanks
<fabbione> mvo: no worries :)
<Keybuk> cjwatson: still trying to figure this udev bzr packaging case out
<Keybuk> hit another problem; the udev git repository doesn't contain (as you'd expect) configure, Makefile.in, etc.
<Keybuk> which means merging with "bzr pull" isn't going to produce something like the orig.tar.gz
<Keybuk> the diff.gz will always end up with autoconf changes
<Mithrandir> not if you nuke them in the clean target
<Mithrandir> (and build-depend on auto*)
<pitti> Keybuk: what's wrong with having autogenerated autofoo stuff in the diff.gz?
<pitti> it might not be nice, but well, it's just noise
<Keybuk> pitti: well, fwics, I have two options
<Keybuk> clean bzr packaging, based off a git import, with merges and changes done with bzr nicely - but messy resultant traditional source package
<Keybuk> or a clean source package, created by lots of by-hand heavy lifting with bzr/git
<Keybuk> also wouldn't it break colin's "what you checkout from bzr must be buildable" requirement?
<pitti> james_w: do you care about backuppc? You did the last merge, but it's currently on my plate since I did a last-minute dependency fix
<pitti> Keybuk: can't speak for others, but for e. g. jockey I don't care about messy diff.gz if the ubuntu package is a direct branch of upstream trunk
<james_w> pitti: I did the last merge as it was DIF and unmerged I believe.
<james_w> pitti: I don't mind merging again if you want it off your plate
<Keybuk> pitti: but then debcheckout doesn't give you anything buildable?
<pitti> Keybuk: since you aren't going to use patch systems or MoM for those, messy diff doesn't really hurt IMHO
<pitti> Keybuk: it should be buildable, of course
<pitti> Keybuk: debian/rules could just call autogen.sh?
<Keybuk> how do you make it buildable?
<Keybuk> but then the package has to depend on auto*
<pitti> lots of packages do
<Keybuk> please nuke autogen.sh ;)
<pitti> (yes, I repeatedly argued against it in the past, for packages which update autofoo on build)
<cjwatson> Keybuk: james_w may have technology to generate the tarball branch (i.e. git + configure/etc.) automatically
<pitti> Keybuk: or autoreconf -v, or whatever :)
<james_w> lies!
<cjwatson> autogen.sh> still useful when you're doing things that autoreconf doesn't do :P
<pitti> james_w: ok, nevermind then; I just wondered if you were actually using it and could test it or so, but seems not :)
<james_w> though it might be possible thinking about it
<Keybuk> it'd have to be a Build-Depend-Indep on auto*, right?
<cjwatson> james_w: the only hard bit is identifying the revision from which the tarball was produced; after that you just unpack and blat the changes into the archive
<Keybuk> or is it only build-depends?
<cjwatson> Build-Depends is stronger than Build-Depends-Indep in practice
<cjwatson> policy is extremely confusing on this
<Keybuk> yeah, I've never really understood it
<Keybuk> at one point I thought -Indep was for "things needed to make the source package"
<Keybuk> but it appears policy disagrees on that now
<cjwatson> basically I only use Build-Depends-Indep if either (a) I have an explicit build-indep rule and the dependency is only used there and/or (b) it's only used in binary-indep
<cjwatson> I don't think policy ever said anything like that
<pitti> Keybuk: the way I understood it, you don't need -indep when building with -B
<pitti> such as the !i386 buildds
<NCommander> I was under the impression that Build-Dep-Indep is anything the independent build-deps needed explicately
<Keybuk> cjwatson: it's entirely likely it didn't ;)
<cjwatson> oh, it might have had confusing language about clean at some point
<Keybuk> thought of the day: we should have an autoreconf meta package :p
 * pitti generally just ignores B-D-I, too confusing to think about
<cjwatson> yeah, that's usually the right answer
<cjwatson> there are a small number of cases where it is important and/or useful
<pitti> that the !i386 buildds use -B is really just an implementation detail packagers shouldn't really care about, FWIW
<pitti> cjwatson: oh? so there's more to it than just buildds?
<cjwatson> pitti: no, I didn't say that :)
<cjwatson> pitti: I just meant that it is usually reasonable to default to sticking everything in B-D, and only think about B-D-I if you find you need to
<pitti> ah, right
<siretart> a common case is running doxygen to create an libfoo-doc package. doxygen can go to B-D-I then
<ScottK> I'm looking at a package that has gone uninstallable in Jaunty because it believes it needs to depend on a non-existant package called glibc-private.  Rebuilding produces the same result.  Package builds and produces an installable binary on Intrepid.  Any suggestions about where to look?
<pitti> ScottK: sounds like a bad .shlibs file?
<siretart> ScottK: bad shlib.local file in the package?
<pitti> ScottK: if local build does the same, grep /var/lib/dpkg/info/*.shlibs for glibc-private?
<cjwatson> ScottK: that means that the package is relying on private glibc symbols and it shouldn't be
<cjwatson> ScottK: it's basically glibc arranging for the package to blow up
<pitti> oh, magic
<siretart> sweet
<ScottK> Argh.  OK.  Thanks for the hints.
<ScottK> Yes.  Does the same thing on local builds, so I'll look.
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462444
<ubottu> Debian bug 462444 in glibc "glibc: Please add symbols files for libc6" [Wishlist,Closed]
<ScottK> Thanks.
<cjwatson> I think you can pass -xglibc-private to dpkg-shlibdeps to skip it if you know what you're doing
<cjwatson> but it's probably worth investigating first
<ScottK> OK.  I'm definitely in an area where "know what I'm doing" doesn't apply.
<ScottK> Which is, of course, half the fun.
<Keybuk> cjwatson: did you autosync contrib or non-free?
 * ogra wonders if MoM is broken 
<ogra> or probably she simply forgot i exist
<pitti> ogra: curious
<ogra> i only seem to have one package in universe
<pitti> ogra: you've got stuff on http://merges.ubuntu.com/universe.html, thoug
<mvo> ogra: generally it seems to be running quite happily
 * mvo just checked the logs 
<ogra> which additionally is better off to be merged by LaserJock
<cjwatson> Keybuk: not yet
<cjwatson> Keybuk: doing so now
<pwnguin> Hobbsee: looking at the record thus far, I don't think the recent post by Vincenzo is "normal" in tone or language. it also doesn't reflect my own interactions with him.
<siretart> Mithrandir: did you have the chance yet to look into the pkg-config issue slomo and I asked you about?
<Mithrandir> siretart: I didn't, no. :-/
<pwnguin> It does reflect somewhat my own frustration with the status quo, but I'm not about to write angry letters over it
<hyperair> what pkg-config issue?
<Keybuk> ogra: ;)
<ogra> :)
<Keybuk> I suspect it's because you've got your "you touched it last" list down to almost zero
<ogra> seems like
<ogra> which is weird
<siretart> hyperair: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504220
<ogra> i thought i touched a good bunch
<ubottu> Debian bug 504220 in libavcodec-dev, "Missing dependencies" [Grave,Open]
<Keybuk> not really, you tend to touch things in universe more than main
<ogra> but i'll pick up leftovers
<Keybuk> and universe has a high "fix after freeze" ratio
<hyperair> hm ubottu handles debian bugs too?
<hyperair> i never knew
<ogra> yeah, since i'm in mobile i touch a lot of universe
<Mithrandir> siretart: you need to depend on the -dev packages.
<siretart> Mithrandir: but isn't that insane? why do depending packages need to care about whether libavcodec-dev links against libtheora or not?
<Mithrandir> siretart: if it is in "Requires.private", then it not only links with it, but also needs the headers from it.
<Mithrandir> like gtk exposes glib types in its headers.
<siretart> Mithrandir: libavcodec does not TTBOMK expose any libtheora internals
<Mithrandir> if it just links with it without exposing any of libtheora's types, using libs.private should be fine.
<siretart> okay. is there any documentation or any document I could point upstream at to get that fixed?
<Mithrandir> once I get around to writing it. :-/
<siretart> may I quote this irc conversation?
<Mithrandir> sure.
<tkamppeter> pitti, did you do the test for bug 292690, I have also added another possibility to test.
<ubottu> Launchpad bug 292690 in cups "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,Fix committed] https://launchpad.net/bugs/292690
<fta> dear archive admins, please, consider opening the ppa gates to jaunty.
<cjwatson> is it our decision?
<cjwatson> I thought that was an LP thing
<fta> i asked there 1st => <cprov> fta: the decision belongs to the archive-admins at this point, so #ubuntu-devel might be a better place to discuss it.
<cjwatson> cprov: do it
<cjwatson> I don't think we have the lever; if we do then please tell me
<cprov> cjwatson: okay, I will organise the opening
<cjwatson> cprov: I can't think of any reason why we wouldn't want to open a distroseries for PPAs at the same time as we open it for regular uploads. Do you know why it is done separately?
<cprov> cjwatson: those decisions are still orthogonal in the DB. We open a new distroseries by change its status from frozen to development
<cprov> cjwatson: PPA archs are enabled per distroarchseries base.
<cjwatson> cprov: OK, I'll edit our NewReleaseCycleProcess to say we need to notify you to enable PPAs
<cprov> cjwatson: right, if you think it's appropriate, we could try to glue those decisions in a single form.
<cprov> https://launchpad.net/ubuntu/jaunty/{i386, amd64, lpia}/+admin
<cjwatson> cprov: I don't mind as long as it gets done; a note in NewReleaseCycleProcess should be good enough
<cjwatson> cprov: yeah, I don't have access to that
<cjwatson> see also: why can't distro drivers administer distroseries, eh?
<cprov> cjwatson: me neither, I will ask kiko.
<fta> cprov, cjwatson: wonderful, thanks guys :)
<jordi> slangasek: I assumed it is as useful as lib64asound2
<cprov> cjwatson: fta: jaunty PPAs are supported.
<fta> great
<cjwatson> thanks!
<siretart> cprov: when exactly did you enable jaunty PPAs?
<cprov> siretart: few minutes ago.
<siretart> ah, ok. I tried this morning and got my upload rejected
<hyperair> ...what happens when someone uploads a html file that redirects to a virus site to launchpad? =.=
<hyperair> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695
<hyperair> see the last comment
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/59695/+text)
<ScottK> hyperair: You should take that up in #launchpad.
<hyperair> lol
<tkamppeter> pitti, ping
<ScottK> hyperair: Why is that funnny?  They're the only ones that can do anything about it.
<hyperair> yesy es
<hyperair> well, i'm the kind of person who laughs when yet another windows user gets struck by a virus
<hyperair> i'm evil like that
<hyperair> anyway i've alerted the guys at #launchpad
<pitti> tkamppeter: hi
<pitti> tkamppeter: btw, I can't configure the lsb splix2 packgage; s-c-p doesn't find it, and if I select the PPD manually, I just get an internal cups error
<directhex> mono 2.0-1 very soon, apparently
<pitti> tkamppeter: oh, nevermind, it didn't get configured (lsb dependency isn't installed)
<pitti> tkamppeter: yep, works now
<pitti> tkamppeter: new filter tested now, too
<evand> Anyone have a 4GB USB disk, a recent Apple computer, and a free moment to test something for me?
<liw> evand, I'm lacking all three, but just for clarification: do you need exactly 4 gigs or at least 4?
<evand> at least
<evand> (I have an image to dd to such a disk, so the other requirement would be a disk that you don't care about :)
<pitti> pedro_, sbeattie: any chance to give gparted in hardy-proposed a test, for bug 37768? I was the uploader, so I need a second tester
<ubottu> Launchpad bug 37768 in gparted "gnome-volume-manager mounting Partition, while working with GParted" [Medium,Fix committed] https://launchpad.net/bugs/37768
<mvo> kirkland: hello! how often is update-motd run ?
<kirkland> mvo: every 10 minutes;  i'm putting a delayer in the script i'm working on to ensure that the update-notifier bit wouldn't run more frequently than once per hour
<mvo> kirkland: the update-notifier bit is to pick up notification from user.d/ ?
<kirkland> mvo: actually, i meant: /usr/lib/update-notifier/apt-check
<kirkland> mvo: i propose something like this: http://pastebin.ubuntu.com/70058/
<kirkland> mvo: call it "notify-updates-available"
<mvo> kirkland: aha, ok - I'm adding support for new release upgrade notification into update-manager-core right now (just fyi) - and it should ideally be only once a day
<kirkland> mvo: similar to "notify-reboot-required"
<kirkland> mvo: cool, what i'd really like is just a number dumped into /var/run/updates-available
<kirkland> mvo: also, i find it really, really odd that /usr/lib/update-notifier/apt-check puts the number of updates available on STDERR ... why's that?
<mvo> kirkland: would it make sense to have a /etc/update-motd.d{.daily/,.hourly, etc} ?
<kirkland> mvo: yes, i'm working on that, as update-motd's upstream
<kirkland> mvo: i intend to do that very soon
<mvo> kirkland: its a workaround because sometimes other stuff gets spit onto stdout
<kirkland> mvo: oh
<kirkland> mvo: it gave me a few fits :-)
<kirkland> mvo: i got around it
<mvo> kirkland: would it make sense to just modify apt-check so that it has a "--for-update-motd" (or something like that) so that it prints out exactly what you need?
<mvo> kirkland: update-notifier has a lot of UI dependencies, so changes to update-notifier are required I assume?
<kirkland> mvo: right, i'd need something in update-notifier-common
<kirkland> mvo: can't really bring all those UI deps into ubuntu-server
<kirkland> mvo: what cronjob currently drives apt-check?
<mvo> kirkland: indeed :) so if we need to do that anyway, I wonder if we should have a apt-check that is tailored to the needs of update-motd in the sense that it outputs the right kind of message (with i18n and everything)
<mvo> then all that is needed is that it installs a symlink to update-motd and is done with it
<kirkland> mvo: okay, so i have throw one more wrinkle into the mix ...
<mvo> kirkland: update-notifier itself drives apt-check, it has inotify rules to monitor apt/dpkg so that it known when it should (re)check for updates
<kirkland> mvo: i think it's going to be landscape-sysinfo that's going to gather this info
<mvo> kirkland: hm
<kirkland> mvo: so landscape-sysinfo could even use a python library to grab this from apt-check
 * mvo scratches his head and thinks about it a bit
<sbeattie> pitti: I'll take a peek
<ddfire> hi
<ddfire> i need help making a deb package
<ddfire> or backporting asterisk 1.4.21 from 8.10 to 8.04
<ddfire> anyone have an idea?
<ddfire> a pdf?
<ddfire> a clue?
<Nafallo> ddfire: wrong channel. try #ubuntu-motu.
<ddfire> Nafallo: thanks
<ddfire> Nafallo: what is the objetive of this channel?
<Nafallo> ddfire: what the topic says ;-)
<EtienneG> quick question ... will we get Mono 2.0 in Jaunty?  I suppose so, just wondering.
<ddfire> ok
<ddfire> thanks
<maxb> The intrepid-backports devscripts has broken the "dch --distributor" option :-/
 * maxb wanders in the direction of launchpad
<pitti> mvo: is it really deliberate that apt-get build-dep installed packages get auto-removed?
<pitti> it makes 'autoremove' pretty useless on a developer box
<ScottK> Maybe we need apt-get autoremove-build-dep-yes-really
<maxb> "apt-get build-dep" is an explicit user request to install packages, so shouldn't they count as manually installed?
<cjwatson> I could go either way
<cjwatson> often build-dep is only very temporary for me
<cjwatson> install, build, remove
<cjwatson> anyway:
<cjwatson>   * make "apt-get build-dep" installed packages marked automatic
<cjwatson>     by default. This can be changed by setting the value of
<cjwatson>     APT::Get::Build-Dep-Automatic to false (thanks to Aaron
<cjwatson>     Haviland, closes: #44874, LP: #248268)
<cjwatson> so change that configuration option if you don't like it
<ion_> Yeah, build-deps are typically temporary â if i want -dev packages that stay, i can make them manually installed.
<pitti> cjwatson: ah, thanks; so feature, not bug
<liw> I tend to find that apt's (or aptitude's) heuristics of autoremovable packages meshes badly with what I want to keep, but I am probably excentr^Wodd
<ion_> liw: You might want to try debfoster. I use that (and apt-mark-sync to sync its decisions to apt and aptitude).
<apachelogger> james_w: we are going to discuss bzr for KDE packages at the next Kubuntu meeting, please select agreeable time slots at http://doodle.com/participation.html?pollId=tvt9bb3fvtbqda8v
<bryce> slangasek: hey, SRU question for you
<bryce> slangasek: wacom tablets are fairly broken right now in Intrepid.  There is a newer version of the linuxwacom driver in Jaunty (0.8.1-6 vs 0.8.1-4) with necessary fixes.  Would a sync of something like that be conceivably within the realm of possibility?
<jdong> bryce: since it's the same upstream version can't we just call it a "SRU"? :)
<bryce> jdong: guess that's my question ;-)
<pwnguin> bryce: isn't it really hard to test jaunty right now?
<bryce> pwnguin: indeed.  In this case, the users self-compiled the driver and tested it on intrepid.
<jdong> I mean if wacom is "fairly broken" IMO it wouldn't hurt to do some ~proposed testing. If you have big enough a base, put it into a PPA I guess
<pwnguin> i mean, im all for better wacom; the status quo is terrible
<jdong> s/base/bug subscriber base/
<pwnguin> i hope i dont have a big ppa base
<pwnguin> anyways, i dont have the right hardware to test
<jdong> me neither.
<jdong> christmas presents welcome ;-)
<pwnguin> heh
<bryce> well, I'm trying to determine how much time this is going to require.  If we can just sync it in, it should be a reasonable amount of time and I'll give it a shot.  If it's going to require patch cherry picking, ppa testing, and so on, I likely won't have sufficient time to see the whole thing through to completion, so ought to focus my efforts elsewhere.
<jdong> bryce: well I assume the differences between debian revision 4 and 6 is just going to be a lot of debian/patches magic, right?
<bryce> probaby
<bryce> +l
<jdong> I'd just package all of those patches into a SRU-like version number (i.e. -4ubuntu0.1) and consider that a SRU candidate, get a couple users to tell you it works okay, then you're done :)
<jdong> (QA FOLKS PLEASE LOOK AWAY)
<pwnguin> heh
<pwnguin> what's the worst that can happen?
<pwnguin> wacom remains broke?
<jdong> pwnguin: from the way it sounds, it can't get any worse.
<jdong> s/any/much/
<pwnguin> i suppose it could crash X
<jdong> I wouldn't expect that to happen with the kind of changes in a new debian revision though.
<pwnguin> but the recovery tools are supposed to be bulletproof now ;)
<jdong> I'd be a lot more scared if it were an entire new upstream release and a huge diff
<mvo> pitti: it was a feature request to have it this way, -o apt::get::build-dep-automatic=false turns it off
 * ScottK notices the upload of sane-backends and waits for insane-backends .
<mvo> pitti: I don't mind either way, I can switch it to the reverse again
<sebner> ScottK: I just subscriped MC, I'll recieve more and more questions so it's easier
<pwnguin> bryce: fyi, wacom is apparently scheduling a new release next week ;)
<ScottK> sebner: OK.  You know you didn't really answer all my questions in your reply.
<sebner> ScottK: well, I didn't know. apachelogger told me. So maybe I'm missunderstanding you or my lack of english skills has the fault
<bryce> pwnguin: nice... wonder if they'll include the changes needed for hal
<pwnguin> i suspect not;
<pwnguin> The new hotplugging (Xorg 1.5.1 or later) will be supported with linuxwacom version 0.8.4 (0.8.3 will be its unstable release).  It is too late to add the support to the coming stable release (0.8.2), which is scheduled to be posted this week.
<pwnguin> ""
<ScottK> sebner: I'll write a new mail.
 * ScottK waits for jdong to package insane-backends
<sebner> ScottK: yeah! yet another mail. keep going. I have a bet running that I'll recieve more than 10 questions :D
<ScottK> sebner: Sent.
<sebner> ScottK: now I'm subscriped, Does also my pending question (for dholbach) get's posted?
<ScottK> sebner: You mean you sent a reply to dholbach?  If so, I haven't seen it.
<sebner> ScottK: besides .. would you mind explaining your question question  ^ ^  I don't know what you want. A specific example?
<sebner> ScottK: well, I wasn't subscriped so it was pending
<sebner> or still is
<ScottK> Yes.  An example of one you wish you had asked for and didn't and one you wish you hadn't asked for and why, what you learned, etc.
<sebner> ScottK: I made mistakes (like syncs that were merges) but I don't have regrets about any sync that filed
<sebner> + I
<ScottK> sebner: Then comment on that to the ML.
<sebner> ScottK: ah, ok (though it seems that is not the answer you wanted to hear) :)
<sebner> ScottK: ah ah ah. I lost your mail xD would you mind resending it to me?
<geser> sebner: I've just moderated your mail to motu-council
<sebner> geser: thx, I'm now subscriped. sry for the trouble
<sebner> geser: but please don't vote yet. still more questions are in the pipelie ;D
<sebner> *pipeline
<james_w> apachelogger: done, thanks. Unfortunately I can't commit to any times this week, but I will do my best to attend if one of those times is picked
<apachelogger> james_w: looks like it's gonna be sunday since you have time and we have a quorum for the membership application :)
<james_w> I have time, but I may be asleep :-)
<ScottK> james_w: As long as you're awake enough to simulate agreement to do stuff, I think it'll be fine.
<ScottK> Better you're not awake enough to really process it anyway.
<james_w> heh :-)
<ScottK> apachelogger: He thinks I'm kidding.
<superm1> kees, ping
<apachelogger> james_w: no one really is awake at kubuntu meetings, at least I am not, I usually just drop off some lines and continue dozing ;-)
<kees> superm1: pong
<superm1> kees, i'm thinking something in default build flags decided to wreck some havock
<superm1> kees, would you mind taking a look, i think you saw this before: bug 296453
<ubottu> Launchpad bug 296453 in kbuild "upgrading cvs to 1:1.12.13-12 causes FTBFS on kbuild" [Undecided,New] https://launchpad.net/bugs/296453
 * kees goes to read
<kees> heheh, that's a great build log
<kees> superm1: I thought cvs was fixed for hardening weirdness.  I will poke at it.
<superm1> thanks
<kees> superm1: I can't reproduce the cvs crashes...
<slangasek> jordi: right, so how useful is /that/? :)
<slangasek> bryce: wacom tablets are broken in intrepid aside from the known, release-noted fdi issue?
<superm1> kees, i'm assuming on jaunty up to date chroot?
<superm1> i've got a local sbuild lvm snapshot that is fully updated with no delta otherwise ( both i386 and amd64) that reproduce it
<kees> superm1: might be a bit out of date, let me try it again, on sec
<cyberix> In some previous version of Ubuntu I double clickked on a gnumeric file and it suggested I should install gnumeric.
<cyberix> Why doesn't this work anymore?
<kees> superm1: here's the note I removed about cvs: https://wiki.ubuntu.com/CompilerFlags?action=diff&rev2=27&rev1=26
<kees> superm1: I still can't reproduce on either amd64 or i386, updated jaunty chroots
<superm1> kees, how weird that you can't reproduce.  i can in sbuild, pbuilder, and on buildd's
<bryce> slangasek: yeah, additional bugs
<superm1> kees, so try to rebuild cvs with that env variable and see if things improve then?
<kees> superm1: are there any minimal commands that fail for you?
<slangasek> bryce: what bugs are those?
<kees> superm1: yeah, that'll certainly force those checks off in cvs, but I'd like to have a better idea of what's going wrong.
<superm1> kees, the most minimal command that fails is "cvs status"
<kees> .... uhm
<kees> it's failing for me now.
<kees> wtf.
<NCommander> hey superm1
<superm1> hi NCommander
<NCommander> superm1, how goes it?
<superm1> NCommander, busy as usual :)
<bryce> slangasek: like #291908, hangs device when any pressure is on it
<NCommander> superm1, busy with what specifically; anything I can do to hep?
<superm1> NCommander, with work related things, so not really so much.  but if you are looking for bugs to fix on stuff, i've got plenty i can point you at :)
<NCommander> heh, ScottK just got me on one :-)
<kees> superm1: ah-ha, cvs 1:1.12.13-11 happened on Jan 27, 2008.  Hardening was enabled on Jun 08, 2008.
<bryce> slangasek: basically my question is whether a sync of the driver is feasible, or if the individual fix needs to be identified and SRU'd by itself
<kees> superm1: so, this is a problem now (I have no idea how it was ever noticed during intrepid... weird)
<superm1> kees, ah so it never got rebuilt for hardening.  the fact that we synced is why it happens now
<kees> superm1: right.  I'm curious how the problem in the wiki was ever noted, but when I tested it had "gone away" since it wasn't rebuilt yet.  wheee
<superm1> kees, well at least i'm catching this early You've got eon's to ponder on it now. :)
 * kees wonders why it doesn't freak out in fedora...
<jackrabbit> I'm having a problem running autogen.sh on a svn build of network-manager-applet since upgrading to 8.10
<jackrabbit> the error I get is: libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
<jackrabbit> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
<jackrabbit> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
<jackrabbit> does anybody know what's causing this?
<cjwatson> jackrabbit: surely that is a warning, not an error; if you aren't the developer you can ignore it
<jackrabbit> well, it started after I upgraded and then I got some other errors as well
<cjwatson> then you should investigate the things that are actually errors
<jackrabbit> and . . . I ma developing
<jackrabbit> :)
<cjwatson> the output you quote from libtoolize is clear instructions to developers on changes in libtool macro handling
<jackrabbit> which I believe are responsibles for the errors later on
<cjwatson> but, as you can tell from the language used ("Consider ..."), they don't need to be fixed immediately
<cjwatson> jackrabbit: it seems unlikely, but it is impossible to tell without knowing what those errors are
<jackrabbit> cc1: warnings being treated as errors
<jackrabbit> utils.c: In function âutils_fill_connection_certsâ:
<jackrabbit> utils.c:231: error: implicit declaration of function ânm_setting_802_1x_set_ca_cert_from_fileâ
<jackrabbit> utils.c:235: error: implicit declaration of function ânm_setting_802_1x_set_client_cert_from_fileâ
<cjwatson> totally and utterly unconnected to the libtoolize output
<cjwatson> what is the svn url?
<jackrabbit> I think they're caused by the abcense of header files
<cjwatson> what would libtoolize have to do with header files?
<cjwatson> (it operates on objects and has nothing to do with headers)
<jackrabbit> svn://svn.gnome.org/svn/network-manager-applet/trunk
<jackrabbit> cjwatson: I'm not that familiar with libtool/autotools etc
<cjwatson> jackrabbit: the network-manager-applet version you're compiling requires a newer NetworkManager than what's packaged in Ubuntu 8.10
<cjwatson> jackrabbit: the nm_setting_802_1x_set_ca_cert_from_file and nm_setting_802_1x_set_client_cert_from_file functions were added in revision 4239 of NetworkManager, which was committed on the day 8.10 was released
<jackrabbit> that's svn too
<jackrabbit> ok, I'll re-install and see if that helps
<cjwatson> that suggests that you are not successfully using the headers from the NetworkManager you built, but are instead using the system headers, then
<jackrabbit> cjwatson: mind if I ask how you figured that out?
<cjwatson> how I figured which bit out?
<jackrabbit> that the symbols were from a newer version than 8.10
<cjwatson> jackrabbit: I checked out NetworkManager, grepped for that function, used 'svn blame' to find out when the lines in the header file in question were last changed, and used 'svn diff' to confirm that the revision in question was the one that initially introduced those symbols
<cjwatson> and then 'svn log' told me the commit date which was later than the time 8.10 was released so I didn't need to look any further than that
<jackrabbit> ok
<jackrabbit> thanks, now I'll be able to check that out next time :)
<directhex> hm, /me spots a minor bug
<directhex> looks like a gtk label doesn't have pango markup enabled on it
<kees> holy cow.  cvs implements its own kind of asprintf.
<kees> and manually constructs %n-using vsprintfs
<kees> superm1: well that was fun to track down.  I've uploaded a fixed cvs now.
<NCommander> hey kees
<kees> hola NCommander
<NCommander> So here's my research
<NCommander> If you have a prebuilt PIE GCC and glibc, you can install it into an existing system
<NCommander> But I need doko's help to actually get a usable patch, mine breaks the C++ compiler from compiling :-/
<kees> why do gcc and glibc need to be PIE before I can built other PIE stuff?
<kees> er, can build
<NCommander> no, if you want glibc/gcc to be pie
<NCommander> :-)
<NCommander> You can have PIE binaries without them
<kees> I'm happy to move one step at a time
<NCommander> kees, if your going to be at UDS, we could work on this there (aka, get the spec fully hammered out and such)
 * kees nods
<kees> yup, I'll be there.  :)
<NCommander> That way, we can also pin doko and extract the secrets of GCC from his brain
<elmo> woo, security vs. toolchain!
<elmo> it wouldn't be a UDS without it!
<kees> :)
<elmo> \o/
<wgrant> Toolchain always wins.
<elmo> wgrant: this time, kees brought reinforcements
<elmo> TAG TEAM CAGE MATCH
<kees> though, I think I still lost since I ended up joining the toolchain group.  :P
<NCommander> We should have a four way fight, toolchain v. server v. kernel v. security!
 * NCommander runs
<wgrant> elmo: But now you've warned doko of the evil reinforcement plan.
<NCommander> elmo, got a moment?
<wgrant> Do the archive admins know that Jaunty PPAs are waiting on them now, or are we in a deadlock like we were with Intrepid translations?
<elmo> NCommander: not really, but what's up?
<NCommander> elmo, its yet another PPA question. I have a pending request to see if the kernel team can get a non-virtualized PPA for the linux-ports kernel. Obviously building the -ports kernel on x86/amd64 is of *ahem* limited value :-)
<NCommander> er
<NCommander> THat wasn't meant to be a PM
<NCommander> https://answers.edge.launchpad.net/soyuz/+question/48531 - the distro team asked me to bring to the PPA admins
<wgrant> NCommander: You mean the other way around?
<NCommander> wgrant, what the otherway around?
<wgrant> The PPA people seem to be asking you to ask the distro team, not vice-versa.
<NCommander> the distro team sent me back :-P
<wgrant> Ah.
<NCommander> EINFINITELOOP
<elmo> well
<NCommander> Ports is somewhat unique, since even just finding some of the hardware *cough*hppa*/cough* is a down right pain
<kees> ogra: can you handle the moodle merge? the security fixes I added are all in the Debian package now.
<DoYouKnow> how do I get the latest development kernel on ubuntu?
#ubuntu-devel 2008-11-11
<sconklin> DoYouKnow: https://wiki.ubuntu.com/KernelMaintenance
<DoYouKnow> ty
<maxb_> On my Thinkpad T40p, since upgrading to intrepid, the "mute" key has turned into a "lock screen" key. I'm a bit lost as to how to debug, or which package to file a bug against
<DoYouKnow> System->preferences->keyboard
<DoYouKnow> did you look there?
<DoYouKnow> check this link out:
<DoYouKnow> http://ubuntuforums.org/showthread.php?t=633403
<DoYouKnow> it's on changing the keymap
<DoYouKnow> click on keyboard moel
<DoYouKnow> *model
<DoYouKnow> and check if the right one is selected
<superm1> kees, awesome! thanks
<fta> to who's behind http://patches.ubuntu.com, please extract the series/00index files, it's confusing upstream when some patches are listed there but are not applied in reality
<lifeless> fta: what do you mean 'extract'
<stgraber> lifeless: I guess, basically only showing patches that are applied (the ones in 00list) instead of all patches with no way to know which are actually applied
<fta> lifeless, referring to " /by-release/extracted/ubuntu"
<lifeless> stgraber: I can guess as well, but fta knows!
<lifeless> fta: sorry, please be more clear. Do you want the file shown, do you want patches that aren't in it not shown? details..
<fta> either way is fine, the current way is not :)
<fta> lifeless, maybe it's easier to only extract the active patches and keep the indexes hidden (as upstream is not always aware of what quilt and dpatch are)
<ScottK> fta: Do you have experience with upstreams that browse p.u.c directly?  IME usually it's a link to a specific patch in a bug report so they know which to look at.
<fta> ScottK, yes, mozilla, they are currently reviewing our patches for xul and firefox
<ScottK> I see.  In that case I can see how it could be a bit confusing.
<fta> ScottK, we have a long list of patches, it's easier that way, compared to using the branch on code.lp
<ScottK> I wonder if there's some bzr-whatever_they_use_now (Hg I think?) plugin where they could pull the branch in and review it in their own VCS?
<fta> it's hg, they have hgweb, a clone of gitweb, and several web tools to dig into the code
<fta> but for a quick patch review, p.u.c is nice
<piju_> hello, how can i make a suggestion in packages ?
<hyperair> piju_: what dyou mean?
<piju_> hyperair, wants to suggest to put newer version of package
<piju_> hyperair, i think squid 2.7 is better than squid 2.6, but squid 3 is different version from 2.* that is why there is two version of squid in debian/ubuntu packages
 * hyperair has no idea
<hyperair> well file a bug on launchpad.net
<hyperair> speaking of which.... squid 2.7 is in ubuntu
<hyperair> piju_: ^
<hyperair> so what's your point exactly?
<piju_> hyperair, ok thanks
 * hyperair is confused
<piju_> my points is, ubuntu user can use the benefits of squid 2.7
<piju_> thats all
<piju_> im not ruining ubuntu
<hyperair> well
<hyperair> squid 2.7 is in ubuntu
<hyperair> so
<piju_> if u feel like im such a jerk. its ok. just forget it
<hyperair> i don't understand
<hyperair> seriously
<hyperair> nono there's some miscommunication or something. =.=
<piju_> pool/main/s/squid/squid_2.6.18-1ubuntu3_i386.deb
<piju_> still 2.6
<hyperair> that's in older versions of ubuntu
<hyperair> ubuntu intrepid has squid 2.7
<hyperair> dyou mean you want squid 2.6 backported?
<piju_> really ?
<hyperair> yep
<piju_> intrepid has squid 2.7 ?
<hyperair> yep
<hyperair> ubuntu hardy has squid 2.6, intrepid has squid 2.7
<piju_> ok. nevermind. coz im using hardy now.
<hyperair> ah
<piju_> hyperair, thanks. maybe squid 2.7 can be backported in hardy
<hyperair> yeah you can file a backport request in launchpad.net =)
<piju_> ok. thanks
<woody86> any body have problems updating their packages after upgrading to 9.04? I try to do a partial upgrade, but then it says "Can not upgrade. An upgrade from 'jaunty' to 'intrepid' is not supported with this tool"
<woody86> and that's using update manager
<wgrant> woody86: If you don't know how to fix that or why it happenns, you shouldn't be using Jaunty.
<woody86> wgrant- well thanks for such an informative response. I'm in the MOTU mentor program right now, and my Mentor wanted me to install 9.04 so he could teach me stuff using 9.04, but he's not online right now to ask
<ScottK> woody86: Who is your mentor?
<dholbach> good morning
<dholbach> the kill switch for wifi on my IBM X40 does not work any more (intrepid), does anybody else have the same problem? what can I do to debug it? loading the ipw2100 does "work", but the wireless LED is still not blinking
<soren> dholbach: Your X40 has a wifi kill switch?
<dholbach> soren: well the FN-F5 thing
<soren> dholbach: Oh, that.
<dholbach> right now it just toggles bluetooth on and off
<dholbach> but no wifi workie workie
<soren> :(
<slangasek> dholbach: the wireless in the IBM X40 is ipw2100?
<dholbach> slangasek: yep
<dholbach> I'm just talking to amitk on #ubuntu-kernel - let's see what he can find :)
<slangasek> dholbach: do you have a /sys/class/net/$dev/device/rfkill directory?  I think each driver has to be converted to that individually and I don't have any idea if ipw2100 has; the acpi-support stuff should still support the old interfaces as well, but that's probably untested in intrepid
<dholbach>   /sys/devices/platform/thinkpad_acpi/rfkill
<dholbach>   /sys/devices/platform/thinkpad_acpi/rfkill/rfkill0
<dholbach>   /sys/class/rfkill
<dholbach>   /sys/class/rfkill/rfkill0
<dholbach>   /sys/module/rfkill
<dholbach> slangasek: http://paste.ubuntu.com/70342/ - it worked like 2 days ago with intrepid, but does not work now
<slangasek> hum
<slangasek> so no under /sys/class/net/$dev/device/rfkill ?
<slangasek> s/under //
<dholbach> what I pasted above is the output of   find /sys/ -name "*kill*"
<slangasek> ok
<slangasek> hopefully you still have /sys/class/net/$dev/device/power/state ?
<dholbach> daniel@lovegood:/sys/class/net$ ls
<dholbach> eth0  lo  pan0
<dholbach> daniel@lovegood:/sys/class/net$
<dholbach> no, doesn't look like it
<slangasek> is one of those your wireless?
<slangasek> (i.e., is your wireless device named 'eth0' for some reason?)
<dholbach> no, I'm connected via cable (eth0) right now
<dholbach> pan0 should be some bluetooth thing I never managed to use :)
<slangasek> mmm, you should still have the device listed there if the kernel detects it.
<UpChuck_Norris> Just to be sure it's not the obvious solution, is your wireless card disabled (keyboard shortcut, power switch, etc.)?
<wgrant> That sort of problem often spontaneously occurs due to the wireless card deciding to disable itself in the BIOS
<dholbach> wgrant: alright, I'll reboot and see what the BIOS says - back in a bit
<wgrant> I've no idea how it happens.
<wgrant> But I'
<wgrant> But I've seen it on a couple of different machines now.
<dholbach> alright
<slangasek> UpChuck_Norris: I guess you're joining us mid-conversation; dholbach's specific complaint was that the keyboard shortcut doesn't work.
<xTr3m3> hi
<wgrant> slangasek: Some wifi kill switches (the one on my father's HP laptop, in particular) actually drop the device off the bus.
<slangasek> then how is un-kill supposed to work?
<xTr3m3> ubuntu 8.10 = really great work!
<xTr3m3> always a pleasure ubuntu to see continue to grow in every respect
<wgrant> slangasek: It's implemented in hardware.
<slangasek> xTr3m3: thanks, we're glad you like it
<xTr3m3> =)
<slangasek> wgrant: tsk
 * wgrant likes happy users.
<liw> I have one of those hardware kill switches, it seems
<xTr3m3> i like it ,open source is the best for future
<liw> except only for bluetooth, not wifi
<wgrant> It's not quite as infuriating as Dell brightness keys, I don't think.
<wgrant> We;ve got libsmbios to control brightness in software, but AFAICT you can't stop the BIOS from controlling the brightness.
<wgrant> So when you unplug the AC, the BIOS drops the backlight immediately, then g-p-m puts it back up and down again in a gradient.
<wgrant> It looks stupid, and there's no way to fix it.
<liw> (bluetooth on usb, wifi on pci, that's probably why)
<wgrant> The lack of dholbach after almost 10 minutes isn't promising...
<StevenK> pitti: I didn't, since I'm bad. :-(
<dholbach> amitk, wgrant, slangasek: seems like I'm an unhappy person today: http://people.ubuntu.com/~dholbach/img_2498.jpg
<dholbach> (so not necessarily an Ubuntu problem)
<mvo> dholbach: alter! *unauthorized*
<pitti> Good morning
<dholbach> mvo: it's built-in wireless
<amitk> dholbach: Unauthorized?!
<dholbach> mvo: no boot - no wireless - no laptop - no happy
<amitk> dholbach: http://www.thinkwiki.org/wiki/Problem_with_unauthorized_MiniPCI_network_card
<pitti> mvo: ah, ok; it was a feature, so don't flip it back and forth; I just wasn't sure whether something was weird
<pitti> ScottK: insane-backends> coming...
<tkamppeter> pitti, hi
<dholbach> amitk: I can't boot the machine at all now :)
<wgrant> dholbach: Well done!
<wgrant> dholbach: Remove the MiniPCI card and see if it works?
<tkamppeter> pitti, I have found a fix for bug 290395 and would like to make an SRU
<ubottu> Launchpad bug 290395 in splix "[Intrepid] Xerox Phaser 6100 driver 2.0.0 does not work causing SpliX error" [Undecided,Invalid] https://launchpad.net/bugs/290395
<tkamppeter> Only problem is that it is not a tiny patch but one has to replace the pdftoraster filter by another one
<pitti> tkamppeter: uh, that sounds regression prone
<tkamppeter> See my last comment in the bug report
<pitti> tkamppeter: can you please sub ubuntu-sru? I'll have a look later then
<amitk> dholbach: did you update the bios recently
<dholbach> amitk: no, never
<dholbach> I'm too boring for things like that
<tkamppeter> pitti, I can perhaps also do it somehow that I add a renamed version of the filter to SpliX and also some .types and .convs files so that only SpliX uses the new filter-
<pitti> tkamppeter: that's a good idea
<pitti> tkamppeter: then this new filter could be shipped in the splix package itself?
<tkamppeter> pitti, yes. This will then only be done for the INTrepid SRU package of SpliX. This will not be introduced in Jaunty. In Jaunty pdftoraster will be replaced straight-away so that it gets full 6 months to get tested.
<pitti> tkamppeter: sounds like a good plan
<tkamppeter> pitti, the filter will be renamed to pdftosplixraster and by conversion rule it produces data of format splix-raster. The SpliX PPDs will then get patched to accept splix-raster as input.
<tkamppeter> And this will be made exclusively for Intrepid, not for Jaunty.
<tkamppeter> pitti, see my last comment on bug #290395
<ubottu> Launchpad bug 290395 in splix "[Intrepid] Xerox Phaser 6100 driver 2.0.0 does not work causing SpliX error" [Undecided,Triaged] https://launchpad.net/bugs/290395
<tkamppeter> pitti, does this work? Can I make a new Intrepid package for SpliX for the SRU without needing to upload it into Jaunty?
<pitti> tkamppeter: if the corresponding filter change is one in jaunty (in cups, I assume?), that's fine, yes
<tkamppeter> pitti, so I should do the Jaunty changes at first?
<tkamppeter> pitti, this means that I remove pdftoraster and its .tconvs rule from CUPS, add the new filter and the .convs rule to Ghostscript.
<pitti> tkamppeter: it should be done by the time it goes into -updates; you can do the SRU first, if you are currently working on it
<tkamppeter> pitti, the cups/ghostscript change also affects Debian, as CUPS is synced.
<pitti> tkamppeter: I guess that's intended?
<tkamppeter> pitti, yes. Debian should also get equipped with the better pdftoraster filter. We only have to do it in a way so that the time where Debian is incomplete (filter taken from CUPS but not yet added to ghostscript) as short as possible.
<pitti> tkamppeter: why does it need to move anyway?
<tkamppeter> pitti, but you can probably also upload Ghostscript into Debian, simply applying the debdiff of my next Ubuntu Ghostscript to it.
<stefanlsd> Anyone use jigdo on Ubuntu that needs an updated Ubuntu mirror list, or is it ok as is?
<tkamppeter> pitti, it has to move as I have placed my pdftoraster filter in the upstream repository of Ghostscript, as pstoraster is already there. The Poppler-based pdftoraster is in the Ubuntu/Debian package of CUPS and upstream neither in CUPS nor in Ghostscript.
<pitti> tkamppeter: no, I can't upload gs into debian
<pitti> tkamppeter: but you should file a debian bug with the changes and ask the maintainer to upload to experimental, so that we can do the cups change in experimental, too
<pitti> tkamppeter: until that happens, we have to fork cups
<pitti> tkamppeter: or put a copy of the new pstoraster into cups
<tkamppeter> pitti, there will probably not be an interruption, if someone happns to have the new CUPS package with pdftoraster removed but not the new Ghostscript with pdftoraster added, CUPS will automatically take a PostScript path using pstoraster. So if Debian's ghostscript maintainer does not follow quickly, most users will not see any problem.
<pitti> tkamppeter: that shuold be done with a versioned dependency on ghostscript
<dholbach> slangasek, wgrant, amitk, mvo: it was a hardware problem, I took out the minipci card, dusted it off, put it back in again and the machine is happy again :)
<tkamppeter> pitti, so as the removal of pdftoraster from CUPS does not cause any breakage and as CUPS trunk is currently only in experimental, I think I will commit the removal to BZR now and the Ghostscript change will probably follow soon, as the gs maintainer can simply take my changes from the Ubuntu gs package.
<pitti> tkamppeter: ok, if that works (I think I did try to remove pdftoraster, and that broke with a "filter not found" error)
<tkamppeter> pitti, as soon as the pdftoraster-equipped gs package appears in Debian, the CUPS package of Debian will get a versioned gs dependency.
<tkamppeter> pitti, you cannot simply take away a filter under a running CUPS daemon. You must also take away pdftoraster.convs and restart CUPS.
<pitti> ah, I didn't remove the .convs
<wgrant> dholbach: How strange...
<dholbach> wgrant: my X40 is 4+ years old, so it was just the off-dusting and re-plugging :)
<hyperair> dholbach: you have an ibm x40?
<dholbach> hyperair: yes
<hyperair> dholbach: how's suspend on it?
<dholbach> hyperair: it works :)
<hyperair> resume with backlight?
 * wgrant likes having a 3 year old laptop - pretty much all of the hardware works fine in Ubuntu.
<hyperair> how very strange. must be one of those models which works
<hyperair> wgrant: mine's 3 months old and everything works =D
<siretart> Mithrand1r: (or anyone involved in pkg-config): I've brought up the pkg-config issue on the ffmpeg-devel mailing list, you can read about it here: http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/76897
<siretart> anyone else, that is.
<dholbach> slangasek, wgrant, amitk, mvo: thanks for your help!
<tkamppeter> pitti, I have built the new cups 1.3.9-4 and tested it. It actually works without pdftoraster by going the pstoraster way. I have pushed it into the Debian BZR now.
<pitti> tkamppeter: can you please refer to the ghostscript debian bug in the changelog, so that it's easy to find?
<tkamppeter> pitti, the Ghostscript Debian bug I will post as soon I have the new Ghostscript package. Then I can directly provide the patch.
<pitti> tkamppeter: ok, great
 * pitti fixes ubuntu-dev-tools buildd to work with pockets
<viviersf> can someone tell me, why when i use an ubuntu alternate cd to make changes to isolinux default config, and rebuild the iso, i get a invalid cdrom error ?
<viviersf> Mithrand1r, you still in charge of this ?
<Mithrand1r> viviersf: no, and I haven't been in a long time.
<Mithrand1r> viviersf: unsure why you should get that error, though.
<viviersf> Mithrand1r, :(
<slangasek> dholbach: n/p, glad to hear you have it working again!
<viviersf> Mithrand1r, who does the alternate cd installer stuff these days ?
<cjwatson> wgrant: we already un-deadlocked jaunty PPAs earlier yesterday; cprov said they're enabled now
<wgrant> cjwatson: Yep, they're enabled. I spoke to him a few hours ago.
<wgrant> Thanks.
<cjwatson> viviersf: exactly what command did you use to rebuild the CD?
<kirkland> mvo: hiya
<kirkland> mvo: I looked at your revision 410
<mvo> kirkland: excellent, thanks!
<mvo> kirkland: how do you feel about it?
<mvo> kirkland: oh, I see the mail now
<sebner> pitti: mighty pitti! what's now with audacious? :P
<kirkland> mvo: very similar to what I was going for in an early revision of the shell script, so i like the concept
<kirkland> mvo: see what you think, about apt-check always writing the human-readable output (and translated) to /var/run/updates-available
<pitti> sebner: this morning I noticed that ports buildds were clogged; I bumped the build score of all SRUs, and many have caught up now; can move as soon as hppa built it
<sebner> pitti: ah I see, thx! sry for the trouble
<DigitalSpirit> j
<viviersf> cjwatson, mkisosfs ?
<viviersf> cjwatson, hold, mkisofs -J -R -l -V "Ubuntu" -b isolinux/isolinux.bin -no-emul-boot -boot-load-
<viviersf> size 4 -boot-info-table -z -iso-level 4 -c isolinux/isolinux.cat -o
<viviersf> ./autoinstall.iso newiso/
<viviersf> cjwatson, i got that from a canonical whitepaper
<cjwatson> viviersf: I am interested to know which, since it's slightly at variance with the options we use for our own images
<cjwatson> viviersf: try: mkisofs -r -V 'Ubuntu 8.04 i386' -o autoinstall.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table newiso
<cjwatson> viviersf: if you can give me the URL of the white paper I may be able to get it corrected
<viviersf> cjwatson, robin barley-wagner mailed it to us
<cjwatson> viviersf: thanks
<cjwatson> viviersf: can you confirm that the options I give make it work?
<viviersf> cjwatson, im gonna try it quick, gimme a sec
<cjwatson> viviersf: also, at what point does it fail? is it a BIOS-type message, or is it a blue screen with an error message from the installer?
<viviersf> cjwatson, its a big red message from the installer
<cjwatson> viviersf: oh. In that case you probably just forgot to copy over the .disk directory
<viviersf> oh!
<viviersf> *dumbass*
<viviersf> lol
<viviersf> cjwatson, ill try with that dir quick
<jordi> slangasek: it isn't on a 64-bit capable system running a 32 bit install (with a 64 bit kernel?)
<jordi> slangasek: honestly, I don't know much about this stuff, my personal desktop is a very modern Athon 800, which wasn't too capable of anything last time I checked ;)
<viviersf> cjwatson, thanks allot :) it works
<viviersf> cjwatson, using a kickstart file, i get a busybox "uknown option : -l"
<viviersf> is that a known problem ?
<cjwatson> viviersf: yes, bug 293586 :-(
<ubottu> Launchpad bug 293586 in busybox "lack of CONFIG_GETOPT_LONG in busybox-udeb completely breaks Kickstart" [High,Fix released] https://launchpad.net/bugs/293586
<viviersf> cjwatson, and how do i bypass that ? :(
<cjwatson> 8.04 ...
<cjwatson> or preseeding
<cjwatson> sorry about this, entirely my fault
<viviersf> cjwatson, lol, i need to deploy 8.10 with kickstarts, can i create a new disc with a different busybox-udeb somehow ?
<viviersf> cjwatson, or can i use a 8.04 cd to install a 8.10 desktop ?
<cjwatson> viviersf: I have no easy solution to offer you right now
<viviersf> cjwatson, ok
<cjwatson> viviersf: https://launchpad.net/~kamion/+archive contains a fixed busybox
<cjwatson> viviersf: but you'd need to rebuild debian-installer against that
<viviersf> ugh
<viviersf> cjwatson, if i use network mirror for 8.10, would a 8.04 cd be able to install it ?
<ogra> eeek, Riddell can you reject my latest xf86-input-evtouch upload ? i accidentially set the distro to interpid-updates instead of intrepid-proposed
<ogra> i'll re-upload with the proper target
<cjwatson> viviersf: no
<pitti> ogra: done
<Hobbsee> ogra: thrown out.
<Hobbsee> pitti: beat you :)  *throws a gummy bear to you*
<cjwatson> viviersf: you could use http://people.ubuntu.com/~cjwatson/tmp/intrepid-busybox-fix/netboot/ if netboot is OK for you
<pitti> ok, Hobbsee beat me by 0.5 seconds
<ogra> gracias !
<Hobbsee> pitti: \o/  Even with aussie lag!
<cjwatson> viviersf: there's a mini.iso there too
<cjwatson> viviersf: only i386 at the moment though
<pitti> Hobbsee: in this case it was my IRC reading lag :)
<Hobbsee> heh :)
<viviersf> cjwatson, i want i386 and as long as i installs im happy ;) thx
<directhex> hurrah. mono 2.0-1: no universe build-deps
<mvo> kirkland: thanks for your mail, I just replied :)
 * mvo goes to get some food
<pitti> ogra: was there any progress wrt. the dhcp3 next-server option patch upstream?
<ogra> pitti, no, and there wont be ever (the discussion predates our patch btw)
<ogra> upstream simply disagrees with our view, jammcq (ltsp) has discussed it several times with them and mdz and i decided to add it on a package level instead so that our users arent affected, i would stil like to keep it until upstream finally releases a v4.x
<pitti> ogra: ok, fine
<pitti> oh, it's fixed in 4.x?
<ogra> no idea, but if there is a 4.x users wont be shoked if features changed
<tkamppeter> pitti, I have made a new Ubuntu package of gs, filed a bug against Debian gs to take the new pdftoraster (Debian bug 505282), and added the bug number to the CUPS changelog. This changelog I have pushed to bzr now. Now you should be able to upload the CUPS package to both Debian and Ubuntu.
<ubottu> Debian bug 505282 in ghostscript "Add pdftoraster filter to Ghostscript" [Unknown,Open] http://bugs.debian.org/505282
<ogra> the thing is that they removed the feature in a minor update where nobody would expect it to vanish
<tkamppeter> pitti, tell me when you have uploaded the new cups package so that I can upload ghostscript to Ubuntu.
<pitti> tkamppeter: cool, thanks; building now
<ogra> pitti, there is no "fix" for disagreement ;) the change is less of a surprise in a new version though
<pitti> ogra: ah, ok; (disclaimer: I never understood what this patch is all about, just monkey-porting)
<ogra> we'll go with whatever will be in v4.x but should keep the patch during the 3.x cycle
<pitti> argh apt
<ogra> its about userfriendlyness, next-server used to default to the dhcp server itself if unset (so tftp gets automatically requested from the same machine on netboot), at some point upstream decided to force it to 0.0.0.0 if unset which breaks all existing setups
 * pitti wonders whether he'll ever remember auto-remove (option) vs. autoremove (command)
 * mvo wonder if he should add a alias option for autoremove for pitti
<pitti> mvo: just teach me harder :)
<ogra> pittiremove ?
<ogra> especially helpful before vacations :)
 * mvo add --teach-pitti-harder
 * mvo add --teach-pitti-harder-with-a-big-whip
<pitti> mvo: rrrrrr
<mvo> lol
<kirkland> mvo: hiya!
<kirkland> mvo: if you'd prefer, the updates-available shell script could actually be python
<kirkland> mvo: update-motd doesn't care...  it just executes the scripts/links in those dirs
<mvo> kirkland: either way is fine with me
<kirkland> mvo: the same goes for notify-reboot-required ...  in python, the translation of that string might be easier (more consistent with the rest of the code)
 * mvo nods
<kirkland> mvo: i'm grabbing some lunch, will catch up in a bit ;-)
<mvo> kirkland: ok, cool
<mvo> kirkland: I think we are 99% there now :)
<mvo> kirkland: a upload today for it should be feasible
<pitti> tkamppeter: cups uploaded to debian and jaunty
<Ng> mvo: does update-manager emit the power management inhibiting things while it's working?
<mvo> Ng: yes
<Ng> mvo: so that would disable suspend and hibernate, but presumably not reboot/shutdown?
<mvo> Ng: yes, I would like to add reboot/shutdown to this too, I haven't figured out yet how to do this
<tkamppeter> pitti, thanks, I will upload gs now. I have already test-built it and with it installed the correct filter chain is used and bug 290395 actually fixed.
<ubottu> Launchpad bug 290395 in ghostscript "[Intrepid] Xerox Phaser 6100 driver 2.0.0 does not work causing SpliX error" [Undecided,In progress] https://launchpad.net/bugs/290395
<Ng> mvo: fair enough. I just fixed an install where the user had shutdown instead of locking the screen, by mistake ;)
<mvo> Ng: in the office?
<Ng> mvo: yup
<mvo> Ng: I make it a priority
<Ng> mvo: while I was thinking about that, I also wondered if it would make sense to refuse to upgrade, or at least display scary discouragements, if the user is just on battery
 * mvo scratches his head
<mvo> that would make sense
<Ng> I think scary discouragements would be the better option than just refusing to do it
 * ScottK would find refusing really annoying.
<tkamppeter> pitti, gs is uploaded now.
<Ng> ScottK: yeah, I think i would too, but I would appreciate being reminded that I'm risking my sanity :)
<ScottK> I think a warning is fine.  I can imagine thinking "Yes, but I have hours of batter left and I just have to walk across the room to plug in.  I just don't feel like it right now."
<ScottK> batter/battery
<hyperair> could someone take a look at pm-utils debian/patches folder? it seems that the 99 patch comes before the 85 patch in debian/patches/series
<hyperair> how very strange
<hyperair> ah nevermind. as long as it builds =.=
<tdomhan> if you want to request a new feature for ubuntu, do you file a blueprint, or should you file a wishlist bug?
<directhex> what kind of feature?
<cjwatson> users should not file blueprints
<cjwatson> blueprints are software design documents and should generally be written by developers
<tdomhan> kk, was just curious what the process is
<cjwatson> generally speaking a wishlist bug is perfectly reasonable if it's a relatively small and contained feature (though you may have to argue with bug triagers who are confused about the validity of the concept of wishlist bugs), while more complex and vague ideas should go on brainstorm.ubuntu.com
<emgent> evening
<tdomhan> ok thx
<tkamppeter> pitti, I have another idea about the garbage printing in bug 292690
<ubottu> Launchpad bug 292690 in cups "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,Fix committed] https://launchpad.net/bugs/292690
<tkamppeter> The splix package has a patch against crashing when it gets fed with data with a wrong paper size: debian/patches/no-crash-on-bad-papersize.patch
<tkamppeter> pitti, the patch applies to a part where a lot of page margin calculations are done.
<tkamppeter> pitti, in src/document.cpp, from line 114 on there is some calcualtion for clipping done. Probably something is mis-calculated there.
<tkamppeter> pitti, for example from line 131 on the clipping is applied to the page height, but there is no such thing for the width.
<tkamppeter> pitti, as you have the printer you could perhaps find out what needs to be corrected.
<Shoopuf> Destruction of erratic volume sliders is on my Christmas wish list.
<pitti> tkamppeter: I can try without the patch, for a start
<tkamppeter> pitti, OK
<mvo> james_w: is there anything like a "pre-build-command" hook in bzr-buildpackage? I would like to run ./autogen.sh automatically when doing the package build
<tkamppeter> pitti, SRU for bug 290395 uploaded
<ubottu> Launchpad bug 290395 in ghostscript "[Intrepid] Xerox Phaser 6100 driver 2.0.0 does not work causing SpliX error" [Undecided,Fix released] https://launchpad.net/bugs/290395
<james_w> hey mvo, check out file:///usr/share/doc/bzr-builddeb/user_manual/hooks.html
<mvo> james_w: exactly what I want, thanks!
 * mvo waves good-by to his arch-build targets
<pitti> mvo: !
 * mvo hugs james_w
<mvo> rrrrrrrrrrrrrrrrrr
<pitti> mvo: bzr-builddeb FTW?
<mvo> good stuff!
<mvo> ftw!
<mvo> how about a policy "bzr-buildpackage" must build it and the whole discussion of "how packages in bzr should be hanleded" is moot?
<mvo> bzr commit -m 'debian/rules: byebye arch-build"
<tkamppeter> pitti, I have uploaded a splix for bug 290395 into -proposed, can you approve it?
<ubottu> Launchpad bug 290395 in ghostscript "[Intrepid] Xerox Phaser 6100 driver 2.0.0 does not work causing SpliX error" [Undecided,Fix released] https://launchpad.net/bugs/290395
<directhex> hm. did someone come up with a plan to allow package selection in the installer, whilst i wasn't looking? or are my dodgy sources talking their usual crap?
<cjwatson> directhex: no
<directhex> cjwatson, crap being talked, then? doesn't surprise me
<cjwatson> directhex: well, in order to answer that, I'd need to know what was actually said - this is sort of a subtle area
<cjwatson> there have been some suggestions, but nothing that immediately translates into something implementable, and nothing that's been a high enough priority to get me to sit down and work it out
<directhex> cjwatson, it's from the anti-mono crowd, so you can guess their plan
<directhex> i think the phrasology was "keep that microsoft/novell trap out of my hardware" button
<directhex> i think they're confused by the disable-restricted-plz option when booting the install disc these days
<pitti> mvo: do you have a minute for bug 296819? the previous SRU was a bit incomplete and missed a product ID on the balcklist
<ubottu> Launchpad bug 296819 in compiz "Intrepid Compiz hangs on login for i945GM video cards" [Undecided,New] https://launchpad.net/bugs/296819
<pitti> tkamppeter: BTW, I usually add the verification-needed tag and instructions when accepting a package, so you don't need to do that
<mvo> pitti: looking
<mvo> pitti: hm, i945? *urgh*
<cjwatson> directhex: sounds like it
<pitti> mvo: itz bad?
<mvo> pitti: yes, i945 is very common and pretty recent, blacklisting that will affect a lot of system
<mvo> pitti: I talk to #ubuntu-x about this first I think
<pitti> mvo: ok, thanks; seems to be a deeper issue then
<mvo> pitti: thanks, I work on it, but I have a bad feeling about it, there are not many cards (from intel) if we blacklist i945 entirely
<pitti> mvo: yeah, absolutely; let's not for now
<pitti> mvo: all i945 have the same product ID?
<mvo> pitti: not sure, for some cards (IIRC 830) there is only one, for others there are multiple ones, I need to find out more about it
<mvo> pitti: dosn't your dell have a i945?
<mvo> or was thas a 965 already?
<pitti> 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
<pitti> mvo: it's a 945, but product ID 27a2
<pitti> hm, wait
<pitti> I *also* have a 27a6
<pitti> that's the one I pasted above
<pitti> the 27a2 is
<pitti> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
<mvo> pitti: hm, could you try compiz on it? does it hang on login for you too?
<pitti> mvo: I have run compiz for months without problems
<mvo> pitti: thanks, do you mind if I put that into the report?
<pitti> mvo: already done
<mvo> heh .) thanks
 * cjwatson considers converting usplash to unifont
<Keybuk>     -> copying [./libs]
<Keybuk> cp: cannot stat `./libs': No such file or directory
<Keybuk> my pbuilder-fu is not strong - what does that mean?
<jpds> Keybuk: I usually see that when one doesn't do "pbuilder build" on the *.dsc file.
<Keybuk> hmm, I gave it the changes file
<Keybuk> silly thing
<Keybuk> sbuild is so much easier
<Keybuk> but not the "done thing"
<Keybuk> geser: around?
<persia> Why isn't sbuild the "done thing"?  Lots of us use sbuild.
<geser> Keybuk: yes
<Keybuk> geser: I was looking at your lockfile-progs
<Keybuk> and something caught my eye
<Keybuk> lockfile-progs (0.1.11ubuntu2) intrepid; urgency=low
<Keybuk>   * Merge with Debian unstable (0.1.11-0.1)(LP: #242086).
<Keybuk> why that version?
<Keybuk> shouldn't it be 0.1.11-0.1ubuntu1 ?
<persia> 0.1.11-0.1ubuntu1 < 0.1.11ubuntu1
<Keybuk> or is there a missing debian/changelog entry for an 0.1.11ubuntu1 (based off 0.1.11 assumedly?)
<Keybuk> persia: there's no 0.1.11ubuntu1 mentioned in debian/changelog
<persia> This is the fundamental issue with not always using -0.0ubuntu1 when ubuntuising native packages.
 * persia refrains from further comment
<Keybuk> ah, Soyuz says there _was_ an 0.1.11ubuntu1
<Keybuk> geser: when merging, it's always best to preserve the merged changelog
<geser> Keybuk: if I remember correctly the old Ubuntu changes got merged in Debian but due to the versioning we needed that fakesync/fakemerge
<geser> the other change was needed to get it build
<Keybuk> even then, I always try and preserve the ubuntu changelog
<liw> https://bugs.launchpad.net/ubuntu/+source/system-cleaner/+bug/285614 -- is there something I can do interpret those stack traces? it's a SEGV inside the Python interpreter, and I don't see any reason why my code would cause that to happen
<ubottu> Launchpad bug 285614 in system-cleaner "system-cleaner-gtk crashed with SIGSEGV in _PyObject_GC_New()" [Medium,New]
<Keybuk> \sh: you really don't need to mention the policy maintainer change in debian/changelog
<RainCT> Symlinking the changelog is correct (and automatically done) in Ubuntu, right?
<RainCT> (I'm about to file a bug against lintian asking for the debian-changelog-file-is-a-symlink not to be shown for Ubuntu packages, but want to be sure first :))
<ScottK> RainCT: Only for CDBS packages it is done (IIRC).
<infinity> RainCT: It's only correct if the package has a dependency on the package that ships the correct changelog.
<infinity> RainCT: And I could have sworn that lintian's check as smart enough to grasp that (note: when checking an entire .changes, not when checking a single deb)
<RainCT> infinity: ah, I get such complains when checking .deb's
<infinity> RainCT: There's no way it can know if one .deb is correct when it's not self-contained.
<infinity> RainCT: It *IS* a bug for a .deb to not ship a changelog.  But if something else from the same source ships the changelog, and the changelog-less deb depends on it, that's fine (hence you need to be checking the upload as a whole).
<infinity> RainCT: If I'm wrong, and lintian still gets it wrong when checking the entire upload, then that's a valid lintian bug. :)
<infinity> RainCT: (In both Ubuntu and Debian... The policy I'm referring to above is Debian policy, not Ubuntu-specific)
<RainCT> infinity: alright, thanks for the info! :)
<cody-somerville> slangasek, can you take a look at https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/291256 ?
<ubottu> Launchpad bug 291256 in bugsy "update-grub ignores non-xen kernels if the system is a domU" [High,Fix released]
<alkisg> Hi, I'm trying to fix hotkey-setup for my laptop (acer-aspire-5900.hk). But there are some keys that I don't know where I should map them. E.g. there is an "e" key which is supposed to start Acer "Empowering Technology". Should I map this to HP_KEY?
<alkisg> Other keys which I don't know where to map are: TV, Acer Arcade, Shortcut help, eSettings, ePower management, touchpad toggle,  euro, dollar sign. Any ideas?
<slangasek> cody-somerville: I've merged your branch into my local branch, but haven't pushed it yet; I was thinking about changing the variable name to indomU instead of in_domU, which I think is more consistent with the existing convention, what do you think?
<slangasek> jordi: sure, that would be on a 64-bit capable system running a 32-bit install with a 64-bit kernel.  The question is, what software is out there that uses alsa, that you would go to the trouble of running in 64-bit mode?
<alkisg> sladen, any hints? ^^^^
<sladen> alkisg: I think there's a POWER key we were mapping the various "open power-saving control panel" function to
<sladen> alkisg: Acer Arcade, probably needs mapping to just one of the PROG1/PROG2 functions
<alkisg> sladen, KEY_POWER it is then. :) The other ones? Is there any documentation in the key-constants?
<sladen> alkisg: touchpad should be easy to spot from the other files
<alkisg> (and I think I'll map TV to KEY_MEDIA)
<sladen> alkisg: hopefully there's enough comments in the other manufacturer files
<alkisg> sladen, should I include in acer-aspire-5900.hk a call to loadkeys with a "-" parameter (=read from input) to make the euro key actually send a euro character?
<sladen> alkisg: dollah and euro aren't fixable for the moment
<alkisg> sladen, thank you very much. I'll upload the file to the bug report and make a wiki page on how other can do the same thing for their laptops.
<alkisg> *others
<sladen> alkisg: the trouble is that hotkey-setup remaps things in terms of actions (volume up, load media player, ...) and not inserting raw textual sequences (ponder over how handle  alt-shift-euro
<sladen> cloest thing would be "load Character Map" but if the kernel doesn't currently have a map for that;  then we're stuck
<sladen> alkisg: null-mapping the might be a good second best
<alkisg> sladen, I don't really like null-mapping because it makes the key useless, but I believe you're right, so I'll null it.
<sladen> alkisg: looking at the acer-aspire-1600.hk  file,  I recorded the infomration in there, but left it commented out, so rather than null mapping, it's doing whatever it was doing before
<alkisg> sladen, right, better this way. I'll look at the other files too.
<maxb> I have a peculiar hotkey problem too. On my ThinkPad T40p, the "mute" key has become a "lock screen" key with the upgrade to intrepid
<maxb> Any hints on how to debug, or what package to report a bug against and how to make it useful?
<sladen> maxb: coo, that's a new one.
<maxb_> Oh, it gets weirder :-)
<sladen> maxb: can you do some 'acpi_listen'
<maxb_> In the early stages of X session startup, it's working properly!
<xTr3m3> hello ,i have a question about ubuntu 8.10... is 7zip included in ubuntu 8.10?
<sladen> maxb: actually this rings a bell, but from 2 years ago
<maxb_> Oh, acpi_listen is a lot easier than socat - UNIX-CONNECT:/var/run/acpi.socket :-)
<sladen> xTr3m3: yes.
<xTr3m3> =) ok thx...
<maxb_> sladen: the acpi event is the one listed in /etc/acpi/events/thinkpad-mute
<sladen> xTr3m3: if you come across a similar question again, the first thing to do could be to experiment;  and if not, try  Applications->Add/Remove  and see if you can find it searching in there
<sladen> maxb_: have a look in System->Preferences->Keyboard
<alkisg> sladen, in the hotkey-setup folder, there are also an "english" and a "greek" file. Do you happen to know if these get loaded, and when? (before or after the laptop hkeys?)
<alkisg> sladen, and some keys that are "information only", like e.g. the wireless button, I shouldn't map them to e.g. KEY_WLAN, right? (like you did in aspire 1600...)
<maxb_> sladen: "Keyboard" or "Keyboard Shortcuts"? Anyway, I've already disabled the "Lock screen" keybinding in "Keyboard Shortcuts" trying to debug this, but the behaviour is unchanged
<xTr3m3> okay sladen ,thx for information
<sladen> alkisg: yes;  in theory they can be listened for, then depending on whether a particular laptop does the change itself, the change can be displayed, or changed, then displayed
<sladen> alkisg: greek file?
<sladen> maxb_: try killing -9 gnome-power-manager tempoaryily
<alkisg> sladen, yes, I'm greek and I have both greek + english files there... ??
<alkisg> (and the brightness bug didn't occur when I switched the keyboard to greek!)
<sladen> alkisg: where is 'there' (pathname?)
<maxb_> sladen: Better... now "mute" does "volume up"
<alkisg> intrepid - /usr/share/hotkey-setup
<sladen> alkisg: and '/usr/share/hotkey-setup' contains greek characters?
<alkisg> !pastebot
<ubottu> Sorry, I don't know anything about pastebot
<sladen> try /query
<alkisg> sladen, http://pastebin.ubuntu.com/70714/
 * lamont looks around for an sqlite-hacker
<jdstrand_> kees: did you happen to see cody-somerville's dput changes?
<jdstrand> mdeslaur: ^
<jdstrand> kees: it allows you to do something like:
<jdstrand> dput security:intrepid ./..._source.changes
<jdstrand> kees: with only one entry in ~/.dput.cf
<jdstrand> kees: it's *awesome*
<jdstrand> go cody-somerville! :)
<maxb_> What component is it that actually shows the volume OSD?
<sladen> alkisg: I don't know where your 'english' and 'greek' files are coming from.  they are are _not_ a standard part of 'hotkey-setup'.  The difference in your pastebin in the Nulling out of the HELP, PROG1 and PROG2 keys
<alkisg> sladen, default intrepid setup. I just selected "greek" when isolinux in the live cd prompted for a language
<sladen> maxb_: on a thinkpad, mute always mutes.  It's emulated, by sending a volume up (unmute) then a mute (force mute) IIRC
<alkisg> sladen, anyway, no big deal there. Thanks again.
<maxb_> yeah, I have come across this in /etc/acpi/always-mute.sh
<sladen> maxb_: mute is not a toggle on a thinkpad, so investigate it carefully if you think it's not doing as it should do
<maxb_> well, with g-p-m killed, it seems that only the "volume up" bit is taking effect
<sladen> maxb_: correct, but in normal operation, g-p-m _would_ be running, and right at the moment, the hardware keys still do as expected (other than for toggling mute)
<sladen> maxb_: I thought your original issue was to do with lock and mute;  does the locking no longer occur?
<maxb_> with g-p-m killed, locking does not occur
<sladen> maxb_: sooo, we've narrowed it down that g-p-m is the one mis-interpreting the key-press
<maxb_> the quirky thing is that muting then still isn't occurring which is different from what happens during the first few seconds of X login
<cody-somerville> jdstrand, :D
<maxb_> hrm
<maxb_> So, on poking around in the g-p-m source, it's starting to look like X is confusing the ACPI event into an XF86XK_Screensaver keypress
<sladen> maxb_: are there any other mappings that don't match
<maxb_> What should I check? That last was a conjecture based on what g-p-m is logging ("Key 160 mapped to HAL key lock") and the fact that X is reading the acpi socket
<maxb_> Interestingly, g-p-m *is* recognizing the key as "mute" - but the OSD doesn't show, and it *also* gets this "Key 160", which it takes to mean lock
#ubuntu-devel 2008-11-12
<savvas> does anyone know what's the difference between libboost_filesystem-mt.so and libboost_filesystem.so ?
<azeem> savvas: -mt probably stands for multi-threading
<savvas> azeem: thank you! :)
<sladen> maxb: gnome-settings-daemon
<savvas> hm, since I'm here, does anyone know what's the proper way to figure out the process id of a user's login? :) I need it for a python project: http://launchpad.net/timekpr
<savvas> we were using "ps -fC x-session-manager", but it seems that KDE and XFCE behave different with it
<Godsize> hey, has anybody here looked at the 2nd stage of the cpu_alloc patches yet?
<ScottK> doko: What would you think of updating our python3.0 packages to RC2?
<FrankH> not sure if motu has their own channel, but i'll make my request here. can the package for eclipse be updated from 3.2 to 3.4?
<Pici> FrankH: #ubuntu-motu actually exists
<Pici> :)
<FrankH> pici: ok, thanks
 * NCommander revives
<kees> weird.  my mouse disappears if I don't move it.
<piju__> cool
<StevenK> If I type in gnome-terminal, it disappears
<kees> mine disappears in all contexts... hmm
<piju__> StevenK, cool, how do u make it ?
<piju__> haha
<kees> hrm, left-over fds
<kees> ls -la /proc/self/fd/
<Chipzz> so that's what's for breakfast? ;P
<dholbach> good morning
<\sh> keybuk: it's still in update-maintainer script of intrepid...I don't do that manually ,-)
<pitti> Good morning
<\sh> moins pitti
<geser> Hi pitti, \sh
<Hobbsee> hey pitti!
<lool> Hi folks
<pitti> Riddell: rejecting your qt4-x11 intrepid-proposed upload, no LP bug #
<pitti> tkamppeter: can you please reupload your splix intrepid-proposed package with "LP: #xxxx"? (you forgot the #); please keep the same version number
<tkamppeter> pitti, done.
<pitti> tkamppeter: thanks, processing
<pitti> tkamppeter: patch looks fine, good work!
<liw> I need help from someone who can upload a proposed SRU of system-cleaner to intrepid/main -- I assume that means a core-dev. Anyone?
<cjwatson> \sh: no it isn't - that was removed in ubuntu-dev-tools 0.33 in intrepid
<\sh> cjwatson: oh well, yes..right...I should say "Y" to dist-upgrade in the other screen session on new server *grmpf*
<doko> pitti: please can we demote gcc-4.1 and gcc-4.2? I know linux-ports still build-depends on it, but let's demote it now so that we can make sure the ports are updated this release
<kirkland> mvo: what do you think about: http://bazaar.launchpad.net/~kirkland/update-notifier/update-motd/revision/418
<mvo> kirkland: looks good, it would be nice to be able to say that only selected bits of motd update itself, the updates-avaialble count will likely be bogus because this notification is triggered in the middle of a install
<mvo> kirkland: another possible issue might be that the message will be displayed (reboot-requred) while the installation may not yet be finished, but that is the case with the other one too
<kirkland> mvo: actually, yeah, the bogus updates-available number was the other thing i wanted to fix
<kirkland> mvo: should hook the "end" of an upgrade operation
<kirkland> mvo: which should solve the reboot-required problem too
<kirkland> mvo: in one place
<mvo> kirkland: yep
<mvo> kirkland: there is the apt hook "DPkg::Post-Invoke"
<mvo> kirkland: that can be used for this, it should not be something expensive, just setting a stamp or triggering something, apt will wait until the hooks are all run
<soren> You could perhaps use dpkg-trigger?
<soren> kirkland: ^
<kirkland> mvo: does update-notifier use dpkg-trigger?  or something else?
<soren> It uses dbus, doesn't it?
<soren> Er..
<soren> Never mind.
<mvo> not sure if triggers are the right solution here
<soren> mvo: No? Why?
<mvo> I think the hooks that apt provide should be adequate, monitoring /var/lib/update-notifier/dpkg-run-stamp (with inotify) is what the update-notifier daemon is doing
<mvo> soren: dpkg is run by apt in various runs, "dpkg --unpack, --configure, --unpack, --configure" and dpkg will run triggers at the end of configure, so its not a reliable "now everything is finished" because there may be another dpkg invocation next
<mvo> (unless some new magic in dpkg was added since I last looked at it which is quite possible ;)
<soren> mvo: Oh, right. I forget that apt calls dpkg several times.
<maxb_> dpkg can even run triggers after --unpack
<maxb_> which can be somewhat unexpected :-/
<soren> maxb_: When would it do that?
<maxb_> I believe a file-based trigger for a non-conffile is executed after --unpack
<soren> maxb: Interesting. I would expect the trigger to be... well, triggered, but not processed.
<maxb> Yeah. It means a trigger of that type can't rely on its triggerer being configured, which is a pain
<maxb> Nor have I found a way to define a trigger that is triggered by package configuration
<soren> How could it be configured?
<maxb> What do you mean?
<soren> It triggered something that I imagine is part of its configuration process.
<soren> Like... Anything that ships documentation that scrollkeeper (or rarian or whatever) needs to process triggers this processing and isn't configured properly until the trigger has been processed.
<soren> That's the whole idea?
<soren> Each package used to call scrollkeeper-update (or whatever), and until that was run, it wasn't fully configured.
<soren> With triggers, we just lump all the calls to scrollkeeper together, and until it's been run, the packages that requested this to happen aren't configured.
<soren> maxb: Are you seeing a different POV?
<maxb> What I mean is that scrollkeeper-update can be called when the packages providing the documentation are in the "unpacked" state
<cjwatson> maxb: I think that's somewhat related to a dpkg bug that was fixed in jaunty, so hold off on judgement for the moment
<maxb> Interesting, I shall peruse changelogs later
<cjwatson> at least, I think in intrepid scrollkeeper itself wasn't quite reliably configured in your scenario
<cjwatson> although it is probably still true that the triggering package doesn't necessarily have to be configured
<cjwatson> maxb: you can call dpkg-trigger from a postinst to activate it by package configuration
<soren> maxb: Ah, I see what you mean now.
<maxb> cjwatson: Indeed, but my scenario was wanting to create a trigger without the co-operation of the package being installed
<maxb> I was creating a package that I wanted to be triggered whenever a JVM was configured
<ogra> erm
<ogra> who rejected my evtouch upload, and why ?
<maxb> My first thought was to trigger on /usr/lib/jvm, but that would trigger me when the jvm was unpacked, but not configured.
<pitti> ogra: me, see bug followup
 * ogra looks
<ogra> pitti, i definately dont want that package in jaunty :)
<pitti> ogra: erm, why not?
<ogra> upstream included all our changes
<pitti> ogra: ATM jaunty and intrepid have the same version
<ogra> so i want a clean upstream without the 20 patches i wrote indeed :)
<pitti> so yeah, feel free to upload the new upstream version instead then
<ogra> right, i will packae the new one (unless debian decides to but i fear they wont before lenny)
<pitti> there's always experimental, which we can sync from
<cjwatson> maxb: interesting; can you explain to me why it needed to be configured?
<ogra> right, if someone will package it there at all, it got as less attention in debian as it got in ubuntu the last three years (the shipped calibration tool never worked for example and nobody in debian ever bothered)
<maxb> Because my trigger was being a bit naughty and modifying conffiles
<ogra> jcristau, does the X strikeforce care for evtouch ?
<maxb> It was a package to ensure that my company's SSL certificate was added to the JDK's cacerts, which is a conffile
<pitti> doko: 4.1> it's not just l-ports, it's also klibc
<jcristau> ogra: beside mattia i don't think any of us know anything about it
<ogra> jcristau, thanks i'll mail him, it got a ton of fixes in intrepid (i.e. a working calibration tool after years of being broken) i guess he might be intrested
<jcristau> ogra: feel free to cc debian-x though, in case he doesn't have time i could try to help getting the fixes uploaded
<ogra> funny that upstream's changelog says he puled the fixes from the debian package
<ogra> jcristau, well, upstream included everything right away (even the very hackish stuff)
<ogra> so its only about rolling the new upstream
<jcristau> ah, ok
<ogra> and you wont want it without hal-input ... so not for lenny
<Riddell> pitti: qt4-x11 re-uploaded to intrepid-proposed
<pitti> doko: 4.2> just enigmail and boost; I'd actually like to demote boost, too, since the newer boost1.35 is in main, too; that requires to build some KDE packages and openoffice against it, though
<pitti> doko: I created a tracking bug 297152
<ubottu> Launchpad bug 297152 in linux-ports "demote gcc-4.1 and gcc-4.2 to universe" [Undecided,New] https://launchpad.net/bugs/297152
<pitti> Riddell: do you happen to know anything which would prevent kde* to build against boost1.35?
<Riddell> pitti: not off the top of my head
<Riddell> pitti: we have quite a few build-deps on libboost-dev
<pitti> Riddell: ok, thanks; do you plan a mass-upload of new KDE versions soon? those would be a good opportunity to switch them
<pitti> Riddell: yes, I added them to the tracking bug above
<Riddell> pitti: yes we'll be packaging KDE 4.2 alpha this week
<doko> pitti: thanks
<xTr3m3> hello developers ;)
<xTr3m3> times wanted to know what you have to Windows Vista / 7 got to say because of this massive DRM, TPM, TCPM matters ... times I would be interested ;)
<xTr3m3> So I would go so far as microsoft and very close to the bankrupt to see
 * Hobbsee wonders how that's possibly on topic.
 * StevenK too
<Hobbsee> xTr3m3: oh, and that wasn't appropriate either thanks.
<xTr3m3> ?
<Hobbsee> xTr3m3: #ubuntu.
<xTr3m3> does not have its own opinion on this? i mean this things with drm
<Mithrandir> xTr3m3: it's offtopic in this channel
<StevenK> xTr3m3: This channel is for development of Ubuntu, not for hand-waving about DRM and other such matters.
<Hobbsee> xTr3m3: seeing as that does not relate to support (for #ubuntu), or ubuntu development (for here), it's offtopic.
<cjwatson> we are not interested in DRM support in Ubuntu, in general; nor are we interested in a discussion about what Windows is doing with it
<xTr3m3> You can also nice to say, and we must not react so :( only an simple private question...
<_s3rggg_> hi
<_s3rggg_> excuse me, how can i upload a patch to release-proposed?
<_s3rggg_> anyone can help me?
<cjwatson> _s3rggg_: do you have upload privileges to Ubuntu?
<_s3rggg_> no
<cjwatson> _s3rggg_: then you can't
<cjwatson> _s3rggg_: you need to find a developer to do so
<cjwatson> #ubuntu-motu is usually a good place to start for mentoring
<_s3rggg_> i've posted the debdiff on launchpad, nominate it for intrepid and hardy and subscribed motu-sru
<_s3rggg_> this is sufficient?
<cjwatson> yes
<cjwatson> except you should have subscribed ubuntu-universe-sponsors instead, really
<_s3rggg_> also ubuntu-universe-sponsor are subscribed
<_s3rggg_> thank yo cj
<viviersf> cjwatson, ping
<cjwatson> viviersf: yes?
<viviersf> cjwatson, ive been using that fixed busybox image of yours, it reads the kickstart and all, but why would it not read my mirror ? It keeps saying its invalid ?
<cjwatson> viviersf: I don't know, would need to see the syslog
<dmulholland> hey, is it possible to install an older kernel than 2.6.27 in ubuntu intrepid?
<hyperair> and why would you want to do that?
<hyperair> it's probably possible, just not advisable
<viviersf> cjwatson, no matter, found it, the canonical whitepaper didnt say you need to mirror the debian-installer dist also
<dmulholland> hyperair, I have a piece of software I need to use (Intel VTune) that doesnt like 2.6.27 because of bits that have been removed from the kernel
<hyperair> what bits?
<dmulholland> give me a sec and ill get the errors
<dmulholland> http://pastebin.com/m419e0fa1
<cjwatson> viviersf: ah
<dmulholland> it built with no problems on 8.04
<viviersf> cjwatson, sorry to bother you with this stuff
<cjwatson> it's ok
<hyperair> dmulholland: well just enable the hardy repo and install all the kernels you want =)
<dmulholland> cheers hyperair
<hyperair> dmulholland: =)
<dmulholland> were there recent updates to intrepid? I'm getting lots of requests to update since I did apt-get update following adding hardy [just want to make sure its not going to backward a lot of the packaged to hardy]
<dmulholland> oh well im letting them install :)
<dmulholland> will see what happen
<pitti> dmulholland: there were tons of post-release fixes, yes
<dmulholland> pitti, thats cool, i think im ok, i took the hardy sources out and ran apt-get update again and it still showed the same number of updates
<pitti> slangasek: btw, https://edge.launchpad.net/~pitti/+archive has the new hal/consolekit from jaunty backported to intrepid (I built it on intrepid, so it shold work fine); would be great if you could test the killswitch with that
<\sh> hmm...does anybody with sbuild have problems installing libsvn-dev because of libaprutil1-dev? while installing it into a clean jaunty chroot apt doesn't say anything?
<pitti> Riddell: http://ppa.launchpad.net/ubuntu-langpack/ubuntu has most intrepid langpacks built now, in particular the French ones; you said you wanted to give them a test before we upload them to -proposed?
<Riddell> pitti: groovy, let me try
<Riddell> il manche!
<pitti> Riddell: je ne parlez-pas Francois
<Riddell> pitti: ja, das is gut
<pitti> Riddell: tres bien!
<pitti> merci beaucoup pour ... erm, testing
<Riddell> pitti: all working, although I still think language-pack-kde-fr-base should depend on language-pack-fr-base
<Riddell> "le testing" I expect :)
<pitti> Riddell: depends> erm, it doesn't?
<pitti> oh, -kde to non-kde
<pitti> yeah, at least a recommends: would probably be sensible
<cjwatson> pitti: without the non-kde one you probably don't have the locale generated, so I'd say depends
<cjwatson> oh, unless kde-fr-base does that too
<Riddell> it doesn't
<pitti> no, it doesn't
<Riddell> hmm, libneon27-gnutls moved to universe?
<pitti> Riddell: no idea why; feel free to re-promote if you need it
<soren> 7win 1
<soren> Gahh...
 * pitti hands soren a shift key
 * soren hugs pitti
<soren> ctrl-n'ing my way from window 4 to window 21 was becoming a hassle.
 * soren does that a lot
<pitti> alt-a FTW :)
<tkamppeter> pitti. did you do further investigations on bug 292690?
<ubottu> Launchpad bug 292690 in cups "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,Fix released] https://launchpad.net/bugs/292690
<pitti> tkamppeter: not today, sorry; still on my TODO list
<tkamppeter> pitti, once I would like to know what happens if you do changes at the place where the page size and margins are computed and where the patch which prevents SpliX from crashing applies and second, I have uploaded new SpliX packages to OpenPrinting, as the previous ones were built with a broken compiler and thjerefore crashed often,\
<pitti> tkamppeter: ah, is that why those didn't print at all?
<tkamppeter> pitti, yes. The rastertoqpdl filter simply crashed in the middle of the processing and therefore it did not print.
<pitti> tkamppeter: then I'll try the ones from openprinting again
<tkamppeter> gcc 4.3 (the standard one in Intrepid) produced broken binaries when used in the LSB SDK. I had to switch to gcc-4.2 to be able to create LSB packages with Intrepid.
<tkamppeter> pitti, the new OpenPrinting packages also update the PPDs of existing CUPS queues automatically, but only the ones which already use the driver from an OpenPrinting package.
<cjwatson> evand: Intel Mac / USB doesn't appear to work, at least not with the built-in firmware; I couldn't get it to boot off the USB stick. It's possible that it would work if you already had rEFIt installed.
<cjwatson> evand: http://ubuntuforums.org/showthread.php?p=5934844 has some speculation about whether putting rEFIt on the stick would help but it's not going to be easy :(
<evand> cjwatson: was this with holding down the alt/option key at boot?
<cjwatson> yes
<cjwatson> I think you would need to figure out how to bless the stick, which (I'm guessing) will require an HFS+ partition on it with rEFIt
<evand> ok, thanks for verifying that.  I'm not too concerned about the rEFIt approach as that's not something we can do across the board.
<evand> indeed, I suspected that as well
<cjwatson> hm, or allegedly blessed FAT32
<evand> hrm
<evand> where did you see that?
<cjwatson> forums thread above, deep down
<evand> ah, ok
 * evand digs
<cjwatson> sounds like BIOS support for USB in legacy mode on the mactel is pretty limited too
<cjwatson> so even if we could get it to boot syslinux, syslinux might not be able to read the kernel off the stick ...
<evand> mmm, fun
<cjwatson> I think it's pretty doomed right now
<directhex> blessed fat32 ought to be okay? EFI assumes you have FAT32 support
<cjwatson> but only if the bootloader can physically get the data off USB
<evand> yeah, agreed.  Something I'll keep an eye on, but it's obviously not going to work with our existing pre-made USB images.
<cjwatson> apparently when you're booting in legacy mode (currently required AFAIK) the BIOS forgets how to do anything much with USB
<evand> heh
<mvo> soren: ubuntu-vm-builder (in intrepid) gives me a odd error: http://paste.ubuntu.com/70977/ is there something like --no-cleanup so that I can investigate that further?
<cjwatson> evand: BTW my iMac is probably not much newer than yours, if at all
<soren> mvo: Try --debug.
<soren> mvo: It'll still clean up, but it's a lot more verbose.
<mvo> soren: thanks, doing that now
<alkisg> sladen, some help please? I've finished acer-aspire-5900.hk, it works fine if I run `service hotkey-setup restart`. But: (1) at recovery console, hotkey-setup is not yet executed. OK, no big deal. (2) hotkey-setup is executed later in the boot process, I've put some debug "echo something" and I saw it. (3) At gdm, some other keycodes are loaded which override those of hotkey-setup. (4) At the gnome session, other keycodes, different that those of gdm
<alkisg> sladen, maybe I should put all those "setkeycodes" somewhere else and not in hotkey-setup?
<soren> mvo: When it fails, just put the output on pastebin, and I'll take a peek.
<evand> cjwatson: noted
<alkisg> sladen, I've even tried setting XKBMODEL="SKIP" to /etc/default/console-setup and creating a new user (so that he uses the default gnome settings), to no avail.
<cjwatson> XKBMODEL=SKIP just tells setupcon to do nothing - I don't think it affects X in any way, shape, or form
<cjwatson> indeed, it doesn't
<cjwatson> arguably that's a bug of some kind
<slytherin> any archive admins around?
<superm1> pitti, i think bug 283765 is happening because you aren't presenting any way for the user to acknowledge configuration script changes in etc/
<ubottu> Launchpad bug 283765 in fglrx-installer "package xorg-driver-fglrx 2:8.543-0ubuntu1 failed to install/upgrade: EOF on stdin at conffile prompt" [Medium,Triaged] https://launchpad.net/bugs/283765
<superm1> (in jockey that is)
<hwilde> Hello, how can I still register with dns (like /etc/dhcp3/dhclient.conf send hostname) if I am not using DHCP but a Static IP ?
<tseliot> superm1: what's the right choice about /etc/ati/atiogl.xml in fglrx? Overwriting the original file?
<superm1> tseliot, generally yes
<superm1> tseliot, but in case they've made customizations to it you want to still ask the question i believe
<tseliot> superm1: I don't think Jockey supports this yet
<superm1> tseliot, right, that's why that bug is occurring
<tseliot> superm1: and I don't know if it ever will since it's supposed to be package-manager agnostic
<hwilde> nobody knows about dns eh ? :/
<hwilde> seems like with a static IP it does not send the hostname to dns
<hyperair> of course not
<hyperair> dhclient doesn't get called
<hyperair> how about static lease?
<hyperair> using dhcp
<pitti> superm1: urgh, that's tricky
<hyperair> but with a stored lease
<pitti> superm1: the backend is spawned by d-bus, it doesn't have GUI access
<hwilde> hyperair, well I don't want to ask the DHCP for an address, I just want it to do the send hostname part :)
<hyperair> heh no idea
<hyperair> =p
<hyperair> avahi should pick it up, but beyond that, no
<superm1> pitti, I suppose passing an X cookie around would be a bit messy too...
<pitti> superm1: yeah :( I think for now jockey can only handle drivers which install non-interactively
<superm1> pitti, so you think maybe querying debconf/frontend from postinst in fglrx and seeing if it's noninteractive would be a solution then?  in the noninteractive case, make a backup and use a mv_conffile to avoid the question being proposed?
<pitti> superm1: did it become a conffile and wasn't before? or what was the probleM?
<superm1> pitti, well it's a conf file since it's shipped by amd with the driver, but can be modified using their GUI tool for open gl settings i believe
<sladen> alkisg: one simple question;  you haven't added code to match Acer 5900s to the initscript?
<sladen> allee: is there anything actually difference from the existing 1600 one;  can you just add a new laptop ID?
<alkisg> sladen, I've modified /etc/init.d/hotkey-setup
<alkisg> sladen, I've updated the bug report: https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/281951
<ubottu> Launchpad bug 281951 in hotkey-setup "Acer Aspire 5920G Fn keys not working correctly" [Undecided,New]
<sladen> alkisg: what line(s) did you add/change in hotkey-setup?
<sladen> alkisg: the mapping at boot is the default kernel mapping
<alkisg> sladen, it's in the bug report (I should paste here... :))
<alkisg> *&I shouldn't
<alkisg> sladen, whenever I manually run "/etc/init.d/hotkey-setup restart" everything works fine
<alkisg> But I think X overrides hotkey-setup, and gnome overrides X, so I don't really know where hotkey-setup is actually useful! :(
<alkisg> hwilde, if you use bind, you may call nsupdate. If not, you may add an entry to /etc/hosts on the server?
<sladen> alkisg: what happens if you   stop hotkey-setup;  switch to greek;  start hotkey-setup
<sladen> alkisg: erm.  if your backspace is sending diamonds there's a *much bigger problem* somewhere
<alkisg> sladen, tried it on a gnome-terminal under X while having switched to (1) greek and (2) english, everything worked fine on both cases
<sladen> alkisg: ignoring the specail laptop keys;  what other "normal" keys are doing weird things?
<alkisg> sladen, I don't see diamonds anymore. The changes were (1) intrepid final instead of beta, and (2) dpkg-reconfigure console-setup => selected Greek font instead of Uni1. I don't know which of the two fixed the diamonds.
<alkisg> sladen, no normal keys malfunction now
<sladen> it could be that console tools greek resets the whole of the keyboard map, insetad of just the non-special areas
<alkisg> sladen, where is hotkey-setup actually effective? I mean, if someone has a different X keyboard layout, won't that override hotkey-setup? And if someone declares a different layout in gnome, won't that also override hotkey-setup?
<alkisg> What can I do to make X/Gnome use the same keyboard layout as hotkey-setup?
<maxb> Can someone explain exactly what the pipeline is for laptop hotkey events?Â Are acpi events being read in by acpid the start of the chain?
<maxb> And thence being forked out to X (reading the acpid socket), hald (reading the acpi socket), and acpid rules ?
<nixternal> kees: are you originally from the chicago land area dude?
<kees> nixternal: I am indeed :)
<kees> nixternal: still got lots of friends and family there
<nixternal> nice..I had no idea..I was looking at linked in and was looking at your profile..I saw Walgreens, AT&T, Lucent, and Snap On
<kees> :)
<nixternal> I was like...that sound like Chicago..then I saw your UIUC schooling
<kees> the Walgreens datacenter is sooo freakin' cool
<nixternal> that it is :)
<nixternal> we share space in their dc
<nixternal> or have some space rather
<kees> nixternal: oh! nice, I didn't realize they sublet
<nixternal> they do now because dc real estate is prime
<nixternal> they have space in teh IBM Equinox building as well iirc
<nixternal> the old RR Donnelly building
<kees> ah, that I've never seen.  I worked on the E10k on the ... left? side of the DC
<nixternal> haha, the E10K was my system when I worked at Sun
<kees> I never did convince my boss to let me boot ultrapenguin on that bad boy
<nixternal> I was one of the Sun Enterprise system engineers...the E4.5k, E10k, all the fun ones
<nixternal> hehe
<kees> my favorite were the e450's I used at Motorola.  for burn-in testing my coworker and I set up a CD-rip/encode farm.  *cough*
<nixternal> I have one at home, super loud
<nixternal> hahaha, cd-rip/encode farm...never thought about that
<nixternal> when did you leave the chicago land area dude?"
<nixternal> do you ever come back?
<ScottK> stgraber: There is a user having dhcp pid file troubles with lstp in #ubuntu-server.  Would you have a moment to join us and help him figure it out?
<stgraber> ScottK: sure
<ScottK> Thanks.
<liw> does MoM handle .git in some special way? particularly, does it remove it?
<alkisg> cjwatson, a quick question please? My laptop echoes a "Â±" character when I increase the brightness. I found a fix for under X, but it still does this on recovery (=plain) console. Is console-setup what I should look into?
<pregier> Not sure what that was, but I think I asked at the wrong time...  I think I may have some info re: a potential GRUB bug but am not sure how much or what type of info to collect since the launchpad section seems to be quite spammy;
<pregier> when we install grub to /dev/sda1 instead of /dev/sda sometimes we end up with a wrong stage2 address at 0x44 after the next boot
<pregier> er, sometimes after update-grub that is, never after grub-install
<pregier> so the next plan is to log each automated call to update-grub to see whether 0x44 gets messed up immediately or only on the next boot; is there any other good information beyond versions etc. that we should be collecting?
<pregier> I've got a meeting (sorry, didn't realize the time); if anyone has any thoughts I'll check back in an hour, otherwise I'll probably just plan on taking what we're collecting now to launchpad later
<kirkland> ScottK: cheers on the blog post;  ditto for some launchpad bugs!
<cjwatson> asac: did the switch-to-alternative-Flash-implementation stuff from https://wiki.ubuntu.com/FlashExperienceIntrepid ever happen? it wasn't entirely clear to me from the LP status whiteboard and I couldn't find it in the UI
<asac> cjwatson: http://people.ubuntu.com/~asac/tmp/alt2.png http://people.ubuntu.com/~asac/tmp/alt1.png
<asac> cjwatson: when you are on a website with a plugin you should see a small plugin symbol in the statusbar and in Tools menu there is Manage Content plugins menu active
<cjwatson> asac: hmm, doesn't seem to work for me
<asac> cjwatson: i will update the specs
<asac> cjwatson: what part doesnt work?
<cjwatson> none of it
<cjwatson> no plugin symbol, no Manage Content Plugins in Tools
<cjwatson> I use flashblock - maybe that's relevant?
<cjwatson> err, I mean "all of it" I suppose, since your question was in the negative
<asac> cjwatson: do you see the menu entry in tools at all?
<asac> (e.g. inactive)?
<cjwatson> no
<asac> should be the bottom most menu entry in tools
<cjwatson> Web Search, divider, Downloads, Add-ons, divider, Greasemonkey, Error Console, Page Info, divider, Clear Private Data
<asac> cjwatson: yeah. strange. en_GB?
<cjwatson> right
<cjwatson> I have cs de ru installed as well for testing purposes
<asac> cjwatson: ubufox installed and enabled?
<cjwatson> yep
<asac> works for me with LANG=en_GB at least so doesnt seem to be a locale issue
<asac> anything in the error console?
<asac> cjwatson: ^^?
<asac> tools -> error console
<cjwatson> lots of whining about particular websites
<cjwatson> "Permission denied to call Location.toString" without any indication of an associated website
<asac> cjwatson: any other extension installed? (besides from flashblock)
<cjwatson> "Failed to load XPCOM component: /usr/lib/xulrunner-1.9.0.3/components/pyabout.py" (and libpyloader.so)
<cjwatson> extensions: flashblock, greasemonkey, link widgets, nukeimage, ubufox, wiki auto-discovery button, and a usage viewer for my ISP (disabled)
<cjwatson> disabling flashblock makes no difference
#ubuntu-devel 2008-11-13
<asac> cjwatson: reconnect
<asac> 00:56 < cjwatson> "Permission denied to call Location.toString" without any indication of an  associated website
<asac> 00:56 < asac> cjwatson: any other extension installed? (besides from flashblock)
<asac> cjwatson: maybe also check that you don't have a test version of ubufox installed in your profile (should be version 0.6 in tools -> addons)
<cjwatson> 23:58 <cjwatson> disabling flashblock makes no difference
<cjwatson> 23:56 <cjwatson> "Failed to load XPCOM component: /usr/lib/xulrunner-1.9.0.3/components/pyabout.py" (and libpyloader.so)
<cjwatson> 23:58 <cjwatson> extensions: flashblock, greasemonkey, link widgets, nukeimage, ubufox, wiki auto-discovery button, and a usage viewer for my ISP (disabled)
<cjwatson> asac: ubufox 0.6~a1 according to tools -> add-ons
<cjwatson> oh, hmm, I do have a stray ubufox here
<asac> cjwatson: i think you really have it installed in the profile then
 * cjwatson nukes it
<asac> cjwatson: try to uninstall it from there.
<asac> good
<cjwatson> asac: thanks! that was it
<cjwatson> sorry for the newbie mistake
<asac> cjwatson: hehe ... no problem.
<asac> cjwatson: its not really obvious that firefox prefers profile even if version globally installed is higher ;)
<cjwatson> that's a nice UI
<cjwatson> (manage content plugins, now that I can see it!)
<cjwatson> it doesn't get on with flashblock
<asac> cjwatson: you mean when flashblock blocks the content?
<cjwatson> even after unblocking it, manage content plug-ins isn't made available, and the plugin icon doesn't appear in the status bar
<cjwatson> it works fine when disabling flashblock
<cjwatson> I'll file a bug on ubufox
<asac> cjwatson: hmm
<asac> cjwatson: i thought that is fixed
<asac> but yeah.
<cjwatson> asac: filed bug 297427
<ubottu> Launchpad bug 297427 in ubufox ""Manage Content Plug-ins" doesn't get on with flashblock" [Undecided,New] https://launchpad.net/bugs/297427
<cjwatson> anyway, bedtime I guess, thanks for the help
<asac> cjwatson: thx.
<asac> cjwatson: sleep well
<cjwatson> oh, I will :)
<cjwatson> *zonk*
<directhex> kirkland, package info in MOTD: very cool
<ScottK> kirkland: Thanks.
<dmulholland> hey, which kernel is going to be used in the next ubuntu?
<dholbach> good morning
<pitti> Good morning
<StevenK> Morning pitti
 * bryce waves
<viviersf> cjwatson, on the kickstart, to get the whole distro as is on the desktop cd, do i just install the ubuntu-desktop package, or must i add the recommended packages alsoed
<pitti> liw: can you please reupload system-cleaner with correct bug closing syntax in the changelog? it's "LP: #xxx", not "LP: xxxx" or "LP# xxxx"
<lool> hi all
<pitti> lool: bonjour Loic!
<dholbach> hi huats
<huats> hey dholbach
<tkamppeter_> hi pitti
<pitti> hey tkamppeter_, guten Morgen
<tkamppeter> I have seen that you have accepted my splix upload from yesterday. The maintainer scripts are not needed in Jaunty, as the conversion rules which I have added to Intrepid's SpliX will not be in Jaunty's.
<tkamppeter> In Jaunty the Ghostscript-based pdftoraster is default and not part of SpliX.
<tkamppeter> Only part of the Intrepid SpliX which has to go to Jaunty, too, is the patch for grayscale printing on color printers.
<liw> pitti, fixed in bzr, now I need to find someone to sponsor another upload
<pitti> liw: oh, I can do that for you
<pitti> tkamppeter: ah, ok, I see
<pitti> liw: do you have the dsc/diff.gz/source.changes somewhere?
<liw> pitti, I can make a source package, just a minute
<pitti> tkamppeter: www.cups.org got quite a redesign...
<liw> pitti, http://files.liw.fi/temp/syscleaner/
<liw> pitti, will that do?
<pitti> liw: "Does not quite close" :)
<pitti> liw: yes, that's fine; thanks
<pitti> liw: note the Launchpad-Bugs-Fixed: line
<pitti> liw: what does the release name mean?
<liw> "last minute package additions are a bad idea"
<pitti> haha
<liw> (that bit is there only to see if people actually read the changelog)
<pitti> just trawling through the debdiff
<liw> that should keep you busy for the rest of the day...
<tkamppeter> pitti, more Apple-like. Probably the web interface of CUPS 1.4 will look the same.
<pitti> liw: I'm curious about license-exceptions; do you have some magic which goes through all the files and yells at you if you forgot a copyright header?
<liw> pitti, yes; the license-check script, run from "make check"
<tkamppeter> pitti, and by the way, CUPS can celebrate the 3000th upstream bug now: CUPS bug 3000
<pitti> liw: uploaded
<liw> pitti, thanks
<tkamppeter> pitti, the new Jaunty package of SpliX is now uploaded. It contains only the grayscale patch.
<pitti> tkamppeter: hm, new splix2 lsb package still doesn't work at all :(
<pitti> tkamppeter: as for the splix package patch, I only see no-crash-on-bad-papersize.patch, which is an one-liner fixing the page height; however, the garbage is on the left border
<pitti> tkamppeter: hm, did the reporter or me actually try to directly print a pdf with lp instead of evince? /me goes to try a test page
<tkamppeter> pitti, the patch no-crash-on-bad-papersize.patch is perhaps incomplete and a minimum to avoid crashes caused by paper size mismatches. The patch can even be wrong.
<pitti> tkamppeter: ok, done two more tests, bug updated
<pitti> tkamppeter: ok, just for fun I'll drop that patch and try again
<tkamppeter> pitti, can you give me a complete error_log of the failure of the OpenPrinting splix2 package? Are you sure that you have the newest version (2.0.0-0.rc2.2lsb3.2)? Did you also try the 1.1.1 package?
<pitti> tkamppeter: I didn't try the 1.1.1 LSB package; the ubuntu 1.1.1 one works fine (see bug)
<pitti> tkamppeter: error_log> can do; I go to the other room to do those new tests (patch removed and error_log)
<tkamppeter> pitti, please also test the OpenPrinting 1.1.1 package to help me finding problems in the Openprinting packaging.
<pitti> tkamppeter: bug updated for error_log and removed patch, testing openprinting 1.1.1 now
<pitti> tkamppeter: error_log with lsb splix 1.1.1 attached as well
<tkamppeter> pitti, can you do "ldd /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl"
<pitti> tkamppeter: that's for splix2, right?
<tkamppeter> yes. for splix1 you should try "ldd /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoslp2"
<pitti> /usr/bin/ldd: line 117: /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl: No such file or directory
<pitti> WTH?
<pitti> $ file /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl
<pitti> /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped
<wgrant> Awesome.
<pitti> that looks exactly like e. g. file /bin/dd
<pitti> tkamppeter: directly running it in bash gives that, too
<pitti> tkamppeter: how did you build that? looks like badly linked
<pitti> nm -D works
<tkamppeter> pitti, once it works on my box, and second, I have built it with the LSB SDK.
<pitti> objdump -x /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl works, too, trawling through NEEDED
<tkamppeter> pitti, can you do "dpkg -l | grep lsb"
<pitti> tkamppeter: oh, *blush*, I don't have that installed
<pitti> I have all the libraries, though, hmm
<tkamppeter> pitti, the LSB packages require "lsb" of the appropriate version. But they are created as RPMs and converted to DEB with alien. Perhaps alien drops dependencies.
 * wgrant shudders violently.
<tkamppeter> Can you install the "lsb" package and try again?
<pitti> tkamppeter: no, the package does depend on lsb; I --force-depends ignored it, because lsb pulls in so much crap
<pitti> I don't need alien, rpm, qt, and postfix(!) on a client box just to run a printer driver...
<pitti> argh, and build-essential and debhelper...
<pitti> *nnnng* cluttering production desktop boxes; but well, I can purge it again
<pitti> tkamppeter: I checked that all libs in rastertoqpdl's NEEDED sections are already there
<mvo> Mirv: hello! thanks again for bug #295080 - I updated it and prepare a new export. I'm also in contact with the debian ddtp people to feed back rosetta translations
<ubottu> Launchpad bug 295080 in ddtp-ubuntu "Some (old enough) translations in ddtp-ubuntu not visible in Ubuntu" [Medium,Triaged] https://launchpad.net/bugs/295080
<tkamppeter> pitti, that is true. The LSB does not provide only an environment for printer drivers, but generally for distro-independent packages. And in general these packages come RPM-only, as commercial app vendors do not provide an auto-download and -update service as OpenPrinting does.
<pitti> maybe depending on lsb-printing would be enough? still pulls in postfix through -core, but at least not lsb-desktop and qt any more
<pitti> well, let's find out what's missing first
<tkamppeter> pitti, do you have /lib64/ld-lsb-x86-64.so.3
<pitti> no, it's a 32 bit installation
<pitti> tkamppeter: I installed "lsb", and still the same error
 * pitti purges it again
<Mithrandir> pitti: strace ldd on it, maybe?  Or strings on it?
<tkamppeter> pitti, then do you have /lib/ld-lsb.so.3?
<pitti> stat64("/opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl", 0xbf9bbc20) = -1 ENOENT (No such file or directory)
<Mithrandir> special
<pitti> sorry, ignore this
<pitti> purging lsb also purged that splix driver
 * pitti installs again
<cjwatson> viviersf: @ubuntu-desktop in the %packages section will do the trick (note the @)
<viviersf> cjwatson, what does the @ do ? install reccomends and all ?
<cjwatson> viviersf: @ means install the task by that name
<cjwatson> viviersf: and tasks are generated such that they include recommends
<viviersf> cjwatson, cool thanks :)
<cjwatson> viviersf: recommends are installed by default in 8.10 anyway, though, so you don't need to do anything explicit to get them
<cjwatson> it's just that @ubuntu-desktop maps properly to how we normally install the desktop
<tjaalton> cjwatson: not true if you preseed pkgsel/include
<tjaalton> cjwatson: I mean, recommends are not installed
<viviersf> thats awesome
<cjwatson> tjaalton: oh, true
<viviersf> makes my work at our client so much easier
<cjwatson> yeah, and individual package installations in kickstart map to pkgsel/include
<tjaalton> cjwatson: any way to work around that?
<cjwatson> so ok, their recommends won't normally be included
<pitti> tkamppeter, Mithrandir: weird: "/lib/ld-linux.so.2 /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl" works
<pitti> but calling it directly doesn't
<cjwatson> tjaalton: pkgsel/late_command I guess
<cjwatson> err, preseed/late_command
<cjwatson> I suppose I should change that in pkgsel
<tkamppeter> pitti, the ldd output of rastertoqpdl once from the Ubuntu package and once from the LSB package differs for me only by the lines
<tjaalton> cjwatson: ok, works for now
<viviersf> cjwatson, uhm ok, so does it install recommends by default or not ? your conversation confused me now
<pitti> tkamppeter: right, with "lsb" installed it WFM
<pitti> tkamppeter: I think it's due to /lib/ld-lsb.so.3
<tkamppeter> "/lib/ld-linux.so.2 (...)" for Ubuntu and "/lib/ld-lsb.so.3 (...)" for LSB.
<pitti> tkamppeter: which is just a symlink to ld-linux.so.2
<tkamppeter> /lib/ld-lsb.so.3 is probably generated by a maintainer script of an lsb-... package.
<pitti> tkamppeter: right, so just installing that symlink and installing the package, but not any lsb* stuff works
<pitti> tkamppeter: okay, trying that driver now
<tkamppeter> pitti, why did you not have this symlink? And what triggered that you get the symlink again?
<pitti> tkamppeter: as I said, the symlink is created by some lsb-* package, which I didn't install because they pull in a lot of stuff which I don't want on that box
<pitti> maybe adding that symlink would be a good idea for our lsb-base package or so
<cjwatson> viviersf: tasks (or "groups" in kickstart, introduced by @) behave as I said; individual packages don't get recommends installed by default
<viviersf> cjwatson, cool thanks
<tkamppeter> pitti, the symlink is created by /var/lib/dpkg/info/lsb-core.postinst, so lsb-core and lsb-printing should be sufficient for printer driver packages.
<pitti> tkamppeter: bug updated again; splix2 openprinting.org package has the same bug
<pitti> tkamppeter: lsb-printing depends on lsb-core already
<pitti> unfortunately lsb-core pulls in postfix
<tkamppeter> pitti, and installing postfix wastes a lot of space and runs a daemon listening on port 25?
<pitti> tkamppeter: debconf asks about it, but by default it does, yes
<pitti> postfix itself doesn't need a lot of space, but you really shouldn't install an MTA without actually needing one and being aware of it
<pitti> tkamppeter: but that's a bug in the LSB, not something in the printer drivers
<pitti> tkamppeter: so don't worry for now, I'm just whining
<tkamppeter> On my box postfix is installed and port 25 is not open.
<pitti> tkamppeter: you probably chose "local delivery only" in debconf
<pitti> but "internet site" is the debconf default
<tkamppeter> pitti, perhaps we should change the default, so that the default is the least-impact one.
<pitti> tkamppeter: for people who install postfix because they actually want postfix, it makes sense, though
<pitti> same for apache, ssh-server, etc.
<tkamppeter> pitti, can you report the "LSB pulls in postfix" bug to the LSB bug tracking system http://bugs.linuxbase.org/? Thanks.
<pitti> "LSB mandates a local MTA" would be the bug, yes
<pitti> tkamppeter: I created an account, once I get it I'll file the bug
<NCommander> so the LSB is now going to be mandating java
<NCommander> Wooo
<tkamppeter> NCommander, did the installation of an OpenPrinting package pull Java for you?
<NCommander> Install what package now?
<pitti> tkamppeter: actually, LSB is just requiring /usr/bin/sendmail to exist
<pitti> so if we had a simple local-only MTA, our lsb-core package should pull in that, instead of postfix
<tkamppeter> NCommander, if you have a distribution-independent package based on the LSB, it pulls the meta-package "lsb", and that pulls all requirements of the LSB.
<NCommander> oh yay, RPM :-P!
<pitti> but I guess the most practical solution for now is to use distro packages instead of "LSB" alien'ed ones
<tkamppeter> pitti, so it is perhaps only a bug in our lsb-core. It should prioritize the absolute minimum to get /usr/bin/sendmail.
<infinity> Easily solved with "Depends: nullmailer | mail-transport-agent" or similar.
<pitti> tkamppeter: it's about shipping something crippled by default in any case
<ion_> I take it someoneâs working on getting the firefox security update to Ubuntu?
<pitti> infinity: right, except that nullmailer is specifically not a local-only MTA
<infinity> pitti: And not LSB-compliant, even, according to the description.
<infinity> pitti: But it was merely an example. :)
<pitti> OTOH I'm convinced that *having* a local-only MTA would be even worse
<pitti> since once programs see /usr/bin/sendmail, they might actually try to *use* it, you know
<infinity> pitti: Then again, isn't our default postfix installation technically a local-only MTA anyway?
<pitti> and send mail into oblivion, instead of saying "I need to send mail, dude"
<infinity> (or close to)
<pitti> infinity: no, not at all; we don't install postfix by default
<pitti> infinity: and the debconf default is "internet site", the full thing
<infinity> pitti: Right, we don't anymore.  I'm thinking about 17 releases ago.
<pitti> which is the right thing
 * infinity lives in the past.
<infinity> Though, to be fair, I don't really see the "bug" that LSB mandates an MTA.
<pitti> infinity: in the end, I think is is and remains a nonsensical LSB requirement which cannot sanely be implemented
<infinity> UNIX-like systems are still kinda expected to have one, even if most desktops don't anymore.
<pitti> right, and that expectation is the bug :)
<tkamppeter> pitti, infinity, I hope we do not need a new lightweight project for making distro-independent binaries, only to make it easier for hardware manufacturers to provide drivers ...
<tkamppeter> pitti, infinity, I think the LSB needs to be modularized and the distro-independent binaries should simply pull appropriate modules, for printer drivers for example lsb-printing and lsb-binary (the latter would provide everything to run generic, distro-independent binaries, likle this symlink).
<pitti> ArneGoetje: hardy langpack updates finished building, so can get a CFT; what's the intrepid status?
<pitti> tkamppeter, infinity: http://bugs.linuxbase.org/show_bug.cgi?id=2407
<ubottu> bugs.linuxbase.org bug 2407 in Core-generic "Consider dropping sendmail as a required core component" [Normal,New]
<Hobbsee> Hmmm, how often is MoM actually running?
<cjwatson> Hobbsee: hourly
<cjwatson> Hobbsee: takes in the vicinity of an hour to run though due to the amount of churn, so sometimes it gets stuck on a lock and only ends up running every two hours in practice
<Hobbsee> cjwatson: oh.  Hmm, I wonder hwy it hasn't picked up irssi's yet, when it was accepted 3 hours ago.
<Hobbsee> cjwatson: ah, right
<cjwatson> and when you factor in publisher cron times + delay into that, it can take a bit
<Hobbsee> yup
<directhex> coo, someone's packaged up xserver-xorg-video-spu, for great ps3 justice
<tkamppeter> pitti, great bug report. I have also posted on the lsb-discuss mailing list about whether one could let LSB packages require only a part of the LSB, by requiring "lsb-printing" and not "lsb".
<tkamppeter> pitti, if you get a clue on the page size calculation inside the SpliX code, I would be grateful if you could get it going. I cannot do much here without having the printer to test.
<pitti> tkamppeter: yep, still on my list
<NCommander> Does a package have to explicately depend on perl?
<NCommander> Or more specifically perl-modules?
<pitti> NCommander: on perl, yes
<pitti> NCommander: perl-base is essential, so you don't need to depend on that
<NCommander> ok
<cjwatson> neither perl nor perl-modules is essential; generally dependencies should be on perl not perl-modules
 * NCommander is fixing svk ATM
 * NCommander fixes SVK
<Hobbsee> errr... Now, are there *any* reasonable reasons I can have a suggests on build-essential?
<Hobbsee> or is that just E,B&W no matter what the situation is?
<pitti> Hobbsee: not EBW, but fairly useless?
<NCommander> EBW?
<cjwatson> Evil, Bad, and Wrong
<pitti> Hobbsee: what's the package and rationale for it?
<liw> unperish could reasonably suggest build-essential, I think
<wgrant> Suggesting build-essential is fine.
<Hobbsee> pitti: it's install-css.sh, where if it can't find a binary, i'tll try to build the source of the libdvdcss2
<wgrant> build-suggesting build-essential would be wrong, if it were possible.
<Hobbsee> it'll manually install it mid script, though, but the other bits are already a suggests
<Hobbsee> wgrant: well, yeah...
<pitti> Hobbsee: it still means that installing the package by any official means will fail by default
<pitti> Hobbsee: if binaries aren't available
<pitti> Hobbsee: so if the binaries are very likely to not be available, but the source is, a recommends: would make sense IMHO
<Hobbsee> pitti: sorry, the actual package is libdvdread3, which contains the script.
<pitti> but I don't see why that should be the case?
<pitti> the hot thing is the CSS decryption, which is illegal in some countries no matter whether it's source or compiled?
<Hobbsee> pitti: yes, which is why there's a script you can manually run to install it from medibuntu, rather than it being there itself.
<pitti> Hobbsee: my general approach to that is to have a proper failure mode in the script itself
<Hobbsee> pitti: (it does).  it's just done multiple times
<pitti> Hobbsee: i. e. print out "packages not available, install build-essential and run me again"
<pitti> suggests: aren't really "seen" by the casual user
<Hobbsee> pitti: it does that.  So now i'm wondering why the other packages there (such as fakeroot) are suggests, as well as being attempted to be installed by the script, where the script bails out if they're not there.
 * Hobbsee scratches head.  Since when did this script include such crack?
<StevenK> Which script?
<Hobbsee> install-css.sh
<Hobbsee> it's relying on 'type', which is a bash builtin, and now doesn't do what it used to
<StevenK> Maybe the script calls dash?
<pitti> type works in dash, too
 * Hobbsee tries to find a manpage for type, in dash.
<liw> manpages document external commands, surely?
<pitti> Hobbsee: man dash has it, yes
<StevenK> Hobbsee: It takes no options, just the filename
<cjwatson> type is technically not POSIX but it's one of those that has very good coverage among shells in practice
<StevenK> What does it use type for, anyway?
<cjwatson> which is theoretically more reliable but has its own portability problems
<Hobbsee>      type [name ...]
<Hobbsee>             Interpret each name as a command and print the resolution of the command search.  Possible resolutions are:
<cjwatson> the usual use of type is for its exit code, to find out whether a command exists
<Hobbsee>             shell keyword, alias, shell builtin, command, tracked alias and not found.  For aliases the alias expansion
<Hobbsee>             is printed; for commands and tracked aliases the complete pathname of the command is printed.
<Hobbsee> StevenK: to check if something's installed.
<Hobbsee> So, it is there
<Hobbsee> but that's a really bad way to check it.
<cjwatson> I should get into the habit of using which instead, but it's an external command and therefore slower
<cjwatson> Hobbsee: why? I do that often
<cjwatson> it has its problems, but it isn't "really bad"
<Hobbsee> if ! type dh_testdir > /dev/null || ! type fakeroot > /dev/null || ! type ; then
<Hobbsee> cjwatson: because, unless i'm misreading it, if you do something like ^, even if you don't have fakeroot installed, it'll still bail.
<Hobbsee> er, it'll still *pass*.
<cjwatson> I don't know what type without arguments is supposed to achieve
<cjwatson> looks like a mistake
<Hobbsee> because '<packagename> not found' will be returned
<Hobbsee> hmm, i'm starting to think so
<pitti> it's essentially an "|| true"
<cjwatson> the above checks exit code, not output on stdout
<cjwatson> what it prints is entirely irrelevant
<pitti> erm, || false
<pitti> which is a no-op
<Hobbsee> oh, right
<Hobbsee> my bad, then.
<cjwatson> (doing tests on the output of a command when exit status is available instead would generally be a mistake)
<Hobbsee> cjwatson: thanks for hte help
<cjwatson> no problem
<cjwatson> I think you were thinking of ! [ "$(type fakeroot)" ] or some such wrongness
<Hobbsee> ah yes, that would be it.
<cjwatson> that mistake is more usually made with grep
<cjwatson> i.e. 'if [ "$(thingy | grep foo)" ]; then ... fi' when 'if thingy | grep -q foo; then ... fi' would have done instead
<cjwatson> or grep foo >/dev/null if you need non-POSIX portability
<Hobbsee> ahhhhh
<Hobbsee> right, got it.  Thanks again :)
<liw> sh -- where everything you do that involves quotation marks is likely to a silly, difficult, or a security problem, unless you really, really know what you're doing
<directhex> liw, got a better idea? :)
<liw> directhex, sure: every time you're not sure whether you are quoting things properly, switch to perl or python
<directhex> now, see, if install-css.sh were install-css.pl, Hobbsee wouldn't even be able to read it to find bugs. yay for write-only languages ;)
<Hobbsee> directhex: well, i've never touched perl, so... :)
<cjwatson> I would have phrased that the other way round; if your sh involves too few quotation marks, it's probably wrong
<NCommander> jdong, ping
<Hobbsee> directhex: how about install-css.bf, to go the whole way?
<liw> cjwatson, that's also true
<pitti> Hobbsee: I consider that steganography, not code
<cjwatson> the rule of thumb I give people is that every $-expansion should always be enclosed in "", unless you know what you're doing and have a good reason not to do so
<Hobbsee> pitti: haha :)
<liw> directhex, I see no reason why Hobbsee couldn't learn Polish in a few afternoons
<directhex> Hobbsee, i was messing around with bf -> .net compilers the other day, would you believe. i won't package one until there's a self-hosting compiler written in bf
<directhex> liw, well, polish, that's easy. it's russian without the cyrillic. mostly
<Hobbsee> directhex: hah
<_StefanS_> any solutions for that issue with firefox3 and applets freezing ?
<_StefanS_> other than installing icedtea6-plugin that is..
<tkamppeter> pitti, will CUPS bug 3001 get a SRU?
<pitti> tkamppeter: I want to wait for upstream's comment, and once Mike is happy, upload it to unstable, lenny, jaunty, and also SRU, yes
<tkamppeter> http://www.cups.org/str.php?L3001
<pitti> I know what you mean :)
<tkamppeter> pitti, I am only testing ubottu, he stopped showing links on CUPS bugs.
<tkamppeter> That is a regression, ubottu did it formerly.
<tkamppeter> STR 3001
<tkamppeter> CUPS STR 3001
<Hobbsee> ubottu: ping
<ubottu> pong
<ubottu> ping yourself ;-) really the diodes all down my left side are sore
<Hobbsee> hmm, it's alive.
<NCommander> O_O;
<tkamppeter> bug 1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<NCommander> bug 123456
<ubottu> Launchpad bug 123456 in xine-lib "podcast crashes amarok" [Undecided,Fix released] https://launchpad.net/bugs/123456
<NCommander> bug 1 is a bad choice because it doesn't actually query LP
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<NCommander> ....
<wgrant> Hmm.
<wgrant> it normally says that it won't do anything.
<NCommander> it was changed
<wgrant> But it's timing out too quickly to be really timing out, so I presume they've just changed the message.
<NCommander> yeah
<tkamppeter> It returns an LP URL, or is this the default "Not found" one?
<tkamppeter> https://bugs.edge.launchpad.net/ubuntu/+bug/1
<ubottu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,In progress]
<tkamppeter> https://bugs.launchpad.net/ubuntu/+bug/1
<NCommander> O__o;
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/1/+text)
<wgrant> bug 1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<wgrant> How odd.
<lifeless> not really
<lifeless> there is a metric shitload of comments
<NCommander> bug 1 is over a megabyte in size
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<wgrant> lifeless: I mean the fact that only 'bug 1' seems to be blacklisted.
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<lifeless> I thought we had a static page for the web page, I wouldn't be surprised if ubottu is using api's now that api's are not protected
<tkamppeter> A browser takes very long to reply to https://bugs.launchpad.net/ubuntu/+bug/1, but it replies the correct thing.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/1/+text)
<NCommander> we need to stop posting links to bug 1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<NCommander> arhg
<lifeless> tkamppeter: I believe it is a static page :) - its just big
<cjwatson> I don't suppose there is some testing channel where ubottu hangs out, so that you guys don't have to play with the bot in here?
<lifeless> sorry; I didn't mean to tweak it before
<lifeless> at least it isn't talking to itself
<Hobbsee> #ubuntu-bots?
<Mirv> mvo: thanks, great that some problem points were found and fixed.
<lifeless> mvo: ping; I know the Str problem fix
<lifeless> mvo: api change in storm; its RawStr now
<luli> hello
<mvo> lifeless: right, I have a fix for this one in the bzr tree
<mvo> lifeless: it breaks with that too unfortunately
<luli> !list
<ubottu> Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots
<lifeless> mvo: oh
<lifeless> mvo: whats the next break?
<mvo> lifeless: I need to run it again to get it
<mvo> lifeless: give me a sec
<mvo> (or two)
<lifeless> mvo: nearly midnight
<lifeless> mvo: don't stress now; I'm feeling guilty about it though
<mvo> lifeless: no worries, I will sent it output by mail, ok?
<mvo> netowrk is *very* slow for me right now anway :/
<lifeless> mvo: please
<lamont> why is it that everytime I restart squid, I find myself tempted to use 'killall -9 squid; /etc/init.d/squid start'?
<NCommander> lamont, no idea, but on another topic, you have ia-64 hardware, right?
<apachelogger> pitti: please take a look at bug 203349 once you get a chance
<ubottu> Launchpad bug 203349 in language-pack-kde-sv "Broken plural forms in KDE" [Medium,Confirmed] https://launchpad.net/bugs/203349
<NCommander> DktrKranz, pinb
<NCommander> ping even
<lamont> NCommander: yeah
<NCommander> lamont, could I convince you to test the ia64 kernel from jaunty?
<lamont> the test box is currently intrepid, with (of course) a hardy kernel, since there isn't an intrepid one...
<lamont> so sure, it'll be late tonight though
<NCommander> lamont, great! I need to fix the HPPA kernel (it FTBFS on the builders, strangely enough)
<lamont> thanks
<pitti> argh, WTH? http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html is awful
 * pitti creates jaunty chroot to debug
<seb128> pitti: starting your archive day earlier? ;-)
<pitti> seb128: no, wondering about my ekiga FTBFS
<pitti> E: No such script: /usr/share/debootstrap/scripts/jaunty
<NCommander> pitti, want a hand?
<pitti> *nng*
<pitti> NCommander: I suppose most of the list is a fallout of basic GNOME libs being uninstallable; if you can track it down, much appreciated
<pitti> I already checked component-mismatches, nothing sticks out there
<cjwatson> pitti: symlink, or I think there's something in intrepid-backports
<NCommander> No, bunch of KDE stuff is broken
<pitti> cjwatson: right
<NCommander> I think the problem is Java isn't installable
<pitti> I wouldn't like to upgrade to jaunty just yet, still too many intrepid SRUs going on which need testing
<NCommander> ah
<NCommander> Found it pitti
<seb128> pitti: same for me
<NCommander> libgnomevgs2-common is uninstallable
<pitti> NCommander: not for ekiga and libgnome2-0
<seb128> NCommander: good, now fix it ;-)
<NCommander> pitti, I can debug that after I figure this out
<pitti> likewise, I'll look into it once my chroot built
<dholbach> hi nxvl
<NCommander> seb128, oh, I see what happened. libgnomevgs2-common became a virtual package, and libgnomevgs2-0 has a versioned depends
<seb128> NCommander: no it didn't?
<NCommander>   libgnomevfs2-0: Depends: libgnomevfs2-common (>= 1:2.24) which is a virtual package.
<seb128> wth?
<NCommander> Ok, aptitude thinks it did :-)
<NCommander> No candidate version found for libgnomevfs2-common
<seb128> oh
<pitti> indeed, it's not in jaunty
<seb128> it's binary new
<seb128> due to the new -dbg
<nxvl> hi daniel!
<NCommander> Well
<NCommander> Mystery solved
<NCommander> nxvl, I need you.
<pitti> :)
<nxvl> dholbach: how are you?
<nxvl> NCommander: mmm
<NCommander> Why do we require binary NEWing?
<nxvl> NCommander: what for?
<NCommander> nxvl, SRU
<nxvl> oh
<nxvl> shoot
<seb128> NCommander: there is a new -dbg binary debian added
<seb128> NCommander: all the binaries are hold when there is one change
<pitti> seb128: did you already accept it? I don't see it
<nxvl> NCommander: bug number
<seb128> pitti: no, I was going to look at it the queue now
<NCommander> nxvl, grabbing it
<dholbach> nxvl: good good - how 'bout you?
<NCommander> Bug 282793
<ubottu> Launchpad bug 282793 in svk "Unsatisfied dependencies in SVK" [High,In progress] https://launchpad.net/bugs/282793
<nxvl> dholbach: having fun in Lexington with the crew
<seb128> pitti: I did upload gnome-vfs yesterday and I know debian added a -dbg so that's guess work right now
<NCommander> http://launchpadlibrarian.net/19612886/svk.debdiff
<NCommander> pitti, if you point me to your build failure logs, I can help working on you on that FTBFS
<NCommander> er, with you
<seb128> pitti: it's not in new, hum
<NCommander> seb128, has it built yet?
<seb128> NCommander: yes, yesterday
<NCommander> seb128, curious ...
<seb128> don't tell me
<NCommander> tell you what?
<seb128> https://edge.launchpad.net/ubuntu/+source/gnome-vfs/1:2.24.0-1ubuntu1/+build/776352
<NCommander> Ok, I give
<NCommander> What am I supposed to be seeing?
<seb128> where? on this url? that it built yesterday ;-)
<seb128> and that the binary is listed
<NCommander> and LP says its published
<NCommander> Curious ....
<seb128> NCommander: that seems to be a soyuz bug
<cjwatson> NCommander: we're working on a similar problem with openjdk-6; I've mentioned that this is affected too
<mvo> who is the archive-admin of the day?
<seb128> mvo: StevenK
<seb128> mvo: what do you need?
<StevenK> It is?
<StevenK> ArchiveAdministration disagrees :-P
<seb128> StevenK: trying to chicken out now? ;-)
<StevenK> seb128: It's 1am local, so yes.
<StevenK> It's Friday here, pitti, la la la la
<seb128> StevenK: I though thursday was your day, how come it's not written there? ;-)
<\sh> soren: ping ubuntu-vm-builder...what will be installed as default user inside the guest when installing e.g. ubuntu?,-)
<mvo> hm, I was just wondering if someone could do a bunch of syncs to cleanup the merge list a bit
 * mvo wonders if he should apply for the job too
<seb128> mvo: I can do syncs, I didn't do those yesterday
<seb128> let me finish some srus first
<mvo> seb128: that would be nice, the bugpackage of the team has a few that are also on the merges page
<mvo> seb128: sure
<NCommander> pitti, where are your FTBFS failure logs?
<seb128> NCommander: those are due to libgnomevfs not being installable, don't bother
<NCommander> ah, ok
 * mvo wonders if anyone minds if I do the tracker merge
<seb128> mvo: go for it
<seb128> mvo: and please fix the bug which was fixed in hardy and has been dropped in intrepid too while doing that ;-)
<mvo> seb128: hum, what bug is that?
<seb128> re
<seb128> mvo: bug #204770
<ubottu> Launchpad bug 204770 in tracker "[hardy] gdmsetup cause intensive disk activity and take a very long time to open" [Medium,In progress] https://launchpad.net/bugs/204770
<\sh> soren: forget that...no man page for ubuntu-vm-builder but --help is very good ,-)
<mvo> thanks seb
<mvo> thanks seb128
<seb128> mvo: you're welcome
<lool> pitti: Looking at your ekiga patches (thanks!) I see:
<lool> +       : # symlink identical Gnome help files within packages
<lool> +       for p in $$(dh_listpackages); do \
<lool> I wonder why the ":"
<lool> pitti: Concerning glade, Debian #313520 and <20081113122021.GA20294@piware.de>, Debian completely dropped glade-2 / glade source (2.12), however I see the same issue is in glade-3
<ubottu> Debian bug 313520 in glade-2 "glade-2: Please generate a POT file during package build" [Wishlist,Closed] http://bugs.debian.org/313520
<lool> Unless it's run during build, hmm
<lool> It seems it's not
<cjwatson> NCommander: libgnomevfs2-common (and a bunch of others) should be fixed in about 1.5 hours
<pinchartl> hi
<NCommander> cjwatson, wooo
<mvo> doko: do you mind if I do the moin merge?
<doko> mvo: not at all
<pitti> NCommander: http://launchpadlibrarian.net/19614590/buildlog_ubuntu-jaunty-i386.ekiga_2.0.12-1%2Bnmu1ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> lool: the : is bogus, sorry
<pitti> lool: it's just a no-op, but it doesn't need to be there
<pitti> lool: glade-3 uses cdbs, so pot is built automatically
<NCommander> pitti, I thought the gnome bug was resolved
<pitti> NCommander: cjwatson said so, yes
<pitti> NCommander: that's still the old FTBFS log from some 5 hours ago
<NCommander> oh
<lool> pitti: It doesn't use gnome.mk though
<lool> pitti: But I just fixed that
<pitti> lool: oh, sorry, it's actually done in debhelper.mk, not gnome.mk
<lool> pitti: Ah is that new?  I see include $(_cdbs_rules_path)/langpack.mk$(_cdbs_makefile_suffix) in gnome.mk
<lool> With cdbs 0.4.52ubuntu7
<pitti> lool: neither is particularly new, since gutsy or so
<lool> pitti: Hmm I see no intltool or langpack stuff in debhelper.mk
 * lool is lost
<pitti> /usr/share/cdbs/1/rules/debhelper.mk, lines 257..
<lool> pitti: Oh wait, sorry, I'm discussing two things at once
<lool> I was thinking about the langpack/intltool-update stuff
<pitti> yes, that's in langpack.mk, included by gnome.mk and others
<lool> Yeah, we were indeed discussing two different things; so are you saying I can drop the symlinking bits?
<lool> I prefer having it in cdbs in Debian as well rather than duplicating that in all packages, but then cdbs maintenance has been quiet lately
<pitti> lool: I'll send the POT and gnome help changes to Debian's cdbs bug list, but they won't be applied by lenny's release
<lool> pitti: Ok; I'll leave it to the new ekiga maintainer then
<lool> I wont minimize the diff by including that and it's not the goal on the long term, so it's not important to merge it now in ekiga
<tkamppeter> pitti, I have some news about pdftoratser: See bug 294671
<ubottu> Launchpad bug 294671 in gutenprint "Driver reports "ColorSpace is not supported" for Canon iP4500" [Undecided,Incomplete] https://launchpad.net/bugs/294671
<tkamppeter> pitti, a user complained about a color space problem and I asked him to use my Ghostscript-based pdftoraster instead of Intrepid's Poppler-based one. The problem went away.
<tkamppeter> He is not using SpliX but Gutenprint. So the pdftoraster causes problems with many drivers. Perhaps we must really do an SRU of putting this pdftoraster into Intrepid.
<spree> Hi ubuntu developers. Is CONFIG_MAGIC_SYSRQ enabled in the official release packages of the kernel?
<spree> I want to know if the magic SysRq key works by default in ubuntu
<cjwatson> spree: look in /boot/config-*
<cjwatson> /boot/config-2.6.27-7-generic:CONFIG_MAGIC_SYSRQ=y
<pitti> tkamppeter: hmkay; it should get some more testing, though
<tkamppeter> hmkay?
<cjwatson> "hmm, OK"
<persia> hmkay : onomatopoeic representation of thoughtful acceptance
<tkamppeter> pitti, so perhaps we should see for a certain time whether pdftoraster causes bug reports on Jaunty, and if not we SRU it into Intrepid for general use.
<pitti> tkamppeter: yes
<hyperair> jdong: bug 267922 still hasn't gotten attention
<ubottu> Launchpad bug 267922 in banshee "Banshee hangs up/crashes when pluggin in MTP-USB-Player" [Undecided,Confirmed] https://launchpad.net/bugs/267922
<persia> hyperair, You might want #ubuntu-bugs, which is the main forum for bug discussion.
<hyperair> persia: jdong asked me to ping him if there still wasn't any attention. he gave ack for sru, nobody's sponsored.
<persia> hyperair, Ah.  I didn't have context.  This is the right place then.  Apologies.
<hyperair> persia: no prob. there was no way you could have known without looking into the bug or digging through the logs anyway =)
<jdong> hyperair: thanks, I'm on it.
<hyperair> jdong: thanks
<poningru> OMG thank you for the arm stuff I dont know who is working on that but I would LOOOVE to help
<poningru> or ... I guess thats a canonical only thing right?
<poningru> or can I work on that? anyone know?
<pitti> poningru: now that it's public, everyone is welcome to help, I guess :)
<poningru> awesome
<poningru> will it be restricted to ubuntu-mobile?
<pitti> poningru: AFAIK it will become a normal port, i. e. it'll build the entire archive
<hyperair> what arm stuff?
<pitti> whether that's sensible is a different question, of course, but lpia builds the entire archive, too
<poningru> awesome!!!
<poningru> hyperair, canonical and arm people have some deal going re: building ubuntu for arm arch
<hyperair> interesting
<persia> poningru, Probably the key bit, as with any new port, is chasing down build-failures at the start.
<pitti> hyperair: http://arm.com/news/23761.html
<hyperair> so is it in archive.ubuntu.com?
<poningru> http://www.digitimes.com/news/a20081113VL204.html
<persia> ports.ubuntu.com
<hyperair> ah so it's not in the official archives then?
 * hyperair breathes a sigh of relief
<persia> hyperair, Well, it's as official as powerpc, lpia, ia64, hppa, and sparc.
<hyperair> eh?
<hyperair> so it will be in archive.ubuntu.com then?
<hyperair> hmm
<persia> None of those architectures are.  Dunno if armel will eventually get promoted.
<hyperair> persia: sparc is
<hyperair> for dapper at the very least
<cjwatson> hyperair: not for current releases though
<hyperair> and powerpc
<poningru> http://ports.ubuntu.com/dists/intrepid/
<persia> Oh, right.  The set of architectures on archive.ubuntu.com vs. ports.ubuntu.com is subject to change for each release.  I'm only speaking of Jaunty right now.
<cjwatson> hyperair: ditto, not for current releases
<hyperair> yeah
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/jaunty/main/
<hyperair> i would know, i maintain an archive mirror =)
<NCommander> Its ports mirrored at all?
<NCommander> s/Its/Is/g
<cjwatson> NCommander: sporadically at best
 * NCommander sighs
<persia> Not generally, but there's no reason it couldn't be if someone was sufficiently interested.
 * pitti tries to untangle his tongue after trying to pronounce the armel buildd names
<hyperair> lol
<cjwatson> pitti: all names of conifers, according to wikipedia
<persia> pitti, The trick is to eat them first.  The astringency helps with pronunciation :)
<poningru> rofl
 * pitti pokes why ddebs.u.c. isn't picking up the armel ddebs
<jdong> sigh, jdong of 10 months ago, why do you mock me?
 * jdong upgraded pbuilder conveniently forgetting he hacked the tarball format to use lzop
<hyperair> lol
<LaserJock> jdong: that's what you get for all your mad-hacking
<jdong> LaserJock: yeah all those couple seconds I saved gzipping are now wasted tracking down why input isnt in gzip format anymore ;-)
<jdong> hyperair: tested and uploaded into intrepid-proposed
<hyperair> jdong: thanks =)
<jdong> no, thank you :)
<hyperair> the bug would have stagnated if you ddn't pop in and ack as well as upload it ;)
<fabio> sera a tutti c'Ã¨ qualcuno con cui parlare??
<ion_> Yes, everyone on the Intertubes speaks your language.
<fabio> hi
<fabio> i have installed eclipse on intrepi ibex
<fabio> but i saw that he wants permission root...why??
<fabio> idem for a program installed in opt..
<fabio> why in intrepid now thera are this problems??
<fabio> sorry for my bud english!!
<hwilde> fabio,  /join #ubuntu-fr
<ogra> hwilde, no -it ?
<ogra> *not i mean
<hwilde> oh is that italian
<hwilde> looked french
<fabio> yes i am italian!
<hwilde> either way,   /join #ubuntu
<ogra> i think parlare is italian :)
<persia> !it
<ubottu> Vai su #ubuntu-it se vuoi parlare in italiano, in questo canale usiamo solo l'inglese. Grazie! (click col tasto destro sul nome del canale per entrare)
<hwilde> !ot
<ubottu> #ubuntu is the Ubuntu support channel, #ubuntu+1 supports the development version of Ubuntu and #ubuntu-offtopic is for random chatter. Welcome!
<persia> Well, yes, but #ubuntu is only English as well.
 * ogra wonders if he can go on with that iteration ....
<ogra> !at
<ubottu> Sorry, I don't know anything about at
<ogra> bah
<persia> ogra, If you speak !at, feel free to submit the right string :)
<ogra> well, its largely german ...
<ogra> i doubt there is an austrian support channel
<persia> Wouldn't !de be more suitable for that?
 * DktrKranz sees #ubuntu-at
<persia> Well then, it needs a string :)
<ogra> persia, !de wouldnt fit the scheme "!it !ot !at !et" :)
<persia> heh
<ogra> vowels ftw :)
<ogra> does !et exist ?
<ogra> !et
<ubottu> Information about games on Ubuntu can be found at https://help.ubuntu.com/community/Games and http://www.icculus.org/lgfaq/gamelist.php
 * ogra scratches head ? 
<persia> See, that's not the same thing.
<DktrKranz> what is !et supposed to be?
<persia> Anyway, for the real vowel win you'd need !aa
<ogra> http://www.crowncombo.com/articles/2007/013_ETAtari/cart.jpg
<ogra> :D
<ogra> http://www.crowncombo.com/articles/2007/013_ETAtari/screenshot.jpg
<ogra> et was the game atari went broke with
<ogra> http://www.snopes.com/business/market/atari.asp ;)
<spree> ogra: there was a video on youtube about that game, the E.T. for Atari 2600, and how it was the worst game ever made in the history of video games
<ogra> yep
<spree> http://www.youtube.com/watch?v=kMREImsJmuo
<spree> the E. T. video game was so bad they recalled the game and buried it in the new mexico desert
<spree> lol it was written in 6 weeks no wonder it was so bad
<pwnguin> lots of games were
<pwnguin> so what's the importance of armel in ports versus archive?
<persia> pwnguin, Mostly just affects the preseeding on the install CDs, and the contents of sources.list for installed systems.  Also, doesn't show in rmadison.
<Cloakey> Greetings.
<Cloakey> I'd like to learn package maintenance.  I'm thinking whether it'd make sense for me to start over at Debian, because their sponsorship program and guidelines seem somewhat established, and I couldn't really find much on becoming a maintainer for Ubuntu.
<sebner> !MOTU | Cloakey
<ubottu> Cloakey: motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<sebner> and
<sebner> !packaging | Cloakey
<ubottu> Cloakey: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<Cloakey> Wow, sebner, thanks.  Not a great sentiment to my Google skills.
<sebner> heh, np
<sebner> Cloakey: any questions about MOTU and packaging can be asked in #ubuntu-motu btw
<Cloakey> sebner: Awesome!  Thanks.
<jtisme> can anyone tell me if ubuntu is going to use alsa or oss in the future for sound
<sebner> jtisme: pulseaudio ;)
<sebner> jtisme: oss is obsolete btw
<jtisme> seb128, ooh! thanks for in heads up
<jtisme> sebner thanks for the heads up
<sebner> np
<peratu> Hi. Somebody know a solution for http://bugs.launchpad.net/ubuntu/+source/linux/+bug/291573 or http://ubuntuforums.org/showthread.php?t=968194   ?
<ubottu> Launchpad bug 291573 in linux "Ubuntu 8.10 live CD fails with error message" [Undecided,Incomplete]
<liw> peratu, have you ran the cd checking option from the boot menu?
<peratu> liw, the .iso pass the md5 test. And I have tried with the LiveCD and the Alternate CD. Both fails with same error.
<peratu> I think that it is a problem with SATA drives... But, I haven't this problem with Ubuntu 8.04 :S
<liw> peratu, checking the .iso does not check that the cd you have burned works; please boot into either cd, and choose the option to check the correctness of the cd
<peratu> Ok, i'll check it, but this is not the problem, I'm sure :-)
<pwnguin> do the ppas build on archs on ports.ubuntu.com? or just the official ones?
<persia> sebner, Just as a note, there's lots of folks excited about the new OSS, although Ubuntu uses ALSA, and pulse on top of ALSA.
<sebner> persia: Yeah, I've heard about OSS revival but I just want to results and I don't support Ubuntu changes to it in near future
 * rlaager hopes for the day when Linux sound isn't a disaster.
<persia> sebner, You suggest switching to pulseaudio.  If that happens for everything, the ALSA/OSS decision becomes moot.
<sebner> persia: sure, but for now ALSA is a lot more around us than OSS
<persia> sebner, Indeed.  The point is just that OSS isn't necessarily obsolete, although pulseaudio is the target for desktop sound.  Anyway, no point arguing.
<sebner> persia: ok :) btw, any new from the MC regarding these many applications (including mine ^^)?
<cjwatson> pwnguin: only architectures with Xen support
<cjwatson> pwnguin: which at the moment, AFAIK, is just the x86en
<pwnguin> is lpia xenlike?
<cjwatson> lpia is perfectly runnable in a chroot from an i386 system ... so "yes"
<hwilde> why would a configure script say "/usr/bin/ld: skipping incompatible ../Work/lib/libkartoMapperSDK.so when searching for -lkartoMapperSDK"
<hwilde> what does this mean skipping incompatible :/
<jcristau> hwilde: it means you can't link a 32bit object with a 64bit one
<hwilde> jcristau, that is what I feared :(
<hwilde> if I use ia32-libs does it defeat the purpose of using 64bit for more RAM ?
<hwilde> eh ia32-libs doesn't help anyways
 * calc hopes he doesn't kill his desktop by upgrading it to intrepid :)
 * calc got bronchitis on his vacation :( so is sitting at home playing with ubuntu
<fta> pochu, liferea is broken. bad MOZILLA_LIB_ROOT.
<fta> MOZILLA_LIB_ROOT=`$PKG_CONFIG --libs-only-L $XULRUNNER_PROVIDER | awk '{print $1}' |  cut -c 3-` is wrong
<fta> it gets the -devel path
<pochu> fta: version/bug?
<pochu> fta: what are the consequences of it?
<fta> liferea_1.4.18-0ubuntu2
<fta> it doesn't start
<fta> fta@ix:~ $ liferea
<fta> Abort
<fta> the wrapper sets LD_LIBRARY_PATH=/usr/lib/xulrunner-devel-1.9.0.3/lib which only exist when xulrunner-1.9-dev is installed, i.e. during build time
<pochu> weird
<pochu> I wonder why it worked for me
<pochu> s/worked/works/ even
<fta> $ pkg-config --libs-only-L libxul-embedding  | awk '{print $1}' |  cut -c 3-
<fta> /usr/lib/xulrunner-devel-1.9.0.4/lib
<fta> (in my chroot)
<joaopinto> liferea works fine on a hardy minimal chroot
<joaopinto> ops, i mean, intrepid
<fta> yep, intrepid was fine, jaunty isn't
<pochu> ah
<pochu> phew
<pochu> I was wondering why launchpad didn't get thousands of reports :)
<fta> http://paste.ubuntu.com/71504/
<fta> hard coding the result of pkg-config in a script is a bad idea
<pochu> liferea 1.5/1.6 removes xulrunner support, btw
<pochu> (1.6 when it's released)
<fta> maybe but currently, it's still gecko and it's broken
<pochu> sure
<fta> it's easy enough to fix, drop the pkg-config call in that script and use /usr/lib/xulrunner-$(xulrunner-1.9 --gre-version)
<pochu> fta: can you fix it? I don't have a jaunty chroot to test it yet...
<pochu> Otherwise, I'll create one this WE and look at the bug
<fta> sure
<pochu> thanks :)
<fta> pochu, do you have a branch ?
<fta> pochu, bug 295490
<pochu> fta: nope
<ubottu> Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Undecided,New] https://launchpad.net/bugs/295490
<pochu> fta: you can get it uploaded directly
<fta> pochu, it's in main, i can't, i'm just motu
<fta> i guess 295490 is the same bug
<pochu> fta: sure 295490 and 295490 are the same bug :-)
<fta> lol
<fta> same as the one i described above
<pochu> sure :)
<pochu> ah, my "nope" was to your branch question :)
<fta> pochu, should i post a debdiff on the bug and call for a sponsor or [cw]ould you do it using a the diff.gz/dsc ?
<pochu> fta: I can't upload to main either :)
<pochu> fta: please use the sponsors queue
<fta> pochu, oh, I thought you were core-dev by now.
<jwendell> hello, pochu
<jwendell> pochu, that's why I used the term 'merge' in my email. I know that there will be many changes. Many parts of that man page is solaris specific
<jwendell> pochu, so, feel free to use what you think it's good from it
<pochu> jwendell: ok :) I didn't know it would need so many changes until I started reviewing it, after saying it would be better to completely replace it ;)
<jwendell> hehe
<pochu> jwendell: I'll do the work if Halton is fine with it
<jwendell> pochu, it doesn't matter for him. That man page is solaris specific
<jwendell> it's not supposed to be upstream
<wasabi> Oh. Is this /. crap real? I'd sure like to see an official build setup for arm. That would be nice.
<wasabi> Tired of building stuff by hand. :)
<pochu> jwendell: oh, I thought that was proposed to be shipped upstream
<jwendell> nope :)
<pochu> jwendell: fine then, I'll clarify it in a mail and do it tomorrow
<pochu> jwendell: thanks!
<jwendell> pochu, thank you
<fta> wasabi: i don't know how official it is but there are 4 builders at work for armel right now
<wasabi> Hmm.
<wasabi> Those are new, no? I don't remember seeing them.
<fta> yep, i started to get buildlogs today
<pochu> fta: if you have time, would be nice if you added this patch to liferea too, it adds Launchpad integration to the help menu: http://pfragoso.org/ubuntu/02_lpi
<wasabi> Cool. Well that is super awesome. I remember talking with mark about this... what, 3 years now, at the first uds in mtv
<wasabi> maybe 2 years? got me.
<pochu> fta: credits to Pedro Fragoso (for the changelog entry)
<wasabi> back then some of the nokia guys were floating the idea of rebasing their maemo distribution on ubuntu.
<wasabi> thought it was a kick ass idea. we told them who to contact and who to push to get things going..... specifcally some builders for armel. And then never heard from them again.
<pochu> fta: but there's no hurry for it... I can do it myself later when I do the update to the latest 1.4.x, or even to 1.5.x
 * pochu waves good night
<fta> pochu, the configure part of the patch is not needed as there's no version to test, d/control is enough. otherwise, it forces to regenerate autoconf.
<fta> i mean to configure
<fta> +regenerate
<pochu> makes sense
<pochu> hmm
<pochu> will it compile fine?
<pochu> if it does, I'm fine with it :)
<pochu> ember_: ^
<pochu> I'm away now, see you!
<kees> evand: oh! you handled all the installer bits for bug 51551.  thanks!
<ubottu> Launchpad bug 51551 in user-setup "newusers, liboobs uses crypt insted of md5, intrepid installer doesn't use sha512" [Medium,Fix committed] https://launchpad.net/bugs/51551
<calc> why is libneon27-dev in universe but libneon27 in main (that seems fubar)
<calc> we support linking to the library but not building against it? :)
<NIK> Hello... anybody here knows if the MOTU 896 woks on linux??
<cjwatson> calc: funky; I don't know quite how that happened. I've promoted it back
<slangasek> cody-somerville: why is dput in jaunty erroring out for me with a complaint about bzrlib and sftp when my config doesn't use sftp?
<calc> cjwatson: ok
<peratu> exit
<cody-somerville> slangasek, is there a traceback?
<slangasek> cody-somerville: um, there's an exception that you're throwing in sftp which immediately exits
<slangasek> well, catching rather than throwing
<slangasek> bug in LP shortly
<cody-somerville> thanks
<slangasek> bug #297851
<ubottu> Launchpad bug 297851 in dput "sftp.py causes dput to fail if bzrlib not installed" [Undecided,New] https://launchpad.net/bugs/297851
<slangasek> cody-somerville: ^^ and subscribed you
#ubuntu-devel 2008-11-14
<fta> pochu, i gave it more thoughts, the xul path in liferea is not important since we are using static glue. it's detected by GRE at runtime. the Abort() comes from something else.
<fta> pochu, i tracked it down to sqlite3
<fta> pochu, see http://mxr.mozilla.org/mozilla-central/source/storage/src/mozStorageService.cpp#68  liferea aborts line 82
<ozzilee1> Can anyone tell me where Ubuntu keeps track of what folder an app's launcher should go in? By folder I mean "Accessories", "Games", etc. It doesn't seem to be in the .desktop file...
 * ozzilee1 will come back after watching a couple episodes of House...
<persia> ozzilee, It's calculated based on the contents of (usually) /etc/xdg/menus/applications.menu which uses the Categories keys in the .desktop files.
<persia> Some flavours (e.g. edubuntu or ubuntustudio) use different locations for customised applications.menu files, but the idea is the same.
<fta> pochu, i just explained all that in bug 295490. please see my last comment.
<ubottu> Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Confirmed] https://launchpad.net/bugs/295490
<NCommander> ScottK, ping?
<andrew_sayers> ScottK: are you available to talk about the downgrading idea?
<wgrant> Ewww.
<Hobbsee> andrew_sayers: i'd be interested in the discussion
 * Hobbsee is looking at brainstorm, for some stupid reason
<andrew_sayers> Hobbsee: fair enough, what's your opinion on the matter?
<Hobbsee> andrew_sayers: well, the only reliable way is goign to be a snapshot of the old system, which you can then go and restore.  How small can that snapshot be made?
<Hobbsee> andrew_sayers: like 'doze does it, with their system backup / system restore stuff.
<andrew_sayers> I don't know, but I have LVM and installing Intrepid is still on my todo list, so I can do a test if someone can tell me how to check the result.
<Hobbsee> i guess you could flush out certain caches
<Hobbsee> such as run stuff like 'apt-get clean', etc, first, and that sort of thing, to get it down
<Hobbsee> i don't actually know how to get a snapshot of a linux system, i'm afraid.
<Hobbsee> but i remember the stuff on backing up had some good info
<ajmitch> trying to downgrade changes made to user configuration files wouldn't be easy
<persia> Well, caches can be flushed, and unmodified files ignored.  It's mostly just grabbing unclaimed and modified files in /etc, dpkg --get-selections, and preserving /home to be able to restore assuming some reboots and the old disk.
<Hobbsee> ajmitch: i don't think any sane person would even attempt that.
<persia> The problem is that downgrades aren't well supported by apt, so it would need to be almost a reinstall to be known safe.
<Hobbsee> ajmitch: it would be a "backup, and reimage" solution
<ajmitch> Hobbsee: that's the problem - people wouldn't want to lose their mail, photos etc which can end up mixed in with per-account configuration
<Hobbsee> andrew_sayers: http://www.psychocats.net/ubuntu/backup is the best thing i've found so far (and related links)
<ajmitch> eg rolling back 2 weeks, you wouldn't want to be losing 2 weeks of stuff in /home
<Hobbsee> ajmitch: well, I was assuming that it would be an immediate rollback, or at least, done within the next day or so
<andrew_sayers> Hobbsee: thanks - I'll work it out if that turns out to be the way to go.  Losing mail would be a problem though - LVM is a bit of a blunt instrument in that regard.
<ajmitch> some problems can take a bit longer than that to surface
<Hobbsee> ajmitch: but warnings, etc, can be written about that "warning:  This will put your system back to X date, running Y version.  Please make sure you have backed up any important files that you have modified since then, and wish to keep"
<Hobbsee> iirc, windows does the same thing?
 * ajmitch shrugs
<ajmitch> haven't dealt with windows much :)
<Hobbsee> unless you keep the updated ~
<andrew_sayers> I've heard the same about Windows, but I've never tried it.  I think it's just for specific stuff like the registry and c:\windows\blah
<Hobbsee> which may be problematic if config files, etc, got updated.
<ajmitch> and config files do get upgraded in interesting ways
<Hobbsee> andrew_sayers: no, it does the entire thing.  I triedit a while ago.  I just don't remember what it does with the stuff in mydocs.
<ajmitch> one reason why sharing /home between different versions can be painful
<Hobbsee> (they pushed a video card update that kept bringing up BSODs for some of the games I was running)
<Hobbsee> ajmitch: indeed.
<persia> There's also the new "preserve /home" function in the installer.  Maybe there'd a way to leverage that?
<andrew_sayers> Hang on, is it just /etc that's the killer to downgrade?
<persia> dotfiles could well be mangled, but that's an easier issue to resolve.
<ajmitch> persia: apps are generally written with upgrade functionality in mind, but not downgrade
<persia> andrew_sayers, /etc, user dotfiles, and possibly some stuff in /var
<persia> ajmitch, Yep.
<andrew_sayers> I take it that now's not the time to be talking about version-controlling those, in the general case?
<persia> ajmitch, The only sane way is wipe&replace, but that doesn't necessarily mean losing 2 weeks of /home.
<persia>  /srv, /var/lib/, /var/log, etc. might be interesting for some users, but not others.
 * ajmitch would be in deep trouble if /var/lib got rolled back
<andrew_sayers> If we wanted to go a la Windows, it wouldn't be that hard to create /var/bzr/foo symlinks that get backed up nightly.
<andrew_sayers> That would make downgrading easier, be easy for packages to add to, and avoid the whole "oh no I Just deleted my config" issue.
<ajmitch> part of the problem is identifying what needs to be be kept & what can be replaced
<andrew_sayers> Yeah, that would have to be done on a per-package basis.
<andrew_sayers> Which shouldn't be all that hard if we're just asking packages to add a symlink to a known dir.
<persia> Well, conservative retention is /var/games, /var/lib, /var/local, /var/log, /var/opt, /var/spool, /var/www, /etc, /opt, /usr/local, and /home.  The rest should be system managed.
<persia> Most of /etc is probably md5sum identical according to dpkg, and can be dropped.
<persia> The tricks are 1) performing wipe & restore without breaking things, and 2) having a restore source (e.g. package repo CD for previous install state).
<persia> Depending on whether the user recently cleaned their apt-cache, this could be gigabytes of packages to download for the older versions.
<andrew_sayers> How wWould the bandwidth for a downgrade be more than the bandwidth for an upgrade?
 * andrew_sayers needs to put delete and enter further apart :s
<ajmitch> downgrade would most likely entail wiping whole parts of the filesystem & installing the appropriate packages, if I understand persia's suggestion correctly
<persia> Yeah, that's the only way I can think of doing it, unless you provide everyone patching any pf the packages with a time machine.
 * ajmitch doesn't even want to think about how maintainer scripts would handle it otherwise
<andrew_sayers> And VCing the sensitive bits wouldn't cut it?
<persia> You can do a store-in-place to local storage, but reconstructing packages from unpacked source is itself inherently risky, so you still probably have download requirements.
<persia> Well, sure.  You could e.g. snapshot, try the upgrade, and revert the snapshot, but that takes even more local storage than using packages.
<andrew_sayers> Okay, so would it be fair to say this: creating a pervasive VC system for config files isn't worth it for backup alone, but might be a good idea for the general health of your system.  If it is a good general idea, it makes the specific case of downgrades easier.
<andrew_sayers> All downgrades actually, since it would in principle be possible to create a snapshot before (un)installing any package.
<lifeless> 'etckeeper'
<persia> Indeed.  There's a number of people who swear by keeping /etc in VCS.  Large chunks of /var would benefit from it as well.  /home in VCS is reasonably common, although usually with a decently large local folder that hasn't been added.
<andrew_sayers> Is there any particular reason it's not done by default?
<persia> Keeping that stuff in VCS doesn't make downgrades any less risky unless you're doing a wipe & reinstall, as maintainer scripts aren't idempotent
<persia> It's a little slower, a little more complicated, and a little easier to break if you don't know what you're doing.
<persia> It's also different than most random Google results on how to perform a given operation.
<andrew_sayers> Fair point, although "easier to break" sounds like a fixable UI issue to me.
<andrew_sayers> When you say wipe, do you mean uninstalling most packages, or deleting everything outside /usr?
<andrew_sayers> Er, /home
<andrew_sayers> lifeless: that's excellent.  I shall now become another /etc in VCS zealot ;)
<rlaager> I don't want to get sucked into this too much, but I'd like to throw out an idea that may or may not help you... I try my hardest to separate (for lack of a better word) "transient" data from the OS data.
<rlaager> So, on client machines, transient data is /home, basically. Everything but /home can be trashed. (I'll get to /etc and /boot in a minute.) On a server, I move everything in /srv. So, for example, /var/lib/mysql gets moved to /srv/mysql.
<persia> rlaager, In many cases, that's not so hard.  For things like /etc/hosts, it's a bit tricky.
<persia> The reason being that /etc/hosts doesn't belong to a package.
<rlaager> How do I deal with /etc and /boot? Well, I maintain that all through the package manager. Everything that I touch there I build into (site-local) configuration packages.
<rlaager> persia: /etc/hosts isn't really a good example, as nobody really modifies that much, except for the machine name.
<persia> rlaager, Well, except that the system doesn't work well without it.  Plus I only have 10-15 files to choose from if I want one that breaks without backup due to being created by the installer.
<rlaager> Completing this idea... Any box should be able to be re-created by 1) re-installing the OS, 2) re-installing the machine configuration packages, and 3) restoring (or maintaining through the re-install) /srv or /home.
<persia> Well, plus chunks of /var, but yeah.
<rlaager> I never keep anything across installs from /var on either clients or servers. What would you be concerned about?
<persia> Still, not so hard to take care of the bits of /etc that aren't md5sum identical with shipped, and set those aside without site-local config packages.
<rlaager> Oh, sure.
<persia> Or use something like puppet to determine config state from remote VCS.
<persia> (well, VCS of rules that generates config, but...)
<persia> And site-local packaging is a little extreme for the user that wants to undo an upgrade on an isolated desktop.
<hyperair> jdong: did you upload banshee (1.2.1-3ubuntu1.1) to intrepid-proposed? it's not in http://archive.ubuntu.com/ubuntu/pool/universe/b/banshee/
<rlaager> persia: Sure. If you want to ship something that Just Works, that's not the way to do it. I wasn't sure of your use case, though. For larger deployments, it makes sense.
<jdong> hyperair: yes, it's uploaded. -proposed needs to be manually reviewed by an archive administrator before showing up
<jdong> hyperair: an archive admin will comment on the launchpad bug to let you know when that has happened.
<rlaager> persia: If I were looking to implement a snapshot-type system, I'd do the dpkg md5sum thing for /etc and grab specific things from elsewhere, e.g. /var (based on a .d directory where packages could drop a file saying, "grab this") and then I'd store in a tree of compressed backwards deltas (ala rdiff-backup) in some place like /restore, which would be left untouched by the installer.
<hyperair> jdong: oh i see. forgive my ignorance =)
<ScottK> andrew_sayers: I'm here now.
<ScottK> NCommander: Pong.
<jdong> hyperair: no probs :)
<andrew_sayers> ScottK: Hey - rlaager has already summed up everything I've got to say and more :)
<ScottK> OK.
<ScottK> andrew_sayers: I was up for making the suggestion.  I really don't have time to work on implementation.
<ozzilee1> persia: Ah, I see. Thanks. (RE application menu two hours ago)
<andrew_sayers> For the VCS part of the equation, I'm quite tempted to put some time into adding the bits that etckeeper would need to be a general thing.
<andrew_sayers> A more specific/newbie-friendly UI and a .d.
<andrew_sayers> ScottK: Do you have time to help with a blueprint?
<ScottK> andrew_sayers: Not particularly.  My main point was that you can't make apt go backwards reliably.  It's really, really not designed for that.
<ScottK> andrew_sayers: I do encourage you to work on the problem and I'm glad you're here.  I can try to answer questions.
<rlaager> andrew_sayers: Yeah, I think you can easily protect the user against breaking their config files. I don't think you can protect against broken system upgrades very easily. If you want to do that, you need good filesystem snapshotting stuff...
<slangasek> "make apt go backwards" --> "downgrades"?
<slangasek> apt is moderately indifferent to that; it's the dpkg design that doesn't support it, and can't do sanely
<ScottK> slangasek: Yes. And yes, that's a more correct way to put it.
<ScottK> slangasek: The request was to be able to upgrade, say to Intrepid, and if it didn't work out due to regressions, revert to Hardy.  My suggestion was good back ups.
 * slangasek nods
<andrew_sayers> rlaager: the problem with snapshotting the FS is that it's a blunt instrument that can't tell /var/mail from /var/lib
<rlaager> andrew_sayers: I'm not sure if you've looked at Nexenta, but from what I've read of their documentation, they have some really sweet apt/ZFS integration which takes advantage of ZFS snapshots. Basically, I think they snapshot before apt starts making changes and even add an entry to the bootloader menu for that snapshot.
<rlaager> If you had /home and /srv (and whatever in /var) as a separate filesystem (which is, of course, trivial with ZFS), it'd be perfect.
<lifeless> andrew_sayers: thats not really a problem
<superm1> slangasek, so as it turns out, fglrx 8.11 resolves the regression that all r3xx hardware is broken.  would you consider an SRU towards it if we let it sit in proposed for a little bit and look for other regressions?
<lifeless> andrew_sayers: because *of course* you are backing up separately your user content
<rlaager> andrew_sayers: I maintain that the FHS is broken in that regard. ;)
<slangasek> superm1: yes, probably
<superm1> slangasek, okay i'll tie of with bryce then and get an SRU for it ready tomorrow
<slangasek> superm1: fglrx was usable at all at release time?  I should that was one of the broken-with-modern-X ones
<superm1> slangasek, yeah it was usable for everything but r3xx
<slangasek> ah
<andrew_sayers> ScottK: Thanks for the offer - if I'm going to be working on my own, it's more likely to be a "2 hours a week for a year" than "2 days solid hacking" type thing, so you won't hear anything for a good long while.
<superm1> AMD came through last minute - like with a week or two to go
<slangasek> ah, heh, I don't think I was aware of that
<ScottK> andrew_sayers: I suspect you can build a community of interest around this.  You might put it on brainstorm and try to recruit people who are interested to help.
<slangasek> I do recall nvidia betas being released the day of the 8.10 release, or some such... :)
<andrew_sayers> ScottK: Yeah, I've already got a little project like that.  When I've done the major work on that project, I guess I'd put this next on my list.  In the mean-time, I'd just be scratching my various itches.
<StevenK> NCommander: Still here?
<dholbach> good morning
<persia> We're just looking at outstanding FTBFS in #ubuntu-motu, and notice that a lot of the !{armel,hppa} cases would benefit from just being given back.  Would it be possible to schedule a mass-give-back?
<infinity> persia: Yeah, it's about time to do that.
<infinity> persia: I'll do it for the arches that aren't backlogged.
<infinity> emet: So, !{armel,hppa,ia64,sparc}
<infinity> persia: ^^ ... Not sure how that turned into emet..
<persia> infinity, Thanks.
 * slangasek erases the leading 'e'
<NCommander> infinity, thanks :-)
<persia> infinity, Should we watch and ask again when sparc and ia64 have caught up?
<infinity> persia: Might not be a terrible plan.
<infinity> persia: Anyhow, all done.
<slangasek> does anyone here have softmac wireless?
<NCommander> persia, we shouldn't do sparc until we at least get a second builder, it would take forever
<NCommander> hey infinity
<infinity> Yeah, sparc needs some hardware love right now.
<persia> NCommander, I agree.  ia64 just needs time.  hppa needs manual intervention.  armel needs to finish digesting the elephant.
<slangasek> (does the softmac driver still exist, even?)
<NCommander> infinity, I dunno if you remember, but we talked about issues w/ Hardy kernel on the powerpc buildds
<NCommander> infinity, do you still have those logs?
<infinity> NCommander: We totally did.  And I totally don't have 'em lying around right now.
<infinity> NCommander: (Note that it's both midnight and a holiday, so I'm just sort of stopping by..)
<NCommander> As I said before, no rush. We still have two years until the next LTS
<infinity> NCommander: Let me see if I can dig something up.
<pitti> Good morning
<lool> Hi pitti
 * lool tends slowly to the pitti-time
<pitti> bonjour lool
<ogra> hmm
<ogra> do we recently support /etc/modules being a dir instead of a file ?
 * ogra glares at bug 297434
<ubottu> Launchpad bug 297434 in fuse "package fuse-utils 2.7.3-4ubuntu2 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/297434
<ogra> there is definately no code that creates /etc/modules/udftools in the udftools package
 * ogra doesnt get where that could come from
 * ogra curses .... 
<ogra> so if i have a static ethernet interface in intrepid and unplug the cable, the interface goes down ?
<ogra> thats just annoying
<ogra> asac, ^^^ is that NMs fault ?
<ogra> (it doesnt seem to touch the iface otherwise, but my nfs export via crossover cable doesnt work once i rebooted the machine on the other side of the cable)
<tjaalton> pitti: duh, the xkeyboard-config cruft that got removed from the update was due to _not_ building this older version first. I was trying the newer debian version which cleans all/most generated files :)
<tjaalton> pitti: but I still don't understand why 100_abnt2.diff is referenced on the debdiff, since neither of those packages have it when unpacked
<pitti> I just looked at debdiff ~/ubuntu/pool/main/x/xkeyboard-config/xkeyboard-config_1.3-2ubuntu4.dsc xkeyboard-config_1.3-2ubuntu4.1.dsc|view -
<tjaalton> well I've got it a lot cleaner, but debdiff still has some "reverted:" chunks
<pitti> tjaalton: so those were just cruft from the previous source build?
<tjaalton> pitti: the intrepid version doesn't clean up after itself, so the diff has a lot of cruft, yes
<tjaalton> pitti: ah, ok.. so the old version also had x-k/patches dir, which doesn't belong there :)
<tjaalton> now the diff is sensible
<tjaalton> pitti: reuploaded
<pitti> tjaalton: ah, indeed that slipped my attention: it's patches/, not debian/patches
<pitti> someone forgot to export QUILT_PATCHES or so :)
<tjaalton> pitti: yeah, well the new version does patches -> debian/patches IIRC :)
<tjaalton> the one that'll soon be in jaunty
 * sonicmctails always forget to set QUILT_PATCHES
 * ogra doesnt get why quilt cant just default to debian/patches ... let the people using it out of packaging have to fiddle with the env 
<cjwatson> quilt started out as a tool for patch maintenance in the kernel, not for Debian patch maintenance
<cjwatson> it seems a bit unfair to hijack it
<ogra> is it used in debian or ubuntu for kernel patch maintenance still ?
<hyperair> ogra: if you're that annoyed, stuff QUILT_PATCHES in your bashrc
 * ogra doubts that since everyone doing kernel stuff uses git anyway
<cjwatson> the package exists in the archive for more than just what we use
<ogra> cjwatson, i know, but is it actually still used in other ways ? :)
<cjwatson> yes.
<elmo> ogra: there are people who use quilt in addition to git for kernel maintenance
<ogra> ah
<ogra> elmo, thanks thats what i wanted to know
<cjwatson> google for 'kernel quilt 2008'
<ogra> then it makes sense to go into bashrc
<persia> ogra, linux-rt uses upstream quilt assemblies to build.
<cjwatson> and TBH when advocating a change like that the onus is on the advocate of the change to figure out whether it's still being used elsewhere
<cjwatson> not for everyone else to have to be paying attention
<cjwatson> people are entitled to silently use things :)
<ogra> well, it never occured to me personally before it showed up in packages i had to touch ...
<ogra> and it still gives me a painful time every time i have to use it
<ogra> seeing comments from others i dont seem to be alone :)
<cjwatson> I am not arguing with that, but "the people I know have problems" really isn't particularly good support for breaking compatibility
<ogra> well, i didnt mean to make the change right now, it was just a question out of interest (and ongoing pain)
<NCommander> ogra, just linux-rt ATM.
<persia> Could well be less pain as various efforts in Debian to establish a common operating model for different kinds of packages bear fruit.
<cjwatson> having people who only ever use it that way set QUILT_PATCHES=debian/patches in .bashrc seems entirely sensible
<cjwatson> although they should be careful to unset it for build testing
<pitti> cjwatson: (just merging fuse) what's the rationale for having fuse in the initramfs?
<pitti> cjwatson: I'd like to give a rationale for forwarding stuff to Debian
<cjwatson> pitti: I already did, they rejected it
<cjwatson> pitti: the rationale is to support ntfs-3g for wubi
<pitti> ah, thanks
<cjwatson> pitti: oh, no, the thing they rejected was putting it in / rather than /usr
<pitti> that would have been my next question :)
<cjwatson> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452412)
<ubottu> Debian bug 452412 in fuse "fuse: install to / rather than /usr" [Wishlist,Open]
<cjwatson> pitti: forward it if you like, I just wasn't particularly encouraged by the response I got to the other bit
<cjwatson> "It has been discussed with others debian developpers and all agree it's useless for the debian project."
<pitti> cjwatson: I set myself a policy to forward all non-Ubuntu specific changes to Debian bugs while merging, so I'll do it
<Y2K38> heya fellas. is it normal for a package upgrade to not have changelog? i mean i get all my informations on new features using devel changelogs.. i am quite suprised when i didn't find one!
<Y2K38> new features + bug fixes :P
<hyperair> Y2K38: no it's not normal, unless you're getting it via ppa
<persia> Y2K38, It's not normal at all.  Which upgrade?
<persia> hyperair, Even then it's not normal (although behaviour is more variable)
<Y2K38> persia: hyperair just had a look at alacarte 0.11.5-0ubuntu1.1
<Y2K38> thats just 1 example
<hyperair> persia: i've never had changelog entries from any upgrades from ppa before
<Y2K38> its not from ppa
<Y2K38> right now we have 25 upgrades and only handful of them have dev changelogs
<Y2K38> travis watkins O_o!!
<Y2K38> wtf is travis watkins!?!!?!
<persia> Y2K38, I don't understand.  I see http://launchpadlibrarian.net/18600518/alacarte_0.11.5-0ubuntu1_0.11.5-0ubuntu1.1.diff.gz as the diff, which definitely includes a new changelog entry.
<Y2K38> persia: that doesn't say anything
<Y2K38> persia: if my local mirror doesn't include changelog what good is it? :P
<cjwatson> it's impossible for an upgrade to have no changelog at all; the very process of creating it requires creating a changelog entry
<Y2K38> maybe its the adept who's fscking up
<cjwatson> it may of course have a minimal or poorly-written changelog
<cjwatson> but if you're not seeing anything at all, you generally ought to look to your package management program for the problem, not to the package
<Y2K38> cjwatson: thats what i thought as well.. i mean the very fact that adept points me to "Index of /changelogs/pool/main" means sth is broken
<cjwatson> oh, if you haven't actually installed the package yet, then adept probably routinely goes to changelogs.ubuntu.com (although technically speaking it would be *possible* to fish it out of your local mirror, it'd just be slow)
<Y2K38> cjwatson: persia whats the command line to get changelogs? :P thanks
<persia> Y2K38, aptitude changelog $(package) is what I use.
<Y2K38> lets see if its me who's PEBKAC or the adept guys
<Y2K38> persia: thanks!
<cjwatson> neither, the problem here is probably that changelogs.ubuntu.com hasn't extracted that changelog yet
<persia> cjwatson, Except it's from May, which makes me think that's not it.  Isn't that usually only a 4 hour delay or so?
<cjwatson> six hours or so - you'd expect so
<Y2K38> wow! that really looks like a PITA..
<cjwatson> Y2K38: ease up for a minute, please!
<ScottK> Y2K38: Are you running Intrepid?
<Y2K38> cjwatson: sure i will
<Y2K38> ScottK: hardy
<persia> Unless changelogs don't get copied until things move to -updates, and this was late.
 * persia looks up publication date
<cjwatson> oh, no, I'm mistaken due to the truncation on changelogs.ubuntu.com's apache directory listings
<cjwatson> http://changelogs.ubuntu.com/changelogs/pool/main/a/alacarte/alacarte_0.11.5-0ubuntu1.1/changelog looks fine
<persia> But it did sit in -proposed for six months.  Only got published 2008-11-12.
<Y2K38> cjwatson: so say i pull packages from archive.ubuntu.com, this should be fixed ya?
<cjwatson> persia: the changelog was extracted on changelogs.u.c on 16 Oct, though
<Y2K38> doh! 16oct! isn't that really late or what guys?
 * persia is extra confused
<cjwatson> Y2K38: huh? lay off
<cjwatson> Y2K38: investigating a problem is rarely helped by people shouting "this is all crap" in the middle of it
<cjwatson> Y2K38: and in fact, that version was published in hardy-proposed on 16 Oct. So in fact, no, it wasn't really late at all.
<Y2K38> persia: as i see it, our local mirror is _supposed_ to pull info from changelog.ubuntu.com but since its _behind_ i do not _yet_ see changelog ... thats what i understood from cjwatsons explanation
<cjwatson> Y2K38: I don't see why your local mirror would pull from changelogs.ubuntu.com. It would pull from archive.ubuntu.com or one of its mirrors. The extracted changelogs are not mirrored.
<cjwatson> Y2K38: of course the packages themselves *also* contain changelogs but adept may or may not look there
 * cjwatson looks at adept in hardy
<persia> Y2K38, I think it's probably adept specific, or specific to your environment, since I can't reproduce with other tools in hardy.
<Y2K38> cjwatson: i take your word since you work for canonical! :) i will try to see the changelogs in couple of days...
<cjwatson> ok, so adept is hardcoded to look at changelogs.ubuntu.com
<cjwatson> Y2K38: your local mirror is not relevant at all here
<cjwatson> I suppose it's possible that adept is confused about the component, although I'm not quite sure how that would happen
<cjwatson> but at any rate, yes, this does look like an adept bug
<mvo> Y2K38: could you please try update-mangaer?
<mvo> Y2K38: just to check if its specifc to adept or not
<Y2K38> cjwatson: mvo ok lets give update-manager a whirl
 * Y2K38 ISP's is acting weird today
<cjwatson> Y2K38: seems like you're suffering from https://bugs.launchpad.net/ubuntu/+source/adept/+bug/136381
<ubottu> Launchpad bug 136381 in adeptmgr "Adept doesn't show changelogs." [Unknown,In progress]
<mvo> hm, so its not implemented in adept at all?
<cjwatson> Y2K38: I've added a comment there with my speculation as to the cause, although how much good that'll be I don't know since Adept 3 doesn't support changelog display at all
<Y2K38> mvo: yes its adept specific it seems
<cjwatson> mvo: in >=intrepid, no; in <=hardy it worked for some packages but not others
<Y2K38> cjwatson: w00t!
<cjwatson> mvo: I think it's due to .source() returning empty when binary package == source package
 * mvo nods
<mvo> cjwatson: I recently make the server side much client friendlier, should be fine to just check the binary packagenames now
<pitti> StevenK: there, NBS brought down from 23042420 packages to 14; love, pitti
<StevenK> Wheee
<StevenK> pitti: Nice work!
<StevenK> pitti: Sorry, I've been ignoring NBS :-(
<cjwatson> mvo: ah, cool, can you mention that in the bug
<cjwatson> ?
<cjwatson> mvo: just in case the adept guys reimplement this ...
<mvo> cjwatson: will do
<pitti> StevenK: no need to be, just done as part of archive day; let's try to not make it so ridiculously large for extended periods of time
<Y2K38> ok guys.. till it gets a fix, i might have to refrain from using adept!!!
<Y2K38> cjwatson: thanks for pointing this out man.
<pitti> StevenK: I didn't do rebuilds, just waded through the dependency circles
<StevenK> pitti: Mmmm
<lasko> ls
<lasko> ls
<lasko> quit
<Y2K38> see ya fellas..
<RainCT> When will bug #291262 be fixed?
<ubottu> Launchpad bug 291262 in python-central "MASTER - package failed to install/upgrade: pycentral pkginstall: not overwriting local files" [High,Triaged] https://launchpad.net/bugs/291262
<cody-somerville> slangasek, I attached a debdiff to your bug re: dput
<soren> I forget... How do I find older versions of Debian packages? Like, say, iptables-1.4.1.1-3?
<elmo> snapshot.debian.net ?
<soren> Using google and hoping for an outdated mirror worked this time, but..
<soren> elmo: Oh.
<soren> elmo: It doesn't show iptables versions more recent than 1.4.0-3 (date: some time in February).
<soren> Does it not keep a record of all versions or has it simply not been updated for a while?
<james_w> snapshot.debian.net is not updating
<ScottK> Which is rougly when it died.
 * soren hugs the outdated mirror he found
<james_w> and had also lost older versions last time I looked
<elmo> oh, that's a shame
<james_w> it's going to become part of the Debian infrastructure
 * james_w hopes that will include all the history that it used to have
<jcristau> james_w: snapshot.d.n seems to have packages i uploaded a few days ago, so maybe they finally fixed the disk full problem..
<james_w> hopefully
<cjwatson> LP is also mirroring Debian source on an ongoing basis now
<cjwatson> soren: https://launchpad.net/debian/+source/iptables/1.4.1.1-3
<cjwatson> only started relatively recently
<soren> cjwatson: *blink* Awesome!
<cjwatson> as in about two weeks ago
<MacSlow> mvo, got a moment?
<ogra> heh Keybuk thanks for the boilerplate mail :P
<Keybuk> heh, don't mention it %(fullname)s
<mvo> MacSlow: yes
 * Keybuk tries to work out whether the lecture from ivoks's mail server meant it didn't deliver the mail or not
<Keybuk> and I'm fully enjoying the irony that someone with silly characters in their name's mail server complains because the headers weren't 7-bit
<blueyed> Can somebody please look at bug 297771, which renders logcheck quite useless on Intrepid?
<ubottu> Launchpad bug 297771 in logcheck "logcheck ignores all logs in "server" or "workstation" config" [High,Fix released] https://launchpad.net/bugs/297771
<slangasek> cody-somerville: thanks for the dput fix :)
<slangasek> cody-somerville: btw, I should be following through on the grub xen fix today
<cody-somerville> Thanks
<murdok> hey kees
<murdok> I saw that you applied the patch to dosemu and that it had nothing to do with the one I made :S, hehe. But it's fine, I have learnt
<murdok> :]
<slangasek> curious, gnome-panel doesn't know what the temperature is here today
<kees> murdok: heh, yeah, I radically rearranged how it was applied, but we get the same results, and in a way that is more standard.  :)
<slangasek> anyone here have broadcom wireless who could check quickly whether bug #47610 still applies?
<ubottu> Launchpad bug 47610 in wireless-tools "iwlist eth1 rate shows nonsense rates" [Wishlist,Confirmed] https://launchpad.net/bugs/47610
<calc> grr the company my wife is doing an infomercial for is totally inept :\
<calc> 6hr into a 3hr session and they haven't even started shotting yet
<SOF4LNX> Some issues to solve: http://mange.dynalias.org/linux/misc/Intrepid_Ibex_errors.txt
<SOF4LNX> Also, how can i get a trashcan on my desktop in Intrepid ?
<joaopinto> SOF4LNX, bugs are reported at launchpad.net ;)
<SOF4LNX> Hello dude :)
<SOF4LNX> Some have been reported, like https://bugs.launchpad.net/ubuntu/+source/gadmin-proftpd/+bug/276181
<ubottu> Launchpad bug 276181 in gadmin-proftpd "gadmin-proftpd crashes on startup" [Medium,Fix committed]
<SOF4LNX> A solution has been out for half a year but no updates so people fill up my inbox :)
<SOF4LNX> Also compile proftpd using "--with_modules=mod_tls"
<SOF4LNX> Correction: --with-modules=mod_tls
<SOF4LNX> Will this also be done ?
<SOF4LNX> Ive also talked to the debian crew about it so maybe it will, i hope.
<SOF4LNX> joaopinto: Would you like a console daemon that distributes passwords for users via ssh and scp ?
<SOF4LNX> and other configurable files as well...
<SOF4LNX> Like, you have one master password server and add some accounts. They will then be distributed to all configured servers you like ...
<SOF4LNX> Sure beats that slow microsoft solution using CIFS stuff
<joaopinto> SOF4LNX, isn't that what ldap and NIS do :P ?
<SOF4LNX> Dont they add extra security issues and slowness ?
<SOF4LNX> (As we talked about:)
<SOF4LNX> Lets turn it around, can you see why it wouldnt be good ?
<joaopinto> I don't see what is good on doing yet another version of something which has been tested for long years :)
<SOF4LNX> I watch bugtrack, ldap is alright but its not the best solution by a longshot (i think).
<SOF4LNX> Auth-Distributor (AD) will be without any security issues as i see it.
<SOF4LNX> Granted, of course that ssh is secure
<SOF4LNX> joaopinto: Lets say it could be awesome and easy to admin servers across the worlds. Would it be nice then you think ? :=)
<SOF4LNX> "No, its not my kind of consolemio" :P
<cjwatson> SOF4LNX: sounds like kerberos to me
<slangasek> sounds inferior to kerberos, to me. :)
<cjwatson> except kerberos has had proper security design :-)
<SOF4LNX> Howq can i make kerberos update and or add new users to remote computers and update other files like samba smbpasswd ?
<slangasek> you don't; you do that with other technologies that are coupled with kerberos
<SOF4LNX> Such as what ?
<slangasek> LDAP is one example.
<slangasek> nss-ldap, or userdir-ldap
<cjwatson> SOF4LNX: seriously, don't try to do your own security design for this - for example distributing passwords around is a really bad idea which is why kerberos distributes tickets instead that you can't just steal
<slangasek> but it's a key feature of kerberos that random servers do *not* get to know the passwords for individual users
<SOF4LNX> So LDAP wont add more security issues then not running it ?
<cjwatson> it won't add more security issues than distributing passwords around your network
<SOF4LNX> cjwatson: will be done irregardless using ssh keys. Not less secure then kerberos
<slangasek> false
<SOF4LNX> true, what do you mean ?
<slangasek> trusting all of your servers with copies of the user passwords *is* less secure than kerberos
<wasabi> If the keys are on each machine, then all you need to do is compromise a machine.
<wasabi> any machine.
<wasabi> and suddenly you have access to every other machine.
<wasabi> There are well understood methodologies for this in place. From NIS to LDAP.
<SOF4LNX> So then an admin should have different keys for all machines, always, even though theyre on the internal network ? And then kerberos is better, why ?
<wasabi> And Microsoft's solution: Active Directory; is pretty much ideal. We can get close with kerberos and LDAP set up by hand.
<wasabi> AD is Kerberos and LDAP. Just set up properly by default. heh.
<SOF4LNX> Microsofts solution is slow and crappy wasabix
<slangasek> wasabi:, NIS and LDAP both still have the problem that the user sends the password to the server for authentication; in Kerberos, the server is *never* sent the password, in any form.
<wasabi> slangasek: NIS isn't a solution. I'm just demontstrating that we have already thought about this.
<SOF4LNX> yes, ssh is more secure then LDAP and NIS
<slangasek> no, it isn't.
<wasabi> Dude. It's not.
<SOF4LNX> wasaabilnx
 * kees pulls up a lawn chair
<wasabi> SOF4LNX: You likely do not understand MS's solution.
<SOF4LNX> Haha, we will keep the laughs up. But really, in the frekkin winter ? (minus degress over here)
<SOF4LNX> wasabi: 15000 clients and i dont ?
<SOF4LNX> doesnt scale
<wasabi> Yeah. You've run Active Directory?
<cjwatson> SOF4LNX: folks here are not exactly short of experience either
<wasabi> So you knwo what Kerberos and LDAP is?
<SOF4LNX> cjwatson: i know that, so asking around wont be bad
<wasabi> SOF4LNX: Folks here have written software for that, and have an extremely intimate understanding of it.
<cjwatson> SOF4LNX: but you also have to listen to what people with experience say ...
<cjwatson> well, you ought to if you want to get the right answer. Obviously I can't tell you to do anything
<wasabi> SOF4LNX: Microsoft's solution is distributed/replicated LDAP with all authentication done using Kerberos. It is the ideal solution.
<SOF4LNX> I _always_ do. Hence asking
<wasabi> We can approximate it by configuring OpenLDAP and MIT Kerberos, or Heimdal
<wasabi> or FDS.
<wasabi> But Kerberos and LDAP are the reigning kings when it comes to enterprise authentication.
<SOF4LNX> wasabi: Id say its very slow and outdated as a solution but i feel youll try to say its not over any cheese in the worlds
<wasabi> SOF4LNX: There's nothing to 'be slow'. It's LDAP.
<SOF4LNX> Lol
<wasabi> And Kerberos. I suspect you don't know what those are.
<SOF4LNX> Its microsoft, anythings slow there
<SOF4LNX> Or broken
<wasabi> *sigh*
<SOF4LNX> Lol
<wasabi> LO!L!!@!@
<SOF4LNX> Same old vsaabix
<wasabi> Off topic now. Bye. :)
<cjwatson> SOF4LNX: LDAP and Kerberos are not pure Microsoft technologies
<SOF4LNX> I know, its not a property of wasabikind :=)
<cjwatson> SOF4LNX: for one thing, both are included in the Ubuntu base system
<wasabi> Man I have no idea what you're talking about.
<SOF4LNX> They do it over CIFS
<wasabi> No, they don't.
<SOF4LNX> Windohbind
<wasabi> But nice try.
<cjwatson> SOF4LNX: please stop throwing around what as far as I can see are personal insults or you will be asked to leave
<wasabi> CIFS is for file sharing and RPC.
<wasabi> ... man what just hit us?
<wasabi> me->real work
<kees> troll or high?
<cjwatson> no need for insults from us either :-)
<cjwatson> just confused, I think
<kees> well, true, but I was very confused
<slangasek> kees: you need a lawn chair with a built-in drink holder
<kees> heh
<cjwatson> it's all too easy to get into the rut of judging security based on bugtraq message count rather than careful thinking about the design
<kees> I guess, but the CIFS mention really threw me
#ubuntu-devel 2008-11-15
<emgent> cjwatson: ping
<cjwatson> emgent: please leave a message with your ping, I'm about to go to bed
<emgent> cjwatson: please wait one moment..
<emgent> it`s an urgent issue.
<cjwatson> it's also 00:42; please spit it out :)
<emgent> hahaha, ok..
<Hobbsee> cjwatson: you can't really want to go to bed.  You need to stay up, drinking :P
<xTr3m3> Hello
<xTr3m3> I have a question for selinux:
<xTr3m3> you can not default in ubuntu activate? So it immediately after the installation is already active? :)
<jdong> this is not the channel for asking support questions.
<xTr3m3> why? devel-users can find the best answer yet
<jdong> because this is a channel to be used by developers only for developing Ubuntu itself. No other topics of discussion are allowed.
<xTr3m3> ok
<sainathas> i want to move my application from one virtual desktop to another through a program. What functions i have to call?How can i do that?
<sainathas> is anyone online?
<busfahrer> Excuse me, is the default Ubuntu kernel a tickless one?
<Hobbsee> i think so
<busfahrer> Thank you.
<ion_> CONFIG_NO_HZ=y in /boot/config... Not sure whether thatâs the setting for that, though.
<|DarkSmoke|> hey guys
<|DarkSmoke|> i want to compile progs using the debian/rules script
<|DarkSmoke|> how do it do that?
<|DarkSmoke|> and will it aply the patches from the patches folder automatically?
<persia> |DarkSmoke|, I'd recommend asking that in #ubuntu-motu, but you might want to read:
<persia> !packaging
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<soren> I commented on a debian bug that was marked as closed. I got an e-mail back that my input would be forwarded to the appropriate parties, but I don't see my comments on the bug page. Is that expected?
<soren> It's been at least 16 hours since I sent my comment, if that matters.
<soren> debian bug 500674, fwiw.
<ubottu> Debian bug 500674 in iptables "iptables: non-relevant documentation included" [Minor,Closed] http://bugs.debian.org/500674
<Treenaks> soren: Have you asked on #debian-devel? (this is about the Debian BTS right?)
<soren> Er...
<soren> It appears my browser was caching a bit more eagerly than I expected.
<soren> I just tried from a different machine, and now it's there.
<soren> Oddness.
<Treenaks> soren: it happens
<soren> Treenaks: I didn't ask in #debian-devel, no. I wasn't really in the mood for something like that :)
<siretart> soren: you mean that mail? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500674#15
<ubottu> Debian bug 500674 in iptables "iptables: non-relevant documentation included" [Minor,Closed]
<Treenaks> gah.. java--
<soren> siretart: That one indeed. I've been checking the page every time I passed my computer, but I always got the cached result (the one without my e-mail in it).
<Treenaks> soren: shift-reload ;)
<soren> Treenaks: Yeah. I just never expected that to be necessary when I actually navigated away from the page, and the went to the URL again.
<soren> Live and learn.
<Treenaks> soren: I don't know which caching headers bugs.debian.org sends
<soren> Nor do I.
<soren> meh
 * soren goes to eat
<Treenaks> hmm.. only last-modified, not even an etag
<Treenaks> your browser shouldn't be caching
<Treenaks> (it's allowed to cache it, but it shouldn't, imho)
<ScottK> slangasek: What's the process for revisiting release notes?  At release, Bug #290153 was only known to affect one motherboard type (the one I have, of course), but now it looks like a broader problem.  I've re-opened the Ubuntu Release Notes task.  Dunno if that's the right way or not.
<ubottu> Launchpad bug 290153 in ubuntu-release-notes "Fails to find boot device in Intel D945Gnt" [Undecided,Confirmed] https://launchpad.net/bugs/290153
<fta> how are we supposed to fix arm(el) issues ? i'd like to fix some in packages i maintain but i don't have access to any arm machine, same as hppa/ia64/ppc btw. is armel doomed to be a low grade citizen like those others arches? :(
<jpds> fta: There's a new #ubuntu-arm channel.
<NCommander> StevenK, ping
<fta> jpds, yes, but my question was generic, i assume most of us only have access to i386/amd64, making the other arches unloved by lack of resources, more than by lack of will.
<slangasek> ScottK: yep, reopening the bug is fine; is there a precise description of the issue that can be copied into the release notes?
<ScottK> slangasek: I think it just needs a more generic title.  The description of the issue is correct, but it's more broad than that.
<slangasek> how much more broad?
<ScottK> slangasek: I don't see a common thread on the hardware that appears to be affected, so I'm not sure.
<slangasek> hmm, ok
<gensenx> i need example code to get interface information in c. Where can i find something that prints out interface name and address ?
<gensenx> Interface name and hwaddr is no problem but printing the address after ioctl(sockfd, SIOCGIFADDR, &ifreq)...
<gensenx> +10 experia for you -> http://www.youtube.com/watch?v=njL34iCt8G8
<cjwatson> gensenx: ((struct sockaddr_in *)&ifreq.ifr_addr)->sin_addr.s_addr is a uint32_t with the IP address in network byte order, so run that through ntohl() and then extract the bytes one by one
<gensenx> aha
<cjwatson> as for example code I'm not sure, Stevens TCP/IP maybe?
<gensenx> %02x ?
<gensenx> If you have an example id very much like to take a look at it
<gensenx> I will need to do byte concatenation on the address as well ?
<cjwatson> I don't have an example to hand, sorry
<cjwatson> well, conventional IP address format would be %d not %02x
<gensenx> cjwatson: i find many pages with Stevens tcp/ip.... hwaddr is %02x, or atleast it works ok
<cjwatson> I meant the book
<gensenx> ok
<cjwatson> hwaddr, sure. I've never seen IP addresses written as 5b.bd.5e.09 rather than 91.189.94.9 though!
<Treenaks> gensenx: ISBNs 978-0201633467, 978-0201633542, 978-0201634952
<gensenx> Thanks!
<Treenaks> cjwatson: some sniffers like print IPs that way (without the '.'s though)
<gensenx> cjwatson: String and thong conversions ;)
<cjwatson> Treenaks: curious
<Treenaks> (+to)
<Treenaks> cjwatson: probably just laziness ;)
<gensenx> Hmm, can i memcpy ifreq.ifr_addr of size struct sockaddr_in directly to struct sockaddr_in via addr pointer ?
<Treenaks> gensenx: this is not really the channel for specific questions like yours, have you tried asking on #c?
<gensenx> Requires nick auth, dont like that
<ScottK> That doesn't make it less OT for this channel.
<gensenx> Id rather search for the answer for a week before authing :=)
<gensenx> k
<cjwatson> gensenx: try http://www.google.com/codesearch for SIOCGIFADDR; the hit in samba should help you part of the way
<gensenx> thank you
<cjwatson> well, I tried ioctl SIOCGIFADDR as search terms; refine creatively as needed
<gensenx> can anyone help fill in if i pastebin it ?
<cjwatson> I was attempting to give you enough material to continue by yourself, not to encourage continuing the conversation here
<cjwatson> as the others said, it's off-topic
<gensenx> as one other said yes, but im not sure i see how its off topic as im developing for ubuntu as well as all other systems but microsoft ;)
<Treenaks> gensenx: this channel is about developing _of_ ubuntu, not _for_ it
<gensenx> this is more system-packaging-channel ?
<gensenx> ok
<cjwatson> as the topic says: "Development of Ubuntu (not support, not app development on Ubuntu)"
<gensenx> My topic row is not so wide that i can see it all
<cjwatson> most clients have a /topic command
<gensenx> So, i can talk about new apps id like to have ?'
<cjwatson> anyway, you know now
<gensenx> yes, i think so
<gensenx> Whats the difference between "Development of ubuntu, not development on Ubuntu" as the topic sais ?
<cjwatson> only if you are volunteering to package them, and even then #ubuntu-motu is the preferred channel for mentoring
<gensenx> Im an ultimate mentor
<cjwatson> this is the channel where the developers talk to each other about what they are doing, problems they are facing, plans, etc.
<cjwatson> it is not a place for people to turn up and ask for help, in general
<gensenx> Nice
<gensenx> then i can ask why i have no "Computer" or "Trashcan" icons on my Intrepix ibex desktop right ?
<cjwatson> no.
<cjwatson> bugs.launchpad.net/ubuntu, answers.launchpad.net/ubuntu, or any of the other places we make available
<gensenx> hmm, reminds me. I need to hand in some bugreports.
<gensenx> Some are solvable by Debian people as well
<gensenx> What can be the cause of Ubuntu audit not letting the named process chroot like this: ? "Ubuntu1 kernel: [  727.509775] type=1503 audit(1225398891.177:39): operation="inode_permission" requested_mask="r::" denied_mask="r::" fsuid=112 name="/var/named/etc/localtime" pid=6375 profile="/usr/sbin/named""
<gensenx> selinux
<gensenx> the "name=" is created by root and owned by the process trying to use it
<cjwatson> I'm sorry, I'm not sure I'm making myself clear. If you are offering a patch and want to discuss its design, that's fine. If you are asking for help, this is the *wrong place*.
<cjwatson> Please use the bug reporting system.
<cjwatson> While this channel happens to be otherwise relatively quiet at the moment, we get thousands of bug reports and if everybody asked them here we would just have to move somewhere else, which wouldn't do anyone any good.
<gensenx> Yes, its very quiet so i thought i could report some errors on Intrepid
 * NCommander pounds his head against a wall
<gensenx> cjwatson: if im understanding you correctly i should be a paid coder and not a volonteer to be speaking here ?
<cjwatson> No, not at all. Plenty of volunteers talk here, but they're talking about the work they're doing on Ubuntu not using this as a bug reporting channel.
<NCommander> gensenx, no, this channel open to any developer, volunteer or coder, but the proper way to handle a bug is ti file one on Launchpad
<gensenx> Give me an example of what i could say because im not getting it ?
<gensenx> ..
<NCommander> gensenx, https://bugs.edge.launchpad.net/ubuntu/+filebug - you need to file your bug on Launchpad
<NCommander> Launchpad is the website Ubuntu Developers and contribtors use to collaborate on filing bugs.
<cjwatson> for example, on-topic conversations yesterday included whether we should be changing the default for QUILT_PATCHES to make it more friendly to Ubuntu developers working on packages maintained in quilt, and a question from one developer to another about whether a patch to fuse should be forwarded to Debian and if so what it was for so that he could write a sensible bug description
<gensenx> cjwatson: Ah, yes, i work closely with Debian people. Then i have an important issue to talk about. It seems Intrepid ibx system allows users of the system to access eachothers home directories. Is this by default ordeal ?
<cjwatson> Yes, that is intentional and has been brought up time and again in bug reports.
<gensenx> Wow :)
<NCommander> cjwatson, that's read-only, not read-write I assume
<cjwatson> of course
<jcristau> NCommander: ...
<NCommander> Good :-)
<gensenx> Holy hmm, how secure :)
<NCommander> gensenx, Debian is the same way, I have read only access to all home folders
<gensenx> Then why dont users login as eachother instead ?
<gensenx> Wow, i never seen this. what debian version are you speaking about ?
<cjwatson> I posted an extensive comment in bug 48734 and would prefer not to go over it *yet again* here
<ubottu> Launchpad bug 48734 in adduser "Home permissions too open" [Medium,Invalid] https://launchpad.net/bugs/48734
<jcristau> gensenx: all.
<NCommander> woo
<NCommander> My 100th upload!
<gensenx> I must read and cry at the same time then because this "but they are generally run by competent system administrators who know how to lock things down." comment is exactly why systems become insecure. It should be the other way around. Why not a question for this at system install and a small gui that can change this behaviour ?
<Treenaks> gensenx: Questions at install time should be kept to a minimum
<cjwatson> Security is not just about locking things down as hard as possible. If you take that too far then you find that in practice people work around the oversecurity and create problems as a result.
<cjwatson> the intrepid installer (alternate/server anyway; desktop will get this in jaunty) offers to create an encrypted private directory (~/Private/) for you
<gensenx> Sure, then add a small gui to allow or not allow users to read eachothers home directory contents. This is bad
<gensenx> Default to not allow
<cjwatson> I'm not interested in discussing it further; I've had the argument a hundred times and have arrived at this position through experience
<cjwatson> sorry
<cjwatson> you are of course quite welcome to change the default on your system if you disagree
 * NCommander personally agrees with cjwatson 
<NCommander> Once security gets to the point that your users are fighting it on a day to day basis, then you end up less secure as a result
<Treenaks> gouki_: dpkg-reconfigure adduser already has that configuration option..
<Treenaks> uhr
<Treenaks> wait
<Treenaks> he's gone, nevermind
<cjwatson> in my experience, there are two major types of multi-user systems: one is the massive shell account farm types (or university systems, or whatever) that have competent system administrators, and the other is family/friends. I'd rather work to make the latter straightforward since I think they are more common
<Treenaks> cjwatson: I agree
<cjwatson> I don't care if my wife can read my files; we trust each other :)
<Treenaks> cjwatson: as long as "the other way" is documented :)
<cjwatson> I believe there's a stock phrase for this approach, something like "crunchy on the outside, soft on the inside" (armadillos!)
<Treenaks> heh :)
<NCommander> ScottK, ping
<NCommander> cjwatson, O_O;
<NCommander> cjwatson, got time for a question or two about seeds?
<cjwatson> sure
<cjwatson> NCommander: ... only if you actually ask them though :)
<NCommander> cjwatson, sorry. In seeds, what does it mean when an item is in ( and )
 * NCommander is spliting packages out that activate hildon on lpia into properly split packages
<slangasek> hrm, why are all instances of monospace "8" being rendered funny in my browser...
<cjwatson> NCommander: the germinate(1) man page documents that, I think
<cjwatson> NCommander: but briefly, it means that they should be represented using Recommends in metapackages
<cjwatson> that syntax is only useful in seeds that have metapackages generated from them
<NCommander> ah
<NCommander> Makes sense
<slangasek> hmm, I suspect that I'm going to tire of typing the word "Jackalope" over the next 6 months
<Treenaks> slangasek: time for a new keybinding ;)
<slangasek> ctrl-meta-antlers
<Treenaks> slangasek: like a true Emacs user :)
<slangasek> yes: escape-meta-antlers-control-shift
<jdong> ok, whoever touched fontconfig is really mean :)
<jdong> skype was not happy with its apparmor profile on subsequent startup.
<slangasek> uhm?
<slangasek> jdong: apparmor is only enabled by default for specific apps that have been configured for it; how does skype fit into that?
<jdong> slangasek: that was my doing. I don't trust skype :)
<slangasek> ah
<jdong> I didn't foresee its need to regen the fontconfig cache thing though
<slangasek> doesn't /etc/apparmor.d/abstractions/fonts take care of that, or had you just not included it?
<ScottK> NCommander: Pong.
<ScottK> jdong: If you get skype figured out, please let me know.
<NCommander> ScottK, feel like sponsoring some uploads in a bit?
<ScottK> Maybe.
 * ScottK is not having a good day, so expect close review.
<bryce> whoa, alpha-1 already
<bryce> time sure doesn't stand still very well, does it
<NCommander> ScottK, question, if I'm reviewing something on REVU, and giving the second +1, and I needed the uploader to make a minor change (a clarifcation in the changelog), do I still need a second +1, or can I use the previous one?
<ScottK> NCommander: It's a judgement call.  I'd probably be OK with something that minor.  I also might just change it myself and upload.
<NCommander> I had the uploader change it for experience sake
<NCommander> ScottK, do I have to send an email to u-mout or u-devel when I sponsor a package from REVU?
<ScottK> NCommander: Yes.  Send a copy of the acceptance mail you get back to MOTU ML.  Just add REVU to the start of the subject line.  I generally clean up the formatting a bit, but that's not required.
<NCommander> ScottK, did and done
<fta> https://wiki.ubuntu.com/ <= nice
<RainCT> o.O
<fta> owned by some guy from Uzbekistan?
<RainCT> since when can pages be deleted?
<NCommander> RainCT, it wasn't deleted
 * NCommander reverts
<RainCT> NCommander: uhm.. I only see on revision in the history
<NCommander> oh, WTF
<NCommander> O_o;
<NCommander> now that's a neat trick
 * RainCT complains in #canonical-sysadmins.. but it's weekend :(
<RainCT> fta, NCommander: ok, it's already being worked on
#ubuntu-devel 2008-11-16
<candrews> Can someone help me complete this packaging process for geoclue? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505255
<ubottu> Debian bug 505255 in wnpp "[needs-packaging] geoclue" [Wishlist,Open]
<candrews> https://bugs.launchpad.net/ubuntu/+bug/260977
<ubottu> Launchpad bug 260977 in ubuntu "[needs-packaging] GeoClue - GIS Geospatial Information Service and API using D-Bus" [Wishlist,Confirmed]
 * Hobbsee wonders at the general mess of https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746
<ubottu> Launchpad bug 88746 in linux "ehci_hcd module causes I/O errors in USB 2.0 devices" [High,Confirmed]
<slangasek> superm1: looks like BuildLiveCD in livecd-rootfs still treats 'mythbuntu' as a bad project name
<superm1> slangasek, did you update livecd-rootfs?
<superm1> (0.74 is the newest)
<slangasek> I'm looking at current bzr, if that's what you mean
<slangasek> grep for 'bad project'
<superm1> current bzr should be able to do it, i updated bzr when i uploaded the latest too
<superm1> slangasek, oh i believe i see what you mean. i didn't realize BuildLiveCD was actually used-  i thought it were just an example
<slangasek> it's an example for any other users of the package; for us, it's what infinity merges onto the buildds :)
<superm1> ah :)
<superm1> slangasek, i'd think just changing that *ubuntu to *buntu would take care of it then. do you want me to make the change or will you take care of it?
<slangasek> I was suggesting that you might want to do it, but I could do it
<slangasek> I'm not sure we want to relax it so far as *buntu though, maybe just add mythbuntu to the list?
<superm1> sure that seems fine to me
<slangasek> ok, committed
<superm1> cool thanks
<alexander> I need help with SWIG, which works under ubuntu 7.04, and partially doesn't work with ubuntu 8.10.
<alexander> For example, wrapping an interface including "#include <climits>" give the error "test.h:3:22: error: climits: No such file or directory" in 8.10, while in 7.04 climits is found in the standard header directories.
<alexander> Of course I can fix this with a -I flag to SWIG, but there are more subtle problems indicating that SWIG uses different compiler settings than g++ in 8.10, although it worked in 7.04 without changes.
<alexander> Any ideas howto properly setup SWIG in 8.10, or suggestions for a better channel to ask in?
<Treenaks> alexander: what's SWIG (other than a google-polluting website), and I think it's better to ask in #ubuntu -- climits does exist if you use a C++ compiler and have libstdc++{version}-dev installed
<Treenaks> oh wait, the polluter is SWIK
<alexander> Treenaks: see swig.org  It is an interface/wrapper generator
<alexander> climits is installed and works fine with g++. But SWIG must be configured differently in 8.10 than in 7.04, as it worked out of the box in 7.04, and now I have to give a lot of options and still can't solve a few problems.
<asac> james_w: http://paste.ubuntu.com/72901/ ... want a bug?
<asac> james_w: ok. thats bug 174539 ?
<ubottu> Launchpad bug 174539 in bzr "export doesn't handle files going missing from working tree" [Low,Confirmed] https://launchpad.net/bugs/174539
<tockitj> it would be nice for ubuntu to have some system wide detailed documentation :p
<tockitj> (both from user aspect and developers)
<persia> !docs
<asac> tockitj: what documentation would a developer want that isnt available right now?
<ubottu> documentation is to be found at http://help.ubuntu.com and http://wiki.ubuntu.com - General linux documentation: http://www.tldp.org - http://rute.2038bug.com
<persia> asac, Actually, I've a fair list of stuff in that category :)  It's a slow process.
<persia> tockitj, Both are intended to exist at the links referenced.  If those aren't complete, help is appreciated to address that.  #ubuntu-docs is probably the right forum for such discussions.
<tockitj> i just think good docs would help greatly
<asac> persia: developer == packager?
<tockitj> i read tldp for greater part :p
<asac> aka ubuntu developer?
<persia> asac, developer == maintainer / ubuntu developer
<persia> tockitj, Most would agree, but it needs eyes and hands.  Help is appreciated.
<tockitj> persia, i know :/
<persia> asac, We've lots of docs, but it's not entirely well organised.  Much of the interesting bits are buried in IRC log transcripts and examples.  There's lots of places where two different pages say slightly different things that can be interpreted to contradict.
<tockitj> but 90% of my free time is allready dedicated to various comercial projects.. i dont see space there for software freedom fighting
<persia> asac, Anyway, most of the answers end up coming on on IRC, but ideally we'd have the answers all in the wiki.
<asac> persia: yeah
<asac> persia: i think wiki is a problem here
<asac> hard to keep up to date
<asac> and also hard to keep branches (e.g. gutsy, hardy, intrepid)
<persia> tockitj, Well, it's what you have time to do.  The log of this conversation won't add much to docs though.
<tockitj> true :-)
<asac> what we would need is a documentation package with all the documentation and maybe a doc reader app
<tockitj> thanks for info, cu
<asac> so for each and every release, we can go through the complete documentation and remove rotting things
<persia> asac, That too.  There's a cleanup effort around UDS every cycle, but sometimes useful stuff gets dropped (e.g. we still have patches from the Ubuntu X transition in Hardy/Breezy that haven't been uploaded again, but we no longer have the page explaining the point of the transition, which confuses some mergers).
<persia> (or at least there was during the Edgy, Feisty, Gutsy, Hardy, and Intrepid cycles, but that's mostly because the wiki didn7t get too messy until later Dapper)
<asac> persia: no clue about developer documentation. i just know that i never find anything in wiki ;)
<asac> persia: what i know though is that the user documentation for networking is kind of a mess ... and i just learned about that right before release
<persia> asac, Yeah.  help.ubuntu.com needs a deep sweep.  It's probably worth organising someting where a couple developers for each area work with the docteam to help get that area correct for Jaunty.
<asac> persia: hmm. Not really convinced. we need something to keep branches. afaik that isnt possible on help.ubuntu.com.
<asac> but yeah. we need dedicated resources for user doc
<asac> at least temporarily dedicated ;)
<persia> We have those.  The docteam.  It's just that as we've grown, the teams don't collaborate as much, so there's a bit of a disconnect between ubuntu-dev and docteam.  docteam ends up playing catch-up.
<persia> Just having each dev spend three-four days reviewing and discussing issues with areas they know well with the docteam would be a *huge* benefit.
<persia> I don't think we need more than that really.
<persia> If it's repeated every cycle, we ought have first-class documentation again.
<mysteryc> Hi.
<mysteryc> Since last year you people developed a newer version of Xorg and since I downloaded it through the update manager, my screen is always messed up. Not it's totally messed up as it only has option for 800 x 600 resolution! :/
<Treenaks> have you asked on #ubuntu ?
<mysteryc> Yes, Ive been askin for the past month, from the day that I booted and my screen was somehow set at 800x600 :s
<mysteryc> And it's still not fixed.
<mysteryc> And I had to get back on windows again cause it's SO annoying, and windows is all laggy and not responding and stuff cause I can't fix the resolution.
<jardi> hi all
<jardi> I have made some change to the guest session scripts in order ton make it use the /etc/skel dirrectory to create the new temp home folder
<jardi> I wanted to submit it to you guys and made a bug report with my patch
<jardi> but I have not received any response in a week, am I doing it wrong ?
<jardi> here is the link to this bug report : https://bugs.launchpad.net/ubuntu/+source/gdm-guest-session/+bug/296993
<ubottu> Launchpad bug 296993 in gdm-guest-session "guest session doesn't use files in /etc/skel to create new user's home" [Undecided,Fix committed]
<jdong> jardi: no you aren't doing anything wrong; just Martin Pitt is a really busy guy :)
<jdong> jardi: it'll get looked at eventually. Did you set the bug to fix committed?
<jdong> (I wouldn't recommend doing this -- fix committed is for when the fix is actually put into Martin's bzr branch and pending upload)
<mophiax> Excuse, but when are there going to be the blueprints for 9.04?
<jardi> thanks jdong, I did but the bug status to fix commited, what state do you suggest, there is no state "fix proposed"
<jdong> jardi: Confirmed is probably the best status right now to put it as, or Triaged
<cjwatson> don't worry about the status, we track patches separately
<jardi> thanks all
<martikka> Would anyone know the current status of defoma? Is it still planned to be used in font (ttf) packaging?
<martikka> or is the "defoma-hints truetype" going to be fixed at some point?
<dethklok> hi
<dethklok> I need help with my ubuntu install.
<dethklok> I am trying to run and assembly some assembly code but it won't work it needs the i386
<dethklok> is there a way to emulate and run in 32bit mode on a 64 bit installation or do I need to reinstall 32 bit ubuntu?
<cjwatson> dethklok: sorry, this channel is for developing Ubuntu itself, not for offering help for people developing on Ubuntu. As a starting point, gcc -m32 is probably the kind of thing you're looking for, but please don't ask about it further here
<maco> Can anybody tell me what version of libusb will be in Jaunty?  Version 0.9 is a requirement for some fairly common fingerprint readers' drivers, but it's not in sid yet, so...
<maco> bug 163156 is open on one of those fingerprint readers
<ubottu> Launchpad bug 163156 in linux-source-2.6.22 "UPEK TouchStrip 147e:2016 not supported at all" [Undecided,Won't fix] https://launchpad.net/bugs/163156
<maco> uh, it's also on "linux" as "triaged"...ubottu just only showed the gutsy one
<maco> for clarity, libusb-1.0 is the official requirement, but 0.9 is what they called 1.0 beta, and it includes the hooks the driver needs
<maco> doh, im sorry, ignore me. i didnt realize there's a package name change when this occurs, so there's a libusb-1.0 package in jaunty already and i can go away and stop annoying you all
<andrews> I have an idea to start or help with a project to make partition clone software run in an easy to use gnome interface.  I am new to developing and would need lots of help.  Does anyone here now where I could start.
#ubuntu-devel 2009-11-09
<starek> hi
<starek> what compiler is suggested for java
<starek> gcj or something else?
<starek> if its gcj why is it so damn slow
<starek> i understand it is being used as the default java interpreter
<directhex> starek, openjdk's javac, i think
<directhex> starek, there's some kind of default compiler metapackage
<starek> yeah
<starek> thats gcj
<starek> why is it so slow
<starek> 2ghz, 2gb ram laptop
<starek> damn thing drags
<directhex> Depends: default-jre (= 1.6-30ubuntu5), openjdk-6-jdk (>= 6b11)
<directhex> looks like openjdk to me
<starek> ok but any idea why this is so slow
<starek> ive switched to javac actually
<starek> thanks directhex
<twb> Is there an article on the wiki that tells me how to write a new blueprint?
 * twb looks...
<twb> #launchpad tells me there's no such article.
<pitti> Good morning
<pitti> bigon: ah, thanks; and, yay for it catching regressions already :)
<dholbach> good morning
<fagan> Morning
<bigon> pitti: about the check for gupnp-igd? I've already told upstream the checks doesn't pass
<pitti> bigon: right; they do pass with the karmic version
<pitti> thanks
<mattn_> good morning
<mattn_> i've just updated my ubuntu box @work
<mattn_> and now i can't click the task panel applications with my first left click anymore
<mattn_> i first have to right click an application, then i can left click again
<maco> file a bug?
<mattn_> any ideas how to fix it?
<mattn_> i thought it is maybe already known
<mattn_> as it's the second box i've updated and it happened on both of them
<maco> http://bugs.launchpad.net/ubuntu/+bugs
<maco> youch
<apw> mattn_, where did you upgrade from?  cirtainly not seen that behavior
<mattn_> apw, update manager
<apw> i mean which release did you upgrade from
<apw> and do you mean that you have to always click right then left works, or just one right in the bar is enough to sort it out
<maco> and was this a normal update or a one release to the next upgrade?
<maco> and do you have -proposed enabled?
<mattn_> 9.04 => 9.10
<mattn_> no, proposed is not activated
<mattn_> maco, one release to the next
<mattn_> apw, before the left clicks are working again, i have to right click the app (in the panel)
<mattn_> alt+tab works fine
<maco> and is this laptop with touchpad, or are you using a normal mouse?
<mattn_> just switching via mouse isn't working
<mattn_> normal mouse
<mattn_> on both of the affected machines
<mattn_> and both were an update from 9.04 to 9.10
<mattn_> i didn't play with any "low-level" gconf stuff
<apw> mattn_, so i hear you saying that each and every left click in the panel you need to do a right click
<mattn_> if that matters ;)
<mattn_> no, not everyone - sometimes it works (but not very often)
<apw> mattn_, are you also finding that left click works everywhere else?
<mattn_> no, some other gtk components are not working via mouse, too
<ajmitch> mattn_: file a bug, it's something that I've seen on 1 karmic install as well
<mattn_> some buttons in some applications only listen to an activating via space or enter
<mattn_> e.g. on my work machine it's eclipse that isn't working as expected for some buttons
<mattn_> and now it worked 5 times ok, then it stopped working again - really strange
<mattn_> nothing i can nail it down to
<mattn_> already tried to reboot and so on
<mattn_> i'm not even sure how i should create a reasonable bugreport for this
<apw> you can really only describe it as clearly as possible.  "left clicks not always functional" or something, but do clearly state is multiple applications and that its intermittent and what you can do to make it start working again
<apw> it would be worth doing an xev and recording its output
<maco> mattn_: ajmitch just said he's seen it before. he may have some insight
<apw> and then do a series of left clicks there
<ajmitch> maco: I wish I did, I haven't had a chance to look into it
<apw> also check dmesg, to see if there is any mouse errors, sometimes we lose sync with mice
<apw> as its all applications which are affected i'd probabally file it against the kernel with ubuntu-bug linux, and then 'we'll' ask for the dmesg and xev tests which hopefully can tell us if its kernel or not
<apw> if not we'll pass it to X for further diagnosis
 * ajmitch has only noticed it on gtk+ apps, mostly the panel 
<ajmitch> I don't think it'll be a kernel issue
<siretart`> I note messages during upgrade like this: "Package foo should be rebuild with new debhelper to get trigger support" it seems to relate with install-info. however, debhelper seems up-to-date
<siretart`> any ideas what package needs merging/fixing?
<dholbach> siretart`: could be that those packages have "old maintainer scripts" and thus need a rebuild with the new debhelper?
<siretart`> dholbach: I don't think so. I'm seeing this with my last emacs22 upload a few hours ago to lucid
<dholbach> ah ok
 * dholbach shrugs then
<soren> siretart`: Does it use dh_installinfo, or does it add install-info calls "manually" to postinst?
<soren> That error message comes from install-info.
<soren> If it gets called from a maintainer script, it will echo that warning, because since debhelper 7.2.17, dh_installinfo does not add a call to install-info, but relies on a trigger to handle that.
<soren> siretart`: I just checked. It does call install-info manually.
<siretart`> but it also ships with a dh_installinfo -a call in debian/rules
<siretart`> so it seems to do both
<soren> siretart`: Yeah, I don't know how it's supposed to work when you want to pass extra options to install-info.
<siretart`> hm. let's see if this happens in debian as well
<soren> siretart`: I'm quite sure it will. See changelog entry for 7.2.17 in debhelper.
<siretart`> hm
<siretart`> why didn't this hit us in karmic as well, but just in lucid?
<soren> siretart`: The texinfo change happened rather late, apparantly.
<soren> Tue, 20 Oct 2009 18:28:40 +0100
<siretart`> so the "bug" is already in karmic, but we just didn't notice
<soren> Yes.
<soren> Oh.
<soren> Tue, 20 Oct 2009 18:28:40 +0100   was time of upload..
<soren> Build: #  Finished on 2009-10-27  (took 3 minutes, 6.7 seconds)
<soren> (for amd64)
<soren> About the same for i386.
<cjwatson> siretart`: yes, just stop using install-info in the maintainer scripts
<cjwatson> cody-somerville: I've promoted diffutils to main, which should fix that particular debootstrap breakage
<soren> If you need to pass special options to install-info, you seem to have to use ginstall-info.
<soren> siretart`: ^
<siretart`> ok. made a mental note
<soren> cjwatson: Unless you know of another way to do so after this change?
<cjwatson> soren: I thought in most situations it was possible to put the necessary information in the info file header to be more trigger-friendly
<cjwatson> we definitely don't want to encourage lots of packages calling [g]install-info directly, AFAIK
<soren> cjwatson: Alright, thanks.
<soren> Keybuk: Are you planning on a UDS session about network configuration in the brave new world of upstart?
<A1Multi> does anyone know how to get nvidia drivers to work with ubuntu when using Sun Virtual box?
<Keybuk> soren: no?
<soren> Keybuk: Hm. Ok.
<ogra> did anything change with networking ?
<ogra> i mean from a users perspective
<Keybuk> users use network manager
<Keybuk> so no ;)
<soren> Some users do.
<soren> ogra: Yes.
<highvoltage> that seems like quite a random arb question :)
<ogra> well, NM is used as well as /e/n/i ...
<soren> ogra: Like, for instance, bonding used to work most of the time.
<ogra> i dont see where upstart comes into play
<ogra> and it doesnt anymore ?
<soren> ogra: Due to lots of stuff being upstartified in Karmic, the order in which certain things happens has changed.
<Keybuk> soren: but bonding still works
<soren> Keybuk: I'm not going to discuss this again.
<ogra> right, but if something is broken due to that, thats a bug
<Keybuk> soren: but you started the discussion
<soren> Keybuk: I'm stating facts.
<soren> Keybuk: Not theory.
<Keybuk> no, you asked if there was going to be a discussion
<soren> Yes, it's racy now, and it was before.
<Keybuk> which, if you're not going to discuss it, is a bit ... contrary
<soren> Keybuk: At UDS.
<slangasek> soren: so put a blueprint on the server track?  I would try to attend, certainly
<soren> Keybuk: I'm not going to discuss it /here/, just with you, again.
<soren> At UDS, certainly.
<slangasek> I don't think this is a topic that requires a lot of discussion from a lot of people; it really just needs one bugfix
<Keybuk> if you want a session on server boot-time network config, add it to the server track?
<soren> slangasek: Oh, really? What might that fix be?
<slangasek> soren: "make it not racy"
<Keybuk> the obvious fix for me is that ifup eth0 should bring up any bonded interfaces attached to eth0
<Keybuk> (provided the other bits are up)
<slangasek> is ifup reentrant?
<Keybuk> no idea
<Keybuk> it's written in LaTeX, so that's probably "Chapter 4" :)
<soren> slangasek: Well, if you guys know how to "make it not racy", there's no point in my driving a discussion about it.
<slangasek> at a high level, yes, I know how to make it not racy - the bonding interfaces need to be event-driven in the same way other interfaces are.  Keybuk's suggestion is one possible solution, if it works
<slangasek> if you think it needs to be discussed, I'm happy to discuss it
<cjwatson> IIRC I've used ifup in a post-up hook in the past
<slangasek> ok
<soren> I think I've tried that, and it didn't work.
<soren> I think it logs /var/run/network/ifstate or whatever it's called.
<soren> Err.. /locks/
<cjwatson> it locks it briefly when updating it, but from a cursory glance through the source it does not appear to lock it for the duration of ifup's execution
<cjwatson> ICBW of course
<Keybuk> cjwatson: I think it used to, and I fixed that
<soren> Ah.
<soren> I kind of thought it was on purpose.
<slangasek> soren: what might make a good UDS topic (IMHO) is "what are the things that upstartification breaks on the server?" - that way we can get out on the table all the issues anyone has run into, and we can make sure they *all* get dealt with for lucid
<soren> slangasek: I would love to get this all solved. I just don't want to have the same type of discussion we had two weeks ago.
<soren> "The only winning move is not to play"
<Keybuk> pitti: how can I turn off the apport "serious kernel problem" thing?
<pitti> Keybuk: it should already be turned off in kerneloops-daemon 0.12+git20090217-1ubuntu4.1
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=daemon
<pitti> Keybuk: i. e. in karmic-updates
<Keybuk> ah ok
 * slangasek points and laughs at ubottu's clumsy attempt
<Keybuk> I'm sick of being told that my BIOS has ECC disabled by default ;-)
<pitti> that's yet another bug which should be addressed in current karmic-proposed linux
<qense> Do XID collision kill you or what does it else?
<qense> GDK seems to be frightened by such error messages
<Keybuk> slangasek: it looks like universe has finished
<Keybuk> urgh
<Keybuk> ValueError: process failed 9: dpkg-source -x quilt_0.48-2.dsc
<Keybuk> +/srv/patches.ubuntu.com/unpacked/q/quilt/0.48-2
<Keybuk> Format: 3.0 (quilt)
<Keybuk> slangasek: looks like the first v3 source packages have hit testing
* Keybuk changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM up to date as of Monday 4am, but now stalled | 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
<mvo> james_w: is there a way to ask merge-package for different merge strategies (like --lca)? I tried it on "shadow" and got a suboptimal merge
<al-maisan> mvo: merge-package does not support that option yet but could be be made to do so.
<mvo> al-maisan: ok, thanks
<mvo> dpm: can I pester you about nightly bzr exports of the ddtp translations project via launchpad? sianis is very keen on getting it to implement "nightmonkey" to make the whole translation experience for package descriptions easier
<mvo> al-maisan: another very nice option would be to have bzr-buildpackage somehow figure out that it was a merge and add the right -vlast-ubuntu-version
<mvo> dpm: along the same lines, bug #374765 is also problematic for nightmonkey
<ubottu> Launchpad bug 374765 in rosetta "Wrong string order in po file after export" [Medium,Triaged] https://launchpad.net/bugs/374765
<mvo> al-maisan: I get a lot of "Conflict adding files to po. Moved to root. errors - do you a suggestion what is causing this?
<al-maisan> mvo: sorry, I am busy with diagnosing a package set problem. Can I get back to you later?
<mvo> al-maisan: sure, no urgent at all
<mvo> al-maisan: I can also talk to james_w when is is around
<al-maisan> yes, that's right.
<dpm> hi mvo, sorry for not replying earlier. First of all, regarding the bug, yeah, I'll ping danilo and the other guys to have a look at it. Or perhaps a better idea would be to mentor sianis to fix it himself, now that LP is opensource.
<dpm> mvo re: the nightly bzr exports of the ddtp translations project, bzr exports for source packages are not yet implemented in LP, only for projects
<dpm> what is he trying to implement which would need the exports?
<dpm> Perhaps there is a better way using some of the existing features
<mvo> dpm: its a export of a project he needs, but its currently not working because of the amount of strings in the ddtp project
<ScottK> pitti: The powerpc, ia64, and sparc uploads for the kdebase-workspace SRU (Karmic) that you accepted earlier today failed to upload. LP has no upload log. This is somewhat concerning since it was fine the last pre-release upload. Suggestions on who I should talk to about this?
<dpm> mvo, ah, I see, yes, it's https://translations.edge.launchpad.net/ddtp-ubuntu. This should be filed as a support request (https://answers.edge.launchpad.net/rosetta/+addquestion) if it's not working, so that the LP devs can look at it in detail. sianis, do you think you could do that?
<pitti> ScottK: I'd start with al-maisan or bigjools on #launchpad
<ScottK> Thanks.
<pitti> ScottK: (I'm afraid my powers don't reach into the inner workings of soyuz :( )
<Keybuk> james_w: I guess we still can't use lp:ubuntu/karmic/PACKAGE for our own packaging branches?
<ScottK> pitti: Right.  I thought it was something I ought to at least make you aware of.
<pitti> thanks; I didn't hear about this before indeed
<geser> ScottK: know problem, bigjools is working it (it also affects normal and PPA builds)
<ScottK> geser: Is there a bug?
<sianis> dpm: I think so
<geser> ScottK: I don't know of one
<ScottK> geser: Thanks.
<ScottK> dpm: Have a moment?
<dpm> ScottK, sure, go ahead
<ScottK> dpm: I noticed with the kdebase-workspace upload to karmic-propsed that I was just discussing I got the usual flood of translation import messages.
<sianis> dpm: https://answers.edge.launchpad.net/rosetta/+question/89334 - is it enough?
<ogra> Keybuk, seems there is another mountall race in bug 435228
<ubottu> Launchpad bug 435228 in ltsp "ltsp doesn't boot due to mount errors in initrd" [Undecided,Fix released] https://launchpad.net/bugs/435228
<ScottK> dpm: Since -proposed is an area for testing, sometimes packages fail testing and never make it into the archive.
<Keybuk> ogra: "in initrd" => NOT MOUNTALL!
<ScottK> dpm: It seems to me that -proposed ought not be used for translation imports since that may leave them out of sync with what is finally delivered to end users.
<ogra> Keybuk, http://launchpadlibrarian.net/32307916/ltsp_2.png
<dpm> sianis, that's good, thanks
<pitti> lamont: seems that crested fell into the digest mismatch problem again; can you please nudge it back to work?
<Keybuk> ogra: fun, got a patch? :)
<ogra> Keybuk, nope, no idea whats going on there yet
<ogra> i'll try to find out though ... there are some reports on the ltsp mailing list that it's not reliable reproducable ... does apparently only happen one out of ten boots or so
<dpm> ScottK, hmm, that's a good point, but there are two other points that come to mind here: in principle uploads to -proposed shouldn't be changing strings (or unless not without notifying translators), and sometimes uploads to -proposed are indeed fixes to strings (in which case we do want the new strings in LP)
<ScottK> dpm: True.  Except what if you change the string and then the update gets rejected for other reasons?
<ScottK> It would seem to me you'd want to know it was going in the archive.
<Keybuk> ARGH! My coffee machine stopped working after I upgraded my laptop to karmic!
<Keybuk> CANCEL THE RELEASE!
 * Keybuk finishes catching up with ubuntu-devel-discuss
<ScottK> geser: Looks like it's fixed now.
<dpm> ScottK, I don't have a definitive solution for this other than letting the translations team know: if an upload to -proposed modified strings in a template and was later rejected, those rejecting it should notify the translations team, who can then manually upload the old template back without requiring a package upload
<ScottK> dpm: I think any solution that relies on developers remembering to tell translators about unusual things is doomed to fail.
<dpm> ScottK, yes, I agree :) I'm also for automatic solutions
<dpm> but I thought uploads to proposed
<dpm> might be something that gets more review before getting uploaded
<dpm> so any string changes are accepted/rejected before the upload
<ScottK> dpm: We upload to proposed for testing and even with all the review before hand, it doesn't always go well.
<dpm> ScottK, but I agree that it makes sense to discuss it
<cjwatson> dpm: while it's true that they get review, I'm not sure how to glue that together with translation workflow
<dpm> cjwatson, I was not implying that they do not get review, sorry if it came across that way
<cjwatson> I know you weren't
<dpm> ok
<ScottK> dpm: In any case, I think it's something to look into.  I'd wait for it to hit updates, but I don't pretend to understand all the translation stuff.
<ScottK> geser: Looks like it's fixed.
<dpm> ScottK, cjwatson there are guidelines on freezes, which mention what to do on string changes. I'm wondering, are there similar guidelines for reviewing uploads to -proposed, in which we could add a note on translations? I know it wouldn't be the definitive solution, but I'm up for anything that raises the awareness on translations
<dpm> ScottK, in any case it might make a good topic for a discussion at UDS
<ScottK> dpm: OK.  You should talk to the translation guy about scheduling it. ;-)
<dpm> yeah, I wonder who that is ;)
<cjwatson> dpm: StableReleaseUpdates
<dpm> ah, thanks. I'll make some notes on translations and send them to the ubuntu-sru team for review
<dpm> sianis, mvo re bug 374765, danilo tells me that it is due to another underlying bug, which is somewhat critical and he'll be working on this asap. If fixing the underlying bug does not work, he'll then look into the other one.
<ubottu> Launchpad bug 374765 in rosetta "Wrong string order in po file after export" [High,Triaged] https://launchpad.net/bugs/374765
<dpm> If you want to keep track of it, it is bug 401618 (note that it doesn't have a milestone yet, since they only assign them when they actually start working on a bug)
<ubottu> Launchpad bug 401618 in rosetta "Remove [I]POTMsgSet.sequence" [High,Triaged] https://launchpad.net/bugs/401618
<pitti> apw: so my request for more debugging in bug 429257 spawned off two new bug reports which are completely unrelated; I'm afraid I need you to run the procedure as well
<ubottu> Launchpad bug 429257 in gvfs "MMC cards no longer auto mount" [Undecided,Incomplete] https://launchpad.net/bugs/429257
<mvo> dpm: thanks!
<apw> pitti, so you want me to file a new bug yes?
<pitti> apw: well, ubuntu-bug does it that way
<dpm> mvo, np :) danilo also tells me that he'll get in touch with you re: ddtp exports
<pitti> apw: alternatively you can do udevadm monitor -e --udev and devkit-disks --monitor-detail manually and attach the logs
<apw> hrm ... just worked for me
<pitti> apw: (the symptom does that for you)
<pitti> symptom apport script, I mean
<starek> hi
<starek> anyone familiar with CBQ / HTB
<tseliot> cjwatson: if I do something like "ls /boot/" in a package script (e.g. postinst) and the package is installed in a buildd I would get the content of the boot directory in the chroot, right? (just to be sure)
<starek> iwas wondering if there are any front ends to configure them
<cjwatson> tseliot: yes
<tseliot> cjwatson: ok, thanks
<apw> pitti, ok both sd and sdhc cards are being mounted just fine as of 'now'
<starek> any ideas
<pitti> apw: nice
<pitti> apw: perhaps it was yet another instance of the "break the world" bug 463347..
<ubottu> Launchpad bug 463347 in udev "devices not detected -- too many open files" [High,Fix released] https://launchpad.net/bugs/463347
 * apw looks
<starek> ive been googling for a bit
<starek> and kinda out of luck
<Keybuk> pitti: how do I make bug #479207 get retraced?
<ubottu> Launchpad bug 479207 in dbus "dbus-daemon assert failure: *** glibc detected *** /bin/dbus-daemon: free(): invalid next size (fast): 0x01606ed0 ***" [Medium,Confirmed] https://launchpad.net/bugs/479207
<hyperair> run apport-retrace?
<Keybuk> hyperair: that involves downloading loads of stuff
<Keybuk> we have an automatic retracer, no?
<hyperair> oh yeah the apport retracing service or something of that sort
<hyperair> i think if you wait it runs automatically, though i could be wrong.
<pitti> Keybuk: the reporter apparently uploaded a "reduced" report  without a core dump, so it can't be retraced
<Keybuk> how do they do that?
<Keybuk> -> invalid then ;)
<pitti> there is some logic which tries to judge whether the user-generated stack trace is "good enough"
<pitti> which apparently spectacularly failed here
<pitti> if there are enough known functions in the trace, it offers this in the details dialog
<pitti> Keybuk: yeah, invalid sounds correct
<starek> anyone pls reply
<starek> :/
<ScottK> pitti: Now that the upload failure in Soyuz is fixed, I went through and retried all the packages that failed because of it.
<pitti> ScottK: wow, that was fast; they cherrypicked a fix?
<ScottK> pitti: "<bigjools> well, cowboyed pending a proper fix"
<qense> Recently something regarding suspend_text() was fixed, probably in -proposed. Does anyone know what it was again?
<Riddell> asac: ping
<LaserJock> james_w: around?
<james_w> hi LaserJock
<LaserJock> james_w: is there a channel for distributed devel?
<james_w> you could jump in #ubuntu-bzr
<LaserJock> james_w: I'm there (all by my lonesome)
<james_w> LaserJock: are you sure?
<LaserJock> james_w: in #ubuntu-bzr
<LaserJock> bah
 * LaserJock stabs empathy
<qense> #ubuntu-bzr doesn't seem to be a registered channel
<asac> Riddell: hi
<asac> Riddell: firefox kde spec?
<Riddell> asac: that was the question
<Riddell> asac: worth scheduling one?
<asac> Riddell: i think its definitly worth scheduling one
<Riddell> ok will do
<asac> Riddell: will you add a spec? maybe also refer to the other spec we had once ... so we can check if the suse patches have everything we thought abuot that that point
<Riddell> asac: yes
<Vorador> Hi. Could someone help with PPA builds? The problem is that the build-bot installs the wrong version of software (I have the needed version in my ppa already built, but it installs ubuntu version instead) and package building fails because of that. Build log -> http://launchpadlibrarian.net/35424976/buildlog_ubuntu-karmic-lpia.audacious-plugins_1.5.1-2ubuntu3~ppa1_FAILEDTOBUILD.txt.gz Package list -> https://launchpad.net/~sandshrew/
<Vorador> +archive/ppa/+packages
<Keybuk> slangasek: bug 426027
<ubottu> Launchpad bug 426027 in util-linux "/dev/disk/by-uuid doesn't exist in karmic kernels" [High,Triaged] https://launchpad.net/bugs/426027
<Keybuk> you say "Given that upstream has a fix for this, we should certainly apply this to karmic via SRU."
<Keybuk> unfortunately the "fix" is after a near-rewrite of blkid ;)
<Ng> Keybuk: is it something that can be detected prior to upgrading?
<Ng> I mean detected and fixed
<Keybuk> Ng: fixing involves dd over partitions
 * Keybuk gets scared
<Ng> not fixing involves an inability to boot, which is also kinda scary
<Ng> and at least pre-upgrade the thing is in a known-good state
<Ng> even just saying "sorry, you can't upgrade" would be better than the current situation
<Ng> imho :)
<Riddell> doko: ping re gdb 7.0/6.8
<Keybuk> whee
<Keybuk> 2,400 unread mails now read
<sebner> Keybuk: hey, indicates you are a social being with many friends and fans. congratulations! ;D
<cking_> Keybuk, you mean you've redirected 2,400 mails into /dev/null?
<Keybuk> sebner: no, just someone who gets subscribed to logs of bugs
<sebner> Keybuk: you are mean, look at the brigth side :D
<sebner> hoi jono =)
<jono> hey sebner :)
<zul> james_w: can you import samba please? thanks!
<lamont> smb: for the lols: crossgrading to amd64 fixes karmic for 445456
<lamont> apparmor.d/libvirt/libvirt-54b68396-8493-97f7-c78a-ac9a74684ddb <-- wtf?
<smb> lamont, the last thing maybe jjohansen knows
<lamont> those are 2 totally unrelated comments, fwiw
<jjohansen> lamont: give me a sec
<lamont> anyway, somewhere in karmic, the jaunty regression that the CVE fix uncovered got fixed.  Meanwhile, karmic/i386 hates booting windoze differently
<sbeattie> lamont: jdstrand added per vm apparmor profile generation to libvirt.
<lamont> karmic/amd64 was on the plate for a while, so I spent a couple hours yesterday doing the crossgrade
<lamont> sbeattie: ok, just per-vm, not per-invocation.. much better
<jjohansen> lamont: jdstrand has add some AppArmor libvirt wrappers
<lamont> mdeslaur: most of postfix should be confinable - just local and it's friends should have issues, no?
<sbeattie> lamont: that's my understanding, but at the moment, my knowledge of libvirt is doing there is theoretical only
<lamont> sbeattie: heh
<lamont> smb: so short answer is that I'm less interested in the bug now, since I haz working windoze again
<mdeslaur> lamont: I haven't looked at the issue, I'm just quoting the fedora page
<smb> lamont, The other thing not surprisingly because the problem seems to be related to setting 64bit flags on 32bit
<lamont> mdeslaur: we can spend some time in dallas staring at it
<smb> lamont, Would you still be able to run test kernels for me?
<lamont> most of the postfix daemons should be very constrainable
<lamont> smb: yeah
<smb> lamont, Great. I have something built (but not tested and uploaded) Maybe a bit later
<lamont> smb: the biggest challenge is that the early karmic kernels don't work with jaunty or karmic userspace very well...  that was when I gave up on bisecting karmic and through some total entropy into the problem by booting the amd64 livecd
<mdeslaur> lamont: with libcap-ng? or are you talking about apparmor?
<lamont> apparmor
<lamont> haven't looked at libcap-ng
<lamont> mdeslaur: or were you talking about libcap-ng?
<lamont> most of the postfix daemons have very specific things that they do, and files/directories that they should touch.  local is the glaring exception of the tip of my head
<lamont> (mixed metaphors are just so much fun...)
<mdeslaur> lamont: yeah, we were talking about libcap-ng: http://fedoraproject.org/wiki/Features/LowerProcessCapabilities
<lamont> ah, more reading.  kthx
<lamont> smb: will be afk most of the day, starting in about 5 min
<lamont> or less
<smb> lamont, As it seems less urgent for you, it can be tomorrow too
<Keybuk> slangasek: I learned debhelper %: dh $@ thingy
<Keybuk> slangasek: I was disappointed that it doesn't help take care of the whole CFLAGS/--build/--host thing in *any way* :-(
<Keybuk> which is by far the largest and ugliest bit of debian/rules
<maco> haha
<lamont> yeah - it's a non-issue for me now.  at some point, I'll migrate the i386 karmic boot tree to not be where it is today, and then things will be simpler.
<cjwatson> Keybuk: it really should; dh_auto_configure takes care of --build/--host
<Keybuk> cjwatson: yeah, but dh_auto_configure has joey's idiotically wrong idea of flags to pass to configure
<Keybuk> so it'll fail on any up to date package due to the unknown options
<cjwatson> really? which ones? I haven't run into any problems
<cjwatson> oh, apart from the one that he took from cdbs, which was wrong
<Keybuk> it unconditionally passes --disable-maintainer-mode and --disable-dependency-tracking iirc
<cjwatson> #541458
<Keybuk> which don't even exist
<cjwatson> doesn't configure just ignore those?
<Keybuk> no, not anymore
<Keybuk> autoconf stopped ignoring unknown options a while back
<maco> ew
<cjwatson> hm, well dh_auto_configure doesn't break on any autoconf-up-to-date package for me
<cjwatson> but YMobviouslyV :)
<cjwatson> have you filed a bug already, or shall I?
<Keybuk> cjwatson: if you could
<cjwatson> looks like he took those two from cdbs as well
<cjwatson> /usr/share/cdbs/1/class/autotools-vars.mk has the exact same thing
<cjwatson> ok, will do so in a bit
<Keybuk> I was also vaquely wondering whether --localstatedir=/var shouldn't be --localstatedir=/var/lib
<Keybuk> but I can't remember which was right
<cjwatson> if you have any references to send me it wouldn't hurt
<cjwatson> localstatedir's default is ${prefix}/var
<cjwatson> but of course that's for the /usr/local layout
<Keybuk> info Autoconf => Site Configuration => Option Checking
<Keybuk> I'll dig up the ref that these are turning into errors now as well
<Keybuk> they are already in git
<Keybuk> (since AC_CONFIG_SUBDIRS does the right thing)
<cjwatson> ah, so by "a while back" you mean "after the last release"? :-)
<Keybuk> they've been warnings for a while already
<Keybuk> which is supposed to be a hint that what you're doing is deprecated
<cjwatson> yeah
 * Keybuk is trying to remember
<Keybuk> if you do
<Keybuk> dh_auto_configure -- CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" --wuth-foo
<Keybuk> whether it needs to shuffle the arguments such that the variable setting ones happen before any others
<Keybuk> (I don't think it does looking at the configure code)
<Keybuk> pitti: I'm not following you on bug #479206
<ubottu> Launchpad bug 479206 in udev "USB flash drive does not mount automatically" [Undecided,Incomplete] https://launchpad.net/bugs/479206
<Keybuk> I can't see why you think there's a udev bug
<tag> Anyone have any ideas about #463199 (java6 segfaulting on karmic 64bit with any swing app)
<tag> Seems like #305551, #479143 and #204193  are the same issue.  The later is quite old.  Switching the AWT_TOOLKIT environment variable seems to fix it.
<cj> hey all
<cj> how do I install packages with init scripts in karmic with chroot?  Specifically, the ones that require a running upstart
<tag> Also changing the look and feel to GTKLookAndFeel seems to bypass the problematic code
<ebroder> cj: (a) this isn't a support channel (b) http://www.ubuntu.com/getubuntu/releasenotes/910#Upstart%20jobs%20cannot%20be%20run%20in%20a%20chroot
<tag> or maybe not, maybe it's only awt
<tag> MToolkit errors this way, XToolkit does not
<cj> ebroder: sorry to trouble you.  thank you.
<lifeless> dtchen: you were helping folk with intel hda audio issues right? is there a good reference page...
<TheMuso> lifeless: Depends on what the issue is.
<geser> ScottK: didn't you want to retry all "Failed to upload" after todays fix? Could you (or any other core-dev) please give-back: apt-setup libcarp-clan-perl libclass-accessor-perl libxml-sax-machines-perl nagious-images tar
<geser> I've already gave back the ones from universe listed on the FTBFS page
<ScottK> geser: I thought I got them all.  Please link me.
<geser> ScottK: apt-setup libcarp-clan-perl libclass-accessor-perl libxml-sax-machines-perl nagious-images tar
<ScottK> I didn't see any of those in the buildd logs.
<ScottK> I"m pretty sure those aren't from today, but I'll check at least a sample.
<ajmitch> https://edge.launchpad.net/ubuntu/+source/apt-setup/1:0.42ubuntu1/+build/1337535 ise certainly a "failed to upload"
<ajmitch> what was the cause of that?
<ajmitch> it says it was 9 hours ago, fwiw
<geser> ScottK: they are listed on http://qa.ubuntuwire.com/ftbfs/ and "failed to upload" partly already last week after the rollout
<ScottK> LP being broken
<ScottK> geser: OK.  I'll look.
<geser> the LP rollout
<ajmitch> ScottK: did you just retry apt-setup?
<ScottK> ajmitch: Yes
<ajmitch> ok, explains why it tells me it can't be retried now
<lifeless> TheMuso: poolies mic isn't working in karmic, on his ibm latop
<geser> they got hit by bug #476316 for which bigjools cowboyed a fix today
<ubottu> Launchpad bug 476316 in soyuz "Slony-I: Table emailaddress is replicated and cannot be modified on a subscriber node (dup-of: 464161)" [Critical,In progress] https://launchpad.net/bugs/476316
<ubottu> Launchpad bug 464161 in launchpad-foundations "authdb Store for scripts connecting to incorrect database" [Critical,Confirmed] https://launchpad.net/bugs/464161
<TheMuso> lifeless: ah ok.
<lifeless> james_w: you say on the list that you can promote packaging branches to be official; how do we make this happen - just mail you ?
<ScottK> geser: I think I got them all.  Thanks.
<RaXOR> hi 2 all, i've loggined into this room with my little idea is to join a developers team of ubuntu soft fo gnome or kde(qt libraries)... who can help me to get any information about it ?
<RaXOR> is anybody reading the text ?
<ion> Wow, just over five minutes of patience.
<directhex> all the patence needed to be a dev ^_^
<james_w> lifeless: yes, stick it in a mail, won't get lost until I have some time to process them all
<james_w> lifeless: one day you will be able to do this yourself under appropriate circumstances, but that's an LP change
<lifeless> james_w: ack ack - thanks
<lifeless> I've a few, will get them to you next week.
<jdstrand> jjohansen: hey, is bug #451375 fixed in Lucid?
<ubottu> Launchpad bug 451375 in linux "apparmor disallows truncate of deleted file" [Medium,Fix committed] https://launchpad.net/bugs/451375
<jdstrand> jjohansen: actually, I meant bug #453335
<ubottu> Launchpad bug 453335 in libvirt "apparmor complains about write access to a readonly file" [Medium,In progress] https://launchpad.net/bugs/453335
#ubuntu-devel 2009-11-10
<slangasek> james_w: hmm, I'm running into a few package merges where the debian/squeeze branch isn't up-to-date
<slangasek> james_w: is there a way for us to trigger those, or do you want a list, or?
<james_w> slangasek: there's no way for you to trigger unfortunately
<james_w> slangasek: a list to me will work, but with added latency
<james_w> slangasek: is the https://launchpad.net/debian/+source/<package> up to date for these packages?
<slangasek> james_w: well, unless you think this might be caused by a bug and having a list will help you track that down, I'm not going to bother, it's obviously much more efficient for me to just grab the merge from MoM in that case
<slangasek> checking (bsd-mailx for the current example)
<slangasek> yes, that page lists the correct "latest release"
<james_w> slangasek: ok, thanks for checking
<james_w> I'm happy for you to mention them to me
<slangasek> ok
<james_w> investigating may help find bugs, and so reduce the frequency
<jjohansen> jdstrand: it should be
<jdstrand> jjohansen: I'll mark it as such-- thanks :)
<dtchen> jdstrand: your audio bug should be fixed in 2.6.32-git
<dtchen> lifeless: WRT hda-intel, mm, not really. There are too many issues, but wiki/DebuggingSoundProblems is a starting point. I've also blogged about common issues (with workarounds) in 9.10.
<dtchen> lifeless: for the most part, the issues are resolved upstream already, but they may not land for 10.04. 2.6.33 will have them for certain.
<lifeless> dtchen: thanks
<jdstrand> dtchen: ok-- I'll keep an eye out, thanks!
<jdstrand> though, it'll be after UDS before I can test it
<slangasek> dtchen: please don't mark bugs as duplicates of #470265 when there's no specific evidence that their /etc/kernel-img.conf was broken.
<slangasek> dtchen: this undermines any efforts to determine the actual cause of the problem the user is having
<dtchen> slangasek: all right, is there a separate bug I should be triaging against?
<dtchen> slangasek: also, sorry for the added workload
<slangasek> dtchen: you shouldn't be marking any bugs as duplicates before you've shown that it's a duplicate!  Just reassign the bugs to the grub package in that case
<dtchen> slangasek: no, I'm specifically asking what I should be doing with Karmic bugs that are filed against alsa-driver that clearly are not running 2.6.31-1[45]-generic
<slangasek> if you need a bug for "I munged menu.lst myself and it broke", I can get you a bug for that; but so far these bugs don't actually seem to be triaged far enough to even say that's the problem the user is having
<slangasek> dtchen: just reassign them to the grub package, then
<dtchen> slangasek: sure thing, thanks
<slangasek> thank you
<JohnFlux> Hey all
<JohnFlux> Hi all
<JohnFlux> Does anyone know who is dealing with input methods at the moment?
<slangasek> JohnFlux: ArneGoetje
<slangasek> james_w: lp:debian/squeeze/cmake also out of date, it appears
<PRIDE> um...question
<PRIDE> question?....new to ubuntu, is this where i come if i need help with getting an update for my laptop webcam..my laptop is hp dv6000
<ScottK> PRIDE: No.  That's #ubuntu.
<ScottK> This is the channel for coordinating development work.
<PRIDE> ScottK, mmmk...the problem is they dont kno anything about webcam so i was wondering if the developers could make an update/patch for hp webcams
<ScottK> PRIDE: Filing a bug on Launchpad is the best way to approach that.
<PRIDE> how would i do that?
<ScottK> That question they will know how to answer on #ubuntu.
<PRIDE> ScottK, thx
<dholbach> good morning
<\sh> moins
<mvo> hey dholbach
<dholbach> hi mvo
<glatzor__> morning mvo and dholbach!
<maco> the vegetarian brigade?
<dholbach> yeeeehaww!
<dholbach> hi glatzor__: long time no see - how are you doing?
<mvo> hey glatzor__! nice to see you
<jsgotangco> wow
<dholbach> hey jsgotangco!
<jsgotangco> hi dholbach, mvo, glatzor__
<mvo> hey jsgotangco
<glatzor__> hey jsgotangco !
<glatzor__> dholbach, quite well. I hope yourself, too!
 * dholbach hugs glatzor__
<dholbach> glatzor__: I got my dose of ubuful before flying to UDS :)
<maco> well dont hug the man, you're gonna infect him!
<\sh> dholbach, this time it could be named ubu-swine-flu ;)
<Tm_T> \sh: why not ubu-flu?
<\sh> Tm_T, ubuflu is the standard ;) ubu-swine-flu is todays hype, regarding our pediatrician ;)
<jsgotangco> dholbach: are you vegetarian already?
<dholbach> jsgotangco: yeah, for more than a year now :)
<dholbach> jsgotangco: it's what India did to me :)
<maco> someone suggested an "ubuntu vegetarians" team on lp so that we could easily coordinate group-meals during UDSs
<jsgotangco> dholbach: i'm almost there too
<maco> maybe glatzor__ or mvo?
<jsgotangco> dholbach: haven't had read meat for more than a year
<dholbach> mvo already owns https://launchpad.net/~canonical-vegetarians :)
<dholbach> look at these happy people: https://launchpad.net/~canonical-vegetarians/+mugshots
<maco> heh nice
<maco> we found a vegan restaurant in barcelona
<maco> a big group of about 20 of us. 17 went in there while the other 3 went "no meat? i'm out"
<\sh> *grmpf* Meeting Topic: "How do you write PHP applications the right wayâ¢" -> gone
<chrisccoulson> good morning everyone
<mvo> maco: ubuntu-vegetrians sounds good to me, that is a bit broader than just the canonical group
<ogra> james_w, i have a slight prob trying to merge apex with bzr ... seems the debian branch misses tags http://paste.ubuntu.com/314967/ anything i can do about that ?
<slangasek> ogra: merge-package doesn't work for native packages
<ogra> aaah !
<ogra> ok, the wikipage should probably state that :)
<slangasek> it's a bug (bug report is open)
<ogra> ah
<slangasek> feel free to document on the wiki, too
<Riddell> asac: how come network-manager-[vpnc|openvpn|pptp] are in universe?
<doko_> Riddell: gdb pong
<Riddell> doko_: I'm told by Qt developers that gdb 7.0 doesn't work well with c++, do you know anything about that?
<doko_> Riddell: no
<doko_> Riddell: is there an upstream report?
<Riddell> doko_: http://lists.trolltech.com/pipermail/qt-creator/2009-November/004963.html
<Riddell> doko_: so I'm getting calls to put 6.8 into backports, does that make sense?
<doko_> Riddell: as a separate package?
<Riddell> yes
<doko_> Riddell: I don't mind, but it's not a step forward for lucid. could you check if disabling the pie patches helps?
<pitti> doko_: remaining java bits for ant moved to -updates now; thanks for confirming the debhelper issue
<doko_> pitti: \o/
<doko_> Riddell: and it would be good to have reports in launchpad to track those
<asac> Riddell: historic reason is that the vpn stuff was more like a second tier product and there were no guarantees that they are maintained in sync
<asac> Riddell: plan is to make at least pptp installed by default in lucid
<Riddell> asac: will also said this.. 12:14 < wstephenson> Riddell: also the dbus policy perms for pptp appear to be globally wrong in *buntu, NetworkManager can't call the VPN plugin to ask it if it needs secrets
<Riddell> asac: is that right?
<asac> Riddell: there is a bug yes. but we verified that the vpn plugins work at least a bit
<Riddell> "a bit" :)
<asac> so its not a general issue ... most likely related to system-settings/user-settings related secrets
<asac> i will ask cyphermox to verify them again ... and fix accordingly.
<JanC> asac: I think the vpnc stuff is at least as useful in main; from what I hear a lot of colleges/universities/etc. use that
<asac> JanC: the main thing we found out around RC time is that in russia you need pptp to get online for most dsl providers .... but I agree ... adding a blueprint for vpn support in lucid
<siretart`> asac: I can confirm that the openvpn plugin works in karmic, but I almost always have to activate my vpn connection several times until it stays for longer than about a second.
<asac> siretart`: you think you could provide me an account so i can test that on the setup where you see that?
<asac> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-vpn-out-of-box-experience
<asac> JanC: ^^
<JanC> asac: nice
<siretart`> asac: hm. that's gonna get difficult. I could paste/attach my logs to some bug if that would help
<asac> siretart`: ok. filing a bug against -openvpn would be a good start i guess
<asac> thx
<ion> Darn, wxErlang is removed in Ubuntu. Not that Wx is very nice, but iâd rather use the Wx bindings than the Tk bindings. :-P
<pitti> mvo: flex merge> hppa is no more, so this could have been a sync
<mvo> pitti: oh, sorry
<pitti> JFYI for next time :)
<mvo> indeed
<mvo> thanks
<jdstrand> Keybuk: hi! I've been going through the blueprints for lucid. I was wondering if there is an upstart session that would be beneficial for people doing upstartification in lucid (ie, what to do, what to avoid, etc)
<jdstrand> Keybuk: I checked around, but didn't see anything that quite fit (I could have easily missed it)
<Keybuk> jdstrand: I don't think it's worth a session
<Keybuk> anything I say now will be out of date by the time lucid releases
<jdstrand> heh
<jdstrand> ok
<Keybuk> and it'd be just a rehash of the session I did in Barcelona anyway ;)
<jdstrand> unfortunately I missed that one
<jdstrand> Keybuk: the part I most care about atm is the part that is likely one of the most moviing targets
<jdstrand> Keybuk: ie, being quiet, but displaying erros appropriately
<jdstrand> errors
<Keybuk> exactly, that's all subject to change
 * jdstrand nods
<dholbach> wow, bug 429322 has 2030 subscribers
<ubottu> Launchpad bug 429322 in seahorse-plugins "seahorse-agent assert failure: ERROR:iop-profiles.c:606:IOP_generate_profiles: assertion failed: (obj && (obj->profile_list == NULL) && obj->orb)" [High,Confirmed] https://launchpad.net/bugs/429322
<\sh> hmmm...I'm now somehow stucked with update-manager-core and do-release-upgrade ... it can't be used from a server which doesn't have a internet connection, but I have an ubuntu mirror inhouse...so how do I configure it correctly, without mirroring changelog.ubuntu.com
<mvo> \sh: do you have a cdrom? the easiest ist to use the alternative cd then
<\sh> mvo, the servers are remote, they don't have any removable medias...:)
<\sh> mvo, and I have hundreds of them ;)
<\sh> I could however copy the meta-release and meta-release-lts files, and point them to my local archives...
<\sh> .oO(and then I wonder why the upgrade tool of hardy points to hardy-proposed and not hardy-updates like e.g. karmic or so (UpgradeTool: http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/dist-upgrader-all/0.87.31/hardy.tar.gz)
<asac> Riddell: did you already add the firefox/kde spec
<mvo> \sh: just download the upgrader in this case http://es.archive.ubuntu.com/ubuntu/dists/karmic-proposed/main/dist-upgrader-all/current/ (karmic.tar.gz) and run it as sudo
<mvo> \sh: if you have just internal uris in sources.list it should DTRT
<mvo> \sh: if not, please let me know, but I now need to take a short break
<\sh> mvo, what should I call from the dist-upgrader archive?
<Riddell> asac: no I'm stuck on something silly that's taking too long, but it's next on my todo list
<asac> Riddell: created this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-firefox-kde-integration ...
<asac> if you have references to current opensuse patches etc. please put them there too
<Riddell> ok
<Tm_T> asac: lovely (:
<Tm_T> Riddell: is there blueprint or other related to why KHTML isn't enough for us, as I would like to do testing with it, what is not working etc
<soren> Keybuk: What was the magic trick to make upstart wait until lo was configured before entering runlevel 2?
<Keybuk> soren: ... and net-device-up lo ?
<soren> Keybuk: WherE?
<Keybuk> in /etc/init/rc.conf
<Keybuk> though that will break being able to switch runlevel
<Keybuk> (ie. you won't even be able to shutdown or reboot)
<soren> So... What to do?
<Keybuk> nothing
<soren> I believe you mentioned you'd SRU a fix for this.
<Keybuk> no I didn't
<Keybuk> I believe I said I wouldn't block someone else doing an SRU if they could come up with a fix that didn't break everything else <g>
<soren> Keybuk: http://irclogs.ubuntu.com/2009/10/27/%23ubuntu-devel.txt at 15:26?
<soren> Maybe I misunderstood.
<Keybuk> but, frankly, I think it's a waste of time dealing with these problems
<soren> mai Ã¦nglish nud so guud.
<Keybuk> races between Upstart jobs and SysV init jobs, that is
<Keybuk> I think it's better to spend the time fixing the bugs that prevent them being made Upstart jobs in the first place
<Keybuk> soren: oh, so I did, but I can think of major breakages that will cause now, so I don't :p
<Riddell> Tm_T: try reading yesterday's news in slashdot
<highvoltage> dholbach: are you around?
<soren> So to sum up... When people come into #ubuntu-server complaining their network is broken because the networking job runs before their nics are available, I just tell them to add a "sleep 5" before "ifup -a" and don't deal with the fact that this will exacerbate the problems caused by lo not being configured (since it will be even longer before it is)?
<soren> Keybuk: Ã
<soren> Er...
<soren> Keybuk: ^
<soren> typing is hard today..
<Keybuk> if you like
<Keybuk> give them a lollipop too ;)
<Keybuk> err
<Keybuk> what networking job?
<soren> /etc/init/networking.conf ?
<Keybuk> that's an Upstart job
<soren> i know
<Tm_T> Riddell: roger (:
<Keybuk> soren: I was actually thinking a bit about this the other day
<Keybuk> we use network manager to bring up network devices
<soren> Keybuk: Where else would I add it?
<Keybuk> so the whole ifup-on-network-device-added thing could go away
<soren> You're not going to install networkmanager on people's servers.
<soren> Are you?
<Keybuk> why not? :p
<soren> Because you are not in #ubuntu-server explaining this to people.
<soren> I am.
<Keybuk> I bet they hate D-Bus too
<soren> Are you adding bridging and bonding support to network-manager?
<Keybuk> no
<Keybuk> that sounds like a server team project
<soren> Or are you just going to declare those completely unsupported?
<evand> Keybuk: You're just here to cause trouble, aren't you? :-P
 * soren gives up
<pitti> soren, Keybuk: could there be an udev rule which checks whether a newly added eth device is in /e/n/i and call ifup for it? (instead of an upstart job)
<pitti> hardware triggered actions sound fine for this?
<pitti> description     "configure virtual network devices"
<pitti> oh
<pitti> soren: so the problem is that those virtual ones sit on top of real ones which aren't available at that time yet?
<pitti> (bonded, etc.)
<\sh> pitti, I'll take over, soren asked because of me
<\sh> pitti, bonding interfaces are in need of hw nics...and somehow after my dist-upgrade, network isn't there (using bonding and vlans on top of the bond) which is horrible for server people
<pitti> \sh: how did that ever worked in earlier releases then? it was just a static init script as well, after all?
<pitti> just sheer luck, and init script running later?
<\sh> pitti, in jaunty is was still /etc/init.d/networking and if-up magic
<pitti> \sh: well, that's pretty much what we have now, too
<pitti> it just might be started a tad earlier
<\sh> pitti, I'm rebooting the server just now...where can I look which job is started when (regarding the mix of upstart + init scripts)
 * pitti declares victory over dk-disks bugs and leaves it with zero new ones
<pitti> \sh: now, ifup -a is started as soon as local file systems are mounted and udev coldplugging is done
<maco> 0 boogs? oooo, shiny!
<pitti> (see /etc/init/networking.conf)
<pitti> maco: 0 new bugs
<maco> still shiny!
<pitti> plenty of incomplete/triaged, too
<maco> slightly shiny ;-)
<\sh> pitti: oh weia...i hope it's not the same crap I triggered during intitramfs dhcp requests with "ipconfig"
<soren> pitti: It's a well known problem.
<\sh> pitti, then I can give you at least one thing: nic devices are not set to auto when doing bonds or vlans
<soren> pitti: The networking job (which calls "ifup -a") is run much, much earlier in karmic than before.
<soren> So early, in fact, that the physical nic's often are not available yet.
<pitti> soren: ah, what I suspected; so it was by and large "luck"
<soren> In a sense.
<pitti> which made me wonder whether we should have an additional udev rule to catch late stragglers
<soren> It's always been racy, but I don't know of anyone who was ever bitten by this before.
<soren> In Karmic, I haven't heard of anyone for whom it works.
<soren> pitti: The solution is to configure the virtual interfaces when the corresponding physical ones are available.
<pitti> is it really the nics which arrive so late? shouldn't udevsettle wait for them?
<soren> pitti: I thought so too, but no.
<pitti> soren: exactly
<pitti> soren: and that's what udev rules are for, like ACTION=="add", SUBSYSTEM=="net", ...
<soren> pitti: Right.
<pitti> with ... being something that calls a script on the $INTERFACE variable which checks if that is in /e/n/i
<soren> pitti: Problem is that /etc/network/interfaces is the other way around.
<soren> pitti: It defines the bond0 interface, which then specifies that it "contains" eth0 and eth1, for instance.
<soren> Rather than:
<soren> iface eth0
<soren>    part-of bond0
<soren> or whatever.
<soren> Otherwise, it'd be easy.
<pitti> sure, but you could just try to bring up all of those
<\sh> pitti, if the interfaces are "auto up" they won't be used by the bond module...they need to be unconfigured, and not up..management of those hw nic interfaces is being done by the bond module
<soren> Keybuk: What if we simply called "ifup -a" from network-interface.conf ?
<pitti> soren, \sh: a very brutal and hopelessly inefficient rule would just be
<soren> Ah, no, that'd be bad.
<pitti> ACTION=="add", SUBSYSTEM=="net", RUN+="/sbin/ifup -a"
<soren> pitti: No, that will be bad.
<pitti> soren: .. assuming that the ones where half of the componetns are still missign will just gracefully fail, of course
<soren> pitti: If you ifdown an interface and then another one turns up, they'll both be ifup'ed.
<pitti> soren: right, which is why I only propose this for a first test :)
<pitti> it doesn't handle manual ifdowns at all
<soren> It will work around the problems on servers, but is not a proper fix.
<pitti> no doubt
<\sh> pitti, don't we get a "I catched all hw nic interfaces now, and I'm, the almighty udev, is done doing jobs on hw NICs, now do your job, evil ifup -a" event
<soren> You can't know when it's caught all the hw interfaces.
<pitti> \sh: that's what I suspected it'd already do
<pitti> after an udevadm trigger/udevadm settle I had expected everything to be "there"
<nxvl> james_w: if there is a package that doesn't have bzr branch, can i import-dsc and upload it? or it needs to be automagically?
<soren> You can never know if another interface is going to turn up.
<pitti> which made me wonder whether it's really the NICs which are missing, or whether some other modules are only loaded later
<soren> Maybe you add a USB one later on.
<\sh> pitti, I ran into a similar problem while doing dhcp request inside the initramfs (ipconfig is executed, I can see the module being loaded, but the dhcp request was already sent out into the dark, which gives a really nice timeout)
<\sh> somehow I wonder if I can change it when adding the correct nic kernel module
<soren> Keybuk: Can you confirm that "udevadm trigger;udevadm settle" does not guarantee that all your NIC's have been handled by udev?
<soren> Keybuk: Or the opposite of "confirm", whatever that is.
<pitti> soren: I actually wondered about that as well; how do you say for "confirm that it is false"?
<dholbach> highvoltage: yes
<\sh> just to remark: if someone does an upgrade from hardy to lucid in the future, this will strike many server people running hardy lts on their infra...and they won't be amused when their tests are failing ;)
<soren> Keybuk: How serious are you about network manager on servers?
<highvoltage> heh, who would want that?
<soren> highvoltage: Noone, except Keybuk, I imagine.
<soren> highvoltage: Trouble is, he sits on upstart and udev and all that jazz.
 * soren /really/ goes to pick up daughter at day care
<highvoltage> soren: ok :)
<Keybuk> soren: sorry, I've been on a call for the past hour
<Keybuk> soren: just reading scrollback
<Keybuk> pitti: actually udev rules must *NOT* be used for this
<Keybuk> pitti: udev rules are subject to timeouts, security issues, etc.
<Keybuk> pitti: ACTION=="add", SUBSYSTEM="net",... in udev => "on net-device-added" in upstart
<Keybuk> pitti: it's run at the same time, except in a sane environment, with very well understood blocking semantics, etc.
<pitti> oh, interesting; and that's safer than a straight udev rule?
<Keybuk> pitti: (and you can multiplex them :p)
<pitti> good to know
<Keybuk> soren: "udevadm trigger; udevadm settle" only guarantees that udev is idle - it does not guarantee *ANYTHING* about the state of any hardware device
<Keybuk> pitti: much safer
<Keybuk> anything in a udev RUN rule should really be considered "part of udev"
<Keybuk> a good rule of thumb is that if it doesn't immediately reconfigure the device in any way, or doesn't result in further processing, it should not be
<Keybuk> (udev-config-printer I'm looking at you - you will die)
<Keybuk> if you want something to happen "when a device is ready", that's what Upstart is for ;)
<\sh> Keybuk, and when you need to know if "more then one device needs to be ready"?
<Keybuk> exactly
<pitti> Keybuk: so ifup'ing doesn't count as "immediate processing'?
<Keybuk> now, the bonded interface problem
<Keybuk> pitti: no, because it can run things like wpa supplicant, dhclient, etc.
<pitti> ah, right
<Keybuk> there are lots of bugs when we used to run ifup from udev where udev got bored and killed it ;)
<Keybuk> thus /etc/init/network-interface.conf
<Keybuk> which is the same udev rule, expressed as an upstart job
<Keybuk> so, NOW, the bonded interface problem
<Keybuk> ifup eth0
<Keybuk> ifup eth1
<Keybuk> that's all easy, because we have a physical device
<Keybuk> bond0 (eth0 eth1) is hard
<Keybuk> what you want is something that notes down each network device as it comes up
<Keybuk> configures them if necessary
<Keybuk> and also knows about bonded devices, bridges, tunnels, and all manner of other virtual devices
<Keybuk> and knows what their dependencies ar
<Keybuk> so when it has both eth0 and eth1, it configures the bridge or the bond
<pitti> shouldn't /e/n/i already have all this information?
<Keybuk> it probably does in the wrong order
<Keybuk> but then you still need a daemon that parses /e/n/i and acts on it, as a result of events from udev
<Keybuk> we have one of those ;)
<Keybuk> we could teach it about bonded interfaces, bridges, and stuff
<Keybuk> and then we would have win
<pitti> (NM stopped reading /e/n/i long ago, I think)
<mr_pouit> james_w: lp:ubuntu/mousepad doesn't seem to exist (it's the first one missing I encounter, so maybe this is a bug :])
<Keybuk> really? the Fedora one still does basically this for its sysconfig stuff
<pitti> well, you probably wouldn't need a daemon, it could be done in the upstart job?
<Keybuk> ah
<Keybuk> now
<pitti> asac: ^
<Keybuk> that's a different thing
<Keybuk> we could do this a different way
<Keybuk> we could parse /e/n/i and generate upstart jobs from it
<Keybuk> since upstart jobs can do the "when eth0 and eth1 are ready" thing
<qense> Aren't the lp:ubuntu/source-pacakage branches now pointing to Lucid?
<ion> Upstart could be extended to watch /e/n/i and create/update internal job definitions like network/bond0: while network/eth0 and network/eth1, ...
<pitti> ah, clever
<Keybuk> so you could have an auto-generated job that was basically
<Keybuk>   on net-device-up eth0 and net-device-up eth1
<ion> Ah, i should have read Keybukâs last few lines. :-P
<Keybuk>   exec ifup bond0
<mr_pouit> qense: there is no branch at all for this package apparently (lp:ubuntu/<release>/mousepad)
<Keybuk> this is, in principle, what we're planning to eventually do for fstab
<Keybuk> we had a bunch of crappy shell scripts that did everything badly
<Keybuk> we replaced it with a daemon that intermediates between udev and upstart
<Keybuk> and encodes all of the corner cases
<Keybuk> and we intend that daemon to go away again in the longer-term, with its code being used to generate upstart jobs instead
<qense> mr_pouit: no there isn't, apparantly it's code is not hosted on Launchpad yet
<pitti> Keybuk: "a daemon" == mountall?
<Keybuk> ie. mountall would become a "upstart-fstab-helper" that resulted in mount/sda1 mount/sda2 type jobs being automatically created
<Keybuk> pitti: exactly
<Keybuk> so for networking, we have basically the same issue
<Keybuk> ifup doesn't really lend itself to event-driven construction
<Keybuk> but we don't have the intermediate daemon either, or the final solution
<qense> mr_pouit: you could try "apt-get source mousepad", but you'd have to have the right source repository enabled
<mr_pouit> qense: I know. I thought that all packages had already been imported, that's why I'm wondering.
<qense> ah
<Keybuk> so given that, it's not unreasonable to have an upstart-eni-helper as well <g>
<qense> I see a lot of people that still have CD-drives in their fstab. Is that really necessary, or does UDev handle them just as well without?
<Keybuk> qense: udev doesn't care about fstab at all
<qense> You could just as well remove the entry?
<pitti> oh, udev 147
<evand> qense: https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-dynamic-cdrom-handling
<pitti> Keybuk: FYI, we have a new CK ready for udev 147
<Keybuk> pitti: yeah
<Keybuk> pitti: it's ready?
<qense> evand, Keybuk: thanks
<pitti> Keybuk: yep; I already committed all our remaining changes to Debian git, so we'd only need to sync
<pitti> Keybuk: new CK has Breaks: udev (<< 147~)
<Keybuk> shouldn't that be << 147 ?
<Keybuk> since 147~ is in karmic
<pitti> Keybuk: right, we need to bump that
<pitti> I'll just bump it in Debian git and upload a snapshot
<Keybuk> http://launchpadlibrarian.net/35479479/amilo-karmic-20091110-3.png
<Keybuk> ^ I wonder whether he's using wubi
<Keybuk> pitti: I think I'll get to udev tomorrow
<pitti> Keybuk: I'll upload a new CK to ubuntu-desktop PPA
<Keybuk> ok
<Keybuk> (I have two hours left of the day, and have some bug triage to do first :p)
<evand> wubi would be my guess as well
<cjwatson> Riddell: FYI: the debconf KDE frontend has been removed upstream, since it's still qt3 and the qt4 perl bindings aren't ready yet. It'll fall back to other frontends as available
<\sh> Keybuk, and what would be now a good workaround for people like e.g. me, upgrading from jaunty to karmic or from hardy to karmic? or should I write upstart jobs as you described earlier?
<Riddell> cjwatson: thanks, that's interesting.  we don't really use it though since packagekit doesn't do debconf much currently
<cjwatson> Riddell: yeah, I have mail about that to process at some point too :)
<cjwatson> anyway, thought I'd better not merge before telling you
<\sh> Keybuk, this net-device-up thingy should work from karmic on?
<Keybuk> yes
<Keybuk> it's *used* in karmic
<Keybuk> though I reserve the right to change the syntax, name of the event, etc. :p
<\sh> Keybuk, well, it's used in mountall-met as "start on net-device-up" but start on (net-device-up eth0 and net-device-up eth1) etc. some doesn't work ;) I replaced /etc/init/networking.conf with that
<\sh> (or I'm too stupid to understand Upstart right now ;))
<\sh> s/met/net/
<Keybuk> sometimes doesn't work?
<Keybuk> or flat-out doesn't work?
<Keybuk> do you have iface eth0 and iface eth1 in your /e/n/i ?
<MacSlow> mvo, hey there
<\sh> Keybuk, no...that's the point using bonding ;)
<Keybuk> if not, you want s/-up/-added/ :p
<\sh> ah...
<Keybuk> ie. when the network device exists, not when it's been broght up
<\sh> yes..ok..understood ;)
<\sh> Keybuk, can someone create the "start on ..." statement in pre-start script automagically?
<Keybuk> \sh: not currently
<Keybuk> and Upstart has no "memory" so even if you created the job on boot, you'd have a race
<\sh> Keybuk, hmmm..
<\sh> Keybuk, btw..http://paste.ubuntu.com/315215/ <- this is now what I have
<\sh> and it doesn't work ;)
<mvo> hey mac
<mvo> hey MacSlow
<Keybuk> please be more verbose
<Keybuk> is it started?
<\sh> Keybuk, it is started somehow (i see the bond interface) but no hw nics (speak eth0 eth1 eth2 eth3) added to the bond...so the bond itself -> success, but no unterlaying hw interfaces
<Keybuk> \sh: so there must be something else it needs
<Keybuk> Upstart is doing the right thing for you, but ifup isn't
<\sh> therefore the next interface (vlan) is not up, because the bond is not functional
<\sh> Keybuk, /etc/init.d/networking restart -> et voila
<Keybuk> that tells me you need something else in that ...and... clause
<\sh> Keybuk, but what is missing? there can't be much more ... module-init-tools?
<Keybuk> \sh: buggered if I know
<Keybuk> bondage is something I prefer to do in my spare time
<\sh> Keybuk, ok...in /etc/modules I have the bonding module and the 8021q module..so module-init-tools is loaded somehow...
<Keybuk> \sh: ...and stopped module-init-tools
<\sh> let see
<\sh> Keybuk, you think we can get that straight before lucid? adding such scripts manually and thinking about a very insane setup I and others have regarding several types bonding ... I think we need for lucid a good safeword to make people happy ;)
<\sh> na..failed
<Keybuk> \sh: I will not get anywhere close to straight on that before lucid
<Keybuk> if it's important, I will need help
<jdong> ooooooh ureadahead?
<jdong> *must play*
<\sh> Keybuk, how can I enable upstart --debug? and where to look after?
<Keybuk> \sh: initctl log-priority info
<Keybuk> (you don't want debug)
<\sh> Keybuk, is this static then, or is this gone after reboot
<Keybuk> \sh: gone after reboot
<Keybuk> you can add --verbose to the kernel command-line to get the same effect
<\sh> Keybuk, in menu.lst you mean and then ? just "--verbose" or more "init=/sbin/upstart --verbose" or something
<Keybuk> just --verbose
<\sh> Keybuk, I can see the networking after udev-finish init: handling started event \n networking main process exited normally goal changed from start to stop netowrking state changed from running to stopping -> init: Handling stopping event state changed from stopping to killed, from killed to post-stop and post-stop to waiting
<\sh> sorry...but I reproduced the output via manual typing while reading from IlO ;)
<\sh> Keybuk, means: networking failed again ;)
<Keybuk> so you need something else too ,g>
<Keybuk> keep adding those ...ands :p
<\sh> Keybuk, lol
<\sh> Keybuk, anyways..ending for today....tomorrow more :) thx anyways :)
<\sh> soren: same goes to you :) thx
<thekorn> ping
<thekorn> whos's the korn now?!
<kirkland> cjwatson: slangasek: approximately when do lucid livecd ISOs start showing up?
<cjwatson> "at some point"
<cjwatson> I think slangasek was planning to do it this week
<cjwatson> kirkland: are you making plans based on them?
<jdstrand> mdeslaur: it just occurred to me slangasek would be good to have in your 2-factor auth session
<xisco> hi all, I want to know if there's any way to stop pynotify right the way
<pitti> mbiebl: hm, do you see a clever way how to get bug 465054 solved for Debian, without an admin group?
<ubottu> Launchpad bug 465054 in devicekit-disks "Do not require a password every time to mount internal disks" [Medium,Fix committed] https://launchpad.net/bugs/465054
<pitti> mbiebl: of course we could just patch the .policy to generally allow it to local foreground users, but that seems a little too much to me
<mbiebl> I don't think that would be a good idea
<mbiebl> question is, if you want to use the "admin" group
<mbiebl> or if we create a custom group for that
<pitti> mbiebl: we don't currently have the concept of "admin" vs. "underdog" users in Debian, I think?
<mbiebl> There are special purpose groups like netdev/plugdev etc
<mbiebl> but afaik no "admin" group by default
<pitti> plugdev was introduced as the exact opposite, though
<pitti> nowadays it's pretty much obsolete, I think
<mbiebl> exact opposite, why?
<pitti> mbiebl: it gave you the privilege to mount removable devices (only) without password
<pitti> that was from the pmount age
<pitti> s/removable/hotpluggab/e
<mbiebl> yeah, and you want the same behaviour for internal devices
<pitti> mbiebl: yes
<mbiebl> I didn't want to imply that we have to use plugdev for that
<pitti> $ grep auth_admin /usr/share/polkit-1/actions/*|wc -l
<pitti> 70
<pitti> I guess this problem extends beyond dk-disks, but there we got the most complaints from so far
<mbiebl> pitti: my thinking is rather if we should design new groups for the pk-1 world
<mbiebl> or reuse existing ones
<mbiebl> groups == roles
<pitti> mbiebl: (https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html FYU)
<pitti> FYI
<pitti> gosh, time to stop typing for today
<pitti> mbiebl: I just went through sid's default groups, and plugdev and cdrom seem closest to me
<pitti> I'm just a bit averse against adding even more
<pitti> powerdev/netdev/plugdev are all related in some way
<pitti> but they are all too specific
<mbiebl> pitti: I think this is something we can discuss in a few days :-)
<pitti> mbiebl: heh, over a dinner with Debian guys perhaps :)
<pitti> mbiebl: it was an easy fix for Ubuntu (just committed), but I guess it'll annoy Debian users, too
<mbiebl> yeha
<mbiebl> I just think you might be overloading the semantics of the "admin" groups i.e. it could be useful to have more fine grained groups
<mbiebl> but maybe not
<pitti> it's a very coarse-grained design, yes
<pitti> mbiebl: oh, having these groups might be useful indeed; the problem is just that each time you introduce a new one, you have to migrate existing users
<pitti> I guess no matter how you design it, some people will not like it :/
<mbiebl> it would be cool if you could say that being part of group admin automatically implies membership of a set of groups (roles)
<mbiebl> which would also allow to grant permissions on a per user / group basis
<mbiebl> in a more fine-grained manner
<pitti> mmmm nested groups
<pitti> . o O { isn't that actually possible with some ldap/AD systems? }
<mbiebl> maybe, dunno
<pitti> mbiebl: however, with PK this would actually work
<pitti> mbiebl: e. g. DK-D would give the *-internal bits to groups "admin" and "diskadm"; network-manager would give them to "admin" and "netdev", and so on
<mathiaz> jcastro: hi
<mathiaz> jcastro: does luke have a LP account?
<pitti> mbiebl: then you can locally decide to put users just into diskdev, or make them full admins (including sudo, etc.)
<pitti> mathiaz: TheMuso you mean? "themuso"
<mathiaz> pitti: oh - no. Sorry - I meant luke kanies
<mbiebl> pitti: we could split it up like that
<mathiaz> jcastro: ^^
<bibinou> cody-somerville: ?
<bibinou> I need help with one bug you reported
<bibinou> https://bugs.launchpad.net/ubuntu/+bug/409640
<ubottu> Launchpad bug 409640 in gstreamer0.10 "Video is tinted blue after update to karmic (dup-of: 395476)" [Low,Invalid]
<ubottu> Launchpad bug 395476 in nvidia-graphics-drivers-180 "Video is tinted blue (nvidia sets HUE to -1000)" [Undecided,Confirmed]
<cody-somerville> okay
<bibinou> in the description, you said you modified something
<bibinou> where did you find this information ?
<bibinou> i'm trying to gather some info about this bug because it is very similar to another bug I misinterpreted as a duplicate of this one
<cody-somerville> one sec, on the phone
<bibinou> no problem
<amgarchIn9> so people, everything breaks. "Nov 10 21:03:18 novo init: kdm respawning too fast, stopped" even after I dpkg-reconigured gdm and choose gdm. I also removed the link /etc/init.d/kdm. Why is kdm being started at all?
<amgarchIn9> I am afraid it is buried somewhre in Upstart configs, but I am not really famiiar with that.
<amgarchIn9> when both gdm and kdm are competing for display ubuntu ends up in a propmpt to reconfigure graphics. "Low graphics mode" prompt if you ever seen that.
<kirkland> pitti: would you mind processing a tiny incremental fix to the eucalyptus package in karmic-proposed?
<kirkland> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/458904
<ubottu> Launchpad bug 458904 in eucalyptus "When installing a node, euca_find_cluster fails to locate the cluster controller if instances are running" [High,Fix committed]
<pitti> kirkland: no problem; can you please build it with -v to include the previous -proposed changelogs into the source.changes?
<kirkland> pitti: whoops
<kirkland> pitti: should i do a .3 with that?
<kirkland> pitti: i added the debdiff to the bug pointed to above^
<kirkland> pitti: oh, actually.... this was a question i had
<pitti> kirkland: ah, you already uploaded? nothing in the queue yet
<kirkland> pitti: yeah, so let me ask this question ...
<kirkland> pitti: i was uploading a .2 version over the top of a .1 in -proposed
<pitti> kirkland: http://launchpadlibrarian.net/35497155/out -> this rewrites changelog history, please don't
<kirkland> pitti: i just edited the current changelog entry, with the existing SRU changes in there
<pitti> add a new changelog entry
<kirkland> pitti: ah, okay, that answers it
<pitti> kirkland: .2 wasn't accepted, so if you upload again, reuse .2 please
<kirkland> pitti: okay, let me redo that then
<pitti> kirkland: http://launchpadlibrarian.net/35497155/out -> what difference does it make?
<pitti> kirkland: the only difference that I see is that the file would end up being executable (missing -m 644)
<kirkland> pitti: it wasn't ending up in the .deb before; it is now
<pitti> ah, so the rule was never executed?
<kirkland> pitti: empirically, yes, that's what it looked like to me
<kirkland> pitti: i did not investigate why
<pitti> kirkland: so, I don't mind the "changed history" too much
<kirkland> pitti: i'll do whatever you require
<pitti> kirkland: the point about -v is to include previous changelogs and bug references, but with that this actually happens as well
<pitti> it's just unusual to rewrite history
<kirkland> pitti: gotcha
<pitti> but nevermind, processing
<kirkland> pitti: oh?  okay?  so you're accepting after all?
<kirkland> pitti: i was fixing the changelog, etc.
<pitti> jsut happens that the two problems (no new changelog, and missing -v)  cancel each other out :)
<kirkland> pitti: so in the future, you want a new changelog entry for each upload going through proposed; that makes sense
<kirkland> pitti: :-)
<kirkland> pitti: well, my heart was in the right place -- to ensure that you saw *all* of the changes in the SRU
<pitti> right, and upload with -v if the previous one didn't go to -updates yet
<kirkland> pitti: i see that -v + a new changelog is a better way to do it
<kirkland> pitti: okay, cheers, thanks man
<pitti> thanks to you
<cody-somerville> bibinou, okay, whats your question?
<bibinou> cody-somerville:
<bibinou> I was wondering
<bibinou> as you provide very specific commands in the description of your bug
<bibinou> where did you find that info and if you have more info about the problem
<bibinou> and more to the point, is it a dupe of https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/395476
<ubottu> Launchpad bug 395476 in nvidia-graphics-drivers-180 "Video is tinted blue (nvidia sets HUE to -1000)" [Undecided,Confirmed]
<cody-somerville> no, its not a dupe of 395476
<cody-somerville> I get the solution from http://www.wiredrevolution.com/ubuntu/fix-blue-tinted-video-in-ubuntu
<bibinou> ok, the second problem is that some people confused the two bugs like me in the comments
<cody-somerville> * git
<bibinou> either in the comments of 395476 that those of 409640
<bibinou> thanks for your link
<cowgarden> will there be a global equalizer one day? I'd love it
<cody-somerville> seb128, I have a patch I'd like to SRU to karmic for gst-plugins-base0.10 but I can't do the initial fix in lucid because lucid's gst-plugins-base0.10 is dep-wait. I see you did that requested that sync. Are you working still on the getting the build deps into lucid?
<seb128> cody-somerville, what change do you want to sru exactly?
<seb128> cody-somerville, I will sort lucid build issues later, you don't need to fix it in lucid to do a sru though
<cody-somerville> seb128, Generally its preferred to fix it in the development series before doing an SRU but since I'm just applying a patch from upstream GIT I suppose I'm not too worried about it getting forgotten for lucid.
<cody-somerville> seb128, http://cgit.freedesktop.org/gstreamer/gst-plugins-base/patch/?id=acaeed6131539facc523862e0f418f8602c6b095
<seb128> right, no need to bother for this change
<seb128> you can sru it before having the change in lucid
<cody-somerville> kk
<cody-somerville> seb128, its refusing to build the alsa plugin. Any hints?
<seb128> cody-somerville, what arch do you use?
<cody-somerville> seb128, amd64
<seb128> and what error do you get?
<cody-somerville> dh_install -pgstreamer0.10-alsa
<cody-somerville> cp: cannot stat `./debian/tmp/usr/lib/gstreamer-0.10/libgstalsa.so': No such file or directory
<cody-somerville> Looking up in the build log, configure lists alsa as not going to be built
<cody-somerville> from debian/rules:
<cody-somerville>  ifeq ($(DEB_HOST_ARCH_OS),linux)
<cody-somerville> PLUGINS += alsa
<cody-somerville> endif
<cody-somerville> I'm guessing that conditional branch isn't being executed.
<seb128> is type-handling installed?
<cody-somerville> ah
<cody-somerville> no it is not
<seb128> jdstrand, hey
<seb128> jdstrand, I've a pending evince sru for fixing printing issues should I wait for the bzip changes?
<seb128> jdstrand, or do you want to look at that in a next upload?
<jdstrand> seb128: I just assume fix it
<jdstrand> seb128: when are you planning to upload?
<seb128> jdstrand, I've the change on disk, no hurry though I can wait until later or tomorrow to batch the bzip change too
<jdstrand> seb128: is a bzr commit and a ping to you good enough?
<seb128> jdstrand, can you send me a debdiff rather? or add it to the bug?
<jdstrand> seb128: sure
<seb128> the bzr has the lucid version now
<jdstrand> seb128: give me a half hour to get it going and test it
<seb128> thanks
<jdstrand> seb128: ok, debdiff attached to the bug. tested and updated qa-regression-testing for this
<jdstrand> seb128: I'll add the SRU text to the bug
<seb128> jdstrand, thanks
<jdstrand> seb128: oh, and committed to bzr
<jdstrand> seb128: I can upload to lucid if you'd like
<seb128> jdstrand, would be nice thanks
<jdstrand> sure, np
#ubuntu-devel 2009-11-11
<ramblagir> Is there a way to download all (or a large part) of the development tools packages in the main repository as a disk image?
<cjwatson> doko_: ok for me to merge dpkg? (you touched it last)
<doko_> cjwatson: please don't ask, my upload was just a version fix
<cjwatson> ok
<mathiaz> mneptok: hi!
<mathiaz> mneptok: re https://blueprints.launchpad.net/ubuntu/+spec/mariadb-inclusion
<mathiaz> mneptok: could you rename it so that it starts with server-lucid- and assign mdz as the approver?
<mneptok> mathiaz: done
<mneptok> mathiaz: new URL - https://blueprints.edge.launchpad.net/ubuntu/+spec/server-lucid-mariadb-inclusion
<mathiaz> mneptok: great - thanks
<virtuald> +
<hedkandi> anyone know about the debian rules file?
<maco> hedkandi: what about it?
<hedkandi> well I'm just trying to understand one here
<hedkandi> http://revu.ubuntuwire.com/revu1-incoming/swiggle-0905081139/swiggle-0.4/debian/rules
<hedkandi> what is the build target?
<cristim> hello, I'm trying to build a package for intrepid using launchpad's PPA, and post it there on my PPA. is it enough to set in the latest changelog entry to intrepid instead of karmic?
<maco> yep
<maco> well maybe
<maco> assuming its compatible with intrepid
<cristim> yes
<maco> ie, that all its dependencies exist in intrepid
<cristim> it pnly depends on Perl
<cristim> no matter which version
<cristim> thanks!
<cristim> is it possible to support them both?
<cristim> I mean, will the karmic one dissapear if I add intrepid?
<cristim> or is it accumulative
<cristim> also, is there a time treshold for PPA uploads?
<cristim> I've repeatedly uploaded a package and it seems it's not getting there at all
<maco> the usual way is to make it like
<maco> ~intrepid1
<maco> and ~karmic1
<maco> for the version #s
<cristim> pygccxml (1.0.0-2-cristi1) karmic; urgency=low
<cristim> is it supposed to be 1.0.0-2~cristi1 instead?
<maco> yeah use ~ for sort order
<maco> that way if 1.0.0-3 comes out, its considered newer than yours
<maco> er...hmm im not sure in which cases it matters actually...dpkg has a --compare-versins to answer that question
<cristim> thanks
<cristim> is there a FAQ for PPA?
<maco> no idea
<maco> really, you're asking #ubuntu-motu questions
<cody-somerville> no, #launchpad questions
<maco> all you're asking is about normal debian packaging
<maco> cody-somerville: hmmm? ok
<cody-somerville> packaging questions can be asked in #ubuntu-motu, sure
<cody-somerville> but generally questions about the PPA service should be asked in #launchpad
<smwn> anyone ubuntu developers here?
<cody-somerville> smwn, tons
<smwn> oh just want to make a comment
<smwn> I like ubuntu but it doesnt work with my usb wifi adapter
<smwn> dwa 160
<smwn> d link
<TheMuso> smwn: Have you filed a bug?
<smwn> No
<smwn> how
<maco> ubuntu-bug linux
<smwn> is that a website
<maco> its a command
<maco> itll open the bug reporter
<maco> you can hit alt+f2 and put that command in there
<smwn> ah
<smwn> I'm on windows
<maco> oh right
<smwn> cuz my net wont work
<maco> uhh
<smwn> once i get that sorted i'll delete windows
<smwn> and install ubuntu
<maco> right
<smwn> I like the free software philosophy
<maco> you cant report a bug in launchpad from web browser easily anymore... (possibly at all if the "no-redirect is broken" bug is still open)
<maco> the bug reporter would attach information about your hardware
<wgrant> maco: It's fixed, and even avoids redirecting by default if you give it a package name.
<maco> are you *sure* its unsupported? maybe if you plug in with a wired connection itll offer to download teh wireless driver?
<maco> wgrant: ooooh! yay!
<maco> so thatd be http://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<maco> smwn: go there ^
<wgrant> Correct.
<smwn> ok
<smwn> maybe it works not sure
<smwn> i'm new
<maco> smwn: try connecting to a wired network
<smwn> ok
<maco> smwn: system -> administration ->hardware drivers
<maco> smwn: there are some wireless cards which that'll offer to fetch you drivers
<maco> alternatively, get the windows driver and ask in #ubuntu about ndiswrapper
<smwn> thanks
<smwn> i'll try that
<maco> alright, im popping off now
<Natanaiel> what is a dpkg hook?
<AnAnt> Hello, a question about 3.0 (quilt) source formats & sync'ing from Debian. If a package in Debian is in the 3.0 (quilt) source format, will it be sync'ed in lucid ?
<AnAnt> I ask because when I asked before about the 3.0 (quilt) source format will be allowed in lucid, the answer is that it won't be for a little while yet
<ScottK> That's still the answer.
<AnAnt> ScottK: so the package won't be sync'ed that is ?
<ScottK> Not yet.
<AnAnt> ok
<AnAnt> thanks
<Natanaiel> what is a dpkg hook?
<dholbach> good morning
<Natanaiel> what is a dpkg hook?
<pitti> Good morning
<pitti> ttx, mathiaz, Riddell: FYI, I just went through https://blueprints.edge.launchpad.net/sprints/uds-l/+settopics (the proposed ones), accepted the "good" ones, and rejected the spam and the ones from people who don't attend; they should appear on summit.u.c. in a few minutes, so please schedule away
<soren> Oh, ttx and mathiaz have scheduling powers? Cool.
<ttx> soren: no we haven't
<ttx> (or maybe I'm a superhero that ignores his own powers)
<soren> Ah. :(
<ttx> pitti: thanks anyway :)
<pitti> hey, it's 11.11 11:11
<pitti> (in CET anyway)
<ogra> pitti, hmm, did you notice that rhythmbox stops playing if you switch to a console nobody is logged in ... is that polkit loosing its authority ?
<pitti> ogra: it's you losing access to /dev/snd/ because you aren't on the active console anymore
<soren> ogra: I believe it's intentional.
<pitti> (unless you are in group "audio")
<ogra> i wonder why the device permissions are so restrictive
<Natanaiel> what is a dpkg hook?
<pitti> ^ never heard about it
<pitti> ogra: well, if you'd allow access to all consoles, you'd hear all user's music at the same time; hardly enjoyable?
 * pitti leaves for an hour for some errands
<ogra> depends :)
<ogra> if there is just one user i dont really care :)
<\sh> moins
<soren> I think it's a rather odd assumption that because I switch to a different desktop or to a console, that I want to listen to different music.
<cjwatson> Natanaiel: while dpkg has various extension mechanisms, there's nothing I know of that's generally referred to as just a "dpkg hook". Perhaps it would help if you gave some context.
<joaopinto> there is a new HPLIP version which brings support for newer printer models, is this likely to get an SRU ? Is someone from HP working with Canonical on this ?
<dholbach> joaopinto: if anybody knows, it's tkamppeter_, king of printing!
<joaopinto> ok, there is a question https://answers.launchpad.net/hplip/+question/84333 , I am not sure it should be linked to a bug report
<tkamppeter> joaopinto: The Ubuntu policy is that new upstream versions get only an SRU if they are pure bug fix releases and/or fix severe problems.
<joaopinto> a non working printer is not a severe problem :) ?
<tkamppeter> joaopinto: I have packaged HPLIP 3.9.10 for Lucid though.
<joaopinto> I have asked my dad to buy HP all-in-one on the  assumption that it would work with the current Ubuntu release, there is a widely publicity that HP all in one printers wok fine on Ubuntu
<joaopinto> I think is reasonable to provide support for hardware which was largely available when the release was out
<joaopinto> the issue here is not new hw, but hw support coming late
<pitti> stgraber: can you please do https://edge.launchpad.net/sprints/uds-l/+attend ? Otherwise it's hard to schedule your blueprints
<cowgarden> will there be a global equalizer one day? I'd love it
<\sh> Keybuk, RE: hw nic + virtual interfaces via /e/n/i == fail on startup in karmic... any more ideas to come up with to test this?
<cjwatson> gilir: you should really check with the person who touched a package last before filing sync requests; I've come across quite a few cases in the archive admin request queue where the touched-it-last person has filed a sync request duplicating yours, so you're clearly duplicating work :-(
<cjwatson> gilir: later in the cycle we might want to hoover up things that haven't been dealt with, but early on it's more efficient to just let the touched-it-last person take care of it
<stgraber> pitti: hmm, I'm already on the list at https://edge.launchpad.net/sprints/uds-l ...
<Laney> requestsync has a simple duplicate check which could help there
<pitti> stgraber: ah, sorry, it was a real scheduling conflict; nevermind (resolved now)
<stgraber> pitti: np
<cjwatson> Laney: that would have avoided the duplicate reports, but not the duplicate work leading up to the reports
<cjwatson> I'm not that bothered about having to hit the dup button occasionally
<Laney> cjwatson: indeed, it's not a solution
<cjwatson> doko_: which is why I asked you about dpkg, btw - it's not because I really thought you desperately wanted to merge it, it's because it's good standard practice
<pitti> siretart: ^ speaking of which, I'd look at cryptsetup merge now, unless you already started?
<siretart`> pitti: please proceed
<lool> Hmm ureadahead is being installed on my system with SRU updates; isn't that a bit invasive?
<ion> Well, even in the worst case scenario, the system will still boot just fine.
<ion> And sreadahead totally killed the performance for a lot of machines with HDDs.
<pitti> hm, is that deliberate? (the transitional sreadahead for karmic-proposed)
<ion> I hope so. :-P
<pitti> I NEWed it to universe, I think it should be promoted to main then
<lool> pitti: Definitely
<cjwatson> I definitely think we ought to - it's rather outside the usual parameters, but it makes *such* a difference on hard disks
<pitti> +1
<pitti> promoted
<lool> I have a SSD so I didn't actually test it; if you have both first hand experience with it then i guess it's a good move  :-)
<pitti> it's aaaaawesome
<lool> haha
<pitti> (which is why I'm concerned about being too biased to make the call :-P )
<cjwatson> lool: it halved my boot time, near enough
<pitti> 57 s -> 25 s for me (grub->gdm)
<lool> Impressive indeed
 * Laney is tempted to reboot just to see
 * ogra rather bought an SSD instead of waiting for ureadahed :)
<cjwatson> with readahead-type changes, you need to reboot twice to see benefits (the first reboot profiles)
<Laney> yep
<Laney> don't have bootchart installed already sadly
<pitti> I deliberately keep my ultra-slow hd until after lucid, for better measurement of boot/desktop speed improvements :)
<tgpraveen1> when can everybody view the lucid blueprints currently it says i
<tgpraveen1> dont have enough priveleges with my username or osmething
<pitti> tgpraveen1: https://blueprints.launchpad.net/ubuntu/lucid/+specs
<cjwatson> tgpraveen1: the list won't be hugely meaningful until after UDS
<soren> Keybuk: It seems ifenslave (recently?) grew an option to define the master/slave relationship the "other" way around. See e.g. /usr/share/doc/ifenslave-2.6/examples/two_hotplug_ethernet
<tgpraveen1> pitti: cjwatson
<tgpraveen1> tgpraveen â¢
<tgpraveen1> Not allowed here
<tgpraveen1> Sorry, you don't have permission to access this page.
<tgpraveen1> You are logged in as tgpraveen.
<pitti> weird
<tgpraveen1> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-empathy-indicator
<tgpraveen1> and clicking Set the URL for this specification
<cjwatson> writing specifications is meant to be a developer activity
<cjwatson> so it may well require developer privileges
<cjwatson> if you see "Set the URL for this specification" it means that nobody has fleshed out the summary into a wiki page yet; that will be one of the outputs from UDS
<\sh> anyone has a clue to teach upstart to log all --info --debug stuff into a logfile? only reading from the console doesn't help
<pitti> siretart`: cryptsetup merged; now my dk-disks test suite passes again \o/
<pitti> (our karmic version didn't support DM_UUID yet)
<siretart`> pitti: have you also tested that booting from crypted lvm still works?
<siretart`> (aka, can I safely upgrade my laptop?) ;-)
<siretart`> (just kidding)
<pitti> siretart`: I didn't test that, no; but the differences to Debian are pretty small now
<pitti> and I did test both LVM and LUKS partitions
<pitti> both manually, and with my devkit-disks test suite
<siretart`> ok. then I'll test the crypto lvm part :-)
<pitti> danke
<\sh> soren, but the option for the hotplug stuff doesn't work out properly, when interfaces are already added via udev...
<soren> \sh: Huh?
<\sh> soren, allow-hotplug eth0\n iface eth0 inet manual \n bond-master bond0 etc.pp.. the test (we talked about that example) fails, because the hotplug event doesn't come through...or the bond interface is not configured when the event occured
<\sh> this bonding thing is really complicated sometimes
<soren> It shouldn't depend on bond0 being configured ahead of time.
<\sh> well...for our upstart thing it doesn't help...and I tried to get the console to my ilo virtual serial, and this fails too, because it stops somehow ... need to play with the speed of it
<soren> Oh.
<\sh> or something drops the console=ttySx
<soren> It's because of the allow-hotplug. the upstart job doesn't set --allow=hotplug
 * soren has to run for half an hour or so.
<\sh> soren, where should it be set? during network-interface.conf pre-start script?
<\sh> soren, no change in behaviour
<\sh> soren, Oh wonder oh wonder...I can only see /etc/init/network-interface.conf be executed, but not /etc/init/networking.conf (added some script echo ... >> /tmp/upstart.log end script foo to the important files
<tkamppeter> pitti, hi
<siretart`> @ftpmasters: will emacs23 be semi-"automatically" be promoted to main and emacs22 demoted to universe during the usual archive cleanups, or is a full MIR report required for this?
<pitti> siretart`: no full MIR necessary, it's by and large just a new version
<pitti> if we can promote/demote at the same time, it will pretty much "just happen"
<siretart`> ok great! thanks
<unimatrix> pulseaudio sucks, please remove it from ubuntu, i need AC3 passthrough
<ion> :-D
<siretart`> I've already did the necessary uploads
<siretart`> unimatrix: try #ubuntu. they will explain you what 'apt-get remove pulseaudio' does.
<blackxored> Hello, I'm just finishing the debian NM process, I'm waiting for DAM approval for becoming an official debian developer, I'm now just wondering if the process in ubuntu is easier than the one I've just passed, to see if I can become an ubuntu dev or MOTU as well, any clues?
<ion> unimatrix: That kind of attitude will get you far.
<unimatrix> ion: but PA people don't like it when you're being nice, they just ignore feature requests
<siretart`> blackxored: try the links in the #ubuntu-motu channel. you'll still need to do a report and stuff, but the process is much easier and faster than NM in debian. espc. because your debian contribution count as ubuntu contributions.
<blackxored> siretart, great let me check the topic at that channel since I'm there as well
<ion> Whatâs the point of AC3 passthrough in the first place? Why not simply decode the audio data just like all other audio data and then send it out using whatever method is available; for instance an AC3 output or an analog multi-channel output?
<Laney> siretart`: They do? I mean, does that imply that any DD can automatically become an Ubuntu developer?
<Laney> I would expect some kind of Ubuntu-specific experience too
<siretart`> ion: because you might want to use the external AC3 decoder below your TV?
<siretart`> Laney: no, I didn't say that
<ion> siretart: How would this method hinder that?
<siretart`> ion: because you do not want your computer decode ac3, but some external device?
<unimatrix> ion: here's another example... your CPU is old, but you have an external decoder...
<siretart`> or the speakers are connected to the external device only?
<cjwatson> Laney: it's a fast track, not a no-effort track. :-)
<Laney> cjwatson: Yeah I was trying to get at the fact that while previous Debian contributions may count somewhat towards an Ubuntu development application, it should only act as an informal shortcut and not a back door
<Laney> A large part of assessing new developers seems to be determining that they know what they're doing technically, and Debian work should count for that
<cjwatson> I think it's a formal shortcut; I'm fairly sure we've explicitly advertised that Debian developers will find it easier
<Laney> well it at least doesn't seem to have a place in the applications procedure
<Laney> whether it's something that the DMB or whoever will take into account is another matter
<\sh> Keybuk, does upstart clean somehow /var/run after a job is stopped or finished?
<Laney> but I don't know practically what people assessing applications would want to see from a DD wanting to be an Ubuntu developer
<\sh> EUREKA ! I found a bug
<Keybuk> \sh: no
<\sh> Keybuk, ok...something removes /var/run/network directory, which you create inside /etc/init/network-interface in pre-start
<\sh> Keybuk, therefore ifup -a inside /etc/init/networking.conf fails
<\sh> adding pre-start script mkdir -p /var/run/network end script inside /etc/init/networking.conf helps to come up with all interfaces which /e/n/i defines
<\sh> Keybuk, http://paste.ubuntu.com/316095/ <- this works as expected
<cjwatson> Laney: that they've figured out how Ubuntu works, and normally a quick double-check on technical clue
<\sh> soren, can you check if that helps you with your briding stuff, too?
<Keybuk> \sh: why use a pre-start script there
<Keybuk>   script
<Keybuk>     mkdir -p /var/run/network
<Keybuk>     exec ifup -a
<Keybuk>   end script
<Keybuk> would be better
<\sh> Keybuk, you are the expert, I just wanted to make it work ;) now to find the bugger who removed /var/run/network after a job is stopped/finished..
<Keybuk> no idea
<Keybuk> /var/run is a tmpfs ;)
<Keybuk> maybe you forgot "local-filesystems" in the ...and bits
<Keybuk> maybe I forgot too :p
<\sh> Keybuk, as you can see in the paste output, I didn't it's the normal job script for this
<\sh> Keybuk, start on (local-filesystems and stopped udevtrigger) is the default content...so something else is triggering a removal
<Riddell> doko_: gdb is still compiling, does this test suite really take a day to complete?
<\sh> it works...
<hdon> should gcc option -std=gnu99 define the _GNU_SOURCE macro?
<ion> Probably not.
<doko_> Riddell: no, this doesn't sound right
<Riddell> doko_: they all seem to be failing too
<Riddell> expect is running but it's not running very fast or using up much CPU
<\sh> Keybuk, could be that /etc/init/networking.conf is being executed before /etc/init/network-interface.conf which means, /var/run/network is really not available at this time
<Keybuk> yes, that's possible
<\sh> Keybuk, testing your idea with "script..." only.
<Keybuk> robbiew_ is brave
<Keybuk> even I didn't just install those packages and reboot <g>
<ion> Which packages?
<StevenK> Keybuk: But robbiew_ does know where you live :-)
<mathiaz> when are conffiles installed? during the unpack phase or the postinst phase?
<Keybuk> robbiew: did it work?
<doko_> Riddell: which version do you try to build?
<robbiew> sort of :/
<Keybuk> ion: plymouth ones
<Riddell> doko_: the one from karmic
<Riddell> doko_: with the pie patches removed
<Keybuk> robbiew: sort of is unsurprising, even I haven't tested it yet :p
<\sh> Keybuk, should I add a debdiff to ifupdown bug #446031 with the change ?
<ubottu> Launchpad bug 446031 in ifupdown "statically configured network interface does not come up at boot" [Undecided,New] https://launchpad.net/bugs/446031
<robbiew> I saw plymouth stuff on shutdown..but nothing on reboot
<Keybuk> \sh: sure
<robbiew> except usplash was removed
<Keybuk> robbiew: yeah, there might be no startup splash yet <g>
<Keybuk> but it works on shutdown <g>
<doko_> Riddell: strange, not seen on the buildds. we once had the lpia build taking way long in the testsuite, but didn't investigate (neither kees nor me)
<Riddell> doko_: meh, I'll try some different things then
<robbiew> Keybuk: and apparently /usr/sbin/plymouth-set-default-theme requires nash :/
<StevenK> robbiew: bash, even?
<Keybuk> robbiew: haha, fail
<Keybuk> StevenK: no, nash :p
<StevenK> Hm. I just tried to look for that and failed
<Keybuk> StevenK: install RedHat
<Keybuk> it's their NIH shell ;)
 * StevenK shivers
<Keybuk> they are killing it
<Keybuk> in favour of dracut
<StevenK> Ooooh, another shell I haven't heard of. Fun!
<Keybuk> dracut is their NIH initramfs-tools
 * StevenK sobs
<StevenK> What is it with RedHat giving things crappy names that have no relation to their function?
<Keybuk> kudzu!
<ion> ubuntu!
<StevenK> Ubuntu *does* relate
<ebroder> "byobu" :-P
 * Keybuk wishes he didn't hear elmo everytime anyone says that
<cjwatson> StevenK: I suppose there are tenuous justifications for casper and ubiquity
<cjwatson> casper => magic ghost (since hardly anyone really understands live CD boot, or did at the time)
<mvo> robbiew_: what plymouth packages? not the ones in the plymouth ppa?
<cjwatson> ubiquity => get Ubuntu everywhere
<Keybuk> the ones in alberto's ppa
<StevenK> cjwatson: Right, there's a connection, albeit one that you have to squint and turn your head for, but it does exist
<mvo> aha, ok. the one in the plymouth one is broken, happy to hear that alberto is fixing it
<Keybuk> upstart => start up, but done the other way round to everyone else
<cjwatson> StevenK: that may be the case for dracut, for all we know :)
 * mvo should borrow his package and drop into the plymouth ppa
<\sh> Keybuk, updated #446031 ->
<StevenK> It's a special cut of crack that includes drano?
<Keybuk> cjwatson: isn't dracut just the town where harald lives?
 * StevenK wildly guesses
<cjwatson> Keybuk: could well be, since it's a town in MA
<cjwatson> I'll have to call my next project belfast. cambridge is probably used for something already
<StevenK> Oooh. Named after the town the author lives in. That thread just snapped
<Keybuk> Plymouth, MA as well
<Keybuk> Fedora 10 was "Cambridge"
 * Keybuk senses a naming scheme here
<Keybuk> mvo: broken how>?
<StevenK> Keybuk: Haha, sounds like one
<Keybuk> mvo: it looks like he's updated it to 0.8.0 from your PPA
<Keybuk> cjwatson: if I were to name something after the town in which I was born, it'd be "Crawley"
<Keybuk> which is ...
<Keybuk> unfortunate
<cjwatson> it has to be a horror to do that
<StevenK> That name just makes me think of a book by Neil Gainman
<StevenK> Whose name currently escapes me
<cjwatson> that was Crowley :) and you mean Good Omens
<StevenK> Ah yes!
<StevenK> So close!
<Keybuk> The Nice And Accurate Prophecies of Agnes Nutter, Witch
 * StevenK needs to re-read that
<StevenK> Hm. The lag from being on an airplane at 37,000 ft isn't so bad
<StevenK> It doesn't feel like two-way satellite, at least ...
<maco> bragging about that airplane-with-tube-access?
<StevenK> Not bragging, surprised
<Keybuk> mvo: looking at this, I suspect this comes from a secret OEM stash of packages they don't give the Platform team <g>
<mvo> Keybuk: I have not investigated, it seems like in the plymouth ppa something with the initramfs generation goes wrong (a file missing maybe) or something
<Keybuk> probably stored in a candy jar or something
<mvo> Keybuk: haha
 * mvo was always good at plundering the candy jar
<Keybuk> it's got an ubuntu theme in it and *everything*
<Keybuk> written by someone called Michael Terry
<highvoltage> mvo: and you admit to it in public? last time I said something like that I got 13 requests on facebook to join a all kinds of cookie jar groups!
<mvo> highvoltage: weehh, scary - and this channel is logged too
<mathiaz> Keybuk: upstart job question - I've got one upstart job that start avahi-publish with a script stanza
<mathiaz> Keybuk: now if avahi-daemon is restarted, the avahi-publish process dies
<mathiaz> Keybuk: how can I make sure that the avahi-publish job will be restarted if avahi-publish dies?
<Keybuk> respawn?
<mathiaz> Keybuk: \o/ - awesome! Thanks
<hdon> using -DDB_DBM_HSEARCH=1 in order to enable the historic ndbm api #defines causes many redeclaration errors http://pastebin.mozilla.org/682943
<hdon> donny@pacemates:~/gpsee/src$ echo -e '#include <pthread.h>\npthread_cleanup_push(foo, bar)' | gcc -Wall -E - | tail -n 1
<hdon> do { __pthread_unwind_buf_t __cancel_buf; void (*__cancel_routine) (void *) = (foo); void *__cancel_arg = (bar); int not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *) __cancel_buf.__cancel_jmp_buf, 0); if (__builtin_expect (not_first_call, 0)) { __cancel_routine (__cancel_arg); __pthread_unwind_next (&__cancel_buf); } __pthread_register_cancel (&__cancel_buf); do {
<hdon> what is with the malformed output of that macro?
<dariocaruso> salve! vorrei chiedere a qualcuno quanlche info sul file changelog
<dariocaruso> devo caricare un programma su launchpad
<dariocaruso> ma launchpad lo rigetta
<dariocaruso> suppongo che dipenda dal file changelog
<dariocaruso> c'Ã¨ qualcuno?
<Goga777> soren, could you have a look please on libmms 0.5 patch http://launchpadlibrarian.net/35334345/checkborders.diff thanks
<mathiaz> james_w: hi
<mathiaz> james_w: seems that apr-util pkg branches are not up-to-date
<mathiaz> james_w: for lucid and squeeze
<billisnice> my kid said 9.10 sucked...lol
<ion> Thatâs okay, he sucks, too.
<billisnice> girl, the screen redraw and it hangs is so bad
<billisnice> i hope it is being worked on
<maco> teach her to file a bug?
<Keybuk> ion: I'm delighted by a find
<Keybuk> plymouth in git gained an X11 backend "for debugging" :-)
 * Keybuk feels some abuse coming
<ion> keybuk: :-)
<billisnice> 9.04 worked faultlessly on an old dell, but this so bad
<Keybuk> I wonder whether it's possible/easy to live switch renderers in plymouth
<ion> That would be neat.
<Keybuk> I reckon it is
<Keybuk> so rather than quitting plymouth when X starts, you'd do plymouth --hide-splash and plymouth --show-splash either side
<mathiaz> zul: bug 472924 - why sync from unstable instead of testing?
<ubottu> Launchpad bug 472924 in apr-util "Please sync apr-util-1.3.9+dfsg-3 from debian unstable." [Undecided,New] https://launchpad.net/bugs/472924
<zul> mathiaz: cant remember why
<mathiaz> james_w: hi - I've tried to use the merge-package command to merge libdbd-mysql-perl
<mathiaz> james_w: following https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<mathiaz> james_w: it failed with an error: bzr: ERROR: The upstream branches for the merge source and target have diverged.
<mathiaz> james_w: not sure what to do next.
<mathiaz> james_w: I don't see why the upstream branch would have diverged between lp:debian/squeeze/ and lp:ubuntu/lucid/
<cjwatson> hdon: it isn't malformed, you're just not permitted to use pthread_cleanup_push without pthread_cleanup_pop. See the comments in the header file
<slangasek> mathiaz: because the package is at a different upstream version in Debian vs. Ubuntu
<slangasek> mathiaz: trying this merge here, I get an error message that says "resolve these conflicts, commit, and rerun merge-package"?
<mathiaz> slangasek: yes - this is what I get
<mathiaz> slangasek: the conflicts are in the upstream branch
<mathiaz> slangasek: I thought I wouldn't have to touch the upstream branch
<slangasek> mathiaz: <shrug> ideally no, but the Ubuntu package (at least) appears to have a patch applied directly to the upstream source
<slangasek> mathiaz: so merge-package has a harder job to do, that does involve merging the upstream source
<mathiaz> slangasek: on a related note - if I managed to get the merge right, how do I create the orig file?
<slangasek> mathiaz: <mumble, handwave>
<mathiaz> slangasek: bzr bd -S will take care of everything?
<slangasek> not AFAIK; I think you have to grab it from somewhere - e.g. from merges.u.c
<slangasek> bzr-builddeb does depend on pristine-tar, but the infrastructure to use it doesn't seem to be there yte
<slangasek> yet
<mathiaz> slangasek: ok - thanks for helping out.
<slangasek> n/p
<mathiaz> slangasek: I'll use the merge command instead
<mathiaz> slangasek: bzr merge lp:debian/libdbd-mysql-perl worked as expected
<slangasek> heh, ok
<mathiaz> slangasek: and I don't plan to push the branch to LP - so it should work out correctly - I'll give it a try
 * slangasek punches NFSv4+ftruncate in the neck
<mathiaz> hm - I run into a bzr ci error now: there is utf-8 character (the arrow) in the changelog
<mathiaz> and bzr bails out
<mathiaz> james_w: lifeless: http://paste.ubuntu.com/316411/
<cjwatson> Keybuk: does merges.ubuntu.com work now that it has a sensible dpkg?
<Keybuk> ValueError: process failed 25: dpkg-source -x xbuffy_3.3.bl.3.dfsg-6.dsc /srv/patches.ubuntu.com/unpacked/x/xbuffy/3.3.bl.3.dfsg-6
<Keybuk> hmm
<cjwatson> http://packages.qa.debian.org/x/xbuffy/news/20091101T002911Z.html looks perhaps relevant
<cjwatson> maybe we need quilt installed?
<Keybuk> maybe :D
<cjwatson> actually I think it was just a bug in that version of the package
<cjwatson> judging from the next changelog along, anyway
<Keybuk> yeah
<Keybuk> I'll wipe it from the cache
<Keybuk> the -7 is in there
<cjwatson> though having quilt installed would insulate us from this
<Keybuk> elmo: can you add quilt
<elmo> Keybuk: done
<Keybuk> elmo: thanking you kindly
<Keybuk> \o/
#ubuntu-devel 2009-11-12
<billisnice> what programming language is mainly used in Ubuntu development?
<TheMuso> billisnice: Python is used a fair bit.
<cjwatson> also quite a bit of C (and too many other languages to list, at varying concentrations), and packaging requires make and shell
<cjwatson> flexibility to pick up new languages quickly is more important than raw proficiency in any single language, IMO
<TheMuso> Agreed.
<hdon> cjwatson: yes, thanks, someone else already schooled me about those particular macros ;)
<LlamaZorz> Hey guys,does anybody know when firefox forks for the flash plugin?
<slangasek> james_w: debian/squeeze/egenix-mx-base also out of date
<slangasek> james_w: in this case, debian/egenix-mx-base also appears to be out of date
 * cody-somerville wonders why dbus-daemon would be eating up 30-50% cpu.
<fagan> cody-somerville: it depends on the traffic
<fagan> its either that or its a bug
<cody-somerville> strace shows it polling over and over and over and each time it says resource unavailable
<fagan> weird
<cody-somerville> I'm thinking its a bug in gnome-system-monitor since gnome-system-monitor is refusing to exit now
<m4t> dbus-monitor show anything?
<cody-somerville> oh yes
<cody-somerville> just as I suspected
<fagan> gnome-system-monitor is a hog anyway
<m4t> hrm which monitors do you have enabled?
<cody-somerville> I think its trying to get info about two loop back devices I have mounted
<fagan> Are the devices properly mounted and recognised at the moment?
<m4t> maybe i have 'gnome-system-monitor' confused with the system monitor panel applet
<fagan> m4t: system>admin>system monitor
<cody-somerville> ah
<m4t> yea. /usr/bin/gnome-system-monitor
<cody-somerville> it was actually the cd in my cdrom drive that was the problem
<cody-somerville> after ejecting it, gnome-system-monitor quit and dbus is much quieter now.
 * m4t uses htop for that sort of thing
<m4t> no pretty graphs though
 * fagan doesnt use cds anymore
 * fagan loves the pretty graphs
<fagan> I cant wait for the UDS :)
<chrisccoulson> cody-somerville - i've seen that issue with gnome-system-monitor as well (and there's a bug report for it too)
<chrisccoulson> it actually seems like a loop in gvfs somewhere
<fagan> cody-somerville: how do you force an upgrade to lucid?
 * fagan got it, good google :)
<sconklin> I am obviously missing something - how can I change the date in karmic - I need to set it into the past to workaround a bug
<sconklin> The admin applet changes it back, even though manual configuration is selected
<mustakrakish> need help with PGP key for repo's http://paste.ubuntu.com/316517/
<mustakrakish> need help with *GPG key for repo's http://paste.ubuntu.com/316517/
<cjwatson> mustakrakish: #ubuntu, please
<maxb> mustakrakish: That is not a development question, so is offtopic for this channel. Please see the general user support channel, which is #ubuntu .
<new_to_linux> hi
<fagan> new_to_linux: hi
<new_to_linux> please help, there is no install button in ubuntu software centre
<mustakrakish> apply
<new_to_linux> i just switched from windows
<ScottK> new_to_linux: The best channel for getting questions like that answered in #ubuntu.
<new_to_linux> ScottK: thanks
<dholbach> good morning
<smwn> morning
<dholbach> hi smwn
<smwn> can I hear a w00p
<pitti> Good morning
<dholbach> smwn: http://photos-c.ak.fbcdn.net/hphotos-ak-snc1/hs202.snc1/6935_251765935091_893075091_8788600_1697850_n.jpg
<smwn> HAHA
<\sh> moins
<liw> tkamppeter, I got my Brother label printer to work yesterday; what's the best way to get that support included in Ubuntu (on the assumption that I don't want to maintain it myself)? should I file a bug and if so, against which package?
<tkamppeter> liw, how did you get your printer to work? Did you download a driver? Is the driver free software? Is it from Brother
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
 * pitti fiddles with tzdata's 3.0 package format until it works with launchpad again
<tkamppeter> pitti, it is about the auto-downloadable drivers. Does Ubuntu ship any download keys for any hardware manufacturers, like NVidia or so?
<Riddell> pitti: amichair is a new member of Team Kubuntu and has been fixing various bugs in Kubuntu apps recently.  he's looking at jockey-kde today and may have some questions to get into the codebase
<pitti> Riddell: oh, great
<pitti> amichair: hello :)
<pitti> tkamppeter: no, not right now
<amichair> pitti: hey there
<pitti> tkamppeter: ideally we wouldn't need to, and just download them on demand; that would require them to be signed by a key that we already trust, though
<pitti> tkamppeter: (well, we need to trust the key either way)
<amichair> pitti: first thing, I'm just looking through jokey-kde bug reports, and I can't quite distinguish between backend and gui bugs (most of them just say 'crash') - do u have more specific info on something I can start out with?
<amichair> pitti: second, I notice there are a bunch of sys.exits around - is this normal? is there nothing requiring orderly shutdown in there?
<pitti> amichair: I'm afraid you have to look at the stack trace; a d-bus error is a backend crash, while most of the rest (sigsegv, etc.) are most probably bugs in python-qt4 or python-kde4
<pitti> amichair: without calling sys.exit(), there are some remaining processes/threads which aren't autocleaned for some reason
<amichair> pitti: hmmm...
<pitti> amichair: bug 458662 is similar
<ubottu> Launchpad bug 458662 in apport "apport-kde: "Invalid problem report: Package nonexistentarg does not exist" => OK => still "Collecting problem information" dialog" [Low,Fix released] https://launchpad.net/bugs/458662
<pitti> amichair: (please note that I didn't actually write most of jockey-kde)
<amichair> pitti: (and I have no previous dev experience with linux, kubuntu, kde, qt or pythong... I think we'll make a great team! :-) )
<pitti> hah
<tkamppeter> pitti, the concept is that manufacturers supply the keys and the distros include the keys from manufacturers which they trust.
<pitti> tkamppeter: well, those are two different "trust" here
<pitti> tkamppeter: we can decide which manufacturer we trust to build good packages -- those are the ones which we can offer
<pitti> tkamppeter: but trusting a key is entirely different, it requires identity verification
<tkamppeter> pitti, this way the distros have to trust the manufacturers and not the LF and only manufacturers and not the LF take responsibility.
<liw> tkamppeter, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555892 has details
<ubottu> Debian bug 555892 in wnpp "RFP: ptouch-driver -- CUPS/Foomatic driver for Brother P-touch label printers" [Normal,Open]
<pitti> i. e. a trusted path through signatures to their key
<pitti> tkamppeter: so, if the manufacturer's key is signed by someone who we trust, we can just download it on demand; but conversely, if we can't trust the manufacturer's key, then shipping the key by default doesn't increase the confidence in it by any way
<pitti> (to the contrary, we would make ourselves untrustworthy with key handling)
<tkamppeter> pitti, so what do I need to tell the manufacturers what they have to do with their keys so that their packages get auto-downloaded? Who must sign their keys so that all distros accept their keys?
<directhex> are we not autosyncing new packages from squeeze?
<ScottK> We are.
<ScottK> Autosync is not, however, a continuous process
<Keybuk> or, in fact, an automatic process ;)
<ScottK> It's done periodically.
<ScottK> That too
<directhex> how periodic? the packages i'm noticing were all in squeeze when karmic shipped
<pitti> tkamppeter: well, you know how key signing works?
<ScottK> Well it's run once since then.
<pitti> tkamppeter: either there's a central authority (like the LF) that generates a key and signs driver manufacturer keys, or we have to meet with them directly to sign them
<pitti> tkamppeter: in the first case, all distros would sign the LF key, and the LF woudl sign all the manufacturer keys; in the second case, each distro has to sign each manufacturer key
<slangasek> directhex: it's conceivable that there hasn't been a new package sync run yet, I know I didn't make it that far on archive day on account of spending my time updating the sync blacklist for existing packages instead
<slangasek> Keybuk: have some time to talk about boot-time hdparm settings?
<directhex> slangasek, oh, debian syncs still go into binary NEW don't they? let me check
<tkamppeter> I know about keysigning session where people meet physically and sign the GPG keys of each other, is a physical meeting of a Ubuntu/Canonical representative with one representative of each manufacturer needed for this signing? Or is there a way by internet and phone to do this?
<Keybuk> slangasek: sure
<tkamppeter> pitti: ^^
<slangasek> Keybuk: so it's a no-brainer that the current behavior, which may cause multi-second delays at boot time, is wrong; but I think we still need to be setting the configured apm policy at boot time
<Keybuk> slangasek: "still" ?
<Keybuk> we don't set that right now
<Keybuk> the hdparm udev rule comes from the days where we had to futz with DMA settings and stuff
<slangasek> hmm, we do, actually... though perhaps we only set it via /etc/init.d/acpi-support
<Keybuk> obviously since libata, that isn't used
<Keybuk> slangasek: I just grepped through that, couldn't find anything about hdparm
<Keybuk> wing-commander /etc% grep -r hdparm init init.d acpi power pm
<Keybuk> init.d/bootlogd:# X-Start-Before:    hostname keymap keyboard-setup procps pcmcia hwclock hwclockfirst hdparm hibernate-clean
<pitti> tkamppeter: you can't do it by internet, since the purpose of this is to have physical evidence that the key creator is actually the one he pretends to be ("can't pull yourself out of the swamp")
<Keybuk> --
<slangasek> Keybuk: /etc/init.d/acpi-support calls /etc/acpi/power.sh calls pm-powersave calls /usr/lib/pm-utils/power.d/95hdparm-apm
<tkamppeter> liw, you tell in the Debian bug report that you have reported your problems upstream. Did you get any answer from the upstream author?
<Keybuk> ahh
<Keybuk> slangasek: got you
<liw> tkamppeter, not yet
<pitti> tkamppeter: phone is better, but not as trustworthy than seeing someone in an office, with a passport, etc.
<directhex> slangasek, nope, doesn't look that way. remind me to check next time the sync run happens
<Keybuk> slangasek: is that one of our scripts, or an upstream one?
<slangasek> Keybuk: dunno offhand; can check
<Keybuk> slangasek: you were thinking we should do that by calling out to hdparm on the drive in a udev rule instead?
<slangasek> Keybuk: now as for the current udev script not doing apm settings... it applies any settings the user has configured in /etc/hdparm.conf, including apm and spindown, and nothing else does this by default
<slangasek> (granted, that's not where we configure the system default apm settings, so yes, by default that part is a no-op)
<tkamppeter> pitti: The problem with a key at the LF is that this could imply that the LF would take responsability on the manufacturer's driver packages.
<pitti> tkamppeter: if the manufacturer has a working SSL certificate, they might also put the key and fingerprint on their web page (with https); that might actually work better
<pitti> tkamppeter: as I said, trusting a key and trusting a package are completely independent
<slangasek> Keybuk: the point I think we want to get to is that there's a single call to hdparm for each drive at the very end of the init sequence for any drives then available, and a udev rule that picks up any drives added after
<pitti> tkamppeter: just because I am convinced that a key that says "Joe Sixpack" really belongs to a physical person "Joe Sixpack" does not mean that I trust any of his actions :)
<tkamppeter> Working SSL certificate meas that their site is trusted by some certification authority?
<liw> tkamppeter, I need to leave now; when you have time, if you can check the Debian bug I referred to for the ptouch-driver package, that would be most helpful, thanks
<pitti> tkamppeter: yes
<slangasek> that would mitigate the effects of hdparm on boot performance
<pitti> the chain has to start somewhere with a physical identity proof
<slangasek> (and if the udev rule itself is doing things that are inappropriate, we can fix that along the way)
<tkamppeter> pitti, will that be enough to trust the manufacturer's keys when they come from this site with SSL certificate via https?
<Keybuk> slangasek: it's not the effect of hdparm I care about
<Keybuk> just the unconditional sync in the existing rule ;)
<pitti> tkamppeter: well, "enough" is a matter of taste, but I think for these purposes yes
<Keybuk> udev doesn'tre
<pitti> tkamppeter: since otherwise people would download them directly from their web site, which involves the same trust (SSL cert)
<Keybuk> udev doesn't really work in a "don't do it during boot but do it later" kind of way
<Keybuk> frankly even upstart doesn't have a "very end of the init sequence" kinda thing
<Keybuk> wouldn't it be better to do the hdparm calls for each drive from udev
<slangasek> Keybuk: right; I don't understand why that unconditional sync is there, but the effect is obvious
<Keybuk> including setting user settings and apm settings?
<Keybuk> that way you get a single hdparm call per drive
<Keybuk> which is called before the drive is actually used
<slangasek> Keybuk: well, <cough> users with /usr on a separate partition aren't guaranteed to have the on_ac_power command available when the udev rule runs, so we would still have to re-apply the correct apm setting later
<Keybuk> slangasek: is that the thing in /usr/bin that only looks in /proc and /sys ? :p
<Keybuk> and is only in /usr because someone wrote it in awk
<slangasek> heh
<tkamppeter> pitti, so what I have to tell the manufacturers is to have an SSL certificate for their site from which the keys and packages should gget downloaded?
<slangasek> it's also in /usr because it's not related to system recovery
<Keybuk> would probably be better to fix *that*
<Keybuk> since we already have the "can't call on_ac_power to decide whether to fsck /usr" thing :p
<slangasek> yeah, that's a possibility
<pitti> tkamppeter: well, either we need to sign their GPG key, or they must have an officially signed SSL cert and put the key/fingerprint on their website
<tkamppeter> pitti, are there any requirements on where to place the keys relative to the packages so that the download tools find it?
<slangasek> ok; so if we get on_ac_power in /bin where we can rely on it, then we can use the udev rule for all boot-time settings, and just arrange to make pm-powersave not call hdparm when invoked from init
<pitti> tkamppeter: if the GPG keys have a proper signature, they should just be on the keyserver network
<slangasek> and then remove that sync if we can confirm it's bogus
<pitti> tkamppeter: if not, then we need to include them (in jockey or whereever)
<slangasek> Keybuk: ^^ sound right?
<Keybuk> slangasek: yup
<slangasek> ok
<slangasek> Keybuk: cheers :)
<Keybuk> slangasek: the sync is almost certainly bogus in Ubuntu
<Keybuk> I can imagine why it's there in Debian
<Keybuk> (udev runs after things are mounted)
<slangasek> hmm
<Keybuk> I can't think of any way a udev rule could run on a mounted filesystem ;)
<slangasek> why does udev run after things are mounted in Debian, either?
<Keybuk> slangasek: I haven't looked at Debian in a while, but udev used to run very late
<Keybuk> like after /usr was mounted
<slangasek> /etc/rcS.d/S03udev
<Keybuk> it wasn't always there though, right?
<tkamppeter> pitti, what I now need to do is to put together some step-by-step instructions of generating keys, getting them signed or getting them onto an SSL-certified web site, what to provide to the download tools and where, ... Note for that that many manufacturers are not very Linux-aware.
<Keybuk> the hdparm udev rule is old ;)
<Keybuk> and converted from an even older init script
<Keybuk> slangasek: ah
<Keybuk> but S03udev just means udevd
<slangasek> Keybuk: I don't see any record in the udev package of an init script migration
<Keybuk> you could still have the block device appear later? even though it's already been mounted
<Keybuk> slangasek: I'm only guessing :)
<slangasek> hrm, how would it /get/ mounted in that case?  static device node?
<slangasek> S03udev includes udevadm trigger/settle calls
<Keybuk> maybe
<slangasek> let me dig through the hdparm package, to see why this rule /really/ does what it does
<Keybuk> at least we absolutely guarantee that we don't mount things until udev is done with them :p
<Keybuk> slangasek: oh, I think it's always been there
 * Keybuk wrote that script
<slangasek> oh? :)
<Keybuk> and it looks like I just copied that from the old init script
<slangasek> odd, the changelog says thom wrote it
<Keybuk> thom uploaded it
<slangasek> ah
 * Keybuk was on the Launchpad team at the time
<Keybuk> (technically :p)
<Keybuk> ahh
<Keybuk> Vibe
<Keybuk> that was a good UDS
<slangasek> yeah, this -q -f goes all the way back to warty
<slangasek> ahwell
<Keybuk> slangasek: hole in the ground, with water in it
<yoshi765> DAMN UBUNTU
<Tm_T> !op | yoshi765
<ubottu> yoshi765: Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<slangasek> yoshi765: not an appropriate use of this channel.
<yoshi765> stfu
<Hobbsee> clearly going to have a lot to say...
<Tm_T> Hobbsee: shame this is one of the few channels I don't have rights ):
<Hobbsee> heh :)
 * Tm_T doesn't like just watch when there's some cleaning to do
<amichair> pitti: when selecting to activate a driver in jockey, is there anything done that might take a long time? does it download anything? or it's supposed to be pretty much immediate?
<pitti> amichair: sorry, was at lunch; yes, it will take a long time, which is why it spawns a progress dialog
<pitti> it needs to download, unpack, install, etc.
<amichair> pitti: ok, my test did a quick one so didn't see progress bar, and wondered if I should add one :-)
<pitti> amichair: there should be one already; it works for me, anyway
<amichair> pitti: ok, thanks
<pitti> tkamppeter: instead of adding the "LogDebugHistory" to cupsd.conf in a patch, can you please just change the internal default? This will (1) keep the setting for admins who changed it, and (2) avoid a conffile change
<pitti> tkamppeter: also, I think "2000" is a more reasonable limit than "999999" -- the latter would potentially result in a 100 MB log file
<tkamppeter> pitti, I would leave the big value, as this makes the logging more or less unlimited. There should not be that many "DEBUG:" messages in the filters. Up to now in user-supplied error_logs in bug reports such an excess never happened.
<tkamppeter> pitti, it is worse if some lines are missing in a user-supplied error_log.
<pitti> but if they do, it'd be more or like a DoS of hard disk and bug trackers
<pitti> well, but a million lines?
<pitti> if there's something logging more than 1000 lines about an incident, this is certianly of questionable utility?
<tkamppeter> A million lines is never reached. 10000 will perhaps happen.
<pitti> so, let's make it 10000 then?
<slangasek> Keybuk: hmm, the awk stuff is only used for PMU and APM... could just ignore this :-P
<slangasek> Keybuk: do you happen to know if non-apci systems shoul also have /sys/class/power_supply/?
<Keybuk> slangasek: they should
<Keybuk> whether they do yet or not ...
<Keybuk> *cry*
<Keybuk> why is gdb skipping the entire body of the function when I do "n"
 * Keybuk blames kees
<slangasek> so I could move that block outside of the "if /sbin/acpi_available" check, and make the awk stuff Somebody Else's Problem
<pitti> tkamppeter: FYI, I'm updating to 1.4.2 to grab the security fix
<tkamppeter> pitti, I will add a fix to pdftopdf, got it from Otani-san today.
<tkamppeter> pitti, you have reverted my last commit?
<pitti> right
<Keybuk> doko: around?
<sladen> pitti: how should I poke apport to stop it reporting particular seahorse-agent crash dumps.  There's a couple of thousand dups to bug #429322 (to the point that it has broken LP) and more stack-trace uploads probably aren't really necessary
<ubottu> Launchpad bug 429322 in seahorse-plugins "seahorse-agent assert failure: ERROR:iop-profiles.c:606:IOP_generate_profiles: assertion failed: (obj && (obj->profile_list == NULL) && obj->orb)" [High,Confirmed] https://launchpad.net/bugs/429322
<pitti> slangasek: there is an apport bug pattern for it since Tuesday or so
<pitti> so it shouldn't even be possible to report further dups
<pitti> (and yay for the bug which kept apport enabled after stable release :-( )
<tkamppeter> pitti, pdftopdf fix from Otani-san is committed.
<sladen> pitti: the dups are still arriving, or so that just the tracer catching up
<doko> Keybuk: otp
<pitti> sladen: retracers still have a huge backlog unfortunately
<pitti> (for the same reason, swamped after final release)
<Keybuk> doko: when you get back, gcc appears to have deleted the entire body of a function when compiling with -O0 ... how would I debug that ? ;p
<maxb> james_w: Hi, are you around today? I was wondering if you could comment on bug 481097
<ubottu> Launchpad bug 481097 in udd "subversion 1.6.6dfsg-1 in Debian not imported to branch" [Undecided,New] https://launchpad.net/bugs/481097
<doko> Keybuk: hmm, do you have a test case? when did this "optimization" start?
<pitti> tkamppeter: btw, I'm going to do an upload now, but I fully expect that I have to do another one next week or so (new poppler in Debian didn't build yet everywhere, and I need to test it on mips again for the PIE issue)
<pitti> tkamppeter: so, if you have other pending fixes they don't need to wait long
<tkamppeter> pitti, I have also done the LogDebugHistory fix now.
<pitti> ah, thanks
<tkamppeter> Simply bzr pull and you have it.
 * pitti cancels build and builds again
<Keybuk> doko: s'ok, was a code error ;)
<Keybuk> silly upsream
<Keybuk> if (console->fd < 0);
<Keybuk>   return
<doko> heh
<tkamppeter> pitti, can you help me on getting step-by-step instructions together for the manufacturers about generating keys, signing them or putting them on an SSL-certified site, signing the packages, so that users can easily get their drivers auto-downloaded?
<theclaw> hi
<theclaw> everytime firefox gets updated, the "quick search" entries get replaced/updated
<theclaw> is this behaviour wanted?
<dholbach> pitti: do you have access to robert_ancell's seahorse fix?
<dholbach> pitti: there's like 3000 subscribers on the bug already
<dholbach> mostly due to duplicates
<pitti> tkamppeter: there's plenty of tutorials already; let's sit down next week and write/link something
<pitti> dholbach: it should already be in karmic-proposed
<pitti> dholbach: what do you mean with "access"?
<dholbach> pitti: the bug is timing out in LP - good to know the fix is on its way :)
<pitti> dholbach: yeah, took me like ten times to get the page, too :-(
<pitti> mail responses FTW
<Riddell> seb128: where did you upload the fix for bug 462049 to, lubic or -proposed?
<ubottu> Launchpad bug 462049 in libindicate "Plasma crashes unexpectedly" [High,Fix committed] https://launchpad.net/bugs/462049
<Riddell> ..lucid
<jussi01> Riddell: did you notice my comment about the links to kubuntu stuff on summit this morning?
<Riddell> jussi01: nope, what was that?
<seb128> Riddell, proposed we pocket copy then
<jdong> lubic :)
<seb128> Riddell, why?
<jussi01> Riddell: just that the links on the summit calendar pages go to non-existant wiki pages when they should go to the corresponding LP pages...
<Riddell> seb128: I just didn't see it in the queue, but there it is now
<jussi01> Riddell: click on kubuntu lucid development here for instance: http://summit.ubuntu.com/uds-l/2009-11-16/
<Riddell> jussi01: I have complained about this but I don't know if I complained to the right person and I probably didn't complain in the right way
<jussi01> Riddell: ok, Ill go annoy jorge and jono about it
<jussi01> Riddell: Ill try make sure it happens
<Riddell> pitti: mind if I accept the SRU for bug 462049 into -proposed?  upstream are getting grumpy about it
<ubottu> Launchpad bug 462049 in libindicate "Plasma crashes unexpectedly" [High,Fix committed] https://launchpad.net/bugs/462049
<mvo> do we have a wiki page that gives a step-by-step instruction how to do/trigger a fsck on the root fs?
 * pitti adds "daily SRU round, take III" to his queue
<pitti> Riddell: will do
<jdong> hahaha
<pitti> mvo: wouldn't tune2fs -C 50 /dev/... do?
<pitti> that's what I usually do for testing
<jussi01> !fsck
<ubottu> fsck is the FileSystem ChecKer, which runs automatically when you boot if you didn't shutdown cleanly. Type "man fsck" for information on running it manually. The command "sudo shutdown -F -r now" will force a reboot and a filesystem check; "sudo touch /fastboot" will skip a filesystem check at next reboot
<jussi01> mvo: ^^
<mvo> pitti: this is similar to what I usually do, but I wonder if that is the way that we suggest to our users
<pitti> mvo: well, I'd recommend -C 50; less dangerous to your data :)
<pitti> mvo: oh, isn't it in friendly-recovery:
<pitti> ?
<mvo> jussi01: thanks
<mvo> pitti: it used to until karmic, now its no longer possible to remount / in ro
<jussi01> mvo: no probs :) If anyone comes across stuff in factoids that is out of date, please lets us know though.
<mvo> pitti: this has to do with upstart changes, I talked to scott about it before the release and he said its intentional
<Keybuk> mvo: it isn't anything to do with upstart
<mvo> Keybuk: right, let me re-phrase it "it used to work by chance, now it does no longer" - better ?
<Keybuk> :) much
<mvo> :)
<tkamppeter> pitti, OK, can you schedule a private meeting for that?
<pitti> tkamppeter: no need to be private; I'll add it
<mvo> Keybuk: hm, shutdown -F is ignored in the upstart code, is there a different magic to force it on restart?
<mvo> Keybuk: nevermind, I think I found it
 * mvo tries touch /forcefsck
<tkamppeter> pitti, with private I meant an informal meeting, without Blueprint.
<smoser> slangasek, ping.
<Ademan> what should i do to find out about the new gdm/xsplash system?  I haven't run into anything from the simple greeter or xsplash that has any documentation...
<Ademan> also while i'm at it... the upstart script for gdm has a seemingly magical variable $CONFIG_FILE, I don't see where that's ever set, is it set by upstart? how?
<lamont> pitti: around?  your comment on bug 447919 is ref: lucid ,yes?
<ubottu> Launchpad bug 447919 in launchpad-buildd "cups testsuite failures don't trigger a build failure" [Undecided,Confirmed] https://launchpad.net/bugs/447919
<Ademan> does upstart set variables that are used in upstart scripts?  for instance the gdm upstart script uses $CONFIG_FILE which isn't set anywhere in the script that i can see.
<StevenK> Ademan: I'm guessing that's set by X, but I can't find anything to back that up
<Keybuk> cjwatson, StevenK: Remember that whole Cambridge, Plymouth, Dracut thing?
<Keybuk> I have another one
<Keybuk> Wayland
<sebner> Keybuk: wayland \o/
<StevenK> Keybuk: Haha
<chrisccoulson> slangasek - i think i understand whats going on with your g-s-d crash now :)
<chrisccoulson> and I think I can see why it regressed from jaunty too
<lhasbs> ubuntu 9.04 server 2.6.28
<lhasbs> massive group descriptor corruption :(
<lhasbs> ext-4: group descriptors corrupted
<lhasbs> Very strange and wierd here.
<slangasek> smoser: pong
<slangasek> chrisccoulson: oh?  Do tell!
<chrisccoulson> slangasek - the section of your xtrace log i quoted in the bug report is all triggered from a single press of Fn+F7. what happens when you press this button is that the screen info is refreshed from the server (because the screen config changed when you connected the monitor). when the screen config changes, a handler in g-s-d autoconfigures the new output. It then acts on the Fn+F7 keypress to reconfigure the output again, wit
<chrisccoulson> h screen information which is now out of date
<slangasek> nice
<slangasek> :)
<chrisccoulson> it didn't crash in jaunty because g-s-d had no handler for auto-configuring new outputs
<chrisccoulson> how soon after connecting the monitor do you press Fn+F7?
<slangasek> chrisccoulson: well, ideally within seconds, I don't go to the effort of plugging in a cable I'm not using :)
<slangasek> but I haven't noticed the monitor ever being autoconfigured for output, without me pressing Fn+F7
<chrisccoulson> what i noticed from the xtrace log is that the Fn+F7 keypress arrives before the first RRScreenChangeNotify event, which should arrive when you connect the monitor
<chrisccoulson> if you say that you've never seen the monitor being autoconfigured, then that would suggest that the RRScreenChangeNotify event doesn't arrive on it's own, and the xtrace log seems to support this
<chrisccoulson> it only arrives after querying the configuration from the server :-/
 * slangasek nods
<chrisccoulson> and that is what seems to mess it up
<chrisccoulson> so there might be a Xorg issue too
<slangasek> sure
<slangasek> though the g-s-d behavior seems to be racy per se
<chrisccoulson> it does. normally the window of exposure should be small if the RRScreenChangeNotify event is delivered when you connect the monitor, but that doesn't seem to happen in your case
<slangasek> yep
<slangasek> (or in the case of other users who've reported this bug previously :)
<chrisccoulson> is bryce around today?
<chrisccoulson> ah, he's in #ubuntu-desktop
<slangasek> right, he doesn't seem to really be around today though
<chrisccoulson> slangasek - i'll add the rest of my thoughts to the bug shortly (so I don't forget them), and then try to get some input from bryce when he's around
<chrisccoulson> slangasek - in the meantime, it might be good to run it through xtrace again, but watch the output in the console and see if you see the RRScreenChangeNotify event when you connect the monitor, or if it only appears after pressing Fn+F7 (just to confirm that I understand what is happening)
<chrisccoulson> i don't know if you can make xtrace filter out specific messages or not
<ebroder> MsMaco: ping?
#ubuntu-devel 2009-11-13
<maco> ebroder: aye?
<maco> ebroder: i gave up on jussi's server coming back
<ebroder> maco: Can you pull together a new debdiff for bug #415766? (I can if you're busy, but I don't want to steal the upload since you've already put work into it)
<ubottu> Launchpad bug 415766 in openafs "evince makes openafs to kernel oops" [Undecided,In progress] https://launchpad.net/bugs/415766
<maco> sure
<ebroder> maco: Cool - jdong is in the same room as me so I can harass him to upload it when you're done O:-)
<jdong> wait what??
<maco> haha
<maco> ebroder: its just a version # change right?
<ebroder> maco: AFAIK
<maco> was the first one uploaded or not? ie, does this need a new changelog entry?
<jdong> no
<jdong> err
<jdong> yes then no
<jdong> unpack in that order
<maco> ok then
<smoser> slangasek, still around?
<dtchen_> james_w: is the general push/practice for bzr usage in Ubuntu to maintain the entire source tree, not just the debian subdir, in bzr?
<dtchen_> (or anyone else, really)
<ScottK> I think that's the long term plan, but it's very mixed at the moment.
<TheMuso> dtchen_: Now that git vcs imports work, it may be worth considering moving over to the entire source tree. Same with alsa, as we can then get an svn import of the alsa pieces.
<dtchen_> TheMuso: yeah, I'm just considering how to approach this in the next two days ;)
<cody-somerville> having everything in the same branch seems much easier to maintain
<dtchen_> cody-somerville: in what senses?
<cody-somerville> the code and the packaging is all in one place
<dtchen_> these 33.6/56kbps dialup connections are horrendous for pulling/pushing branches
<cody-somerville> thats certainly one drawback
<maco> dtchen_: why are you on dialup?
<dtchen_> it's only a one-time hit (I think), so I could live with it
<ScottK> Personally I like keeping a clear separation between what I've done and what's upstream
<maco> we have 10Mbps internet at home
<dtchen_> maco: work sites don't generally give unfettered access anywhere
<cody-somerville> I used to have 25mbps but I recently moved and now have 4mbps
<cody-somerville> : (
 * StevenK suggests cody-somerville try Australia
<maco> ScottK: i think part of the point is that not everything's in debian/patches/ so this way you can merge the patches that are applied directly to the packages more easily
<ajmitch> StevenK: You're cruel
<maco> from what i hear about internet access, australia is in wales
<ScottK> maco: For some version of easily, sure
 * TheMuso had to convert a bzr branch to using the debian vcs-imports branch + Ubuntu  yesterday, due to the debian package no longer using patches, and the bzr branch for Ubuntu only containing the debian dir.
<StevenK> ... We speak in Welsh?
<TheMuso> lol
<maco> StevenK: even welsh people dont speak welsh
<kklimonda> TheMuso: interesting - so they are using a branch for debian/ and apply patches directly to source?
<StevenK> maco: That's because it requires physically tying your tongue into 3 knots
<maco> StevenK: i can speak a >tiny< bit of welsh :P
<TheMuso> kklimonda: They are using git, and import upstream git into their branch, and apply their changes as git commits, even to files that are part of the upstream code.
<StevenK> maco: Yes, that's the tiny bit that doesn't. :-P
<maco> StevenK: ive forgotten most of that tiny bit, but i can still make the sounds :P
<TheMuso> kklimonda: So those changes then up in the .diff.gz.
<kklimonda> TheMuso: nice - which package is that?
<TheMuso> kklimonda: libcanberra
<ajmitch> TheMuso: it does make sense to not duplicate a vcs as a patch system
<ScottK> That's increasingly common
<cody-somerville> is that the future?
 * kklimonda hopes so
<TheMuso> ajmitch: I agree.
<ScottK> ajmitch: Also makes maintenance work without access to the VCS pretty impossible.
<ajmitch> though it's fairly common still to have the whole package in git/bzr/something else & still have debian/patches
<ebroder> Ugh - I hope we get v3 source packages if that's the future
<TheMuso> ajmitch: As long as those changes are in individual commits, so one can pull/pick/revert as needed.
<cody-somerville> I doubt that'll happen for long
<TheMuso> ajmitch: I have seen where a package has been moved into git, and changes done in .diff.gz to the upstrea msource are not in individual commits.
<ajmitch> that makes it just painful
<ScottK> Personally I think this entire move a VCS thing is great for people who do this every day, but will significantly increase the learning curve for new people.
<TheMuso> ajmitch: Yes, thats why I pointed that out. :)
 * ebroder agrees with ScottK
<TheMuso> ScottK: Yeah I would agree with that.
<dtchen_> a VCS with frikkin laser beams would be nice.
<ajmitch> usually the source package won't carry the .git or .bzr dirs though
<ScottK> Same thing with the push to Quilt as the one true patching system
 * cody-somerville likes quilt.
<TheMuso> See that is where a vcs is very useful. No *-edit-patch, or make change, duplicate source, unpack fresh source, etc.
<maco> ScottK: see i think "bzr push" is easier than making a debdiff
<TheMuso> Just make the change, write a commit message, commit, done.
<ScottK> maco: Once you get through all the VCS stuff to that point, sure.
<maco> ScottK: bzr branch *wait* *do stuff* bzr commit
<dtchen_> TheMuso: 0.9.20 ready to go in lp:~crimsun/pulseaudio/lucid
<ScottK> "Oh, you want to contribute to Ubuntu, first you have to learn this new VCS that is used almost nowhere else"
<TheMuso> dtchen_: Ok thanks.
<kklimonda> what is the workflow for keeping full source tree + debian/ in the same branch? we checkout tagged release from vcs, apply cherrypicked patches from master branch and then release? what about VCSes which you can't easily import from?
<cody-somerville> I prefer having discrete sets of changes instead of snapshots over time.
<StevenK> ScottK: And the fact that you mostly treat bzr like svn is just papered over?
<StevenK> Because that weakens your argument, so therefore it must not be important.
<maco> bzr and hg basic commands are exactly the same
<maco> git is mostly close too..clone v. branch is the difference
<ScottK> StevenK: For someone who has svn experience it's not so bad, but it's still an increase in the barrier to contribution.
<ajmitch> contributing to ubuntu or debian requires plenty of esoteric knowledge as it is
<maco> (note: *only* for basic commands. git gets insane)
<ajmitch> it's yet to be seen whether having everything in branches will simplify it or not
<StevenK> maco: clone is about the only git command I know
<ebroder> ajmitch: Doesn't mean we should make it worse
<dtchen_> s/insane/usable for a select workflow or way of thinking/
<maco> StevenK: commit and push are the same
<maco> StevenK: oh, pull too
<StevenK> dtchen_: s/$/If you're very lucky, or Linus/
<ajmitch> ebroder: I'm undecided whether it's making it worse or not
<maco> StevenK++
<ScottK> I think it's better, just harder.
<cody-somerville> atleast we're not using git, then it would be worse and harder!
<StevenK> But faster!
<maco> yes
<cody-somerville> StevenK, for small values of fast only
<TheMuso> Speaking of Australia, I now start the big gamble that is applying for ADSL on a newly activated/connected phone line in a apartment. :)
<dtchen_> which is well, kinda useful when pulling down hundreds of megs.
<StevenK> I find git slower, in that it takes me 4 times longer to figure out how to do something in git that I can just do off the top of my head in bzr/svn.
<cody-somerville> +1
<ebroder> StevenK: That's perception bias. I'm exactly the other way around
<chrisccoulson> heh, i find git quite hard too. it's a shame that gnome uses it now
<cody-somerville> I'm sure if I knew how to use git I'd love how powerful and robust it is
<StevenK> ebroder: You didn't use svn much?
<dtchen_> ScottK: perhaps if there solid guis for bzr, the barrier may be a bit lower than you're suggesting?
<dtchen_> there are*
<ebroder> StevenK: I use git for almost everything, and git-svn where I can't
<ScottK> dtchen_: It's been a while since I looked.
<RAOF> chrisccoulson: I have to say that my interaction with git.gnome.org is entirely through bzr.
<StevenK> ebroder: Well, then of course you're biased towards git.
<dtchen_> I admit I haven't actually tried editing sound/pci/* in, say, Eclipse
<chrisccoulson> RAOF - you can't commit to git.gnome.org that way though can you?
<cody-somerville> http://doc.bazaar-vcs.org/migration/en/_images/welcome-new-project.png <-- I think bzr does have a nice gui now.
<TheMuso> dtchen_: Would you want to? :)
<kklimonda> RAOF: how well does it work? using bzr to interact with git repositories?
<ebroder> StevenK: I think the point is that it's entirely a matter of what you're used to
<cody-somerville> chrisccoulson, I think you can
<RAOF> chrisccoulson: You could.  I don't have commit access to anything, but you certainly can.
<chrisccoulson> ah, i didn't know that
<ebroder> StevenK: I know people who used RCS but not svn and found git more intuitive than svn
<chrisccoulson> i'll have to try that next time i commit something
<StevenK> Yes, but RCS is .... awful
 * StevenK had to try multiple times to not using a curse word for that sentence
<cody-somerville> hmmm... the help file for git log is 26 pages long. :/
<RAOF> chrisccoulson: AFAIK there isn't any way to specify a git branch that isn't master, but that might have changed.  That's, I think, the last big hole.
<chrisccoulson> i wasn't aware of that - thanks!
<TheMuso> RAOF: In what context are you referring to when you talk about specifying branches?
<chrisccoulson> although, i don't commit to git.gnome.org all that often
<maco> cody-somerville: wow
<RAOF> TheMuso: The git context.  As in: I'd like to bzr branch this particular branch of a git repository, do some hacking, and then push back to the git branch.
<TheMuso> RAOF: Right, I think when you clone a repo, it clones all branches. You then have to set up a local branch to track a remote branch, make your changes, and then push back to the remote repo specifying the branch you want to push to.
<TheMuso> Complicated to explain in a few words.
<RAOF> TheMuso: Oh, no.  I know how to do it with git, but you can't do it with bzr-git.
<RAOF> Sorry, that was obviously less than well-explained.
<TheMuso> RAOF: Oh right.
<ajmitch> I think it's complicated because bzr & git have slightly different views of branches & repositories, from what I've seen
<dtchen_> ajmitch: I think so, too
<RAOF> It is, yes.
<RAOF> It wouldn't be impossible to add a new branchspec that understood how to get a particular branch from a git repository, though.  At least, in my limited understanding.
<LaserJock> kirkland: just read your blog post on testdrive but I'm a little uncertain of what it actually does. Does it just download the .iso and fire it up in KVM/VirtualBox?
<kirkland> LaserJock: basically, yes
<kirkland> LaserJock: where "download" =~ tries to incrementally sync it
<kirkland> LaserJock: such that it'll be useful with daily iso's, once Lucid starts publishing dailies
<LaserJock> hmm, but doesn't a simple zsync command do the same thing?
<ajmitch> it sounds basic but useful
<kirkland> LaserJock: yes, it use rsync || zync || wget
<LaserJock> did it come from the downloader that the QA team has?
<kirkland> LaserJock: no
<kirkland> LaserJock: what downloader is that?
<LaserJock> dl-ubuntu-test-iso
<LaserJock> it's in ubuntu-qa-tools
<LaserJock> it uses zsync, rsync, or wget I think
<LaserJock> you tell it what arch/flavor, etc. and it grabs the .iso
<LaserJock> the man page is mostly rsync but I know they added zsync later in Karmic
<maco> LaserJock: dude thats awesome
<LaserJock> maco: what is?
<maco> LaserJock: what you said about dl-ubuntu-test-iso
<maco> i had no idea that existed
<chrisccoulson> has anyone noticed recently an increase in the number of users who just come and randomly change bug states without any comment?
<ScottK> chrisccoulson: Yes.  It's thanks to the ajaxification of that in Launchpad.
<ScottK> It's now very easy to do.  In fact it's encouraged by the design.
<sbeattie> maco|LaserJock: fair warning, zsync has problems handling files > 2GB on 32bit platforms; there's an SRU for karmic that addresses it.
<maco> the isos arent that big...
<ScottK> DVD ones are
<maco> ah yeah
<chrisccoulson> ScottK - you're probably right. i wasn't sure whether users were doing it accidentally, or doing it just to be disruptive
<ScottK> chrisccoulson: Not sure.  I think it's mostly a combination of accidents and not realizing they should make a comment.
<ScottK> IIRC, Ubuntu people asked Launchpad people to have the change reverted and got told no.
<chrisccoulson> it is quite annoying to have to revert changes nearly every day now :-/
<ScottK> Well IMO Launchpad and quite annoying are frequent associates.
<chrisccoulson> heh
<chrisccoulson> i had to delete 600 mails from one bug from my inbox today
<chrisccoulson> it's quite annoying when getting spammed each time the retracer finds another duplicate of a popular bug
<ajmitch> how many extra mails do you get from people wanting to unsubscribe from that bug?
<chrisccoulson> the seahorse-plugins bug? quite a few people asked for instructions to unsubscribe, and there were also a lot of people posting instructions, and some people clearly confused about why they were getting so many mails
<chrisccoulson> it's a shame we can't view the bug in launchpad any more, because i've fixed it in karmic-proposed, and could do with getting feedback from users with the normal SRU process
<chrisccoulson> that's difficult at the moment though
<kklimonda> chrisccoulson: you have fixed it? my hero :)
<chrisccoulson> kklimonda - yep, it's fixed, if you want to test it ;)
 * kklimonda got tired of getting ~80 mails every day ;)
<ScottK> It's even better when you're getting the bug mail because a team is subscribed to the package or because you're subscribed teo the package bugs.  Basically you can't unsubscribe.
<chrisccoulson> that's a pain. fortunately, i'm not subscribed to many teams which get bug mail
<chrisccoulson> i suspect you probably see significantly more bug mail than me ;)
 * ScottK has seen bug mail where people were begging to make it stop.
<kklimonda> chrisccoulson: you can easily fix that and subscribe to desktop-bugs ;)
<kklimonda> ScottK: ya, I've seen that too with seahorse-plugins bug..
<ScottK> Usually when a bug affected multiple packages and the one package they cared about was long fixed
<LaserJock> ScottK: yeah, well I lost a  whole team to that
<chrisccoulson> in some cases, it would be useful to be automatically subscribed to bugs for a particular package for a couple of weeks after doing an upload
<LaserJock> ScottK: I had collected a group of Debian developers and then they all left after the 3rd or 4th bugmail storm
<StevenK> Ha. Lightweights.
<ScottK> LaserJock: I believe it.
<StevenK> Were none of them subscribed to debian-devel?
<LaserJock> I believe they might have been
<StevenK> Then they really are.
<LaserJock> we got ~ 100 emails in about 1 hr
<StevenK> Or they need to filter e-mail better
<ScottK> The translation template mails are even less use and more annoying from my perspective.
<StevenK> Oh, agreed
<LaserJock> what's frustrating is even if you mark your task Invalid you still get flooded
<StevenK> Why must I get a whole bunch of useless mail when I upload something?
<ScottK> StevenK: Because we use Launchpad.  What more do you need to know.
<ajmitch> this is why most of my bug mail goes into a large folder & I just use mutt searches to narrow down the flood
<ajmitch> ScottK: it's free software now, go fix it that way -->
<StevenK> Haha!
 * ebroder <3 Gmail's search
<StevenK> ajmitch 1, ScottK 0
<ScottK> Last time I asked, the response was something like "but someome might want them", IIRC
<StevenK> ScottK: So? Submit a branch, that makes it slightly harder to say no.
<ScottK> ajmitch: I don't have commit rights.  This isn't a bug, it's the design
<StevenK> ScottK: I'm curious why that's a problem.
<ScottK> StevenK: I don't think my blood pressure could take it.
<ScottK> Back in 5 ...
<ScottK> StevenK: Why what's a problem?
<StevenK> ScottK: Why is you not having commit access a problem?
<LaserJock> because it has to be OK'd
<ajmitch> noone has commit access, really, since all branches get reviewed
<LaserJock> therefore get's checked against "we designed it that way"
<ScottK> LaserJock: Exactly
<StevenK> So? That's a feature
<ScottK> So "It's Free Software" only helps in the case of accidental problems, not the on purpose kind
<StevenK> The barrier of entry is higher than you percieve it
<cody-somerville> lol
<ajmitch> like any free software program, you have to argue for design changes
<StevenK> This is sounding more and more like "Oh, that sounds like real work. Oh well, I'll just complain about it, and hopefully annoy someone else into fixing it."
<ScottK> No, it's I've talked to the developers about it and they think it's fine the way it is and don't intend to change it.
<ScottK> It's possible they changed their minds or I misremember.
<StevenK> I suggest subscribing a developer to a team that gets bug stormed and then see what happens. :-)
<StevenK> That strikes me as somewhat cruel.
<ajmitch> Sometimes you must be cruel to be kind, right?
<ScottK> In the right measure, yes.
<StevenK> But surely you can fix the team so that bug mail gets sent to a list
<StevenK> If you don't want to get stormed, unsubscribe from the list
<LaserJock> and you miss the bugmail
<zul> procmail usually helps as well
<StevenK> Well, sure, but there's no magical button in Launchpad to say "only mail me the bugs that look like they may interest me"
<LaserJock> no
<LaserJock> but you should at least be able to unsubscribe
<LaserJock> which is all I asked for like 2 years ago
<StevenK> And you miss the bugmail
<StevenK> To use your own argument against you
<LaserJock> but you made that choice
<LaserJock> for the particular bug
<ScottK> The explicitly unsubscribe to a bug you've been implicitly subscribed to is an open bug
<StevenK> I thought you could do that?
<ScottK> The "it's that way one purpose" was about the translations email.
<StevenK> ScottK: Oh, that's easy to fix. Get one of the launchpad guys to sponsor an openoffice.org upload
<LaserJock> StevenK: perhaps that's been fixed "recently" but my team is long gone
<ScottK> Just checked.  No unsubscribe button for a bug that I'm subscribed to the package for
<ScottK> LaserJock: Not fixed AFAICT
<jml> ScottK, https://bugs.edge.launchpad.net/malone/+bug/412925 fwiw
<ubottu> Launchpad bug 412925 in malone "new ajax interface for changing bug statuses is too easy" [High,Triaged]
<ScottK> jml: That's the one.
<ebroder> maco: Looks like you ended up with a bunch of extra autoconf/manpages stuff in the latest debdiff for 415766
<jml> ScottK, I haven't spoken with the malone team recently, but I think they agree that something needs to change.
<maco> ebroder: oh boo now whyd it do that
<jml> I'm confident that they'd be happy to help someone prepare a patch :)
<maco> ebroder: can i just manually mangle the old debdiff? would anyone care?
<ebroder> maco: I've caught the clean stage of the openafs package doing that before. Don't remember why off the top of my head
<ebroder> maco: Yeah, that's totally fair
<ScottK> jml: I last saw the bug after it was wontfixed.
<nixternal> just ignore the bug reports, that's what I do...now anything with the word 'BUG' gets sent straight to [GMail].Spam ;p
<maco> ebroder: sent
<nixternal> and then in a year, when I feel like fixing bugs, do a "Oh, I apologize for not responding sooner to this report, here is a piece of chocolate"
<LaserJock> I've just been using the package report pages
<LaserJock> and pretty much ignore bugmail
<ebroder> maco: I think the version should be 1.4.11+dfsg-1+ubuntu0.1 - that's what I've used for openafs SRUs in the past
<maco> ebroder: oh right cuz debian is -1....wah thats confusing
<ebroder> Yeah...
<maco> ebroder: this pkg has truly fubar versioning
<ScottK> ebroder: Without the "+"
<ScottK> 1ubuntu0.1
<ebroder> ScottK: No, you need the +, otherwise it screws up modules built by module-assistant
<ScottK> Oh.
<ScottK> Nevermind
<maco> right this is why we're sitting here mucking with version strings
<maco> because 1ubuntu0.1 is what i uploaded before
 * ScottK nods
<ebroder> One of these days when I'm feeling particularly masochistic, I may write up a proposal for Ubuntu to use N+ubuntuM instead of NubuntuM. Debian uses this for their stable release updates these days
<ebroder> c.f. libcups2 1.3.8-1+lenny7
<maco> ebroder: ok NOW is it ok?
<ebroder> maco: I'll let you know when it makes it to LP
<ScottK> ebroder: Because our revision numbers aren't long enough already?
<ebroder> ScottK: Becuase if Ubuntu was consistent about it I wouldn't have to argue about the + every time I want to upload to openafs :)
<ebroder> maco: Looks perfect - thanks
<maco> wow...you mean we could have libcups2-1.3.8-1+lenny7+ubuntu1?
 * StevenK twitces
<StevenK> *twitches
<ebroder> Well, we don't sync from post-release Lenny updates
<StevenK> That isn't a sync
<StevenK> And we can merge from wherever we want, if we so wish to
<jdong> maco: *SLAP*
<jdong> AARRRRRRGH
<maco> jdong: ebroder made me do it!
<jdong> maco: didn't we have this discussion about hand-editing patches?
<maco> jdong: i didnt touch the patchy part or add new lines!
<maco> oh.
<maco> wait...this is that one that i hand-edited before
<maco> slightly more hand-edited but without new lines this time
<jdong> :)
<maco> he said it was ok *points to ebroder*
<ajmitch> maco: where's the +isreally+1.2.6 part that it needs? :)
<ebroder> I <3 that in version numbers
<maco> jdong: you're going to give me noogies if we ever meet, arent you?
<jdong> lol
<jdong> don't worry
<jdong> I still love you ;-)
<StevenK> Be warned that jdong considers noogies a form of affection
<maco> great so StevenK's going to tickle me for making fun of his accent and jdong's gonna give me noogies...
<StevenK> Sounds like fun.
<StevenK> jdong and I should make sure to do it at the same time, too
 * ajmitch would be worried about that
<maco> hahaha
<maco> sounds like i need a corset and a helmet
<StevenK> Oh, a corset won't stop tickling
<maco> you cant tickle through a corset
<ajmitch> something like an electric cattle prod would help keep them off
<ScottK> It's Texas.  Firearms are legal.
<maco> i know, the ubuntu women team is organizing a trip to the shooting range
<maco> for uds
<StevenK> maco: They aren't that thick, and they're skin-tight, so it should be possible ...
<jdong> WHAT ON EARTH IS GOING ON?
<ajmitch> jdong: madness
<maco> high levels of silly
<ScottK> It says something when jdong is the stable, level headed one in the room.
<ajmitch> heh
<ajmitch> very much so :)
<LaserJock> maco: oh man, you're going to go shooting? I'm envious. I had to leave all my weaponry in MT when I moved to Boston
<maco> LaserJock: *i'm* not going shooting. akgraner is, and czajkowski's like "you have guns in your country? i wanna try!"
<ScottK> maco: Why aren't you going?
<maco> eek! guns!
<maco> now if they were going to the *archery* range..
<LaserJock> maco: well, they're similar, just one goes a little faster and has a bit more bang to it ;-)
 * TheMuso reads backscroll and can't stop laughing.
<ajmitch> LaserJock: similar in a vague sort of way...
<LaserJock> ajmitch: well, I've killed things with both, the effect is similar
<ScottK> :-)
<LaserJock> although I am always amazed when I have friends try a pistol/rifle for the first time
<LaserJock> apparently it's not exactly how it looks on TV
<ajmitch> now that's a surprise :)
<StevenK> Haha, yes
<StevenK> "Um, I just fired this rifle, and now I'm on the ground."
 * TheMuso would be frightened of both the recoil and the bullet.
<jdong> maco: poke poke
<jdong> are you regenning the patch?
<maco> am now. but before it spewed weird autoconf stuff into it when i tried
<ebroder> Try...doing a debuild clean before you do the debuild -S or something?
<maco> jdong: ok ther
<maco> ebroder: it worked this time *shrug*
 * ebroder shrugs. That doesn't surprise me too much
<jdong> someone play refresh timer for me.
<jdong> maco / ebroder : uploaded
<ebroder> Yay :)
<maco> yay
<Hemidrone> My love goes out to these people. I sync my datas, set up vpns, play with my MP5's. Truely sexxi!!! -> http://mange.dynalias.org/linux.html
<Hemidrone> Hmm, why are there always brown wimen on the music channels ? ... I dont dislike them, but we also pay so i think a few white wimen could also be nice to watch.
<Hemidrone> Yeesh! Looks ugly when brown wimen wants to look whiter using some lenses and video lenses etc. Now, i have some brown friends and i like those.
<Hobbsee> Hemidrone: i don't think you really want to continue...
<Hemidrone> Korean wimen are very sexxi.
<ScottK> Thanks.
<mneptok> is the speed of -server sessions being added to the UDS schedule affected by my use of the refresh icon?
<Ademan> does upstart set variables that are used in upstart scripts? for instance the gdm upstart script uses $CONFIG_FILE which isn't set anywhere in the script that i can see.
<cody-somerville> Ademan, no, I don't think so
<cody-somerville> Ademan, and looking at gdm-binary --help, it doesn't look like it accept a config file as an argument.
<pitti> Good morning
<pitti> lamont: yes, that was lucid
<dholbach> buon giorno!
<Ademan> cody-somerville: so you think the upstart script is bogus?
<bossekr> hi all; within the last two days I tried to use the edit@bugs.launchpad.net email interface to change bugs in Ubuntu as Debian developer for "my" package but nothing happens
<maco> bossekr: replace "edit" with the bug number
<bossekr> hmm, the edit@ interface for multiple bugs and this is what I've done
<bossekr> there are a bunch of bugs to change
<maco> ah ok
<siretart`> morning
<siretart`> pitti: just to be sure, we don't allow GPLv2 licensed applications to link against MPL licensed libraries in ubuntu. is this correct?
<pitti> siretart`: hm, can't say offhand; was it handled like that so far?
<siretart`> I'm not sure if the current case I'm looking at is deliberate or a mistake.
<siretart`> in fact, its the only divergence we currently carry from debian. I suspect we imported the package from debian and then the package was changed
<siretart`> filed as bug #481789
<ubottu> Launchpad bug 481789 in kid3 "kid3 links against libmp4v2" [Undecided,New] https://launchpad.net/bugs/481789
<pitti> james_w: do you know if there's any way to suppress the millions of "branch linked" LP mails which hit my mailbox every day?
<maco> pitti: the openafs one that was in proposed was -1ubuntu0.1 this is -1+ubuntu0.1 because module-assistant gets stupid without the +
<pitti> maco: oh, sorry; will reprocess then; so that was the only change, right?
<maco> yeah
<maco> just a bumped version number to make m-a happy
<pitti> done
<maco> pitti: thanks
<pitti> maco: ooh, congrats to your new MOTU badge!
<Tm_T> another lost soul...
<ashiswin> ls
<ashiswin> umm
<ashiswin> could anyone tell me how to develop for ubuntu
<ashiswin> i do C java C++
<ashiswin> stuff like that
<ashiswin> so any help?
<azeem> #ubuntu-motu is for getting involved with Ubuntu development
<azeem> as for development *on* Ubuntu, that is off-topic here
<\sh> moins
<Keybuk> mvo: that's how I want to do fsck forcing eventually yeah :)
<mvo> Keybuk: cool, thanks
<primes2h> apw: Hello, Could you have a look at this please? bug #374459 . It has already a commit from upstream ready to apply.
<ubottu> Launchpad bug 374459 in linux "touchpad can be switched off, but not on again" [Unknown,Fix released] https://launchpad.net/bugs/374459
<lamont> pitti: 127.0.1.1       invalid <-- should fix it, yes?
<lamont> hrm... ah.
<pitti> lamont: 'invalid'?
<pitti> lamont: oh, you mean "you should fix it", not "this should fix it" :)
<lamont> yeah - that's the host name
<lamont> but that's not how I fixed it before and so yeah... let me see about smacking it over the head harder...
<apw> primes2h, that should be fixed in karmic right?
<primes2h> apw: it's not fixed yet. It's fixed upstream, here you find the info about the commit that fixes it http://bugzilla.kernel.org/show_bug.cgi?id=13363
<ubottu> bugzilla.kernel.org bug 13363 in Input Devices "touchpad button won't work after switching off once" [Normal,Resolved: patch_already_available]
<apw> primes2h, which is false as the commit upstream is already in the release karmic kernel and not fixing you, correct?
<apw> i've added that info to the bug, and asked for testing and collection of some more information
<primes2h> apw: I'm not sure that the commit is already in karmic kernel, because the bug is present :) and because of this comment https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/374459/comments/44
<ubottu> Launchpad bug 374459 in linux "touchpad can be switched off, but not on again" [Unknown,Fix released]
<apw> primes2h, i am cirtain that the fix is in the karmic kernel, i just checked.  but the fix is model specific
<apw> so your model is not _exactly_ the same one then the fix will not trigger
<primes2h> apw: ah, ok.
<apw> hense the request for testing and on failure the attach of dmidecode output
<primes2h> apw: by the way, I can't use the  workaround described because it applies to grub, not to grub2
<primes2h> apw: I mean this kernel option i8042.nomux=1
<apw> you can add kernel options in both?
<primes2h> apw: (I have to learn hot grub2 works)
<primes2h> :)
<apw> it may be GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub that sets it
<apw> then run update-grub
<primes2h> apw: Is it safe to add a line by hand in /etc/default/grub. It's advised against doing it.
<primes2h> ?
<primes2h> grub?
<apw> /boot/grub* is normally replaced and you lose your changes
<apw> i _though_ /etc/default/grub was the right place, but i can't say i know for sure
<primes2h> apw: BTW, I already did an apport-collect about linux package in the bug report. Is it enough?
<apw> the important thing is that the dev trying to fix it knows which dmi-decode and which model name and which 'does not work with latest karmic' go together
<apw> so i would put the dmi-decode output on an attachment to the update which says your model isn't working
<primes2h> apw: Does I need just to launch dmidecode in a terminal?
<apw> that makes out job simpler, as we cannot get things mixed up
<apw> probabally sudo dmidecode in a terminal yes
<primes2h> apw: Yes ;)
<primes2h> I meant that
<lamont> pitti: if you would be so kind as to reupload cups with the test suite back on?  should build now.  Assuming so, could you migrate the bug to launchpad-buildd by whatever means makes the most sense - lp-buildd should be fixing the hostname in the chroot, rather than the hack we have to resolve invalid
<pitti> lamont: \o/ thanks muchly, reuploading
<pitti> lamont: the bug is already assigned to launchpad-buildd project -- that isn't right?
<lamont> absolutely correct.
<lamont> color me illiterate
<helger> Anyone know Where can I report a bug in Ubuntu One
<helger> ?
<primes2h> apw: Done. I added dmidecode output into the bug report. Thank you very much.
<pitti> lamont: hm, failed again :-(
<lamont> pitti: gar
<lamont> what exactly is the hostname it looks up, I wonder?
<StevenK> lamont: Surely there is no hostname resolution on the buildds, though?
<lamont> StevenK: well... they can resolve things like 'archive.ubuntu.com' :-)
<lamont> random hostnames? no.
<StevenK> *cough* ftpmaster.internal :-P
<chrisccoulson> congrats maco!
<StevenK> But yes, I was meaning random hostnames
<pitti> lamont: I thought just the local host name, let me check the code
<lamont> StevenK: we broke that semi-recently, it used to be able to resolve, but not to contact
<maco> chrisccoulson: thank ya
<pitti> lamont: "vernadsky"
<lamont> pitti: and WTF does it look up that host name?
<StevenK> lamont: I thought that is were Build-Depends downloaded from? :-)
<pitti> lamont: it's what httpGetHostname() determined
<StevenK> pitti: Does it use gethostbyname() or a custom resolver?
<lamont> StevenK: I meant resolving random hostnames
<StevenK> lamont: Oh, right
<pitti> lamont: http://paste.ubuntu.com/317888/
<StevenK> lamont: My context switching is broken
<pitti> lamont: gethostname()
<pitti> lamont: but "vernadsky" sounds correct for the buildd?
<lamont> pitti: 'vernadsky' is a buildd, yes
<lamont> and (intentionally) the search list in resolv.conf lacks 'buildd', and vernadsky.canonical.com is NXDOMAIN
<pitti> lamont: hm, it worked until some weeks before karmic; any idea what changed at that time?
<StevenK> But vernadsky.buildd should surely be in /etc/hosts?
<StevenK> It's using gethostbyname(), so /etc/hosts should certainly be checked
<lamont> hostname; hostname --fqdn
<lamont> king
<lamont> hostname: Unknown host
<pitti> so it uses gethostname(), and if that isn't a FQDN, uses gethostbyname() (but if that returns NULL, it doesn't bother)
<lamont> StevenK: that would surely be the point of the bug
<pitti> so AFAICS, if it can resolve "vernadsky", it should suffice
<lamont> StevenK: /etc/hosts used to contain an entry for whatever host built the image.
<lamont> and the search list had buildd in it
<lamont> pitti: what you're actually saying is "please add buildd back to the search list", or "please make /etc/hostname contain the fqdn for the host on all of the buildds"
<lamont> though I suppose that testing network connectivity for cups might entail using a hostname
<lamont> pitti: as for why it broke, the chroots were changed to not have buildd in the search list
<pitti> ah, I see
<lamont> and ultimately, the fix is to have a hosts file entry, written by lp-buildd as part of unpacking the chroot
<pitti> how wonderful .. all those days it's nice in Dallas except for next Sunday, when we have our only day off :)
<StevenK> Ah yes, since you don't want to do that for the chroots themselves
<serialorder> not sure if this is the right channel but I am getting the following error: Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory
<serialorder> and I am trying to find out where it is coming from
<lamont> pitti: so the long and the short is that un-hacking cups is easiest described as "blocked by this here lp-buildd bug"
<lamont> :-(
<amichair> mvo: I made a bunch of fixes on software-properties-kde... are u the man to talk to about reviewing/merging?
<Riddell> amichair: actually glatzor might be more a candidate for that
<Riddell> amichair: and of course I can do it too, just a bit busy with preparing for UDS right now I'm afraid
<Martyn> Same here.
<amichair> Riddell: I noticed u and apachelogger seem very busy... trying to find someone else to bug :-)
<Martyn> And gobby seems to be down
<Martyn> PLUS the topic script on the UDS site is also really broken
<Martyn> If you go to any given day on the schedule, you can clearly see the right things on the right days
<Martyn> if you try doing it by topic (server, mobile, etc) it all gets stuffed between 14:00 and 15:00
<kees> good morning!
<kees> zul: btw, I've noticed in security updates that cyrus-sasl2 and cyrus-sasl2-heimdal have to be the same version.  when you sync one, can you bring in the other too?
<zul> kees: sure
<pitti> slangasek: hm, the samba karmic-proposed SRU has a lot of new files (source3/exports/libsmbclient.syms, source3/exports/libsmbsharemodes.syms, source3/lib/netapi/tests/Makefile, etc.); was that intentional?
<mvo> amichair: hey! yeah, I'm the one for the merge, what is the branch name?
<bdmurray> pitti: Do you think bug 455740 needs a karmic task?
<ubottu> Launchpad bug 455740 in imagemagick "convert crashed with SIGSEGV in CloneImage()" [Medium,Fix released] https://launchpad.net/bugs/455740
 * mpt_ wonders how the Ubuntu Software Center could tell that package Y is an add-on for package X
<mpt_> e.g. that adblock-plus is an add-on for firefox-3.5
<StevenK> mpt_: Sounds like a use-case for Enhances
<mpt_> Does Enhances exist?
<StevenK> Certainly does
<mpt_> cool
<mpt_> oh, of course it does, it's in the window I'm staring at right now
<mpt_> nifty nifty nifty
<StevenK> Heh
<mpt_> thanks StevenK, I thought I'd get a useful answer in here
<amichair> mvo: lp:~amichai2/software-properties/fixes
<amichair> mvo: u can ignore the revision with gpg, it is later reverted
<amichair> mvo: and being new to python/qt/kde, I'd be happy to get as much feedback as possible :-)
<ttx> mneptok: ping
<mneptok> ttx: pong
<ttx> mneptok: hey -- about the mariadb session for uds
<ttx> mneptok: I assume you are willing and able to chair the session ?
<mneptok> ttx: sure. happy to do so.
<mneptok> ttx: are you working on scheduling by any chance?
<ttx> mneptok: yes
<mneptok> ttx: if you can schedule it for Monday i can probably get Monty there, as well.
<ttx> mneptok: let's see
<ttx> mneptok: tricky
<mneptok> ttx: just be aware, i work for Monty Program. i'm not a completely disinterested party in this. we'll of course follow what the community wants to do, but in the interest of full disclosure ....
<ttx> mneptok: I'll need to move a few slots around
<ttx> mneptok: I'll let you know asap
<mneptok> ttx: don't jump through too many hoops. having Monty would be great, but i'd rather not do it if it means disruption to other blueprints.
<ttx> mneptok: ok
<slangasek> pitti: samba karmic-proposed> that's because I always do a debuild -uc -us -b first, and apparently the clean target is insufficient
<smoser> slangasek, ping
<ebroder> gdm sticks a little Ubuntu logo at the top of the login box - where does that come from? It's not part of ubuntu-xsplash-artwork like the rest of the artwork
<mterry> persia, can you add me to ubuntu-universe-sponsors?
<Azverkan> Has there been any discussion as to reverting mountall for karmic and pushing it to lucid?  Or releasing a separate alternate karmic installer that doesn't attempt tot use it?
<StevenK> Azverkan: Why?
<Azverkan> On all the test upgrades I've done it works with varying degrees of success
<StevenK> Then file bugs, rather than advocating reverting it?
<Azverkan> It seems like the package still has a few months of bugfixing before it could be declared stable
<Azverkan> Long term getting the bugs reported and fixed is the best approach, I'm just wondering what to do in the short term as the package renders many configurations unusable
<ScottK> AFAIK, the mountall changes are very intertwined with the other boot changes, so you can't really just 'revert mountall'.  It would be the whole boot process.
<StevenK> Yeah
<mjr> On Dell Latitude E4200 / 9.10 it seems that the (touchpad) mouse is often lost on resume from suspend, though comes back after VC back-and-forth. Known? Should probably report properly?
<Azverkan> the new boot process is all event based now, is there a page anywhere that details the best way to debug it?  (I remember all the fun with kernel 2.6.31-rc8 breaking inotify and how nonobvious it was)
<slangasek> smoser: might take fewer round-trips if you would say what you need :)
<SNLala> hey. google-earth zoomt bei einer suche auf die richtige stelle. aber der "placemark" der gesetzt wird, ist an einer anderen stelle. kennt das auch jemand?
<tormod> SNLala, -> #ubuntu-de
<SNLala> sry. wrong channel
<SNLala> yeah thank you
#ubuntu-devel 2009-11-14
<directhex> looks like between 89% and 116% of reported karmic issues on ubuntuforums are bug 411941
<ubottu> Launchpad bug 411941 in gtk+2.0 "f-spot.exe crashes when using new wave theme" [Medium,New] https://launchpad.net/bugs/411941
<Yoe> hi -- I'm the Debian (and upstream) maintainer of nbd, which is still at a rather old version in ubuntu
<Yoe> There's a "please merge" bug open in launchpad, but it hasn't seen an update in quite a while now
<Yoe> I've prepared a patch, but launchpad seems to hate me; would anyone here be kind enough to post the URL for me? http://grep.be/~wouter/ubuntu/nbd_2.9.14-2ubuntu1.dsc
<Yoe> thanks!
<chrisccoulson> directhex - interesting. is it possible to run mono applications with "--sync"?
<chrisccoulson> the backtrace in that bug report isn't particularly useful, as the X error actually occurred at some point in the past
<directhex> Yoe, are there specific reasons for ubuntu to remain diverged? are there ubuuntu-specific patches which couldn't be binned or usefully integrated?
<directhex> chrisccoulson, i'm not aware of such an ability, but the gtk-sharp mailing list would know better
<chrisccoulson> directhex - thanks
<directhex> chrisccoulson, it'd be nice if you could set an env var to alter than behaviour
<chrisccoulson> i'm not sure if there is anything in xlib that honours that. it would probably be worth me checking
<dtchen_> directhex: it looks like the changes from 1:2.9.11-2ubuntu1 are still relevant
<chrisccoulson> (or i could just run f-spot in GDB and break on XSynchronize)
<chrisccoulson> assuming that's possible :-/
<dtchen_> Yoe: done. Also subscribed ubuntu-main-sponsors.
<directhex> dtchen_, oh, one of THOSE kinds of divergence. those need carrying for years :/
<dtchen_> Yoe: thank you for looking into it.
<JanC> eh, nbd is treated as a "native" package or what?
<dtchen_> JanC: hmm? It's a normal upstream-DebRevUbuntuRev
<dtchen_> unless I misunderstood your question
<JanC> apperently I was looking wrong
<i--pink> hii
<i--pink> someone here?
<persia> !ask | i-pink
<ubottu> i-pink: 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. :-)
<i--pink> hehe
<i--pink> ok
<i--pink> how i cant make the point in the cursor bigger
<persia> i--pink: I suspect you want #ubuntu: this isn't a support channel.
<i--pink> persia, ^
<i--pink> hehe.. is developer channel..
<i--pink> i need to make it, is not a problem in the ubuntu, is something are i need to make
<i--pink> is for touch-screen
<persia> i--pink: Ah, you want to adjust the contact point size for a touch screen?
<i--pink> yes
<i--pink> to resize the point on the cursor
<i--pink> now is 1 pixel and i want to make it 20 pixels
<persia> Well, one of those is a config change and the other is a replacement graphic.  The person who knows best isn't about right now, and this still isn't the right channel, unless you're proposing to change it for Ubuntu (in which case I'd recommend proposing it for an ubuntu-mobile meeting)
<persia> Note that the X event will still be a single X,Y coordinate, so it may not achieve the effect you want.
<i--pink> mmm ok
<i--pink> no no no
<i--pink> look.
<i--pink> the cursor make effect only on 1 pixel, i want it effect on circle of 20 pixels
<persia> i--pink: I think that would be very tricky, as I think X assumes a single pixel, as do most X clients.
<i--pink> mmm ok
<i--pink> and you know about option to show all the open windows - without compiz
<persia> libwnck can be a useful way to access that.
<i--pink> i mean some fetcher in ubuntu,
<i--pink> i am dont want to make it if it's done.
<persia> i--pink: There's a whole bunch of them.  `apt-cache rdepends libwnck22` will show at least 5 (although some of what it shows are also not tools to do that)
<i--pink> what is this list?
<persia> It's a list of packages that use libwnck.  Note that there are also other libraries to handle window stuff, so it's not a complete list.
<i--pink> i get 100 lines..
<persia> I only get 39.  You may have more sources enabled in your sources.list than I.
<i--pink> what is avant-window-navigator
<persia> Your package manager will tell you.
<i--pink> hehe
<i--pink> Error: Screen isn't composited. Please run compiz (-fusion) or another compositing manager.
<i--pink> dont help me
<i--pink> it use compiz :(
<maco> its a dock program
<maco> think like at the bottom of a mac
<JanC> no, it needs a compositing manager
<i--pink> ahhhh avn
<i--pink> AWN
<i--pink> *
 * persia notes that both the purpose of the tool and the use of the composite extension are in the package description
<i--pink> no no.. i need something like ALT+TAB but after it you can chose the application with the mouse
<persia> i--pink: Right.  So, to get that, you'll either want to ask for good applications that meet your needs in the support channel, or investigate the available applications using the development tools and testing :)
<i--pink> i ask you if you hear about application like this OR i need to make it..
<JanC> i--pink: I don't think there are any in the Ubuntu repositories outside of compiz, or maybe AWN (which I don't use so don't know)
<persia> Understood.  I'm not familiar with all the applications that do window selection.  That's why I pointed you to a handy library that does that (so you could investigate the tools that use it), or to the support channel, where there tends to be at least someone familiar with almost any application available.
<JanC> but I think you have a bigger chance in #ubuntu to hear about such applications
<maco> i--pink: ive never heard of anything like that for linux
<JanC> maco: well, compiz does it, so everybody uses that  ;)
<i--pink> is for a concept netbook
<JanC> why not use compiz then?
<i--pink> but compiz kill the processor
<maco> JanC: can you choose with mouse whch thing to pick when you alt+tab in compiz??
<JanC> no, it doesn't, it runs almost completely on the GPU
<persia> i--pink: Select a different GPU, with accelerated #d drivers for x.
<ScottK> maco: The problem is the wrong compositing.  Kwin works great on netbooks.
<JanC> maco: not with alt-tab maybe, but there is a way to do it IIRC
<i--pink> is not only that
<JanC> ScottK: compiz (and kwin, I suppose) works on intel 8xx graphics cards, which are way less powerful than what is in a netbook
<i--pink> if i rotate the screen in 90 deg. compiz make crazy things
<ScottK> JanC: Works great on my Dell mini 10v (Kwin with plasma-netbook)
<JanC> i--pink: ah, then file bugs to compiz  ;)
<i--pink> i have accelerometer and it control on the screen rotate
<JanC> ScottK: which has either 915 or poulsbo?
<ScottK> JanC: 915.
<i--pink> is atom 1.6 and 945
<JanC> right, the same as my EEE 900
<ScottK> JanC: Sorry, 945.
<persia> I didn't think there were any poulsbo drivers for recent X.
<ScottK> Mini 10 is poulsbo, 10v in 945.
<JanC> seriously, that GPU has too much power for compiz already  ;)
<i--pink> and games not work good with compiz
<ScottK> persia: There aren't.
<JanC> except if you want some of the more crazy plugins
<i--pink> you get flickering screen
<persia> i--pink: Games work fine with compiz, as long as there is GPU power available.  Making them work together is a BOM decision, rather than a software decision.
<Amaranth> JanC: I can't think of a plugin that would be slow on a 945 except maybe blur
<Amaranth> assuming blur works...
<Amaranth> BOM?
<Amaranth> ODM?
<persia> bill-of-materials: the stuff inside the computer
<JanC> Amaranth: yeah, blur is what caused problems on my laptop in the past
<Amaranth> persia: Actually as long as the driver is done properly compiz should have almost zero impact on games
<i--pink> if i open a game like tux racer the screen start flickering
<persia> Amaranth: hrm?  What happens if I'm running nifty stuff and other nifty stuff and run out of ability to process polygons?
<JanC> i--pink: on karmic?
<Amaranth> persia: Unless you're actively using compiz effects the only real cost is the GLX_EXT_texture_from_pixmap which is supposed to be a noop
<i--pink> on hardy
<Amaranth> persia: Well, I suppose you could run out of memory...
<i--pink> i use hardy
<JanC> i--pink: right, intel driver improved a lot since then  ;)
<i--pink> all the support channels and the forums tell me to disable the compiz
<Amaranth> persia: But so long as the pixmap is in video memory GLX_EXT_texture_from_pixmap should be zero-copy, just some bookkeeping to use it as a texture
<Amaranth> persia: Although afaik that's really only possible with GEM/TTM
<persia> Amaranth: right, but a lot of the lower-cost memory solutions are limited in various ways.
<i--pink> and when i disable it the games start work good!
<Amaranth> i--pink: So disable it
<persia> s/memory/video/
<i--pink> but now the the touch-screen not useful
<JanC> Amaranth: he wants some sort of "exposÃ©"-like tool, which would be easiest to do with compiz of course
<Amaranth> persia: Well intel should be the best at this, really
<i--pink> what is s/memory/video/ ?
<Amaranth> JanC: In that case I guess he'll have to try again with karmic :)
<persia> i--pink: sed command to apply to my last statement.
<i--pink> i delete the karmic today
<persia> Amaranth: poulsbo aside, yes :)
<Amaranth> crap, poulsbo...
<JanC> he has 945
<Amaranth> try again with lucid? :)
<i--pink> i have not drivers for the touch-screen
<JanC> i--pink: so, you dano't have karmic drivers for the touch screen you mean?
<JanC> don't
<Amaranth> i--pink: Try installing compizconfig-settings-manager then running ccsm and disabling Unredirect Fullscreen Windows in General Options
<i--pink> i cant calibrate the touch-screen
<i--pink> yes
<i--pink> i try it
<i--pink> not work
<JanC> hm, and you can't use a touchscreen that has open source drivers?
<i--pink> is penmount
<i--pink> i try to install the drivers of the 9.04 and it calibrate the screen but disable the keyboard..
<i--pink> and i try to remove the calibration tool from the startup but is back all the time..
<i--pink> after 5 testings and 3 days i back to the stable hardy
<sbalneav> tkamppeter: Hey, Till, you about?
<i--pink> this ids the driver
<i--pink> http://www.penmount.com/down_2_1_6k.php
<i--pink> i work with the USB
<sbalneav> tkamppeter: if you're about, I'm tracking down Bug #307471
<ubottu> Launchpad bug 307471 in cupsys "Multi bin printing broken in OpenOffice.org due to cupsys pstops filter bug" [Undecided,Confirmed] https://launchpad.net/bugs/307471
<JanC> i--pink: I guess they will release an Ubuntu 9.10 driver in the future?  Maybe ask them?
<RAOF> Urgh.  Why is pv->disk being NULL in grub-probe?  That makes everything unhappy.
<hsn> if i traslate app on launchpad, it gets exported upstream?
<manuel_> does a update from 904 work if the whole system is enctypted?
<manuel_> thanks
<cumulus007> Hi, I have just completed the Dutch translation of the Ubuntu 9.10 release notes. I made a note of them on this page: https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes/Translations
<cumulus007> Should I do anything else to make sure that my translation will be used and will be accessible via the installer's start page?
<ari-tczew> qa.ubuntuwire.org is down :-(
<Symmetria> lo all, quick question, has anyone seen any problems with the ixgbe drivers under both jaunty and karmic (I've tried various kernels), I am getting odd kernel panics and stuff when I start throwing serious traffic around
<Symmetria> http://inetpro.org/pastebin/79 <=== thats what I'm seeing
<lhasbs> ubuntu doesnt seem to like being in a saved state in virtualbox
<lhasbs> ipv4 network is missing
<lhasbs> the /etc/init.d/networking restart doesnt re up it
<dtchen_> it wouldn't. You want to restart network-manager.
<lhasbs> is there a quick way to do so?
<lhasbs> and why doesn't it restart with the above command?
<dtchen_> in 9.10, sudo restart network-manager
<lhasbs> I al;ready did that, this is 9.04 though
<lhasbs> added iface eth0 line to interfaces, good to go
<lhasbs> I removed n-m from 9.04
<lhasbs> dtchen_ ?
<dtchen_> lhasbs: yes?
<lhasbs> am I correct here?
<dtchen_> lhasbs: to what does "correct" refer?
<maco> lhasbs: if 9.04 then its called NetworkManager
<dtchen_> in 9.04, it would be /etc/init.d/NetworkManager
<lhasbs> Is there any easy way to change monitor driver in ubuntu. i have to do this to get a higher resolution. It says i got a compaq 16" but it's 17".
<azeem> lhasbs: please ask in #ubuntu; this is not a support channel
<lhasbs> done there
<lhasbs> noone answered sir
<azeem> sorry about that
<lhasbs> :/
<azeem> try again during the week or the forums then
<lhasbs> ok
<sam__> hey
<sam__> just want to say something
<dtchen_> ugh. Ubuntu needs libsdl1.2debian-pulseaudio on the discs as opposed to libsdl1.2debian-alsa. Which is going to be tough because Kubuntu and Xubuntu don't ship PulseAudio.
<sam__> my wifi finally works out of the box, thank you...
<m4t> any recommendations for a non adobe flash plugin for firefox? gnash?
<m4t> there isn't one in the base desktop install, is there? i don't recall removing one..
<maco> OT for this channel, but i like swfdec
<m4t> all i need is flash cookies
<Kartinka> Is there anyone who knows a lot about DevKit and udev Rules?! I need some help by hiding unmounted partitions.
<maco> m4t: no there is not
<maco> m4t: swfdec is what i used for about a year, but again...not exactly a -devel question
<Kartinka> mh
<Symmetria> ullo all
<Symmetria> anyone awake?
<maco> i think many are either on airplanes or packing to get on airplanes
<Symmetria> http://inetpro.org/pastebin/79 <=== I need someone who can give me SOME clue as to whats going on there
<Symmetria> the moment I start downloading serious traffic through ixgbe, I start seeing messages like that in dmesg, and then the box locks up solid
<Symmetria> and I've tested it on 3 different machines configured identically
 * Symmetria is thinking memory leak in the tcp stack with adjusted window sizes
<maco> file a bug against the kernel?
<maco> "ubuntu-bug linux"
<Symmetria> :) yeah was just hoping for some pointers first so that I could include a bit more detail in a bug report rather than saying "I see this, and the box locks up" :) figured maybe someone had something for me that would allow me to do some more investigations first
<maco> ubuntu-bug will attach some information
<maco> lets take this over to #ubuntu-bugs
<serialorder> i was going to merge telepathy-mission-control-5 but the change introduced was to ship the AccountManager service file
<serialorder> there is a note in the readme that says  "# The AccountManager.service is inappropriate on mainstream distributions"
<serialorder> got me thinking that maybe this is not something we should ship with lucid
<ScottK> serialorder: For telepathy stuff, I think bigon is the best person to ask.
<serialorder> ScottK, ok
<pvl1> hey, i really wanna learn to develop for ubuntu, but i dont know where to begin. are there sdk's or something like that?
<sebner> !MOTU | pvl1
<ubottu> pvl1: motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<sebner> pvl1: "click here!"
<pvl1> i was looking at that page but i got confused as to what i was looking for
<pvl1> i guess ill look around a bit more
<pvl1> ty
<sebner> np
<bigon> serialorder: well I'm not really aware of the mc5 stuff, you can maybe ask smcv (upstream and debian maintainer)
<sjoerd> sebner: shipping that services file is perfectly fine
<sjoerd> uhm, serialorder ^^
<bigon> oh you're here too :)
<sjoerd> bigon: i'm everywhere :p
#ubuntu-devel 2009-11-15
 * mneptok checks his pants
<mneptok> sjoerd: you lie.
<maco> O_o
<maco> thats an interesting conversation to walk in on
<mneptok> maco: if i had a nickel ...
<jdong> maco: considering that it's mneptok, you could've walked in on far worse....
<jdong> *hides*
<maco> jdong: thats probably true
<jdong> just like with xinetd services, knock and wait a couple seconds before entering?
<jdong> (heh actually launchd on the iPhone is the worst at playing this game)
<Amaranth> wow my notify-osd just went into a debug mode or something
<jdong> the first time you SSH into an iPhone it literally spends a minute generating SSH host keys.
<Amaranth> everything was all framed out and at the top it said "normal - report incorrect urgency?"
<Amaranth> oh, maybe a lucid thing
<dtchen_> okay, I know I'm dense, but do we officially document how to navigate to browseable online source for source packages?
<dtchen_> I'm going through similar pain to fix an alsa bug in openSUSE 11.2, and uh, no documentation is *bad*
<dtchen_> maybe https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource ?
<maco> there's browsable online source?
<maco> you mean aside from the handful of packages in bzr?
<dtchen_> maco: that's very much what I'm hoping
<dtchen_> otherwise it's going to be a very long night :/
<dtchen_> ...I think this is one stellar argument for having all source, not just /debian, in bzr
<dtchen_> err, in bzr branches on LP
<maco> agreed
<wgrant> maco: All packages are available in bzr now.
<maco> wgrant: i thought it was a few thousand?
<wgrant> maco: The entire archive (except perhaps for a few that failed) has been imported.
<maco> with full source, not just debian/?
<wgrant> Correct.
<dtchen_> wgrant: code.launchpad.net/foo ?
<dtchen_> (where foo is the source package name)
<maco> wouldnt it be /ubuntu/+source/foo?
<dtchen_> maco: doesn't seem to be a loggerhead link anywhere
<maco> *shrug*
<wgrant> dtchen_: code.launchpad.net/ubuntu/SERIES/+source/PACKAGE
<wgrant> dtchen_: Or drop the SERIES/ to get a list of all.
<dtchen_> man, either I fail, or I can't get them for linux, alsa-*, pulseaudio -- probably because none of them have upstream series set?
<dtchen_> e.g., I can see eglibc's fine
<wgrant> That's not necessary.
 * wgrant checks.
<ccheney`> dtchen_: coming to UDS? :)
<dtchen_> ccheney`: no.
<ccheney`> dtchen_: oh :(
<wgrant> dtchen_: you appear to be cursed in your package selection.
<dtchen_> yeah, go figure.
<jdong> maybe dumb question
<jdong> but how do you get an orig.tar.gz+diff.gz out of a LP branched bzr package?
<jdong> that's the last piece of the bzr-kept-packages thing that I don't understand
<maco> i think, theoretically, youre not sposed to need those
<jdong> errr
<jdong> suppose I want to make a change to znc then upload it back.
<jdong> what would be the workflow?
<maco> uhhh i guess one of those bzr/deb commands would be necessary...
<jdong> naturally, bzr branch lp:ubuntu/lucid/znc
<maco> branch, change, debcommit, push to somewhere....?
<jdong> then cd into znc and edit whatever I want.
<maco> i dont think lp will auto-build it when you debcommit & push though
<jdong> right
<jdong> it seems like you need to dput *something*
<maco> is james_w in a US timezone yet?
<jdong> debcommit just performs a bzr commit using debian/changelog
<jdong> and I just tried bzr builddeb -S and it generated one native znc debian package
<maco> right but it makes it so that when you push that branch to lp, it is automatically marked as being with that bug
<ion> When i do bzr branch lp:ubuntu/lucid/foo, i donât get a branch for the original tarball and the pristine-tar, data, right?
<jdong> ion: from what I can see you only get the branch representing the fully unpacked debian source package.
<jdong> the history seems to encode Debian changes as merges
<jdong> which is why I asked if there were some bzr-builddeb magic for reconstructing pristine-tar
<ccheney`> maco: iirc i heard you recently became a motu?
<maco> ccheney`: aye, yesterday
<ccheney`> maco: congratulations :)
<maco> ccheney`: thanks :)
<ion> I wish bzr allowed multiple branches in a single repository in a single directory with a single working tree.
 * ccheney` hopes we have a powermgmt session at UDS, karmic seemed to be a bad regression :-\
<ion> One could get the upstream, debian, ubuntu and pristine-tar branches with a single âbzr get lp:ubuntu/lucid/fooâ command.
<jdong> ccheney`: what nonsense! Karmic dims my screen if I don't touch my mouse in 2 seconds!
<jdong> ;-)
<ccheney`> jdong: heh, and mine takes 10s+ to wake up now
<ccheney`> if it does decide to wakeup at all
<jdong> haha ouch
<jdong> my wakeup is still okay
<jdong> just networking literally takes 2 orders of magnitude longer to come up compared to its stock OS.
<ccheney`> nice
<maco> jdong: which will remain unnamed? :P
<ajmitch> ccheney`: 5 minutes to wake up from hibernate isn't bad, is it?
<ccheney`> ajmitch: hahaha
<ajmitch> on a good day
<ccheney`> ajmitch: if you have a slow drive i suppose
<jdong> maco: yup :)
<ccheney`> 10-20s from sleep though is pretty slow
<ajmitch> yeah I think it's a 5400 RPM drive
<jdong> ajmitch: I couldn't tell if you were being sarcastic!
<ajmitch> I usually just suspend & it wakes up from that pretty fast
<jdong> heh even Win2k got out of hibernate in 30-ish seconds
<ajmitch> my problem is more the occasional severe slowdown once woken up
<ajmitch> I can't remember the bug #
<jdong> ah
<maco> ccheney`: 10-20s for resume from s2ram sounds like my laptop back on hardy
<jdong> the loveliness of swsusp sending everything to  swap
<ccheney`> assuming you have a swap partition and less than 4GB of ram hibernate doesn't really need to take more than 1min to work
<maco> ccheney`: also sounds like a cold boot on jaunty (but not on karmic)
 * ajmitch has a swap partition & 4GB of RAM
<ccheney`> maco: heh, yea mine was working fine on jaunty not sure what happened with karmic
<maco> i think i had a 15s boot on hardy. 35s on karmic (shouldnt say this too loud in front of ke yb uk, eh?)
 * ccheney` hasn't tested to see how slow hibernate is for him, but his drive does ~ 100MB/s with hdparm test
<ccheney`> maco: there is a ppa that is supposed to help a large amount
<ccheney`> maco: haven't tested it myself, but yea jaunty->karmic boot did get noticably slower with stock setup
<maco> i think thats hat the ureadahead sru was for
<ajmitch> I was pleasantly surprised at how well suspend/resume mostly works though :)
<maco> i havent rebooted yet though
<maco> hrm i should do laundry so i can pack for uds
<ccheney`> maco: hmm that is what i should be doing now as well, i blew it off for irc :)
<maco> my excuse was dinner
<maco> but i finished eating now
 * ccheney` will be driving up tomorrow afternoon, takes ~ 3.5hr by car
 * ajmitch would like to be there :)
 * jdong loves how maco used ureadahead and sru in the same sentence ;-)
<maco> jdong: what?
<maco> didnt something like that just happen?
<maco> or am i very confused?
<maco> yeah is in -proposed
 * ccheney` is done :)
<jdong> yes it did happen
<maco> this laundry thing is making me discover i have much better t-shirts than the men's black-t-shirt-with-band-name-on-front ive been wearing
<jdong> but that doens't stop me from commenting on that.
<jdong> I'm quite sure if I SRU'ed Azureus with transmission I'd get into trouble ;-)
<maco> hahahaha
<ScottK> Nah, it'd be "It's jdong, what did you expect".
<jdong> lol
<jdong> haha speaking of azureus
<jdong> had someone else recently bicker to me about the beg screen.
<jdong> err that's plural. beg screens.
<maco> beg screens?
<ScottK> jdong: Canonical supports putting adverts for their proprietary serverices in the default install, so I can't see how it would be different.
<jdong> I think the difference is if you say no, they don't tell you how many Canonical employees poured their hearts into it, and that you're a bad person and won't get any christmas gifts from Santa.
<jdong> maco: see bug 434979
<ubottu> Launchpad bug 434979 in azureus "vuze just asked me for money" [Medium,Confirmed] https://launchpad.net/bugs/434979
<jdong> and attached screenshots
<maco> haha ok
 * ccheney` reminds him of the hans copyright message
<ScottK> jdong: OK.  I just argued against an SRU.
<jdong> :)
<ScottK> jdong: I was restrained.  I could have marked it invalid since arguable although annoying, it's not a bug at all.
<ebroder> system-config-printer isn't using polkit, is it?
<ebroder> how is it escalating privileges?
<dtchen_> not that I see, but there's system-config-printer-udev.
<ebroder> Yeah - it looks like Fedora and/or SUSE (can't tell which) wrote cups-pk-helper, which relatively recent versions of s-c-p can use to escalate themselves
<ebroder> I find myself wanting cups-pk-helper for an unrelated project at the moment :)
<ebroder> Google is not helping me find this cups-pk-helper project, though
<ebroder> Looks like the Fedora spec file points at http://www.vuntz.net/download/cups-pk-helper/ ?
<dtchen_> ebroder: Till Kamppeter would be your best POC, I think
<ebroder> dtchen_: Ok, I'll touch base before doing anything
<dtchen_> ebroder: (or pitti, but I don't know if he still touches the printing bits)
<ebroder> Can I not have a .orig.tar.bz2? Does it have to be a .tar.gz?
<wgrant> ebroder: The new 3.0 (quilt) format permits bzip2 compression, but is not yet supported in Ubuntu.
 * ebroder nods
<ebroder> I thought you could do that with old-style packages, too
<wgrant> Sort of, but no archive software will accept it.
<wgrant> And I'm not sure if dpkg supports it any more.
<ebroder> Sure
<ebroder> It's been a while since I created a package from scratch - I'm shaky on the details
<jdong> since when did Phoronix start reviewing computer cases?
<jdong> and not even a timed MAFFT benchmark for the case.
<yofel> hi, would it be possible to SRU bug 402188? The upstream patch has been tested in a ppa and works fine. I could supply a debdiff myself.
<ubottu> Launchpad bug 402188 in vim "gvim complains about "gtk_form_set_static_gravity: assertion `static_gravity_supported' failed" in the shell it's started from" [Undecided,Confirmed] https://launchpad.net/bugs/402188
<pitti> ebroder, dtchen_: s-c-p relies on "lpadmim" membership; I think it shold also ask you for user/pwd if you aren't in that group, but I'm not sure (the cups web UI does)
<dtchen_> pitti: ok, thanks
<qense> What is the prefered way of installed GConf schemas? gconftool-2 or gconf-schemas?
<KArtinka> Hey ;)
<Kartinka> I have some Questions about DevKit and udev Rules, is here anybody who knows something about them in connection with hiding unmounted partitions
<TheMuso> c
<fcuk112> i get this pbuilder error: dpkg-shlibdeps: error: couldn't find library  avg.so.0 needed by                         debian/python-libavg/usr/lib/libColorNode.so.0.0.0 (ELF format:  'elf32-i386'; RPATH: '').
<fcuk112> i setup a pbuilder hook and when i try to grep for the file i get this: http://www.pastie.org/699559.  the debian/rules looks like this: http://www.pastie.org/699485.  can anybody help?
<ebroder> pitti: Do you know if anybody has done work on cups-pk-helper yet?
<dtchen_> hmph, I broke PA in Lucid.
<ion> naurun
<Kartinka> I have some Questions about DevKit and udev Rules, is here anybody who knows something about them in connection with hiding unmounted partitions
<dtchen_> there, PA fixed and pushed
<RetDude> Who here is experienced with PCI 2.1 add-in video cards and Ubuntu?  (Ben Stein:  Anyone?  anyone?  anyone?)
<yml> hello
<yml> I would be interested to package an new software called uwsgi and to create a PPA
<yml> I have read quite some documentation up to now and I have a couple of questions
<yml> the first one is how to integrate this operation in a dvcs workflow ?
<Kartinka> I have some Questions about DevKit and udev Rules, is here anybody who knows something about them in connection with hiding unmounted partitions
<ebroder> Kartinka: It looks like there isn't. Your best bet may be to send mail to ubuntu-devel-discuss
<ebroder> Kartinka: But in general, it's better etiquette to just ask your question instead of asking to ask
<yml> uwsgi (the application I would like to debianized is in a mercurial  repository. My idea was to create the debian folder directly inside the repository. Is there anything wrong with this approach ? dh_make refuse to run because the repository is called uwsgi and does not have yet a version.
<yml> the application is available here : http://projects.unbit.it/uwsgi
<RAOF> yml: Yes and no.  We like to have a clean separation between upstream & the packaging.  This is normally done by taking the upstream tarball and adding a debian directory to the source package only (so it goes in the .diff.gz).
<RAOF> You could also do this by having a separate mercurial branch, if hg-buildpackage exists.
<RAOF> (Which it does)
<yml> RAOF: the idea is to contribute the debian  directory to upstream
<RAOF> Well, we (as in Ubuntu & Debian) really prefer it if upstream _doesn't_ have a debian directory, at least in their releases.
<yml> so that it is part of the repository and evolve together
<yml> where is  this file managed in revision ?
<gigabytes> yml: the problem is that sometimes debian and ubuntu have different packages and the debian directory can't be the same.
<maxb> And the problem is more that the debian/ directory needs changing outside the package's upstream release cycle
<yml> gigabytes: for now it has none  :-)
<yml> ok I understand the principle
<yml> but I would prefer to be able to use mercurial to manage this file at least locally
<RAOF> Take a branch of trunk and add the debian directory.
<yml> RAOF: I installing hg-buildpackage
<RAOF> That's perfectly acceptable.
<ScottK> yml: You can, just don't include it in the tarball for a release.
<yml> this make sense
<yml> for now I plan to use MQ
<Kartinka> For my Problem specially look here: http://ubuntuforums.org/showthread.php?p=8323565#post8323565 i hope anyone can help
<maxb> Kartinka: This is a development channel, for support, please see #ubuntu
<Kartinka> there they said i should write my problem here
<Kartinka> sorry but when everybody said another shit to me what can i do :(
<ScottK> They are wrong.
<ScottK> There is also an ubuntu-users mailing list.  Maybe more luck there
<dtchen_> Kartinka: wrong channel, as stated previously.
<dtchen_> Kartinka: to answer your questions, however, they are not hidden from the system, only from devicekit-disks, which means the partitions won't appear in GNOME
<Kartinka> can i ask you, is there any way to hide them completely from the system?
<dtchen_> Kartinka: as for the syntax, please see /usr/share/doc/udev/writing_udev_rules/index.html
<ScottK> Time to board.  See you later.
<Kartinka> mh okay is there any declaration about how to know that i have to use for example KERNEL=="loop*|ram*", GOTO="hide_partitions_end"<--- loop*|ram* in this part and so on?!
<Kartinka> because i would like to understand what i do not only copy and paste cause of that i ask...
<dtchen_> Kartinka: see the file I referenced.
<Kartinka> okay i will take a look about when i switched system! sorry for nerding...^^
<Kartinka> cause can you give me last answer on the question above
<Kartinka> cause of hiding them from the whole system is it in any way possible to do or not?
<dtchen_> Kartinka: yes, of course it's possible
<dtchen_> Kartinka: if you really don't want to reboot, use http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/files/head%3A/docs/writing_udev_rules/
<Kartinka> oh thats really nice from you thank you!
<Kartinka> dtchen_ can i ask you, in which method is it possible to hide the partitions completely? :/ i hope i distrb you not to much but i found nobody before
<dtchen_> Kartinka: please, this channel is not appropriate for general support questions.
<Kartinka> can i talk to you in query?
<Kartinka> i don't want to write without asking you for it...
<dtchen_> sorry, but I'm fairly busy at the moment
<Kartinka> mh okay sorry... :(
<pitti> ebroder: first time I hear about cups-pk-helper, I'm afraid
<andersk> Why hasnât libmoose-perl synced from Debian yet?  Itâs currently uninstallable in lucid.
<ebroder> Huh? squeeze and lucid both have 0.92-1
<andersk> Lucid has 0.82-1 unless thatâs changed very very recently.
<ebroder> Ah - looks like it's in depwait
<ebroder> https://launchpad.net/ubuntu/+source/libmoose-perl/0.92-1/+build/1325365
<andersk> Looks like itâs waiting on libtest-simple-perl >= 0.88?  That should be satisfiable now.
<ebroder> No, it's in depwait for libtry-tiny-perl
<ebroder> Which is a new package. Don't archive admins have to approve new packages?
<andersk> I thought they donât (before DebianImportFreeze).
<ebroder> The process described on https://wiki.ubuntu.com/ArchiveAdministration#Syncs sounds like they have to be manually ACKed
<ScottK> If there's an existing Ubuntu diff, it takes a manual sync
<ebroder> ScottK: this is a package that was previously not in Ubuntu
<ScottK> Ah.
<ebroder> (s/previously/currently/, really)
<andersk> https://wiki.ubuntu.com/DebianImportFreeze says it should be automatic.
<ScottK> Even auto sync needs a manual push.
<andersk> Hmm, but https://wiki.ubuntu.com/LTSDebianImportFreeze does not.
#ubuntu-devel 2010-11-15
<pitti> Good morning
<pitti> tlyu: hello
<pitti> tlyu: oops, sorry; tab completion error
<SpamapS> pitti: hey, got a second to answer a question about upower?
<pitti> SpamapS: sure, what's up?
<SpamapS> pitti: so, on my macbook pro 5,1 I used to be able to suspend, but now I can't..
<SpamapS> pitti: upower --dump shows can-suspend: no
<pitti> SpamapS: what changed between "then" and "now"? dist-upgrade?
<SpamapS> pitti: I see your name come up on a lot of upower bugs and comments, so I'm hoping you have some advice for me as to where to start looking
<SpamapS> pitti: no, I installed laptop-mode-tools is all I can think of
<dholbach> good morning!
<pitti> SpamapS: it conflicts with pm-utils
<pitti> hey dholbach
<dholbach> hey pitti
<SpamapS> pitti: so, upon removing laptop-mode-tools, I needed to also re-install pm-utils, and that should enable suspend again?
<pitti> SpamapS: you can't install both at the same time, they conflict
<pitti> SpamapS: pm-utils already does most of the useful stuff of pm-utils
<pitti> sorry, of l-m-t
<SpamapS> well and with l-m-t installed, I just can't suspend at all. :(
<SpamapS> pitti: so, I just removed l-m-t and installed pm-utils again.. should I reboot to get upowerd to find pm-utils again?
<SpamapS> pitti: thanks for taking a look btw.
<SpamapS> This seems like a bug report worthy problem.. l-m-t shouldn't totally disable suspend.. :-P
<pitti> SpamapS: reboot shouldn't be necessary
<pitti> SpamapS: well, l-m-t should be removed completely, and remaining useful functionality integrated into pm-utils really
<SpamapS> pitti: upower --dump still shows can-suspend: no
<pitti> SpamapS: try "sudo killall upowerd"
<SpamapS> yaaaaay
<SpamapS> I was afraid to do that..
<SpamapS> it can be downright dangerous
<SpamapS> I installed laptop-mode-tools thinking it would be helpful on my vacation to have better battery life through aggressive techniques that it uses..
<SpamapS> then I closed the lid, threw the laptop in my backpack, and went to the airport...
<SpamapS> as I was in line for security I noticed my back getting HOT
<SpamapS> the case of the MBP nearly burned my hand
<SpamapS> pitti: thanks for the tips. I'll file a bug report against laptop-mode-tools now
<pitti> SpamapS: "stop existing"? :-)
<micahg> SpamapS: I had a similar problem at UDS
<SpamapS> bug 638307 seems to already be there. :p
<ubottu> Launchpad bug 638307 in laptop-mode-tools (Ubuntu) "Laptop-mode-tools breaks suspend" [High,Confirmed] https://launchpad.net/bugs/638307
<SpamapS> pitti: I think the proper fix for that bug is probably to just remove it.
<SpamapS> micahg: btw, it was a pleasure meeting you at UDS.. I don't think we've had a chance to chat since then. :)
<micahg> SpamapS: indeed, what TZ are you in BTW?
<SpamapS> micahg: pacific
<SpamapS> micahg: but I just got back from HI timezone. :)
<micahg> SpamapS: ah, ok
 * SpamapS finishes updating the mactel help page that led him astray to l-m-t in the first place
<mpt> pitti, hi, do you know why the work items tracker might be showing only 2 items for me this cycle when I actually have 16 or so?
<mpt> (Not that I'm complaining about lack of work or anything)
<doko> Riddell, ScottK: jbrown is looking to fix qt this week.
<pitti> mpt: where do you see that?
<mpt> pitti, <http://people.canonical.com/~platform/workitems/natty/all.html> says "mpt		2	0	0	0	0	0%"
<mpt> pitti, it doesn't include the 3 items for me on <https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-donations-for-free-software-through-software-center> for example
<pitti> mpt: that's because this spec isn't targetted for natty
<pitti> apparently it was added much after UDS (Jason and I went through the UDS specs and targetted everything)
<pitti> mpt: added to natty now
<mpt> <https://blueprints.launchpad.net/ubuntu/+spec/packageselection-n-desktop-wine-software-center> is from before UDS but doesn't look targeted either
<pitti> mpt: this needs urgent drafting and review, though
<pitti> mpt: btw, it is named "desktop", but stuart is from the u1 team, isn't he?
<Chipzz> mpt: why are you adding <> around your links?
<pitti> mpt: it doesn't have any people assigned
<Chipzz> makes it harder to copy/paste them ;)
<pitti> mpt: we don't want to plan this for natty unless we actually have someone to work on it -- do you know if someone is?
<mpt> pitti, there are assignees for all of the work items.
<mpt> I can't set the assignee for the bp as a whole because I didn't register it.
<pitti> mpt: is that ready for review?
<mpt> I don't know what that means.
<pitti> mpt: updated that one, too
<pitti> mpt: status is "new"
<mpt> thank you
<pitti> mpt: by now, the desktop specs should be drafted by the drafter, and set to "pending approval" or "review"
<pitti> (our team deadline was last Tuesday, but it's still fine to add to the pot)
<mpt> I thought we stopped "drafting" specifications a couple of years ago
<mpt> since we started using the work item tracker instead
<pitti> mpt: the wiki pages, yes; but we still use the status, and it now means that the whiteboard and work items are "ready"
<mpt> So I need to find the person who registered each one and ask them nicely to set the status to "Pending Approval"
<mpt> and then find someone else and ask them nicely to approve it
<mpt> thanks pitti, sorry for the trouble
<pitti> mpt: I can do that for you, just wanted to know if you or Scott are still working on drafting
<pitti> (done)
<mpt> No, it's complete, we both know what we need to do
<pitti> good
<mpt> Chipzz, I've done that since about 1999 because it disambiguates where the URL ends and punctuation around it begins.
<Chipzz> mpt: actually I think it creates the very problem you're trying to avoid :)
<mpt> Most IRC clients have "Copy Link" or similar menu items.
<Chipzz> but that's just my 2c
<Chipzz> to say more, I would say it makes the very problem you're trying to avoid *worse*
<geser> pitti: do you know if any "decision" about postgresql-9.0 in natty got made?
<pitti> geser: wasn't discussed yet
<geser> do you know when it's going to get discussed? (so I know when to ask about an update)
<pitti> geser: main problem is that all packaged extensions are still 8.4
<pitti> and we don't have anyone in Ubuntu who deals with them
<pitti> we could stick with 8.4 until Debian squeeze releases
<geser> in that case "postgresql-debversion" should probably only build for 8.4, right? it currently wants to build for 9.0 too
<pitti> geser: how many packages does this affect?
<pitti> if there's a significant number of Debian packages building for 9.0, we could just switch
<geser> till now I've only spotted postgresql-debversion in the FTBFS list
<sebner> didrocks: /here in natty compiz quite crashes pretty often when doing a lot of scrolling in Ooo.(?!), have you heard of such a weird thing before? Couldn't find a bug about it yet
<didrocks> sebner: not that one. Can you please get a backtrace, file a bug and subscribe smspillaz, please?
<sebner> didrocks: aye
<geser> pitti: looks like postgresql-debversion is the only package for 9.0 (couldn't find another in Debian either)
<Riddell> doko: who's jbrown?
<didrocks> sebner: thanks :)
<doko> Riddell: see #linaro
<cjwatson> mpt: better to just ensure there's whitespace around the URL, IME
<cjwatson> (not that it's all that desperately important)
<ScottK> doko: Thanks (re Qt).
<mpt> cjwatson, that means following punctuation sometimes ends up on a separate line when it should not.
<cjwatson> *shrug*
<cjwatson> you could use a non-breaking space, or reword.
<cjwatson> I used to do the <> thing too, then discovered it didn't really work well in practice so stopped
<JanC> the <> delimiters are actually recommended practice in the URL/URI RFCs (and they work fine in XChat)
<JanC> but whitespace works too
<cjwatson> I know, but they rely too heavily on people having just the right word selection algorithm in their terminal
<cjwatson> communication is best when it's convenient for other people, after all
<pitti> ebroder: FYI, we should stop the un-perl-ification for now; this requires some discussion with the Debian perl maintainers first
<apw> cjwatson, fyi it looks like the live CDs boot at least on amd64
<sebner> didrocks: meh, that's all I get: http://pastebin.com/sDBTvj6c , when debugging in gdb the screen freezes so I have to kill compiz manually and therefore get no real backtrace :( Any suggestion? (don't do debugging that often)
<cjwatson> apw: oh good.
<didrocks> sebner: run it on tty1 with gdb compiz | tee log
<didrocks> sebner: then: run --replace
<didrocks> (of course export DISPLAY=:<your_display/screen> first :))
 * cjwatson discovers that his peak sustained merge performance is around 16 packages per hour
<didrocks> waow :)
<apw> cjwatson, that sounds like a lot to me
<cjwatson> otavio did a big pile of translation uploads to d-i, so most of those were fairly easy, but hence "peak"
<sebner> didrocks: I'll try :)
<Chipzz> cjwatson: rock :)
<Chipzz> cjwatson: out of curiosity, what does that number look like in more normal cicrumstances? :)
<pitti> doko: --as-needed by default> cool!
<pitti> cjwatson: bzr FTW :)
<cjwatson> Chipzz: not sure, maybe more like half a dozen or so
<Chipzz> pitti: as much as I applaud that (and I do), won't that cause like *tons* of FTBFS'es?
<pitti> Chipzz: how so?
<pitti> how is revision control related to testing and building packages?
<Chipzz> pitti: I meant the --as-needed
<pitti> Chipzz: presumably it will; OTOH a lot of packages explicitly enable that in debian/rules or patches right now
<Chipzz> pitti: there's the matter of "what's a lot" though. :) If hundreds of packages use it now, that is indeed a lot, but still a rather small fraction of the whole archive?
<pitti> Chipzz: well, let's see how much it breaks
<pitti> Chipzz: I've seen a few packages failing with --as-needed, but most just work
<Chipzz> but anyway don't get me wrong, this is something I applaud big time :)
<cjwatson> Chipzz: yes, it causes a decent number, hence doing it at the start of a release cycle
<cjwatson> not insuperably enormous though
<Chipzz> cjwatson: with the possibility of rolling it back if too much breaks I presume?
<cjwatson> they're generally simple to fix, too
<cjwatson> Chipzz: well, it's just a switchable default so I suppose so, but I don't think it will be necessary
<cjwatson> there'd been a mass-bug-filing campaign about this in Debian for quite a while before we changed the default
<Chipzz> cjwatson: ah k, that changes things
<Chipzz> did doko do a test-rebuild of the whole archive though?
<Chipzz> (isn't that what's usually done when introducing such pervasive changes? :))
<cjwatson> I don't recall, you'd have to ask him.  I trust him to have a good understanding of how much it was going to break, and it doesn't worry me
<cjwatson> bug 673073 worries me more because the resulting build failures are harder to fix
<ubottu> Launchpad bug 673073 in linux (Ubuntu) "<net/if.h> and <linux/if.h> are incompatible" [Undecided,New] https://launchpad.net/bugs/673073
<Chipzz> right, but that has a different cause though :)
<doko> Chipzz: no, a lot of the failures are already fixed upstream (Fedora already has this change).
<doko> Chipzz: about the build failures, yes, need to be fixed. please subscribe me to bug reports
<cjwatson> Chipzz: I know it has a different cause; my point is that in general causes of hard build failures are more worrying than causes of easy build failures
<cjwatson> and I don't think we should agonise too much about the latter early in the release cycle
<sebner> didrocks: this ok? bug #675506
<ubottu> Launchpad bug 675506 in compiz (Ubuntu) "Compiz crashes when scrolling in Openoffice" [Undecided,New] https://launchpad.net/bugs/675506
<didrocks> sebner: well, extra points if you can install the -dbgsym package and get debug symbols :)
<sebner> didrocks: I thought so but couldn't find a compiz-dbg package?!
<didrocks> sebner: there are -dbgsym in the ddebs repo: http://ddebs.ubuntu.com/pool/main/c/compiz/
<didrocks> sebner: more info at https://wiki.ubuntu.com/DebuggingProgramCrash (they are generated automatically)
<didrocks> sebner: so, *compiz*/*glib* dbgsym should be enough already
<ogra_ac> lool, why is bug 587632 set back to inprogress ? do you know of someone working on it ?
<ubottu> Launchpad bug 587632 in libmad (Ubuntu) "Sound very distorted on armel" [Undecided,In progress] https://launchpad.net/bugs/587632
<lool> ogra_ac: I think I documented that Dave was working on it back then
<lool> ogra_ac: See the earlier activity in the bug by him
<ogra_ac> oh, i see the order of comments is out of sync due to cjwatson fixing the LP janitor inbetween
<apw> cjwatson, also booted i386 live natty, also seems to work
<ogra_ac> lool, yeah, i was confused by the manual close after dave worked on it
<ogra_ac> seems the marm can go andd i should just update the patch
<lool> ogra_ac: In any case it was wrong to have it Fix Released
<ogra_ac> lool, yes
<didrocks> ogra_ac: hey
<didrocks> ogra_ac: did you see your WI to port the part for armel in the netbook seed to the desktop one?
<ogra_ac> didrocks, nope, not yet, i'll take a look
<didrocks> ogra_ac: ok, I'll take care about the netbook != armel part. This should be done for A1 so that we can kill the netbook seed and iso
<didrocks> (apart if you see that you still want just one for armel)
<ogra_ac> didrocks, we will likely needs something "non GL-ish"
<ogra_ac> *need
<ogra_ac> since 80% of the arm HW wont have free drivers we can just ship
<didrocks> ogra_ac: right, but that's not related to having a netbook seed or not
<didrocks> ogra_ac: it's either, editing the desktop seed and adding [!armel] and [armel]
<ogra_ac> well, as i understand it for x86 the fallback will be a plain desktop
<sebner> didrocks: done, thanks for your help!
<didrocks> ogra_ac: yes, so that should work for you as well. It's not related to the seed stuff
<didrocks> sebner: great!
<ogra_ac> didrocks, we would like to have a 2D netbook UI for netbook images
<ogra_ac> while that will work with !armel/armel it will be a lot more work to maintain i suspect
<ogra_ac> and we will likely also have some arches where we will have to provide plain desktop images
<ogra_ac> how do you plan to do a preselection ?
<ogra_ac> if you have all sessions in the same image
<ogra_ac> (note that we neeeed to select the session at build time on the preinstalled images, no preseeding available)
<didrocks> ogra_ac: we will kill the netbook image for i386 and others at least, as the selection is only "do you have brasero or cheese"
<didrocks> ogra_ac: please look at the blueprint: https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-bringing-desktop-and-netbook-image-closer
<ogra_ac> yes, i'm looking at that since you pinged me
<didrocks> ogra_ac: why do you want a preselection? if unity can't run, it will fallback to the traditional GNOME ui
<ogra_ac> right, what about armel netbook users that dont have GL drivers installed by default ?
<didrocks> ogra_ac: well, unity and compiz won't be able to run on them, so compiz will fallback to metacity with gnome-panel
<didrocks> ogra_ac: this is specified at https://blueprints.launchpad.net/ubuntu/+spec/other-dx-n-unity-compiz
<ogra_ac> right, we want to have a solution for 2D as we always did
<ogra_ac> didrocks, see PM
<didrocks> cjwatson: is it possible to keep the netbook seed right now, rename it armel and only have an armel build image from it?
<cjwatson> I guess, but I'd rather you didn't rename it - it's confusing to have seeds named after architectures, IMO
<didrocks> cjwatson: but if we don't rename it, can there be some confusion that there is no more "UNE" but still a netbook seed?
<didrocks> if you can just ensure for now that we only build armel from it, it will be a start :)
<cjwatson> pitti: I just ran across bug 674632 - the suggested patch works for me
<ubottu> Launchpad bug 674632 in apt (Ubuntu) "apt-changelog fails to use the right server directory if more than one package version is available" [Undecided,New] https://launchpad.net/bugs/674632
<cjwatson> didrocks: seeds aren't particularly user-visible, so I doubt there would be much confusion
<ogra_ac> its rather about the amount of extra maintenance not about user confusion
<didrocks> cjwatson: sounds the safest way then, agreed
<pitti> cjwatson: oh, didn't see that it got filed; I fixed it this morning, closing
<cjwatson> thanks
 * pitti o_O: dbus-python (0.83.1-1) UNRELEASED; urgency=low
<pitti> was this a fake sync/upload?
<cjwatson> pitti: no.  the Debian maintainer appears to have hacked about with their .changes file before upload - the package in Debian really is like that.
<pitti> ah, thans
<ScottK> doko: Was #675240 intentional?  If so, I'll close the bug.
<cjwatson> SpamapS: I suggest that https://wiki.ubuntu.com/ServerTeam/Specs/Natty/UpstartServerEnhancements ought to mention the plymouth interworking that's in a work item on the corresponding LP page
<geser> is there a connection between the "core" package set and packages in main or is it pure coincidental that almost all packages from "core" are in main?
<cjwatson> core should be a strict subset of main, aside from temporary desynchronisation
<cjwatson> issues
<geser> is "ruby1.9.1" such an issue? (it's have always been in universe as far as LP tells)
<doko> ScottK: yes, let's see if we get the qt fix this week, else I'll revert the gcc change temporarily
<ScottK> doko: OK.  A warning would have been nice as that affected work I was trying to do over the weekend.
<doko> ScottK: well, I didn't expect that something like this wasn't yet fixed, even in header files
<ScottK> OK.
<diwic> is "a USB device" or "an USB device"?
<diwic> s/is/is it
<cjwatson> geser: good question ...
<geser> cjwatson: I noticed it while working on adding packageset information to the FTBFS page (I'm also wondering why gimp is in the ubuntu-server packageset)
<cjwatson> geser: ah, yes.  you can see it in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - currently scheduled for either (a) promotion to main following MIR or (b) developer deciding that it's not needed and removing it
<cjwatson> geser: packagesets tend to correspond more to the view of main that would result if all of component-mismatches were applied
<geser> so packages get sometimes added to packagesets before their MIR bug gets processed?
<cjwatson> yes
<cjwatson> largely because the process of main/universe promotion/demotion and packageset movement aren't yet integrated
<cjwatson> which in turn is because the first is done on cocoplum inside sudo -u lp_archive, and the second is a launchpadlib operation ...
<cjwatson> if somebody made the first of those into a launchpadlib operation, it would be possible to integrate the two processes
<geser> just curious: do you know why "gimp" is in the "ubuntu-*server*" packageset?
<cjwatson> the best way to find this out is to look at germinate output
<cjwatson> it's basically loads of build-depends
<cjwatson> e.g. gutenprint (in print-server) build-depends: libgimp2.0-dev
<geser> ah
<cjwatson> ebroder: your gfxpayload-blacklist branch looks good enough to me that I'm just going to merge it and then play around with it ...
<cjwatson> ebroder: have you sent all the grub-extras changes upstream?  I saw the enum_pci fix
<cjwatson> ebroder: also worth noting that PCI enumeration broke a couple of machines late in the maverick cycle, so we're going to have to figure out what's up there
<cjwatson> but of course explicitly setting GRUB_GFXPAYLOAD_LINUX is a workaround for that
<cjwatson> jibel: are you intending to draft other-qa-n-testing-different-architectures?
<seiflotfy> hey guys
<ebroder> cjwatson: I sent the bitop and enum_pci changes upstream. The only other change in my branch should be backporting to the 1.98 version of the extras
<cjwatson> ebroder: right - planning to switch to 1.99 in the natty cycle anyway
<jcastro> charlie-tca: if you have time can you confirm the fix in the PPA here so we can roll it out? https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/627744
<charlie-tca>  sure.
<SpamapS> cjwatson: re plymouth<->upstart WI interworking on https://wiki.ubuntu.com/ServerTeam/Specs/Natty/UpstartServerEnhancements: ack, will add mention.
<SpamapS> cjwatson: spec updated. Thanks for the heads up.
<cjwatson> SpamapS: no problem.  helps that I've mostly done it :)
<cjwatson> Keybuk: could you moderate my mail to upstart-devel?  the plymouth guys are being slow about moderation - I probably should've ensured I was subscribed before sending it
<pitti> lool: hey! would you mind if I did an nss-mdns NMU to Debian to drop the unnecessary Perl dependency?
<SpamapS> cjwatson: cool! I thought for some reason that upstart didn't already publish these things on dbus. Are you saying you added both sides, or just the plymouth bits?
<cjwatson> SpamapS: I needed to extend upstart slightly - patches on code.launchpad.net pending review
<cjwatson> (not very much though)
<cjwatson> SpamapS: http://paste.ubuntu.com/532400/ mbox with plymouth patch, pending mailing list moderation
<pitti> lool: (just submitted a bug report with patch to BTS, still waiting for it to land)
<cjwatson> the other thing I forgot to mention in that mail is that some job descriptions probably need to be tidied up a bit, particularly tasks (where prefixing with "Starting " didn't seem to produce what I felt were good results, given that they often already started with a verb)
<mvo> pitti: still on the campagne to get rid of perl ;) ?
<pitti> mvo: some easy parts of it anyway
<pitti> mvo: for the more hairy ones I'm currently discussing with the Debian perl team
<mvo> :)
<cjwatson> grammatically my gut feel is that service descriptions should be the name of the service in lower case, only starting with an initial capital if the service name is always written that way; and task descriptions should be a phrase describing what the task does, normally starting with a progressive verb with an initial capital ("Doing")
<cjwatson> we can figure out translatability later, but I don't think this should impede it
<cjwatson> (plymouth-upstart-bridge currently prints " * %s" for tasks and either " * Starting %s" or " * Stopping %s" for services)
<Keybuk> cjwatson: sure
<Keybuk> approved
<ari-tczew> cjwatson: did you merge around 30-40 packages today? awesome number!
<cjwatson> ari-tczew: sounds about right :) discovered my peak throughput is about 16/hour
<cjwatson> has to be fairly easy to manage that though
<cjwatson> I mean the merge has to be easy
<ari-tczew> congrats anyway
<cjwatson> ta
<smoser> cjwatson, around ?
<cjwatson> hi
<smoser> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/671097 . could you review that and possibly sponsor ?
<cjwatson> sure.
<smoser> i believe the changes were easier than we originally had thought
<bdrung> how can i check which uploads rights a person have?
<Laney> bdrung: from lp:ubuntu-archive-tools use edit_acl.py -p lpid [-S series] query
<bdrung> Laney: i get "Unauthorized: Expired token"
<cjwatson> reauthorise then; it shouldn't require any particular privileges
<cjwatson> I probably ought to change how that works since for querying the anonymous login should work
<bdrung> cjwatson: how do i reauthorise?
<cjwatson> I think the credentials live under ~/.launchpadlib/ somewhere
<cjwatson> that's odd, if I log in anonymously then I can't see ArchivePermissions, but can see the package list
<cjwatson> guess that plan won't work then
<cjwatson> geser: I think "PS?" on the ftbfs page would be clearer if it said "Set?"
<Keybuk> what I *really* want is some kind of minion who watches me write stuff on the whiteboard, and turns it into C for me
<Keybuk> a bit like the DX team do
<Keybuk> ;-)
<Keybuk> (damnit, njpatel left :p)
<apachelogger> Keybuk: you are not alone with that desire... ;)
<cjwatson> heh, I find it easier to write code than to describe it sometimes :)
<bdmurray> cjwatson: How could I determine the names of packagesets for natty using the Launchpad api?
<cjwatson> bdmurray: iterate over launchpad.packagesets
<cjwatson> bdmurray: (also see edit_acl.py in lp:ubuntu-archive-tools)
<ebroder> Can I talk any core-devs into sponsoring SRUs for bug #601732? It's proving to be a small but persistent thorn in my side
<ubottu> Launchpad bug 601732 in update-inetd (Ubuntu Maverick) "postinst using both update-inetd and debconf hangs on first install" [Undecided,New] https://launchpad.net/bugs/601732
<cjwatson> smoser: can you please rebase your branch on lp:~ubuntu-core-dev/ubuntu/lucid/grub2/lucid?  unfortunately the one you used has no common ancestor with the one I'm actually working on
<cjwatson> (out for a while)
<smoser> cjwatson, ah. sure. i branched from lp:ubuntu/lucid/grub2
<smoser> i wish there was a solution for that.
<bdmurray> cjwatson: great thanks!
<smoser> i find the fact that lp:ubuntu/<dist>/package is the most obvious and easiest thing to branch, but quite likely not the thing that someone wants you to use.
<smoser> s/.$/ to be a pain/
<cjwatson> I should probably push those branches over the top of the imported ones
<smoser> yeah, but that ends up having issues sometimes
<smoser> i'm pushing over the top of lp:~smoser/ubuntu/lucid/grub2/lucid-uec-kernel-upgrades/ right now
<cjwatson> issues> it's ok as long as you keep copies
<smoser> cjwatson, well, the issues i run into were in the branch importer winning as it (being a machine) was in the end more persistant than me. second was that i really dislike storing of .pc/ in a branch.
<cjwatson> then you repush :) if you have the latest upload tagged it won't touch it
<lool> pitti: nss-mdns > sure; thanks!
<lool> pitti: Happy if you NMU it as well
<cjwatson> chrisccoulson: are you planning to merge xulrunner-1.9.2 1.9.2.12 into natty?  I noticed it was newer in maverick-updates
<cjwatson> chrisccoulson: actually - I see that the version in natty was copied from maverick-security (probably by me), so I'll copy this new version too
<cjwatson> so disregard that
<chrisccoulson> thanks. yeah, we need to pocket copy them from maverick for now, as it doesn't work with the new toolchain
<cjwatson> righto
<cjwatson> done
<chrisccoulson> thanks
<cjwatson> smoser: BTW, I can't upload this until bug 581760 has been verified
<ubottu> Launchpad bug 581760 in grub2 (Ubuntu Lucid) "[Wubi] when updating it advices to install grub on all partitions" [High,Fix committed] https://launchpad.net/bugs/581760
<cjwatson> I'll see if I can find a machine to do that on tomorrow
<smoser> but you're good with the approach ?
<cjwatson> yes, I merged it
<cjwatson> cyphermox: are you still intending to draft packageselection-n-network-stack?
<cyphermox> cjwatson, what do you mean?
<cjwatson> cyphermox: it doesn't have a properly-written wiki page based on SpecTemplate
<cjwatson> it only has work items
<cjwatson> specs are generally expected to be written up in prose as well
<cyphermox> cjwatson, I've honestly never used wiki pages for Specs
<cjwatson> it's been Ubuntu standard since forever
<cjwatson> that's what the drafter slot in the LP blueprint page means - "person who'll write this up"
<cyphermox> well sure, let's write it up
<cyphermox> looking at the template now
<cjwatson> thanks
<cjwatson> I'm just going through all the sessions I attended and either writing them up or making sure the designated drafter's going to do it
<cyphermox> I won't look at it now, I'm finishing up on something, but will get to it today
<charlie-tca> jcastro: verified the fix for bug 627744 in -proposed now gives me the note names
<ubottu> Launchpad bug 627744 in tomboy (Ubuntu Natty) "Tomboy note names are blank in the Application Indicator fallback menu" [High,Fix committed] https://launchpad.net/bugs/627744
<jcastro> charlie-tca: woo hoo
<jcastro> kenvandine: ^
<smoser> kees, around ?
<charlie-tca> jcastro: we will need that fix in Natty too.
<G> hallyn: ping still around?
<hallyn> G: here
<G> hallyn: comment #8 for #589063 still applies
<G> hallyn: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/589063 btw
<hallyn> G: ok, thanks.  so what we would need is either input fromsomeone 'who knows', or lots and lots of testing?
<G> hallyn: I kinda gave up on the SRU because I never got any response
<hallyn> i'll try to take a closer look at it
<G> hallyn: well that was just to cover my backside ;)
<G> hallyn: there seem to be a couple of people that are using my PPA package w/o problems
<hallyn> G: but, your patch doesn't apply against the original source, so waht is in the ppa?
<G> hallyn: and there were very few BIOS changes between whats in Lucid now and whats in Maverick
<hallyn> is it a heavily patched qemu, or precisely lucid's qemu + your patch?
<G> hallyn: qemu-kvm has nothing to do w/ it
<G> hallyn: I marked it as confirmed for the seabios package which is totally seperat
<hallyn> oh?  then that woudl be why i was confused :)
<hallyn> lol
<hallyn> now i see
<hallyn> G: if you can get even one of those ppl using your ppa to comment that it fixes it for them, i'll request the sru
<G> qemu tarball does include prebuilt seabios, but they are thrown away at compile time
<G> hallyn: Troy did
<hallyn> right - i was looking at hw/acpi.c in qemu and wondering how ti compared :)
<G> hallyn: #9
<hallyn> ok, good enough for me.  I'll write up the SRU prose tomorrow.  (or you can if you want)
<G> hallyn: I originally just attached the debdiff and forgot to attach the patch on it's own
<G> hallyn: you can, as I said I gave up
<hallyn> G: and you promise youcan still boot 1 cpu and 8 cpu linux guests with it?
<G> hallyn: I seem to be able to boot 1 CPU guests for sure
<G> haven't really tried 8 but I'm sure it works
<hallyn> I'll inquire in the bug, to make sure
<hallyn> G: thanks!
<G> hallyn: the other option is to completely backport 0.6.0 or seabios
<G> *for
<G> which from Maverick we know works
<hallyn> G: I'd feel irresponsible doing that
<hallyn> Don't get me wrong, i'd *like* to do that for both seabios and gpxe
<hallyn> but don't feel i can
<G> hallyn: yeah, based on the git history it seems a bit over the top
<G> I'd have to double check but it was one of the first changes after what we are using in Lucid now, and there wasn't another bios change for a while
<hallyn> hm,
<hallyn> zul: around?
<hallyn> G: you say it is fixed in maverick right?
<G> hallyn: definately
<hallyn> (dunno why i'm asking, i know i've done 16 cpus in maverick in win2008...)
<hallyn> thanks - then i'm going to mark fix committed,
<hallyn> bc otherwise we can't proceed with an sru :)
<G> hallyn: I even asked a friend at Red Hat to test it
<G> hallyn: fwiw: https://lists.ubuntu.com/archives/ubuntu-server/2010-August/004585.html
<hallyn> G: and did it slip through the cracks from there, or wsa it nacked?
<G> hallyn: never responded to
<G> hallyn: and I've never seen an SRU e-mail since
<hallyn> G: yeah, i don't know what happened to the SRU mentions at server meetings.  And sorry that bug shouldnt' have sat so long.
#ubuntu-devel 2010-11-16
<RoAkSoAx> hi all... after the recent change to the linker (passing --as-needed by default) I have a package that is FTBFS with something like "./.libs/libpengine.so: undefined reference to `resource_location'." So I was wondering how can I find where are those symbols located (or in which library), so that I can add that to LDFLAGS?
<RoAkSoAx> before the change, the message was "warning: symbol resource_location used by debian/libpengine3/usr/lib/libpengine.so.3.0.0 found in none of the libraries."  however it didn't FTBFS
<micahg> RoAkSoAx: use apt-file to search for the library that provides that?
<james_w> RoAkSoAx, that's rather a generic name for a symbol, so it might be supposed to come from the package itself. Might be worth grepping the package source first
<RoAkSoAx> james_w: i did that with this result: http://pastebin.ubuntu.com/532677/
<ebroder> RoAkSoAx: It's in lib/pengine/utils.{h,c}
<james_w> RoAkSoAx, ok, so depending on the buildsystem there is probably a missing dependency between parts of the project
<james_w> RoAkSoAx, is it autotools?
<RoAkSoAx> james_w: yes it is
<RoAkSoAx> ebroder: right, but that's the thing, libpengine says those are missing symbols of itself?
<james_w> RoAkSoAx, it probably doesn't link utils.o in to libpengine.so
<RoAkSoAx> james_w: so what could be the possible fix? patch the makefile somehow?
<RoAkSoAx> james_w: or telling it to use that utils.o by passing it through LDFLAGS?
<james_w> RoAkSoAx, I'm just trying to remember how all this works
<RoAkSoAx> james_w: this is the makefile btw http://pastebin.ubuntu.com/532685/
<james_w> RoAkSoAx, that doesn't seem to build libpengine
<james_w> RoAkSoAx, can you grep for libpengine in all Makefile.am in the tree?
<achiang> RoAkSoAx: what package are you actually building? libpengine?
<james_w> achiang, pacemaker
<achiang> is there a full build log available somewhere?
<RoAkSoAx> james_w: the only one that list libpengine i a makefile is this one: http://pastebin.ubuntu.com/532686/
<RoAkSoAx> achiang: i'll get it for you :)
<james_w> RoAkSoAx, line 59 has utils.c, which is what I would have suggested you add :-)
<RoAkSoAx> achiang: http://launchpadlibrarian.net/59133765/buildlog_ubuntu-natty-amd64.pacemaker_1.0.9.1%2Bhg15626-2ubuntu1_FAILEDTOBUILD.txt.gz
<RoAkSoAx> james_w: indeed, and yet it still FTBFS
<james_w> RoAkSoAx, ah, it's building the executable when it fails
<james_w> RoAkSoAx, now I'm even more confused :-)
<james_w> it seems to link pengine fine the line before, then fail when linking ptest
<RoAkSoAx> james_w: indeed it is confusing... I think I'll just opt for a ' -Wl,--no-as-needed' to disable the '--as-needed'
<ebroder> RoAkSoAx: That seems almost certainly like obscuring the problem...
<RoAkSoAx> ebroder: indeed... but upstream doesn't even know why it may be failing and I can't seem to find a solution for the problem :(
<ebroder> resource_location isn't declared static or something like that, is it?
<RoAkSoAx> ebroder:in  utils.h is extern void resource_location(resource_t *rsc, node_t *node, int score, const char *tag, pe_working_set_t *data_set);
<achiang> this looks like an optimizer problem to me
<ebroder> ...it's declared extern?
<RoAkSoAx> ebroder: and in utils.c is just a simple voide resource_location...
<achiang> if object file foo.o requires symbols from object file (or library) bar.[s]o, then foo.o must come to the *right* of bar.[s]o in the linker invocation
<achiang> otherwise, the optimizer strips out all unused symbols from foo.o
<achiang> sorry, the optimizer strips out unused symbols from bar.[s]o
<RoAkSoAx> achiang: could you provide an example cause I don't seem to follow :S
<achiang> RoAkSoAx: let's say ptest.o needs a symbol from libpengine.so
<achiang> that means when you link it, you must say: bla bla bla -lpengine -o ptest.o
<achiang> what happens is the linker looks at the symbols in ptest.o; it sees something called "resource_location", and it's undefined in ptest.o
<achiang> "no problem" says the linker, i'll find it later somewhere up the line
<achiang> if you do it the other way around, the linker looks at libpengine.so, and sees a symbol called "resource_location"
<achiang> it says, "hm, no one is using this symbol yet, so i can just optimize it out"
<RoAkSoAx> achiang: so this should be changed from: -o .libs/ptest ptest.o  ../lib/common/.libs/libcrmcommon.so ../lib/pengine/.libs/libpe_status.so ./.libs/libpengine.so -lncurses /usr/lib/libhbclient.so /usr/lib/libccmclient.so -lcoroipcc ../lib/cib/.libs/libcib.so ../lib/transition/.libs/libtransitioner.so /usr/lib/libgnutls.so /usr/lib/libplumb.so /usr/lib/libpils.so -lbz2 /usr/lib/libxslt.so /usr/lib/libxml2.so -lc -luuid -lpam -lrt -ldl /usr/lib/libgl
<achiang> then when you try and link ptest.o, you get the undefined reference
<achiang> RoAkSoAx: that is my theory without actually looking at any code. it's a simple test to try for now
<achiang> RoAkSoAx: in one sentence, the linker reads from right to left, not left to right. so you must arrange your objects that way
<ebroder> achiang: AFAICT, pengine is using automake+libtool in the way that the docs recommend. If you're right, then all automake+libtool things should be breaking
<RoAkSoAx> achiang: so how would I do that, fixing up the Makefile?
<achiang> RoAkSoAx: let me try and find an example
<RoAkSoAx> achiang: thanks :)
<achiang> ebroder: like i said, it's just a theory
<achiang> RoAkSoAx: here's one that i fixed a while ago... https://bugs.launchpad.net/ubuntu/+source/alpine/+bug/668499
<achiang> RoAkSoAx: hm, that is not very instructive, is it? :-/
<achiang> feh, my natty pbuilder seems busted. can't do a test build of pacemaker due to unmet dependencies
<RoAkSoAx> achiang: more or less :/ I'd just need to find where to patch it :)
<achiang> RoAkSoAx: as a quick test for my theory, i think you can try adding this:
<RoAkSoAx> achiang: yes....?
<achiang> ptest_LDFLAGS = -l$(top_builddir)/lib/...
<achiang> sorry, trying to figure out the relative path of libpengine.so
<RoAkSoAx> achiang: cool I will. Thanks for the help :)
<achiang> RoAkSoAx: sorry, that's not complete yet
<achiang> still trying to figure out the answer
<achiang> ah, ok. there it is
<achiang> add this to the proper makefile:
<achiang> ptest_LDFLAGS = libpengine.la
<achiang> i *think* that should force the library *before* ptest.o
<achiang> RoAkSoAx: if you try that, can you please show me the build output afterwards, whether it works or not?
<RoAkSoAx> achiang: i will
<RoAkSoAx> achiang: I added this, but shows same error: http://pastebin.ubuntu.com/532712/
<achiang> RoAkSoAx: ok, i need to see the complete build log please
<RoAkSoAx> http://pastebin.ubuntu.com/532713/
<RoAkSoAx> achiang: oh ok, give me a sec
<achiang> RoAkSoAx: nm, i see it didn't make it onto the linker line
<achiang> RoAkSoAx: i don't know how to force libpengine.la before ptest.o to test my idea. perhaps whereever you were going to add "-Wl,--no-as-needed", you could instead add the reference to the library instead
<RoAkSoAx> achiang: yest that's what I was thinking off
<RoAkSoAx> achiang: something like  LDFLAGS += -Wl,--no-as-needed -libpengine.la -Wl,--as-needed ?
<achiang> RoAkSoAx: well... i would not use -Wl,--no-as-needed because as mentioned earlier, that masks the real problem.
<achiang> RoAkSoAx: try LDFLAGS += -llibpengine.la
<achiang> RoAkSoAx: but i must admit, you might have to play around with that a little. sorry, i'm not giving very good advice right now, a little distracted and thinking about dinner (i'm GMT-7)
<RoAkSoAx> achiang: haha that's fine :)... I'm in same situation (GMT-5)
<achiang> :) speaking of which, time to go a-foraging
<RoAkSoAx> achiang: i'll try that but im too tired and too hungry to keep on fighting with it. Thanks for your help :)
<RoAkSoAx> ebroder: james_w thank you to you too guys :)
<ScottK> doko_: It looks like the Qt patch to add the missing IT instructions for Thumb2 support is ~working well enough to let it build.  The problem I thought was related to lack of implicit-it=thumb in the new gcc-4.5 is actually a different problem.  So Bug #675347 is blocking us now on getting qt4-x11 and the rest of the Qt/KDE stuff building on arm.
<ubottu> Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) "volatile int causes inline assembly build failure" [High,Confirmed] https://launchpad.net/bugs/675347
<ebroder> ScottK: In the interests of making backports bugs more machine-parseable, what would you think of adding tags to indicate the source release? i.e. from-natty, etc.
<ScottK> ebroder: I think without a script to file such bugs they will be too error prone to rely on the tags.
<ScottK> If we have proper tool support, then I think it's all good.
<ebroder> ScottK: Ok, fair enough. I guess I'll have my "backport-helper" script prompt for now
<ScottK> OK.
<dholbach> good morning!
<pitti> Good morning
<dholbach> barry, do you know what still needs to happen wrt bug 663343?
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<dholbach> your merge proposal is marked as 'merged' - can we close the bug? what about Clint's merge proposal?
<wgrant> mvo: Hi.
<mvo> hey wgrant
<wgrant> mvo: I just saw your comment on bug #45129.
<ubottu> Launchpad bug 45129 in Soyuz "FFe: update-manager should have per-package changelog locations (was: uses changelogs.ubuntu.com for all packages)" [Low,Triaged] https://launchpad.net/bugs/45129
<wgrant> mvo: In the IRC discussion you said you'd have to use the binary name and version in the changelog path. But the update-manager diff uses source name and version.
<wgrant> The latter is better for us, but just wanted to confirm that that's still the case.
<mvo> wgrant: let me double check, but iirc my concern was cases like "gcc-defaults" with src_ver != bin_ver. but because the Source: field contains the src-ver it should work just fine
<wgrant> mvo: Yep, that's what I thought.
<mvo> wgrant: i.e. update-manager can construct the url without the need for a deb-src line
<mvo> wgrant: I just checked the code, the sourcepkg and sourcever should be enough
<mvo> wgrant: to make u-m work
<wgrant> mvo: Perfect, thanks.
 * mvo goes and implements that in apt-get changelog too
 * wgrant goes and implements that in Soyuz.
<mvo> !!!
 * mvo hugs wgrant
<wgrant> deathrow might be a bit of a challenge, but we'll see.
<mvo> that is the orphan cleanup part of soyuz? or punishment if tests fail?
<wgrant> It's the bit that removes orphaned files from the pool.
 * mvo nods
<TLE> pitti: Hallo, I'm presently working on the schedule for language packs updates for Maverick. I was wondering how long it takes to build them and distribute to the proposed update repositories
<pitti> TLE: building and uploading the sources takes about 3 hours; getting them built about half a day
<pitti> a full base export takes a bit longer
<TLE> pitti: more specifically, if the build starts on wednesdays at 1400 UTC at which time can I then plan on those packages being built, you copying them to proposed and finally them being distributed among the mirrors?
<pitti> TLE: your first "the build" is for the LP export, or langpack-o-matic?
<TLE> langpack-o-matic
<TLE> the exports seems to have a welldefined timeframe for them in this schedule: https://dev.launchpad.net/Translations/LanguagePackSchedule
<pitti> TLE: it wildly depends on the load of the buildds, but I'd say 12 hours in good circumstances (by and large idle buildds), and 20 in peak times
<TLE> ok, then after they are built, how much time for you to upload to proposed and circulate between mirrors, roughly?
<TLE> What'm really interested in is when we can tell users they can start testing them
<pitti> TLE: those 12/20 hours include the total turnaround starting from langpack-o-matic cron job
<pitti> until you can apt-get them on clients
<TLE> ahh ok, I thought that you would have to manually intervene to upload to proposed
<pitti> TLE: I do, but that's part of the process
<pitti> TLE: we never upload anything to -proposed automatically
<pitti> we do (or at least, want to, it's broken right now) upload to the daily PPA, and from there it's a manual process to copy to -proposed
<TLE> I'm a little confused, so as it is right now, you start a process at the dates we agree on that builds the latest exported files from launchpad and puts them in proposed, and that takes <24 hours, correct?
<pitti> right
<pitti> TLE: more precisely, the cron jobs will build them automatically from Launchpad and upload into the test PPA
<pitti> TLE: and from there I'll copy them to -proposed at the agreed dates
<TLE> All right, but you are in some way informed when the builds are done or something, so you don't need much time to do the uploads
<TLE> I just don't want to set to tight deadlines for us
<TLE> I mean to copy them from the ppa to -proposed
<TLE> sorry if I'm a little dense today, I just want to get it right
<pitti> TLE: the point where I need to do manual action is to issue the copy from PPA to -proposed; the rest happens automatically
<pitti> I'm not notified when all the builds are finished, though
<pitti> one can find out by looking at https://launchpad.net/builders
<TLE> pitti: ok, cool thanks
<pitti> tkamppeter: I am currently debugging why jockey takes so long to detect hardware
<pitti> tkamppeter: I shaved off 5 seconds, now I'm down to about 15.5 seconds on my system
<pitti> tkamppeter: of which 15 seconds is cupshelpers.getDevices(), all the rest is trivial
<pitti> tkamppeter: i. e. this takes 15 seconds here: python -c 'import cups, cupshelpers; print cupshelpers.getDevices(cups.Connection())'
<pitti> tkamppeter: do you know what takes it so long?
<pitti> tkamppeter: should jockey perhaps not do that in the first place? s-c-p always calls it with a particular printer model already, right?
<didrocks> doko_: hey, around? I'm fighting with a gcc 4.5 build issue
<doko_> didrocks: still firefox?
<didrocks> doko_: ? I'm not maintaining firefox :) no, it's about gnome-settings-daemon: http://launchpadlibrarian.net/59165700/buildlog_ubuntu-natty-i386.gnome-settings-daemon_2.32.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> doko_: as you can see we are building an additional file called debian/gnome-update-wallpaper-cache.c (http://paste.ubuntu.com/532905/) which simple options
<didrocks> doko_: we were already building the package for --as-needed for quite a long time. I tried even --no-as-needed without any success
<didrocks> doko_: I confirm it's still building fine with gcc 4.4
<doko_> didrocks: would be nice to see how pkg-config expands ...
<didrocks> doko_: sure: http://paste.ubuntu.com/532927/ nothing to worry about it seems
<cjwatson> pitti: pkgstripfiles seems to still be removing changelog.Debian.gz in the odd case, e.g. https://launchpad.net/ubuntu/+source/biococoa/2.2.1-1/+build/2048985
<cjwatson> something to do with symlinked changelogs between multi-binary sources maybe?
<cjwatson> pitti: I bet the symlink is broken so test -e fails.  perhaps:
<cjwatson> -if [ ! -e "$dch" ]; then
<cjwatson> +if [ ! -e "$dch" ] && [ ! -h "$dch" ]; then
<pitti> cjwatson: right, it shouldn't touch symlinks at all
<pitti> cjwatson: thanks for pointing out; I'll add a test case and fix it
<cjwatson> ta, just noticed 'cos new-binary-debian-universe complained at me
<YokoZar> pitti: ~branding-ubuntu -- do you think we can put pngcrush in there too?
<YokoZar> also kudos on the improvement ;)
<pitti> YokoZar: do you think pngcrush does anything good on top of optipng and advancecomp? (which are already done in pkgbinarymangler)
<YokoZar> actually maybe branding-ubuntu doesn't have any png, only svg...
<YokoZar> pitti: actually, good question, I'm not sure if pngcrush -9 is better than optipng
<YokoZar> maybe binary mangler could just run both and compare
<YokoZar> and shouldn't optipng be in main if it's done in pkgbinarymangler?
<pitti> YokoZar: optipng is in main
<YokoZar> oh, just not in maverick
<YokoZar> err nevermind
<joaopinto> mvo, hi, attempting to upgrade a package using a .deb,  using software center should work ?
<pitti> mvo: ^ I tried software-center yesterday to install a .deb from firefox, worked great; is that meant to make gdebi obsolete, or was it just an accident?
<pitti> ah, seems we already dropped it, nevermind
<bdrung> hallyn: you dropped the capslock patch in qemu-kvm 0.12.4+noroms-0ubuntu1, which let bug #427612 reappear in maverick. i am using the NEO2 layout, where the caps lock key is a normal key.
<ubottu> Launchpad bug 427612 in qemu-kvm (Ubuntu) "does not pass pressed caps lock to client" [Low,Fix released] https://launchpad.net/bugs/427612
<jml> cjwatson: just to be crystal clear, this week is not a week before an alpha is it?
<jml> cjwatson: nm
<mvo> joaopinto: is that not working?
<cjwatson> jml: no
<joaopinto> mvo, nope, at least not on maverick, it just shows the installed button disabled
<joaopinto> the install
<hallyn> bdrung: yes, that's what i said yesterday.  Someone needs to explain in the other bug: if we're going to carry a patch somewhere, why shouldn't it be in SDL to fix the root cause.
<stgraber> ogra_ac: Any change you can try to build https://launchpad.net/ubuntu/+source/lightspark on something faster than my Beagleboards/EfikaMX ?
<bdrung> hallyn: is that really a bug in sdl?
<ogra_ac> stgraber, will tyr to
<stgraber> ogra_ac: cool, thanks
<DktrKranz> stgraber: please consider it won't build other than i386 and amd64 (ppc port is still WIP)
<stgraber> DktrKranz: ah, ok. Any plan for an ARM port ?
<hallyn> bdrung: yes, that's the explanation by upstream on why they won't take it
<DktrKranz> stgraber: most of the code is portable (C++), but it also has a per-architecture portion of code written in assembly, which requires soneone to write it
<DktrKranz> someone, even
<hallyn> bdrung: and we really don't want to have patches which were rejected by upstream.  we'd *like* to follow their guidance to pursue the proper fix.  Unfortunately I haven't had time yet to look into the SDL code for more background.
<hallyn> bdrung: if you have time, that'd be *awesome*.  In fact, if in the end you can explain why SDL must be so, and why there's no other way, then we can (grudgingly) take the patch back into qemu.
<bdrung> hallyn: i have not enough time to dig into it, but i am offer testing. my testcase: set keyboard layout to NEO2 (in host and vm) and press caps+t (result should be "-")
<bdrung> hallyn: in NEO2 the caps lock key is used as modifier (similar to shift and ctrl)
<hallyn> bdrung: now, as a workaround, using vnc should work correctly for you, right?
<bdrung> hallyn: how do i use vnc with kvm?
<Keybuk> cjwatson: I was looking for a way for Launchpad to show me the merge preview in the review interface
<davmor2> Keybuk: mad fool
<cjwatson> Keybuk: it would do if not for the Launchpad bug I linked to in my comment
<Keybuk> heh
<hallyn> bdrung: if you're using kvm from cmline, you do 'kvm -vnc :1' (or :2, etc) then from the host 'vncviewer :1' to connect to it
<hallyn> bdrung: it's particularly useeful as it makes it easy to cross ssh tunnels
<jturek> 310
<bdrung> hallyn: thanks. i tested vinagre and in vinagre the caps lock behave correct. what does this tell us?
<hallyn> bdrung: only that you have a workaround
<hallyn> bdrung: well, kirkland supports putting the patch back in, so maybe we'll end up doing that
<soren> hallyn: Don't use xvncviewer :)
<soren> hallyn: gvncviewer uses gtk-vnc which is What You Want To Use[tm]. I believe it supports "-via", too, just like xvncviewer.
<hallyn> soren: think i use tightvncviewer
<hallyn> and actually i don't use -vio
<soren> hallyn: Same deal.
<hallyn> via
<hallyn> hm, why?
<soren> hallyn: So you do the ssh forwarding manually? dude, you're missing out :)
<soren> hallyn: Lots of things are simply not supported properly in clients other than gtk-vnc.
<soren> raw key codes, for instance, which is a deal breaker for many use cases.
<hallyn> hm.  allright, i'll try it sometime.  but as for forwarding, doing it manually means i can just do it the same way on my n900, on my mom's windows machine, etc.
<hallyn> soren: in the past, i had a lot of trouble with mix-matching vnc's, and back then i just settled on xtight as something that works everywhere
<hallyn> i wonder whether that's been mostly addressed by now
<hallyn> soren: so package gtkvncviewer ?
<kirkland> lool: did you push your changes for qemu-kvm (0.13.0+noroms-0ubuntu3) to lp:ubuntu/qemu-kvm ?
<soren> hallyn: There's an interesting intersection of people working on gtk-vnc and on various virt technology.
<kirkland> lool: i just had an upload conflict
<soren> hallyn: Like danpb and aliguori.
<soren> hallyn: It's packaged.
<hallyn> yeah, but there are at least 2 that sound like it :)
<hallyn> gtkvncviewer and gvncviewer
<soren> hallyn: Both should be fine.
<soren> hallyn: They both use gtk-vnc.
<soren> hallyn: gvncviewer is just more familiar if you're used to xvncviewer.
<hallyn> all right, installed, i'll give it a spin, thanks :)
<soren> sure :)(
<soren> :)
<bregma> I'm looking for some guidance on filing an SRU in maverick, is there anyone around to give me some advice?
<kirkland> hallyn: okay, mouse fixes uploaded
<kirkland> hallyn: i had to resolve a conflict with lool's last qemu-kvm upload
<hallyn> kirkland: oh?  i had just fetched the tree late last night
<kirkland> hallyn: yup, you did the right thing
<hallyn> <big sigh> i'm getting just about burned out on bugs for the week
<zul> hggdh: ping
<kirkland> hallyn: it's tuesday :-)
<zul> hallyn: bugs are to be taken orally not rectally ;)
<hallyn> doh!
<NoobFukaire1> anyone know of a PPA or something with an ubuntu kernel and the new wonder UI patch applied?
<bdrung> NoobFukaire1: you may ask in #ubuntu-kernel
<NoobFukaire1> thx
<pitti> kees, cjwatson, mdz: TB in 5 mins, right? or in an hour?
<cjwatson> my belief is 5mins
<ogra_ac> stgraber, omg ... 700M build deps ?
<highvoltage> ogra_ac: do you perhaps have a minute to shed some insight on a classmate issue in #edubuntu?
<stgraber> ogra_ac: I'm guessing it build-deps on gstreamer and a few similar stuff :) Though as mentioned by DktrKranz earlier, it'll fail anyway as the code needs to be "ported" to ARM (as in, add a bit of ARM assembly in the code).
<stgraber> ogra_ac: they support x86 32/64bit and seem to be working on a powerpc port, maybe we can find someone willing to do the work (or at least look at it) to make it compatible with ARM
<ogra_ac> stgraber, assembly ???
<stgraber> 14:29 < DktrKranz> stgraber: most of the code is portable (C++), but it also has a per-architecture portion of code written in assembly, which requires soneone to write it
<stgraber> apparently, yes ...
<ogra_ac> bah
<ogra_ac> there should really be no assembly
<stgraber> I agree :) I'm guessing it's meant for performance optimization or whatever.
<ogra_ac> thats nonsense in times of gcc 4.5 ;)
<hggdh> zul: consider yourself ponged
<zul> hggdh: sorry i figured it out :)
<hggdh> zul: heh
<kirkland> hallyn: qemu-kvm FTBFS: http://launchpadlibrarian.net/59199370/buildlog_ubuntu-natty-i386.qemu-kvm_0.13.0%2Bnoroms-0ubuntu4_FAILEDTOBUILD.txt.gz
<ogra_ac> stgraber, so there isnt really any point in me doing a testbuild
<stgraber> ogra_ac: I'd guess it's simply going to fail on the ASM part. I haven't looked at the code but based on DktrKranz's comment earlier, I wouldn't think it's going to fallback to "less efficient" c++ code
<hallyn> kirkland: i think that has nothing to do with us...
<kirkland> hallyn: interesting, alright ...
<hallyn> 'gcc: Internal error: Killed (program cc1)
<kirkland> kees: toolchain issues in natty at the moment?
<kirkland> doko_: ?
<hallyn> kirkland: and too bad, bc i'm about to propose another little merge for the same tree
<kees> kirkland: not sure; I just got back from holiday
<hallyn> kirkland: wonder whether the amd64 will pass
<kirkland> hallyn: doubtful
<kirkland> hallyn: did you try a pbuild local?
<hallyn> pessemist
<kirkland> hallyn: heh
<hallyn> yeah, but against maverick
<kirkland> hallyn: ah
<hallyn> (so i could run it)
<kirkland> hallyn: yeah
<ogra_ac> pfft, thats so unimportant, important is if armel will pass
<hallyn> a build is under way in a natty schroot
<ogra_ac> :)
<kirkland> ogra: ;-)
<hallyn> ogra_ac: so true
<hallyn> kirkland: if you're not on a call right now, interesting conversation on qemucall (about distro bugs)
<kirkland> hallyn: hmm, no i didn't join today
<ScottK> pitti: Would you please review the paragraph I added to https://wiki.kubuntu.org/Kubuntu/UpdatesPolicy (at the end of the policy section) and make sure I captured it correctly.
<pitti> ScottK: that sounds fine to me, thank you
<ScottK> pitti: Thanks for checking.
<hallyn> kirkland: ha!  https://launchpad.net/~serge-hallyn/+archive/virt?field.series_filter=natty
<hallyn> kirkland: last night it compiled fine for natty
<pitti> ScottK: added to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<ScottK> Cool.
<ScottK> That's only been on my TODO for a year and a half ....
<ogra_ac> stgraber,
<ogra_ac> CMake Error at CMakeLists.txt:96 (MESSAGE):
<ogra_ac>   Platform armv7l not supported
<kirkland> hallyn: weird
<dholbach> pitti, can we reset the burn down line of canonical-community?
<dholbach> pitti, I tried to find a way, but there seems to be no natty.cfg
<pitti> dholbach: there is, on lillypilly
<pitti> dholbach: sudo -u platform -i, then you can edit natty.cfg there
<pitti> dholbach: (sorry, in meeting)
<pitti> dholbach: lillypilly is people.c.c.
<dholbach> aha, I was looking in ~pitti ;-)
<tkamppeter> pitti, hi
<tkamppeter> pitti, sorry for not having followed IRC.
<tkamppeter> pitti, cupshelpers.getDevices(
<pitti> hello tkamppeter, how are you? (no problem, it's not that urgent)
<dholbach> thanks pitti
<pitti> tkamppeter: I disabled cupshelpers from normal jockey operation for now, since printer drivers are almost always installed via s-c-p
<tkamppeter> pitti, cupshelpers.getDevices() takes 15 seconds like "lpinfo -v" does as CUPS waits 15 sec for answers of network and Bluetooth printers.
<pitti> tkamppeter: ah, that explains it
<tkamppeter> pitti, Jockey does not actually need to look for printers. Local printers are handled via UDEV when plugged or via CUPS startup during boot.
<pitti> tkamppeter: that's what I thought
<pitti> tkamppeter: ok, thanks for confirming
<tkamppeter> Remote printers printers should not be set up non-interactively. One usually sets them up on one or two boxes and then one activates CUPS browsing. Therefore these printers should only get set up on explicit request by the user (via s-c-p).
<tkamppeter> So for printers Jockey should only get called for the actual driver download for an already detected printer, not for finding the printers.
<pitti> right
<doko_> kirkland: preprocessed source?
<didrocks> pitti: cjwatson: FYI (just saw the meeting and the /opt discussion), I've implemented a tentative of getting prefix support for python-support and such. It's on my ppa now: https://launchpad.net/~didrocks/+archive/ppa/
<pitti> didrocks: oh, nice
<didrocks> also Quickly trunk now support installing in that prefix
<didrocks> (and upgrade existing projects)
* You're now known as ubuntulog
<smoser> in a debian 3.0 quilt format, stored in bzr, should i store the bzr with the patches applied ?
<smoser> i think the answer is yes
<cjwatson> didrocks: we should be moving to dh_python2/dh_python3, though, right?
<cjwatson> smoser: yes (IMO)
<smoser> cjwatson, and store the .pc directory also ?
<cjwatson> I don't, normally, although the importer does
<cjwatson> it's an open question
<didrocks> cjwatson: I have a work item to prepare dh_python* to support prefix. But not sure with unity and such I'll have the time to support it this cycle. So, I've just keep with what exists
<smoser> or were there fixes to that bug you had opened to have rules force-apply them.
<cjwatson> I find it easier not to
<cjwatson> and cope with the fact that other people working on the branch will have to do a little bit of fiddling after checkout/update
<cjwatson> but that's just my opinion
<smoser> i prefer no .pc, so i'll go with that. and add a rule to force fix .pc.
<smoser> thanks.
<ogra_ac> stgraber, hmm, i get it to compile but on my ac100 it triggers compiler errors (which are more likely kernel errors with the tegra kernel), i will try it on a panda soon
* You're now known as ubuntulog_
* You're now known as ubuntulog
<RoAkSoAx> kirkland: howdy!! For PowerNap I was thinking if it would be a good idea to turn off some services when on powersave mode... such as stopping logging or things that can still cause disk I/O or something... would that e something easily doable?
<kirkland> RoAkSoAx: hmm, i'm not too sure about that
<kirkland> RoAkSoAx: maybe in a future iteration
<kirkland> RoAkSoAx: lets focus on hardware hacks for now
<RoAkSoAx> kirkland: yeah the problem is that I've been trying to spin down the harddrive but it gets woken up. Maybe I'm not doing it right... Other thing I thought about is extend the time on which the data is actually written into disk
<RoAkSoAx> from memory to disk
<RoAkSoAx> kirkland: by reducing the dirty page writeback frequency
<seb128> ev: could you review https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/661289 when you have time?
<rsajdok> how to get access to send email to https://lists.ubuntu.com/archives/ubuntu-devel/ ?
<micahg> rsajdok: anyone can send, but it's moderated for non-developers AFAIK
<rsajdok> micahg: I sent email yesterday. It is not yet approved
 * lamont has a question... https://bugs.launchpad.net/ubuntu/+source/apt/+bug/673446 is, in fact, not an apt bug, but was an archive issue.  does that mean it should get closed as 'invalid', or would 'fix released' be more accurate?
<seb128> lamont, invalid
<lamont> seb128: thanks
<seb128> the apt task was invalid at least, you can add a comment saying that
<highvoltage> e/win 19
<lamont> seb128: commented that it was actually an archive issue on old-releases, which I have now fixed.
<seb128> lamont, ok, thanks
<lamont> so amusingly,  while it's not a bug in ubuntu, it is my bug.
<lamont> for sad values of 'amusingly'
<smoser> cjwatson, is bug 581760 testable without a windows installation ?
<ubottu> Launchpad bug 581760 in grub2 (Ubuntu Lucid) "[Wubi] when updating it advices to install grub on all partitions" [High,Fix committed] https://launchpad.net/bugs/581760
<geser> kees: do you know what happened to the 'Dynamic "per package upload permissions" for Debian Developer' topic on the TB agenda? From a look at the wiki edits it looks like it simply got dropped without getting discussed. Sylvestre is asking about any information of the outcome.
<kees> geser: hmm... IIRC, it was supposed to go to the mailing list for further discussion?
<jdstrand> wendar: fyi, I add PostReleaseApps/SecurityChecklist today
<wendar> jdstrand: excellent, thanks! I'll read through it now
<geser> kees: the TB mailing list?
<kees> geser: yeah
<geser> kees: I don't see anything in the archives for Oct and Nov
<highvoltage> ddd/win 13
<highvoltage> (bah)
<kees> geser: yeah, best to bring it up on the list then.
<wendar> jdstrand: also sending the link on to the ARB list, for all members to review
<jdstrand> wendar: cool, thanks
<geser> kees: looks like it was discussed during the meeting on 2010-11-02. Will reply to Sylvestre with the link to the meeting log.
<kees> okay
<ajmitch> jdstrand: some of the social items in there will need more discussion, like the developer contract & $
<jdstrand> ajmitch: oh absolutely
<jdstrand> ajmitch: I imagine that document to be refined after further discussion, but based on our team's current understanding, etc, etc that is what we came up with
<ajmitch> jdstrand: thanks for putting it together
<jdstrand> ajmitch: sure np. I wrote it up, but everyone on the ubuntu-security contributed
<jdstrand> the ubuntu-security *team* that is
<wendar> jdstrand: the comments on socially encouraging good security behavior by preventing anonymous contributions are an important addition too, thanks!
<wendar> jdstrand: at the moment we require a PPA, which is a certain level of "verification" of a real human. and in the future it looks like we'll be integrating ARB with our commercial signup process, which is another level of verification
<wendar> jdstrand: we may not charge a dollar for submitting an application, but we may very well take financial information from some developers, if they want to accept donations for their free software
<jdstrand> wendar: regarding 'anonymous contributions'-- thank mdeslaur (but we all agree :)
<jdstrand> wendar: it doesn't have to be a dollar-- it could be $.01. the idea is that it makes it harder to be anonymous (unless you are being seriously criminal)
<jdstrand> wendar: but all the PPA business was that we don't want their software changing the upgrade system, etc
<jdstrand> well, you probably ment that the PPA is one deterrent
<jdstrand> wendar: anyhoo, yes it is, but it is easy to miss intentionally malicious software without a very thorough and time-consuming review. with social deterrents, you tend to get for free
<jdstrand> /get/keep malicous software out/
<jdstrand> mind you, *tend* :)
<jdstrand> a really bad guy will find a way
<wendar> jdstrand: aye, there's always a way, but we can prevent/discourage as much as possible
<jdstrand> absolutely! (hence the checklist ;)
<cjwatson> rsajdok: then it's in the queue - I'll look at it next time I'm at my laptop
<cjwatson> smoser: no
<wendar> jdstrand: and, on PPAs, yes, meant the fact that they have to set up account with valid email and sign the code of conduct, etc, etc, is a beginning of social pressure for good behavior
<jdstrand> wendar: we discussed that and recognize it is the beginning, but that alone is a pretty low barrier in our opinion
<wendar> wendar: agreed, it's possible to complete with entirely fake identity
<jdstrand> wendar: anyhoo, it seems we are on the same page for that. certainly worht more discussion for more social pressure
<wendar> jdstrand: very much so. will loop back with you once ARB has had a chance to discuss. thanks for putting it together!
<jdstrand> sure! :)
<lifeless> kees: ping
<lifeless> pitti: ping
<kees> lifeless: sup?
<lifeless> please try your private files thing
<lifeless> on launchpad production
<kees> oh, is it live?
<lifeless> just now
<lifeless> evaluating whether we broke anything
<kees> one moment...
<kees> *drum roll*
<kees> no 503!
<kees> \o/
<lifeless> kees: faster ?
<kees> lifeless: looks great for the one smaller package we've got in a secppa
<lifeless> \o/
<kees> lifeless: dunno about actual transfer through-put, but yeah, when 5 out of every 6 downloads don't have to retry 3 times with a 10 second pause between each attempt, it's much faster ;)
<lifeless> kees: awesome. Feel free to blog about lp awesomeness :)
<lifeless> kees: though we may have to roll it back - dunno yet :)
<kees> heh, d'oh
<kees> lifeless: well, FWIW, this is the first time in maybe a year (or more?) where there have been no 503 retries. well done! :)
<lifeless> rolling it back
<lifeless> would break apport right now
<lifeless> actually
<lifeless> I think we can avoid this.
<kees> oh? bummer.
<lifeless> kees: keeping it live
<lifeless> please let me know how it goes
<ScottK> wendar: Having a PPA is not related to not being anonymous.
<ScottK> The fact that there is a valid email address doesn't help that at all.
<kirkland> kees: fyi, your dmesg change will break kvm-ok, at least until you get the changes checked in to check kvm in bios outside of dmesg ;-)
<SpamapS> is anyone else overjoyed that we actually have v3 of mdadm in natty?
<kees> kirkland: yeah, I've been making a list. I intend to replace kvm-ok and the nx test with proper MSR calls anyway.
<ebroder> kees: Does that mean that I'll be able to detect if the BIOS disabled HW virt without loading the kvm modules? Because that would be awesome
<kees> ebroder: yes, I think so. As I understand it, the kvm modules are just checking a specific MSR.
<kees> ebroder: it'll look something like this: http://bazaar.launchpad.net/~cpu-checker-dev/cpu-checker/trunk/annotate/head%3A/check-nx
<kees> except I'll be adjusting it to not do all that crazy stuff at the start and just expects to run as root with msr-tools installed.
<ebroder> kees: Oh, I can do this now? Even better
<kees> ebroder: yup, if you can find the MSR you need to read, it should be trivial. It just hasn't bubbled to the top of my TODO yet.
<kees> ebroder: but if you do get it written, please share. I want to get it in there. :)
<kees> (I also need to write an MIR for msr-tools)
<ebroder> kees: Will do. Shouldn't be too hard - last time I looked at this I gave up when I found that the instruction the kernel used was privileged only. Hooking the bits together should be easy, though
<kees> ebroder: well, that part isn't much different, only root can read the msr device.
<ebroder> kees: That's fine. I can arrange to be root for my use case. I didn't want to arrange to be the kernel
<kees> haha yeah
<kees> well, while I'm waiting, now I want to go look
<ebroder> rdmsrl(MSR_VM_CR, vm_cr); is one of the manufacturers
<ebroder> That's AMD
<ebroder> is_disabled in arch/x86/kvm/svm.c
<ebroder> And vmx_disabled_by_bios in arch/x86/kvm/vmx.c
<RoAkSoAx> kirkland: btw.. just saw you gonna work on cobbler. You might wanna take a look at: http://www.threedrunkensysadsonthe.net/2010/07/installing-cobbler-on-ubuntu
<kees> MSR_IA32_FEATURE_CONTROL
<ebroder> kees: I think rdmsr --bitfield 4:4 0xc0010114 will work for AMD
<ebroder> Still working on understanding the logic for Intel, but it's various bits of 0x3a
<RoAkSoAx> kirkland: seems unaccessible for now, but that guy branched cobbler and made changes that supposedly enabled it to work in Ubuntu
<kirkland> RoAkSoAx: where at?
<RoAkSoAx> kirkland: http://www.threedrunkensysadsonthe.net/2010/07/installing-cobbler-on-ubuntu (Seems unaccessible for me, for now)
<RoAkSoAx> kirkland: I read it like couple weeks ago or so
<kees> ebroder: when svm is disabled in the BIOS, does it still show up in /proc/cpuinfo?
<ebroder> kees: Not sure
<kees> kirkland: ?
<ebroder> kees: vmx definitely does
<kirkland> kees: huh?
<kirkland> kees: oh, yes, it does
<kees> ah, yeah, looking at kvm-ok, it does. okay
<kirkland> kees: see the current logic in kvm-ok
<kirkland> kees: that logic is correct
<ebroder> kees: I take it you're writing the code at this point so I shouldn't?
<kees> ebroder: I think I'm close. I just need hw to test with
<kees> ebroder: I'll continue in a bit
<ebroder> kees: I have Intel hw I can reboot repeatedly if that helps, although I don't think I can test any of the trusted boot stuff
#ubuntu-devel 2010-11-17
<cjwatson> SpamapS: thank psurbhi for that
<psusi> cjwatson, say umm... is it known that the amd64 builds of grub-emu are broken?  I get "invalid arch independent ELF magic" trying to load modules, but not on an i386 system
<dholbach> good morning!
<didrocks> good morning Mr Holbach :)
<dholbach> salut monsieur didrocks
<dholbach> comment Ã§a va?
<didrocks> dholbach: trÃ¨s bien, et toi ? :)
<dholbach> trÃ¨s bien aussi - merci
 * dholbach va chercher du cafÃ©
<didrocks> dholbach: french speaking day for you? :)
<dholbach> didrocks, just a little bit :)
<apw> anyone know if there was a build farm problem last night, i have an i386 and a powerpc build failure without logs
<wgrant> apw: Yeah, there were some issues.
<wgrant> apw: Not entirely resolved, but it should be mostly better now. Please retry.
<wgrant> We may do a mass-giveback later.
<wgrant> Once we have everything fixed.
<apw> wgrant, that sounds bad
<wgrant> But no guarantees.
<apw> not pkgmangler ?
<wgrant> No, internal Launchpad issues.
<wgrant> pkgbinarymangler is easily fixable.
<apw> wgrant, yay another successful launchpad release ?
<wgrant> apw: No, that's not for a couple of hours :)
<wgrant> Although this was an update to see if the release was safe...
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 10:00-12:00 UTC for DB update | Archive: Open | maverick-proposed is now unfrozen | 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/Help
<rsajdok> How long does it take to get approval of a sent message to the list?
<cjwatson> rsajdok: between when I answered you last night and about now, I've been (a) having family time and then (b) in bed.  patience!
<ogra> you really need to cut donw on that bed stuff :P
<cjwatson> there were a whole 7 messages in the queue when I last looked - not a huge backlog or anything
<ogra> did you notice that antimony seems to have run out of space ?
<cjwatson> so what else is new :P
 * ogra wonders whom to ping
<cjwatson> I'll look in a bit
<ogra> heh
<cjwatson> rsajdok: uh, this mail isn't really appropriate for ubuntu-devel - the package is clearly buildable by Ubuntu so it's basically a support request, and there isn't enough information in your pastebin entry to fix your problem even if it were appropriate
<cjwatson> rsajdok: which bzr branch did you check out before running bzr-buildpackage?
<cjwatson> rsajdok: I'd be happy to help you figure out your problem, just not on the ubuntu-devel mailing list
<joaopinto> good morning
<joaopinto> how do we report bugs for partner packages ?
<cjwatson> they should have source package entries in Ubuntu in Launchpad
<joaopinto> gstreamer0.10-fluendo-plugins-mp3-partner presents an acceptance dialog, but I am not alllowed to cancel the install
<joaopinto> ubuntu-bug tells me it's not a genuine package
<cjwatson> https://launchpad.net/ubuntu/+source/gstreamer0.10-fluendo-plugins-partner/+filebug (when LP comes back out of read-only mode)
<joaopinto> ok, will do, thanks
<rsajdok> cjwatson: yes, I did check out bzr branch, like description: http://unity.ubuntu.com/getinvolved/#coding
<rsajdok> cjwatson: so, where is better place for this question?
<cjwatson> rsajdok: I see your confusion.  lp:unity is the upstream branch - it doesn't have packaging metadata, so you can't build it with bzr-buildpackage
<cjwatson> rsajdok: looking at the source, I guess you need to use cmake to build it (not a build system I know very well).  #ayatana can probably help if you have detailed questions on that
<didrocks> the packaging branch is at lp:~unity-team/unity/packaging.
<didrocks> rsajdok: you have build instructions at https://wiki.ubuntu.com/Unity/InstallationGuide
<rsajdok> cjwatson: Where is better place to ask questions of involved unity?
<cjwatson> rsajdok: I already suggested #ayatana, which I think is right - didrocks?
<didrocks> yep, this is the good place to be :)
<rsajdok> cjwatson: thanks for wiki. This is it.
<rsajdok> didrocks: thanks also!
* mthaddon changed the topic of #ubuntu-devel to: Archive: Open | maverick-proposed is now unfrozen | 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
<seb128> ev: thanks for the usb-creator upload
<ev> sure thing.  Sorry I didn't get to it sooner
<cjwatson> grr, one of these days I will do a man-db release and not screw something up
<cjwatson> ogra: cleared up 27GB or so, hopefully that will keep us going for a bit
<cjwatson> (well, rm -rf still running)
<ogra_ac> great
<ogra_ac> cant we have some additional disks ?
<ogra_ac> so we dont always hit the limit
<cjwatson> feel free to file an RT, I gathered there were some physical limits
<cjwatson> plus there are problems on the internal cdimage mirrors if the size goes up very much, so it's not just that one machine
<ogra_ac> hmm, k
<cjwatson> the local archive mirror does tend to grow though
<cjwatson> I wonder if I should just drop the separate universe mirror
<ogra_ac> long term it might be good though, if we one day start building more armel flavours the space might get eaten up faster
<cjwatson> but that makes it easy to have accidents
<cjwatson> if you do you're going to have to figure out hosting
<cjwatson> it's a problem
<ogra_ac> well, we only need the temporary space during builds
<ogra_ac> but if you build in parallel that might be a lot
<cjwatson> hosting => cdimage.ubuntu.com
<cjwatson> not talking about antimony ...
<ogra_ac> right, hosting should be okayish, the resultimg images are rather small
<ogra_ac> *resulting
<ogra_ac> and currently we dont build many more flavours
<ogra_ac> (natty that is)
<ogra_ac> cjwatson, oh, btw, feel free to ignore the armel build failure of d-i for now, i'm still waiting for a statement from the kernel team about the possibility of using linaro kernels for omap3, until then its fine to let it fail
<cjwatson> ah, here, I can do some backup clearance
<cjwatson> ogra_ac: ignoring :-)
<cjwatson> ogra_ac: 93GB free now, should last for a while
<ogra_ac> yeah, sounds good
<geser> mvo: Hi, do you have a minute to look at this libapt-pkg check from postgresql-debversion? http://paste.ubuntu.com/533447/ Do you have idea what's causing this?
<apw> pitti, is the natty.cfg under platform under revision control at all ?
<pitti> apw: no, not any more; other projects use the wi tracker as well now, and I don't think it's appropriate to keep them all in trunk
<apw> pitti, yep understand why our configs wouldn't be in there, wondered if there was a branch for it,  ie a place with just our configs into which we regularly merge trunk or ... its not in VCS
<pitti> it's not a VCS right now
<apw> if its not thats fine, just don't want to do the wrong thing... thanks :)
<pitti> if somebody wants to create one, I don't mind at all
 * ogra_ac lols about none-kernel-n-misc ... apw now thats a funny spec 
<apw> heh why funny ?
<apw> our left over crap spec
<ogra_ac> apw, you are aware that this addes another 5-10 items for canonical-arm to even produce such an image ?
<ogra_ac> unless the kernel team planned to build it
<apw> ogra_ac, why so?  i swap in kernels into an existing image all the time
<apw> the item was to cover the fact that you need to know whether a linaro kernel is any good for making CDs or not?
<ogra_ac> ah, thats something the workitem should say ;)
<ogra_ac> i cant really say if the built initrd will be good, if jasper will work etc
<apw> [canonical-arm] to swap in a Linaro kernel into an existing CD image confirm feature set:TODO
<apw> is that better ?
<ogra_ac> unless i actually build it the way we build all our images, the preinstalled images we ship are more like live images
<apw> ogra_ac, yeah i have been droppiing replacement kernels into live CDs, its not 'easy' but its doable
<ogra_ac> yes, we cant say if it will work for preinstalled that way, but can at least roughly judge if the HW works
<apw> as long as you then put them on a USB stick anyhow
<ogra_ac> right
<ogra_ac> preinstalled images make that a lot easier than live ones, but its a bit more work than just replacing vmlinuz
<apw> yep you have to unwrap the initrd and replace the modules and roll it back up
<ogra_ac> nah
<ogra_ac> in preinstalled you just chroot into the rootfs and run update-initramfs ;)
<apw> ahh
<ogra_ac> the tricky part is that you need to do the bootloader bits by hand
<ogra_ac> i.e. run mkimage to create uImage and uInitrd for uboot
<apw> anyhow i've used the reworded item so you don't explode :)
<ogra_ac> and put them in the right places
<ogra_ac> i dont explode ;)
<ogra_ac> originally it just sounded like we should build an image
<apw> (through overwork)
<ogra_ac> which needs MIR etc
<apw> heh no, this is a pre-cursor activity, though if they arn't supporting them then its likely they fail before then
<ogra_ac> well, the kernel and security teams from ubuntu would have to support them
<ogra_ac> they would just offer the base tree but aligned with our master
<apw> and i suspect that the work is minor for security but i don't see where we will have resource to do that for sometime yet
<ogra_ac> so the only issue left to use them are config alignments and security updates
<ogra_ac> apw, well, dont you have two new arm positions ?
<ogra_ac> once these are filled one of them could work on that
<apw> so if it takes 2 months to fill them, and 2 months to train them, we'll have resource available after feature freeze
<ogra_ac> i assume one fulltime person is enough and it would load off most of the arm work to linaro
<apw> kernel freeze even
<ogra_ac> yeah, thats a bit late
<ogra_ac> though its likely that the only kernel for now will be omap3
<ogra_ac> omap4 is handled differently anyway
<apw> and what is the use case for omap3 ?
<ogra_ac> it has teh biggest community in arm land
<apw> omap4> indeed
<ogra_ac> we dont want to lose them
<ogra_ac> oh, omap4
<ogra_ac> contracts ;)
<apw> yeah happy we have the incentive and resource for omap4
<ogra_ac> bryan will work full time on omap4 with TI as last release
<apw> yep
<ogra_ac> there wont be many changes apart from timing at TI side
<ScottK> apw: There are other teams making plans based on the understanding there will be an omap3 kernel.
<ogra_ac> so the only intresting part is omap3
<ogra_ac> since we want to keep it for the community
<apw> ogra_ac, you wanted omap3 pulled out of master, why was that
<apw> given noone is sending anything to add to any hyperthetical omap3 branch
<ogra_ac> apw, because it got in your way wrt build time and it got into our way wrt flexibility for adding patches late in the cycle
<apw> though now you have nothing instead
<ogra_ac> having it in mainline vs a topic branch was always getting in our way
<ogra_ac> now i have a vibrant discussion with linaro
<ogra_ac> and hopefully wiht the kernel and security teams
<apw> heh well there is that
<ogra_ac> with the target to load all core maintenance work off to linaro
<ogra_ac> and only have the long trem tasks in karnel/security
<ogra_ac> *term
<apw> but if they provide no support for their kernels how do they end up doing anything maintenance wise
<ogra_ac> the omap3 kernel is pulled directly from our mainline
<ogra_ac> including the ubuntu sauce
<ogra_ac> and the existing config
<ogra_ac> so all i need is security commitment for post release
<apw> but we already had exactly that in our kernel before we ripped it out, if that is where it is coming from
<apw> so i am doing the work anyhow before release, and after we'd have to do it?
<apw> so thats lose lose lose for me ?
<ogra_ac> right, but you wont have to handle e.g. my $new_omap3_board misses patch XY
<apw> yeah we do, as they don't do any support after release
<ogra_ac> all the patchwork goes to linaro
<apw> they don't maintain any released versions, they move on to new ones and do not look back
<ogra_ac> so we could define that no SRUs happen for that kernel ;)
<ogra_ac> only security maintenance
<apw> then we still gained exactly nothing for adding linaro into the loop
<ogra_ac> which should be trivial given they are both the same tree
<ogra_ac> sure you do
 * apw waits to be enlightened
<ogra_ac> you dont have to care for it at all during development
<ogra_ac> since linaro does that
<apw> except their tree comes from whats in our master branch
<ogra_ac> plus their patches
<apw> and i am providing the sauce and ocnfigs
<apw> how are they helping me at all
<ogra_ac> they maintain the arch specific config
<ogra_ac> not your job
<ogra_ac> they maintin everything thats arch specifc
<ogra_ac> you dont have to touch it
<apw> are they commited to an ubuntu config there?  i heard they were going minimal on all their configs
<ogra_ac> well, thats discussable i think
<ogra_ac> how i see it is that during developemtn you shouldnt have to touch it at all
<apw> see now we have to have a discussion ... i am not convinced there is any time saving in here
<apw> if we'd just left it in master you'd have 2.6.37-rc2 ker
<ogra_ac> and post release you would take over security maintenance
<apw> kernels by now, instread of none
<ogra_ac> hmm
<ogra_ac> but you have the maintenance work, have to review patches etc
<apw> OMAP3 is mostly upstream though isn't it
<ogra_ac> i'm fine not having omap3 before alpha2 if that turns into less duplication
<apw> as its nearly so old as to being dead
<ogra_ac> its mostly upstream plus linux-omap
<ogra_ac> the work intensive part is the -omap tree merges
<ogra_ac> which adds i.e. support for extra boards etc
<apw> you didn't need any of that last cycle
<ogra_ac> look at all the IGEP2 bugs that are still open
<ogra_ac> with plenty of them being SRU
<ogra_ac> there is a *lot* omap3 HW out there my guess would be that we only support 20% yet
<ogra_ac> so there is more to come
<apw> ok so i'll assume that sometime someone will tell us where omap3 is coming from :)
<apw> and in the meantime i can definatly strip the omap3 configs from our tree
<ogra_ac> would you prefer to maintin it ?
<mvo> geser: looking now
<apw> ogra_ac, no i just don't want any supprises
<ogra_ac> my whole idea was to putt workload off the kernel team
<apw> so i keep poking the anthill with my stick
<ogra_ac> and you dont sound like i did
<apw> yep, you have convinced me you are getting something different from linaro if you take their kernel so there is something in it for you
<apw> sounds like you think you don't need any help from kernel till release
<ogra_ac> i might
<apw> and you know when we might have resource to help if you do
<mvo> geser: was this working before?
<ogra_ac> thats still open, and thats why i started the ML discussion
<ogra_ac> i'm a bit sad that nearly everyone chimed in on that apart from kernel and security teams
<apw> ogra_ac, to my mind your team is the only one which can determine whether that branch is acceptable
<ogra_ac> right, but also only for the boards we have
<apw> as for not responding, that is cause we didn't at the time at least have a clue if we had resource
<apw> we know now we do not until the heads are filled
<ogra_ac> the only real resource that can determine it is the community
<highvoltage>  /win 15
<mvo> geser: hm, that seems to be working for me (that snippet)
<apw> ogra_ac, your team doesn't have any omap3 to test with ?
<ogra_ac> right, *i* know that you dont have resources, the people discussing in the thread dont
<ogra_ac> we have beagleboards
<ScottK> apw and ogra_ac: I know there will be some community testing of omap3.
<mvo> geser: with g++4.4, let me try 4.5
<ogra_ac> ScottK, yeah, i would expect so
<apw> ogra_ac, yep someone needs to respond now the position has shaken out, i'll poke people
<geser> mvo: this was from a natty pbuilder
<ogra_ac> apw, thanks a lot :)
<mvo> geser: ok, let me try that (for the record, g++-4.5 compiled it too)
<geser> mvo: I've tried now to build the package in my maverick pbuilder and it worked there, only natty fails
<mvo> geser: I can reproduce it here now
<hallyn> Does the i386 build failure at https://launchpad.net/ubuntu/natty/+source/qemu-kvm/0.13.0+noroms-0ubuntu4 look to anyone like anything but a natty toolchain failure?
<ScottK> hallyn: It's a gcc problem.  You might try to grab the previous gcc-4.5 version and see if you can build it.  The latest gcc-4.5 update is not regression free.
<hallyn> ScottK: ok, thanks.  can i specify the version with build-depends, i suppose?
<ScottK> No.
<hallyn> drat
<ScottK> You'll need to grab the old one from LP and try it locally.
<hallyn> well, i know under maverick it compiled fine
<hallyn> i'm just wondering whether to ask kirkland to just re-try the official build, and hope that the dice get cast in my favor this round
<mvo> geser: hm, I just checked the code and I can not spot the problem - doko, do you have a idea what changed in g++ in natty that makes http://paste.ubuntu.com/533447/plain/ fail? in mav with g++-4.5 that builds fine
<doko> mvo: no, does it work with gcc-snapshot?
<ScottK> doko: Does gcc-snapshot use linaro or fsf upstream?
<doko> ScottK: fsf
<ScottK> doko: Speaking of which, any thoughts on Bug #675347?
<ubottu> Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) "volatile int causes inline assembly build failure" [High,Confirmed] https://launchpad.net/bugs/675347
<doko> ScottK: as mentioned yesterday, please ask jbrown on #linaro
<ScottK> OK.
<geser> mvo, doko: adding --no-as-needed to the -Wl flags makes it link
<ogra_ac> we should just rewrite everything in shell
<ogra_ac> would fix all compiler issues
<doko> geser: which lib has the symbol?
<geser> doko: it should be in libapt-pkg, see http://paste.ubuntu.com/533466/ for the ldd of the linked binary and objdump -T for libapt-pkg.so
<doko> geser. mvo: maybe fix the conftest, so that the library is really linked?
<mvo> doko: hm? is -lapt-pkg not enough to really link it?
<geser> doko: what you mean with really linked? the configure script used "x86_64-linux-gnu-g++ -o conftest -g -O2  -Wl,-Bsymbolic-functions -lapt-pkg conftest.cpp"
<geser> I used "g++ -o conftest -g -O2  -Wl,-Bsymbolic-functions,--no-as-needed -lapt-pkg conftest.cpp" to make it link
<doko> mvo: apparently the symbol you are checking for can be used without the lib
<doko> it's included from the a header
<mvo> doko: its in the header as "extern" - is that not enough?
<doko> mvo: apparently not with --as-needed
<mvo> doko: hmhm
<doko> mvo: hmm, the test works on i386
<geser> I'm on amd64 if it matters
<doko> geser: can't reproduce it here :-/
<geser> doko: on natty? I got it while test-building a package in my natty pbuilder
<doko> yes, natty
<geser> hmm, mvo perhaps you can help doko how to reproduce it as you managed to reproduce it too
<geser> when I copy the code from the paste and try "g++ -o conftest -g -O2  -Wl,-Bsymbolic-functions -lapt-pkg conftest.cpp" I get the linking error
<doko> geser: my libapt-pkg-dev is 0.8.8ubuntu3
<geser> the same
<geser> g++ is 4:4.5.1-1ubuntu3 and g++-4.5 is 4.5.1-10ubuntu1
 * geser is away for around 2h
<seb128> didrocks, did you open a bug about the gcc-4.5 issue breaking gnome-settings-daemon?
<seb128> or just pinged doko?
<seb128> I think other sources fail the same way
<didrocks> seb128: I just pinged doko and gave him some pastebin as examples
<seb128> doko, did you have time to investigate the issue didrocks pinged you about? do you need a bug report?
<mvo> james_w: what is the best way if I have packaging in a bzr-builder compatible branch (i.e. just the packging files like rules, watch, no debian/ dir) and want to build a source pkg from that. I basicly want to say "bzr-buildpackage -S" from such a branch (if possible :)
<james_w> mvo, --merge
<mvo> *cough*
<mvo> thanks james_w
<mvo> doko: hm, odd - on my normal natty system it works, in my pbuider it does not, let me try to figure out what is different
<apw> pitti, on the 'overall cycle' versions of the burn-down charts, what is _not_ included in the graph that is included in the tables below?  I added up the tables and found I had 129 tasks, but when I put that as the burn down start I find the graph is somewhat short at about 118 entries .. and am wondering why
<mvo> doko: aha! funny (or not). order matters: "g++ -o lala  -lapt-pkg lala.cc" fails, but "g++ -o lala lala.cc -lapt-pkg" does no (<- geser)
<doko> mvo: ahh, so the fix should be easy
<mvo> doko: well, its all genearted by configure.ac
<seb128> doko, hey
<seb128> doko, so I've sources failing with gcc-4.5, I think it's the same issue that didrocks pinged you about yesterday
<seb128> doko, should I make those use an another gcc version for now?
<doko> seb128: didrocks wanted to file a bug report, I didn't see one yet ...
<didrocks> doko: you didn't answered me if you wanted it and asking for others questionsâ¦ I was taking that as a "no"
<doko> hmm ...
<kirkland> hallyn: i was going to merge your last proposal and send that for a build
<kirkland> hallyn: cool?
<seb128> didrocks, can you open a bug now?
<didrocks> now that it's a clear "yes", sure I can
<mvo> geser: something like http://paste.ubuntu.com/533486/ should work
<mpt> Who is able to approve blueprints for Natty? Is it anyone in Ubuntu Drivers?
<didrocks> doko: seb128: bug #676519
<ubottu> Launchpad bug 676519 in gcc-4.5 (Ubuntu) "link failing despite the right linking arguments are presents on command line" [Undecided,New] https://launchpad.net/bugs/676519
<seb128> didrocks, thanks
<doko> didrocks: this smells like mvo's problem above. put the objects before the libs
<didrocks> doko: indeed, that worked
<mvo> I guess a common way of doing it before was using LDFLAGS to smuggle in libs
<mvo> where LIBS should be used
<doko> yeah ...
<cjwatson> or LDLIBS, yes
<mvo> especially on configure tests its a bit anoying, but *shrug*
<cjwatson> (LDLIBS for make's implicit rules)
<mvo> cjwatson: which is the more "correct" one?
<mvo> cjwatson: aha, ok
<hallyn> kirkland: cool, thanks
<hallyn> kirkland: and if it fails to build, then just resend it.
<hallyn> cause the toolchain is eating us for breakfast
<seb128> doko, bug #676519
<ubottu> Launchpad bug 676519 in gnome-settings-daemon (Ubuntu) "link failing despite the right linking arguments are presents on command line" [Undecided,New] https://launchpad.net/bugs/676519
<seb128> doko, you don't consider that a regression from gcc?
<seb128> we have several sources failing this way, that used to work, is there any reason gcc couldn't handle the other order?
<doko> seb128: yes, --as-needed. it's not a regression, it's exposing a sloppyness in the test case
<seb128> it was working some days ago with --as-needed
<doko> no
<seb128> the previous upload from those source in natty worked
<doko> --as-needed was introduced on Monday
<seb128> and --as--needed was in place since it failed due to it
<seb128> so --as-needed is different from the dso changes?
<doko> --no-add-needed is in place since the opening of natty, --as-needed since Monday
<mvo> doko: mumble?
<highvoltage> life/win 13
<highvoltage> bah! (sorry, I should really add gnome-do to my default session!)
<smb> pitti, Could you accept the kernels for maverick and lucid so they get build
<seb128> doko, I don't get why the object have to be before?
<seb128> the gcc man says
<seb128>        gcc [-c|-S|-E] [-std=standard]
<seb128> ...
<seb128>            [-o outfile] [@file] infile...
<seb128> that ought to work in this order no?
<doko> no, the order of objects does matter, same for libs
<cjwatson> yeah, this is traditional unix linker stuff
<cjwatson> gcc's been a bit permissive in the past so people have got a bit sloppy
<cjwatson> but the way you've generally had to do it is that objects that provide symbols used by other objects need to come later
<seb128> so I guess in a Makefile.am the .la should come before the _LIBS in a _LDADD
<seb128> NOTIFICATION_AREA_LDADD =				\
<seb128> 	$(NOTIFICATION_AREA_LIBS)			\
<seb128> 	libtray.la
<seb128> is failing because the .la is after the _LIBS?
<cjwatson> depends, does libtray.la use symbols from $(NOTIFICATION_AREA_LIBS)?
<seb128> yes
<cjwatson> then yes
<seb128> hum ok, I'm not sure how to explain that to upstream in the bug report though
<cjwatson> "breaks with ld --as-needed" should be enough?
<cjwatson> we're not the only distribution trying this
<seb128> well it seems fedora has dso linking on and it doesn't break for them
<seb128> well point is that this order works on other distros
<seb128> or at least on fedora and opensuse
<seb128> so I'm not sure how the way we do it is different or pickier
 * ScottK also doesn't recall this being disucssed in the planned toolchain changes.
<doko> seb128: no, fedora doesn't have it, but OpenSuse has
<seb128> hum, got disconnected
<seb128> doko, then I need to check with vuntz why he doesn't get the issue on opensuse with the same tarball
<lifeless> kees: is it still fast ? :)
<geser> mvo: thanks, works without any further changes
<mvo> geser: cool
<geser> I guess the fixes for the missing DSO linking done to some package (add the lib to LDFLAGS) won't work then anymore and the packages FTBFS again
<ogra_ac> cjwatson, erm, bug 673504 is not a duplicate ... (beagle XM isnt omap4 but omap3)
<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
<ogra_ac> err
<ogra_ac> Bug 673509 i mean
<ubottu> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (dup-of: 673504)" [Undecided,Confirmed] https://launchpad.net/bugs/673509
 * ogra_ac looks what happened there
<jdong> wow, this put-each-tty-in-a-cgroup patch works beautifully
 * SpamapS is having a bout with his mad-scientist side that wants to spawn 10 ec2 c1.medium's to grep through the entire archive for bash tab completion scripts...
<sladen> cjwatson: do you bother using the upstream (top level) 'ubiquity' project in LP
<ebroder> SpamapS: Elastic Map Reduce?
<ebroder> SpamapS: Although apt-file is probably faster :-P
<SpamapS> ebroder: I actually need to look at the content of the scripts, so apt-file would just produce the list of stuff to map/reduce. ;)
<kees> lifeless: let me try again...
<ebroder> cjwatson: I'm slightly confused by your e-mail. Is the conclusion that you're going to turn Lua on for 1.99 and we can go forward with that? Or do you want me to look into doing the hwmatch stuff as a C module?
<SpamapS> ajmitch: ping? I see you grabbed the php5 merge (https://merges.ubuntu.com/main.html) ...
<ajmitch> SpamapS: that's probably an old comment, but I can do it if you'd like :)
<SpamapS> ajmitch: no, I am working on it, so I'll clear that out. ;)
<ajmitch> ok
<ajmitch> SpamapS: it would have been a comment from a previous release, they should get cleared automatically now
<SpamapS> ajmitch: hm.. maybe a bug or something
<ajmitch> SpamapS: yeah, a bug that was fixed but the previous comments haven't been cleared out for packages that weren't showing
<ajmitch> no big issue though
<ari-tczew> yes, cjwatson has fixed this bug, but if comment is old, it has to be updated. after update, comment won't be saved anymore
<SpamapS> hrm, something broken in natty with the LDAP/SASL libs..
<SpamapS> configure: error: LDAP SASL check failed. Please check config.log for more information.
<SpamapS> zul: ^^ thats from php5
<SpamapS> zul: current and merged versions
<zul> SpamapS: umm...interesting
<SpamapS> zul: help me with sbuild/schroot .. if I wanted it to drop me to the bash command line instead of kicking me out of sbuild.. can I do that with sbuild or do I have to sort of emulate it through schroot'ing in and then making stuff happen?
<zul> SpamapS: schroot -c <chroot> -u <user>
<SpamapS> zul: ok, but then I need to install the build-deps ..
<SpamapS> zul: so -u root, then su to my non-root user after that?
<ebroder> SpamapS: Do you know about schroot -bc, -rc, and -ec?
<zul> you can
<SpamapS> ebroder: the man page doesn't seem to mention a -b
<ebroder> SpamapS: I do something like session=$(schroot -bc <chroot>); schroot -rc $session -u root apt-get build-dep whatever; schroot -rc $session
<ebroder> SpamapS: Then be sure to do schroot -ec $session when you're done
<SpamapS> ahh there it is
<SpamapS> ebroder: ok thats what I was looking for
<ebroder> SpamapS: Also I usually will install pbuilder in the chroot and run schroot -rc $session -u root /usr/lib/pbuilder/pbuilder-satisfydepends out of laziness :)
<segler> i want to upgrade a package in universe, i did not find any usefull help. where do i start? i already have done packaging it. where do i send it? to revu or directly post it in bugs database?
<ScottK> segler: Open a bug, attach the .diff.gz to the bug and subscribe the ubuntu-sponsors team to the bug.
<segler> ok, thank you
<segler> hmm, my source package does not have a diff.gz
<segler> do you mean the debian.tar.gz?
<ScottK> segler: yes
<ScottK> diff.gz for format v1 packages and debian.tar.gz for format v3
<segler> ok, thank you :)
<kees> hallyn, kirkland: do either of you have an AMD svm system that can test the new version of kvm-ok? (i.e. test it with bios blocking svm and not block svm, etc)?
<hallyn> kees: not me i'm afraid
<ebroder> kees: I know we've got an AMD machine at the office...somewhere around here. If you can't find someone else I can probably hunt it down and commandeer it.
<kees> ebroder: sweet, that would be great. I can test the intel half, but I have no AMD with virt extensions.
<RoAkSoAx> achiang: finally fixed the problem for pacemaker :)
<achiang> RoAkSoAx: cool! what was the answer?
<ebroder> kees: Ok, found a machine. It's currently in use, so it may take me a little while before I can commandeer it. (AMD machines are *hard* to find these days)
<RoAkSoAx> achiang: in pengine/Makefile.am I added ptest_LDFLAGS  = $(top_builddir)/pengine/libpengine.la and it worked. However, searching on upstream's mercurial repo, I found that they added libpengine_la_LIBADD  = $(top_builddir)/lib/pengine/libpe_status.la.
<achiang> ah ha
<RoAkSoAx> achiang: so I just took upstream's change :)
<achiang> RoAkSoAx: so actually, my theory was correct (iirc). i think it was the syntax that was busted
<ebroder> kees: When I get the machine, I'm looking at lp:~cpu-checker-dev/cpu-checker/trunk?
<RoAkSoAx> achiang: yeah, upstream changelog for the fix is: " Correct the linking order so that libpe_status is linked after libpengine."
<RoAkSoAx> achiang: so indeed was the linking order
<kees> ebroder: http://bazaar.launchpad.net/~cpu-checker-dev/cpu-checker/trunk/annotate/head%3A/kvm-ok
<ebroder> kees: Cool. I'll let you know
<achiang> RoAkSoAx: good to know that my understanding of the toolchain is correct. i think it'll be another decade before i understand autotools though. :)
<RoAkSoAx> achiang: hahah same here :)
<SpamapS> is there something broken in the linker right now in natty?
<Sarvatt> SpamapS: working as intended unfortunately
<SpamapS> http://paste.ubuntu.com/533574/
<Sarvatt> https://lists.ubuntu.com/archives/ubuntu-devel/2010-October/031860.html
<SpamapS> failing to find sasl_version in libsasl2 ...
<SpamapS> ok, so -lsasl is there...
<SpamapS> err
<SpamapS> -lsasl2
<SpamapS> and sasl_version is indeed a symbol from that library
<cjwatson> ogra_ac: I didn't dup that - it was like that when I got there
<cjwatson> sladen: just for code hosting, not bugs etc.
<cjwatson> ebroder: could you look at doing it as a C module?
<cjwatson> ebroder: if it's really infeasibly awkward then we'll use lua, but Robert seemed pretty down on that with his upstream hat on
<ebroder> cjwatson: Sure. I don't suspect it would be hard, although I might change the {black,white}list format to be more C-friendly
<ebroder> cjwatson: FWIW, I definitely do need Lua for the stuff I'm doing at work, which is part of why I was hopeful we could do it in Ubuntu - so I wouldn't have to rebuild GRUB myself. But I understand if it's a no-go
<kees> lifeless: still fast, no 503s
<geser> SpamapS: the problems are the -l... before the conftest.c; since the latest gcc changes (--as-needed) the order matters now
<cjwatson> ebroder: yeah, just uncomfortable at doing it over a nack from Robert
<ebroder> cjwatson: OOC, is upstream's support for Lua different from their support for the other extras?
<cjwatson> ebroder: extras vary wildly
 * ebroder nods
<cjwatson> ebroder: lua's particularly controversial because of its overlap with grub script - most of the others provide a more obviously new feature
<cjwatson> the gpxe extra is fairly scary and poorly tested right now so we don't build that in
<cjwatson> the others are fairly noninvasive (zfs does what it says on the tin, ntldr-img is a bit messy but doesn't really get in anyone's way, 915resolution is basically just an extra command)
<cjwatson> they're in extras just because they aren't copyright-assigned to the FSF
<cjwatson> it's a shame extras can't be built truly separately
<ebroder> cjwatson: Do you think hwmatch seems like something that would be upstreamable, or should I create it as a new extra? (or should I do it as a distro-specific patch to core)
<SpamapS> hmmm.. it seems that php expected sasl_version to be included in -lldap .. precisely the DSO problem.. but still.. it did -lsasl2 too.. so what gives?
<cjwatson> ebroder: if you're happy to copyright-assign it, and don't mind arguing out the interface, it should be upstreamable
<cjwatson> initially I guess it would be a distro patch though
<ebroder> cjwatson: Oh, sure. I'll be doing this on work time, so I guess I'll have to get back to you on copyright assignment. Shouldn't keep me from at least starting on the code, though
<SpamapS> aha.. looks like upstream needs to be smacked a bit. ;)
<SpamapS> s/smacked/hugged and brought along the path of enlightenment/
<ajmitch> SpamapS: it's PHP...
<SpamapS> ajmitch: True, they've been smacked so many times, its clear that corporal punishment just doesn't work with them.
<cjwatson> ebroder: yeah, if it can't be assigned an extra will probably be ok
<geser> SpamapS: -lsasl2 is left of conftest.c
<cjwatson> as long as it's GPLv3-compatible
<ebroder> cjwatson: Boss just got out of his meeting - copyright assignment won't be an issue
<SpamapS> geser: yeah I just figured that out now. :-P
<cjwatson> excellent
<SpamapS> geser: but thank you for confirming. :)
<SpamapS> geser: patching config.m4 to check sasl2 for sasl_version, which is where it has always lived anyway, is the appropriate fix
<geser> SpamapS: I know it since this afternoon now too, run into the same problem
<SpamapS> Oh boy.. more of these happen later in the build. :-P
<ajmitch> SpamapS: OK, I'm glad you're doing the merge now :)
<SpamapS> ajmitch: haha yeah no kidding
<ScottK> Right.  Because DSO, gcc-4.5, and a new Python weren't enough pain for one release cycle.
<SpamapS> looks like OpenSSL is linked improperly as well.
<SpamapS> ScottK: at least we're doing it now, and not in O or P!
<SpamapS> ScottK: I will say that more and more developers that I talk to respect the constant toolchain advancements and appreciate that we figure out how to get stuff working before they have to.
<ajmitch> ScottK: how much of it has been done in fedora already?
<ScottK> SpamapS: I don't mind toolchain advancements.  I do mind toolchain advancement suprises and I don't recall this one being discussed.
<ScottK> ajmitch: For the -as-needed ordering stuff, none of it.  Allegedly done in opensuse, but accounts vary.
<ajmitch> hm, it may have been F15 that I was reading about it
<ScottK> They did the DSO linking bit.
<ScottK> They've also done Python2.7.
<ajmitch> right
<cjwatson> I think this was oversight rather than deliberate surprise ...
<bdrung> hallyn: i did more investigation in the kvm / libsdl caps lock bug: the caps lock button is mapped to 'alt gr' and correctly passed to kvm.
<hallyn> bdrung: meaning what, exactly?  The client should be able to decode it as alt-gr?
<bdrung> hallyn: i patched libsdl: http://pastebin.com/JPwTqqnR - and the press and release of the caps lock key are detected (as alt-gr), but the client doesn't get the key press.
<bdrung> hallyn: let me test what kvm thinks which key it gets
<hallyn> well, the old patch implies that the guest gets keydown but not keyup?
<bdrung> yes, but the client should get 'alt gr' instead of 'caps lock' if caps lock is pressed (caps lock and alt gr are modifier for the same level in NEO2)
<RoAkSoAx> are new binary packages approved automatically, or do they pass a manual inspection?
<cjwatson> the latter
<cjwatson> more or less
<cjwatson> new binary packages that came from Debian get waved through semi-automatically
<RoAkSoAx> cjwatson: what's the case when those are binary packages that didn't come from a debian sync/merge?
<cjwatson> then we check them manually
<RoAkSoAx> cjwatson: ok then, I guess i'll just have to wait because of that, another package FTBFS :) Thanks for the info
<cjwatson> seb128: are these shared-mime-info and telepathy-mission-control syncs in ~lp_archive/syncs/ yours?
<seb128> cjwatson, oh yes, I started on that early and got an dsl disconnect which made me stop and I forgot to finish those
<seb128> cjwatson, you can flush them if you want
<seb128> sorry about that
<seb128> cjwatson, if you are doing syncs "-S experimental -f telepathy-glib" and "-S experimental telepathy-gabble" are to do as well
<seb128> I will do them tomorrow otherwise, I was about to go to bed now
<seb128> 'night
<cjwatson> flushing, thanks
<seb128> cjwatson, thanks
<cjwatson> sure, I can do those.  -b seb128?
<seb128> yes
<cjwatson> I was just going to do a man-db sync
<seb128> cjwatson, thanks
<cjwatson> np
<bdrung> hallyn: can you test the patch attached to bug #427612 and share your results?
<ubottu> Launchpad bug 427612 in qemu-kvm (Ubuntu) "does not pass pressed caps lock to client" [Low,New] https://launchpad.net/bugs/427612
#ubuntu-devel 2010-11-18
<hallyn> bdrung: building it in a ppa at https://launchpad.net/~serge-hallyn/+archive/kvm-keys-test in case you want to have others try it out
<smoser> pitti, awake ?
<hallyn> bdrung: uh - but capslock works for me in kvm!
<mwhudson> where should i ask about python-apt questions?
<NCommander> directhex: ping, so have you been looking at the mono issues on ARM?
<lucent> uh... I'm needing some help to get a PPA built for multiple Ubuntu releases
<lucent> when I copy the PPA package, launchpad UI complains that the same name exists
<lucent> so, what is the naming I should be using such that copy will work within the same PPA and onto a different release target?
<lucent> https://bugs.launchpad.net/soyuz/+bug/189223 using this UI
<directhex> NCommander: which current arm issues?
<dholbach> good morning!
<directhex> NCommander: i'm aware of problems with 2.8 on arm, but the existing 2.6.7 i'm not
 * apachelogger tickles pitti with bug 676663 ^^
<ubottu> Launchpad bug 676663 in kdenetwork (Ubuntu Karmic) "Kopete ICQ plugin broken due to login server change" [Medium,Triaged] https://launchpad.net/bugs/676663
<mvo> hey seb - too late
<pitti> Good morning
<pitti> apw: that sounds like a bug -- the graph is supposed to have all WIs
<pitti> smb: I think cjwatson did yesterday
<pitti> smoser: hello
<smb> pitti, Hi and yes. Sorry for the noise.
<pitti> apachelogger: will do SRUs today
<apw> pitti, i was wondering if it might be an overlap issue, as the bar is actually 10 bars on top of each other
<apw> not had a chance to investigate it yet
<lool> pitti: Hey there, would you mind NEWing linaro-image-tools https://launchpad.net/ubuntu/+source/linaro-image-tools/0.3/+build/2040596 ?
<pitti> lool: done
<lool> pitti: thanks!
<sebner> didrocks: my compiz crash in openoffice is now fixed in git. I can prepare a debdiff later unless you want to upload it yourself as you have rights for main which makes it a little bit easier and faster
<didrocks> sebner: I have other pending upload and I'll make dist a newer version soon
<didrocks> also, the git commit doesn't fix everything, there are still some pending issues
<didrocks> hopefully, we will have a new version next week :)
<sebner> didrocks: aye, thanks :)
<didrocks> yw :)
<MTecknology> This probably isn't the best place to ask.. How hard is it to convert an init script to an upstart script?
<apw> MTecknology, depends on the initscript complexity but not so hard, i would think #ubuntu-devel is a better place though
<apw> oh heh, this is there
<MTecknology> apw: LOL..
<MTecknology> apw: the init script is something I wrote - so obviously not complex :)
<smoser> pitti, was pinging regarding https://bugs.launchpad.net/ubuntu/+source/apt/+bug/676790
<smoser> but i'm on vacation today
<pitti> I've seen the bug fly by
<pitti> will look at it in due course
<MTecknology> smoser: vacation?...
 * MTecknology googles
<seb128> doko_, when you fix a bug which concerns debian and has been opened in the bts as well could you send your patch to debian?
<seb128> doko_, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603676 for example
<seb128> doko_, should bug #650945 be closed as well with your upload?
<ubottu> Launchpad bug 650945 in cairo (Ubuntu) "Symbols file incorrect for compilers supporting LTO" [Low,New] https://launchpad.net/bugs/650945
<doko_> seb128: dude, give me some time ...
<seb128> doko_, ok ;-) I was not sure if you checked for open bugs since you didn't list the bug number is the changelog
<seb128> is -> in
<seb128> doko_, I was pointing the bug references in case you didn't know about them, thanks
<hrw> hi
<pitti> mvo: apt-get download> yay you! (and for changelog as well)
<mvo> pitti: :) its pretty nifty, it supports all the niceness of apt-get install (like pkg/natty pkg/maverick, pkg=version etc)
<mvo> regexp
<pitti> oh, new firefox
<pitti> mvo: that's awesome! so much nicer than having to download it manually in the browser
<mvo> yeah, I'm happy too :)
<sebner> pitti: I miss the reload Icon Â¬_Â¬
<pitti> I miss vimperator
<sebner> pitti: not ported yet?
<pitti> the update check didn't find it
<cjwatson> http://paste.ubuntu.com/533879/ <- grep-ubuntu-irclogs, for when your local IRC logs (if any) are insufficient
<cjwatson> (bit cheesy)
<soren> cjwatson: I miss the days when I could log into the machine serving the irclogs. That's saved me a bunch of time on multiple occasions.
<soren> cjwatson: Sometimes, grep is just better than Google.
<testi> Is this the place where you discuss blueprints?
<sebner> pitti: F6 is now focusing the first tab??
<pitti> sebner: not for me, it behaves like ctrl-l for me (go to URL bar)
<sebner> pitti: ctrl-l works for me but F6 focuses the first tab xD
<soren> sebner: well, ctrl-1 and ctrl-l looks and awful lot like each other in many fonts. Maybe it gets confused.
<sebner> soren: ??, I said ctrl-l works and F6 does *not* work
<soren> sebner: Well, if F6 is supposed to to the same as ctrl-l, and ctrl-l looks just like ctrl-1 (at least if you squint)..
 * soren is kidding, of course
<cjwatson> I can't tell what F6 does.  It seems to draw a dotted border around the main page window.
<cjwatson> s/draw/toggle/
<pitti> so it's "do any action, except the one which is on your mind at the moment"?
<sebner> cjwatson: main page windows = main page tab? It seems F6 toogles always the selected tab /here
<cjwatson> sebner: no, I mean the frame surrounding the rendered page
<pitti> mvo: hm, where does http://launchpadlibrarian.net/59278887/apt_0.8.9ubuntu1_0.8.9ubuntu2.diff.gz actually drop apt-changelog?
<pitti> mvo: oh, it's in the previous diff
<mvo> pitti: *cough* hawk eye! I forgot it in the initial upload changelog
 * mvo knew he would not get away with it ;)
<pitti> mvo: heh, np; sorry, I'm not spying after you
<mvo> :)
<mvo> "the fact that you are paranoid does not mean they are not after you"
<pitti> mvo: I just wanted to know whether 0.8.9 changed anything wrt. bug 675641, it got closed
<ubottu> Launchpad bug 675641 in apt (Ubuntu) "[Natty] apt_0.8.8ubuntu3 seriously slows down synaptic" [High,Fix released] https://launchpad.net/bugs/675641
<pitti> but I didn't see anything
<mvo> let me check
<pitti> mvo: nevermind, I'll check it out in a bit (need to leave for some mins)
<mvo> pitti: thanks, I don't think I changed anything there
<chrisccoulson> pitti - if you want vimperator - http://is.gd/hm9Tv
<chrisccoulson> i miss venkman, which doesn't work either :(
<chrisccoulson> sebner - " I miss the reload Icon Â¬_Â¬" - what's wrong with the new icon? ;)
<mpt> skaet, hi, besides you, who can approve blueprints for Natty?
<mpt> where by "approve" I mean "accept" in Launchpad-ese
<skaet> mpt, hi, each of the manager for the teams are approving the blueprints.  Once the manager take a pass, we're intending to take an overview pass to see if it all makes sense from an available folk's time to work on, and adjust a bit.
<mpt> skaet, so all a designer/engineer needs to do is make sure it's "Proposed for natty"?
<skaet> mpt,  and let the appropriate manager or team lead for the area know you're looking for a review ;)  (extra communication is good thing here)
<mpt> ok, thanks skaet
<mathiaz> Daviey: hey!
<mathiaz> Daviey: I'm going to remove myself as an administrator from ubuntu-server@
<mathiaz> Daviey: do you think of anyone else to pick the role?
<mathiaz> SpamapS: would you like to become an adminstrator of the ubuntu-server@ mailing list?
<manjo> superm1, ping
<superm1> manjo, whats up?
<manjo> superm1, 1. USB install failed
<superm1> manjo, hmm, was it at least detected?
<manjo> yes the bios is able to see the usb drive and I am able to browse through the files
<manjo> I will talk to intel to see if I need to do anyting diff
<superm1> but did it offer it as a potential target to boot uEFI like it does for CD?
<manjo> yes
<superm1> so at which point did the failure occur then?
<superm1> and more importantly, did you have to do anything special to get it to show up in that list?  like format the drive fat16 or anything like that
<manjo> not tried fat 16yet, this is the default 32bit
<manjo> sorry fat
<manjo> does it not even show up on your laptop ?
<manjo> as target?
<superm1> i'll have to recheck, when i first did a while back it wasn'
<superm1> so where is the problem occurring for you then?  after picking the target, grub is failing to load?
<manjo> not exactly sure, but looks like grub is not loading
<manjo> superm1, I might be visiting UK on the 4th of Dec, we talked about a uefi laptop for colin, is this something that can be arranged ?
<manjo> if so I can pick it up and deliver it to him
<superm1> manjo, yeah we should be able to work something out
<cjwatson> manjo: is this one without firmware flaws? :)
<cjwatson> (dunno which Colin you mean, mind you)
<manjo> cjwatson, yeah this is the intel dev platform
<manjo> cjwatson, oh the laptop is for cking
<cjwatson> right.  actually that's good.
 * manjo broke the usb stick shit!
<cking> manjo, gotta laptop for me?
<manjo> cking, I might be in UK on the 4th dec, so I will bring you one that superm1 gives me
<manjo> cking, I will be there from 4-11
<manjo> cking, also the WD 3T disk
<ivanka> mvo: hi
<cking> manjo, how ya gonna get them from millbank to my home?
<manjo> cking, bummer... never thought of that!
<cking> just joining up the dots..
<cking> perhaps you could ask somebody in millbank to fedex them to me
<cking> manjo, alternatively, you could just fedex the kit to my home straight from the US
<manjo> cking, true
<SpamapS> mathiaz: re admining ubuntu-server .. sure.. somebody needs to do it. :)
<mvo> ivanka: hi
<mvo> ivanka: sorry for the delay, I was at dinner
<ivanka> mvo: shouldn't you now be enjoying post dinner and not be looking at irc?
<mvo> ivanka: *cough*
<ivanka> mvo: :-)
<mathiaz> SpamapS: which email address should I use?
<SpamapS> @ubuntu.com I think makes the most sense
<SpamapS> mathiaz: ^
<pitti> chrisccoulson: nice, vimperator on 4.0, thanks :)
<shtylman> anyone know what software runs packages.ubuntu.com?
<ebroder> shtylman: There's a link to http://packages.ubuntu.com/about/ at the bottom of the page
<shtylman> ebroder: holy crap.. totally missed that
<shtylman> thank you :)
<jono> hey all
<jono> installed natty on a USB drive and it hangs at SYSLINUX, is this a known bug?
<jono> using the latest live daily
<fagan> jono: I had a quick check of the bug list for natty and its not there so id say report a bug for it
<firewave> jono, is it in virtual or not ?
<jono> firewave, no native, but on a USB stick
<firewave> jono, yeah sorry.. lol
<jono> oh I think I may have screwed up the creation of the disk
<jono> re-creating now
<fagan> oh thats good to hear then
<firewave> jono, I'd tell you to try with maverick to check all the creation
<firewave> jono, and if it actually works, report the bug for it
<jono> creating it nw
<jono> now
<jono> thanks firewave
<firewave> jono, don't, I did anything to solve your problem :-s
<firewave> Somebody know how to track a f*** freezing bug ?
<firewave> Because all freeze, I'm not able to have some log or anything
<firewave> Think it's nvidia prop driver but I can't do anything...
<firewave> to check that
<fagan> firewave: have you changed anything big with your install? Im not getting any freezes at the moment in natty but im on an intel GPU so it could be a nvidia thing
<firewave> fagan, the thing is very nasty, appends randomly every 30min or 1 days..
<firewave> but same with maverick... humm
<fagan> firewave: well it sounds like a driver issue then but its hard to debug
<firewave> metacity and compiz, even in GDM one time..
<firewave> yeah
<firewave> I'll check if an opensource driver work for me
<fagan> good idea it might help
<firewave> even if no 3D, after 2 days, I would know if it's nvidia or something else
<jcastro> slangasek: around?
<slangasek> jcastro: hey there
<jcastro> slangasek: I have a button in lp that says "rebuild" when I was investigating why nux/unity didn't rebuild
<jcastro> and I clicked it
<jcastro> and now it's rebuilding it
<jcastro> https://launchpad.net/ubuntu/+source/unity/3.1.4-0ubuntu1/+build/2052937
<slangasek> jcastro: ok, good? :)
<jcastro> can that do anything bad? It feels like I shouldn't have clicked that, I'm not an archive admin or anything like that
<slangasek> jcastro: it makes the log of the previous build attempt unavailable; but that's a secondary concern
<slangasek> jcastro: the button is there so that people click it and don't have to ask people with hats :)
<james_w> I thought only people that could upload could retry
<slangasek> I think that's right
<jcastro> ok so I certainly should not be pushing it.
<slangasek> jcastro: then maybe you've found a bug in LP
<jcastro> slangasek: at first glance it was like "oh something didn't build I get a chance to make it build"
<james_w> my guess is that jcastro's UDS superpowers get him this ability somehow
<jcastro> james_w: not likely, there's a seperate uds drivers group, perhaps my registry powers?
<james_w> jcastro, maybe, yeah
<james_w> one of your many superpowers at least
<jcastro> ok, so don't click it anymore, got it.
<james_w> only when you really want to ;-)
<jcastro> well, if something fails to build reclicking it won't magically fix that
<slangasek> if it's a kernel build that failed after 12 hours, don't click it
<jcastro> so really all I've wasted is 10 minutes of build time. :-/
<slangasek> no, the "magically fix the package and rebuild" button is *very* heavily restricted in LP
<jcastro> how can something like that even exist?
<highvoltage> can't you use that button to enable it for everything? or is that like asking the genie for a 1000 more wishes?
<slangasek> jcastro: ... magically? :)
<jcastro> slangasek: I don't miss working with you one bit. :)
<slangasek> you don't fool me
<slangasek> you weren't working!
<slangasek> ;)
<jcastro> slangasek: james_w: I have filed bug #677207
<ubottu> Bug 677207 on http://launchpad.net/bugs/677207 is private
<james_w> thanks
<[reed]> RAOF: ping
<RAOF> [reed]: Pong?
<[reed]> RAOF: what's it going to take to get bug 650539 fixed?
<ubottu> Launchpad bug 650539 in xorg (Ubuntu Maverick) "Launching QT apps under Xinerama crashes Xorg : affects SpeedCrunch, KeePassX, Lucky Backup, Pencil, Stellarium, Skype, Google Earth, VLC, Konqueror, VirtualBox, Opera ..." [High,Triaged] https://launchpad.net/bugs/650539
<[reed]> the fix has been committed upstream, so they've signed off on it
 * RAOF waits for firefox to start.
<[reed]> lol
<RAOF> That's part-way through the SRU process, isn't it?
<[reed]> I'm not sure how to tell that... I didn't see any specific comment, though maybe I overlooked something
<RAOF> Hm, no, you're right.
<RAOF> So, that gets fixed by me actually going through the SRU process.
<[reed]> RAOF: that would be awesome if you could do that :)
<chrisccoulson> RAOF - if you're waiting for firefox to start, then you can't be running natty yet ;)
<RAOF> chrisccoulson: Oh, I am.  I just needed to kill the first firefox process that had hung somewhere :P
<chrisccoulson> oh :(
<chrisccoulson> did you upgrade to 4.0 today?
<RAOF> Yes
<RAOF> Well, yesterday, but this was the first run.
<chrisccoulson> it starts quickly here ;)
<RAOF> I've switched back from Chromium on the basis of lower memory useage.  And the tab grouping thing is pretty nifty, too.
<chrisccoulson> yeah, it's pretty nice :)
<superm1> manjo, cjwatson i managed to get the uefi option to show up for a usb device on my system, but had to pull efi/boot/bootx64.efi out of boot/grub/efi.img and put it in efi/boot/bootx64.efi at the root of my fat32 usb stick
<manjo> superm1, wow
<superm1> i really don't see how it could have worked for you the more i think about it
<superm1> because that means that it was loop mounting boot/grub/efi.img which is a non-standard location
<manjo> superm1, like it only showed up on the list of devices to boot from, but never able to boot from it
<superm1> manjo, ah, see by doing this i can actually load grub
<superm1> it looks like there are some other problems once it gets loaded with trying to find the right grub.cfg potentially though
<superm1> this was with today's natty
<superm1> so maybe it's a natty problem with trying to find the right grub.cfg
<superm1> so there's two ways to generally address this though: 1) in the CD build process, make sure efi/boot/bootx64.efi is left in the ISO in the right place (will use 348k more space on the ISO).  2) teach usb-creator to extract efi.img to the right place
<manjo> superm1, should probably recorded in a bug and assigned to cjwatson
<superm1> yeah
<superm1> manjo, do you have a gold maverick amd64 handy you can try what I did with?  i only have a natty here atm
<manjo> superm1, no I can create one ..
<NCommander> directhex: ping, I've got some mono on ARM questions for you :-)
<directhex> NCommander: go
<NCommander> directhex: any idea why I'm getting PInvoke failures int he test case? I've been poking around and this looks like banshee is completely foobar'ed
<directhex> hang on, let me boot this thing
<NCommander> directhex: http://paste.ubuntu.com/534065/ - I'm thinking this is an issue with Thumb2
<superm1> manjo, okay bug 677260
<ubottu> Launchpad bug 677260 in usb-creator (Ubuntu) "CD images aren't able to boot off USB sticks in uEFI mode" [Undecided,New] https://launchpad.net/bugs/677260
<NCommander> the big ones that consider me are pinvoke which suggest calling convention issues, and vararg
<superm1> i'll leave both tasks as new so cjwatson can decide which one is more appropriate
<manjo> superm1, I will update that bug, creating maverick usb now
<superm1> manjo, i think additionally it looks like bootx64.efi's grub image appears to be missing part_msdos and vfat support
<superm1> at the rescue prompt i'm not able to ls on any of the (hdX) devices because it gets unknown filesystem.
<superm1> my guess is that it was built with iso9660 support only with the expectation that it would load additional modules from the CD
<directhex> NCommander: it'd take some digging through the git commit logs to see what fixed those test cases
<directhex> NCommander: i know the whole test suite passes on mono 2.8
<superm1> so maybe a second efi/boot/bootx64.efi needs to be built that's a little bit different than the one contained in efi.img so as to contain this additional support
<directhex> NCommander: and i don't know about "completely fubar" - i'm currently listening to an mp3 on banshee on maverick on armv7
<directhex> NCommander: u1ms seems broken though
<NCommander> directhex: thats counter to everything I've tested and GrueMaster has tested w.r.t. to banshee
<NCommander> banshee will crash failure quickly if idling or if you try to do something with it in my experience
<cjwatson> superm1: loop-mounting /boot/grub/efi.img> you know that /boot/grub/efi.img is assigned as the content of the EFI boot catalog entry, right?
<cjwatson> fagan: can you please try to avoid top-posting and including the entire previous message in your message when posting to ubuntu-devel?  please trim quotes
<fagan> sure sorry about that
<cjwatson> thanks
<fagan> I write emails fairly quickly normally so I forget about formatting
<directhex> NCommander: i can take a more extensive look tomorrow, but regular playback with a test track seems normal here
<cjwatson> superm1: /boot/grub/efi.img is very definitely supposed to be built with part_msdos and vfat.  it was not my intention when constructing it to build it with iso9660 only.
<cjwatson> hm, I think, anyway
<cjwatson> I suppose it's possible there was an oversight there - I certainly consider it a bug if it's missing part_msdos and fat though
<cjwatson> no need for a second image
#ubuntu-devel 2010-11-19
<bdrung> cjwatson: you are fast!
<cjwatson> eh, you got lucky :)
<cjwatson> it'd be a bad idea to release binfmt-support 2.0.0 while slightly drunk, right?
<directhex> cjwatson: depends, do you like living dangerously?
<cjwatson> ish
<cjwatson> I think on balance perhaps not tonight
<sebner> cjwatson: pre-alpha is perfectly fine for drunk uploads! :P
<cjwatson> maybe not so much for uploads that involve complete rewrites
<sebner> heh
<cjwatson> directhex: do you use binfmt-support very much, or do you just basically assume it works?
<cjwatson> (out of interest)
<jono> which package do I file bugs against for the installer?
<jono> for the GTK UI
<cjwatson> ubiquity
<jono> thanks cjwatson
<directhex> cjwatson: i ignore its existence, and just run ./foo.exe without thinking about the back-end
<cjwatson> fair enough
<cjwatson> that's the way it should be really, just curious
<directhex> cjwatson: we don't use it at all as a matter of policy for packaging (iirc not all arches support it), but i use it for testing etc
<cjwatson> all Linux architectures support it, and therefore all Ubuntu architectures, but it's true that not all Debian architectures due
<cjwatson> s/due$/do/
<cjwatson> it ought to be trivial on the Hurd.  no idea about kFreebSD
<directhex> cjwatson: well, kfreebsd is a mono arch, so we can't assumebinfmt works
<cjwatson> yeah
<cjwatson> your policy makes sense
<superm1> cjwatson, okay i didn't dig much into it, but thats at least what it appears on the surface (unable to ls into partitions)
<superm1> and yes i was aware /boot/grub/efi.img was assigned as the content of the efi boot catalog entry
<kees> siretart: mplayer ping... libavformat52 has Breaks: mplayer (<< 2:1.0~rc4) but the latest mplayer is 2:1.0~rc4~try1.dsfg1-1ubuntu1. I was going to just do a version bump to 2:1.0~rc4+try1.dsfg1-0ubuntu1 so that it would be installable again. How's that sound to you?
<siretart> kees: argl. no, let's please update the breaks to mplayer (<< 2:1.0~rc4~~) instead
<siretart> kees: rc4 is not released yet
<siretart> I need to do that in experimental as well
<kees> siretart: okay, cool; will you take care of that, or should I?
<siretart> kees: I can do so this afternoon. if you think its urgent, then go ahead
<siretart> need to rush to work now
<kees> siretart: no rush, just wanted to get mplayer installed again. :)
<pitti> Good morning
<TheSarge> So are we supposed to use the kernel patch that Linus put out? Or the bashrc route?
<TheSarge> For the kernel patch that improves response times under high cpu strain?
<TheSarge> Lol anyone?
<amitk> TheSarge: better asked on #ubuntu-kernel
<TheSarge> K thx
<geser> good morning pitti
<pitti> hello geser, how are you?
<geser> I'm fine, and you?
<doko> gahh, gnome's circular dependencies ...
<TheSarge> In my linux class based on students complaints of the labs not working with ubuntu we all have to learn on a 5 year old version of fedora..
<TheSarge> Ooops wc sorry.
<raphink> TheSarge: ah, I would have said your nickname suggested you were on a 5-year-old version of Debian
<raphink> ;)
<TheSarge> raphink: ?
<TheSarge> Oh the RC
<TheSarge> That is where the name came from.
<raphink> sarge is the codename of Debian 3.1, released in 2005
<TheSarge> I made it when I was using that version lol.
<raphink> hehe ;-)
<TheSarge> I also have this one
<TheSarge> err cant change cause I am in ##linux
<TheSarge> But it is Gentoon
<raphink> what about being in ##linux?
<dholbach> good morning
<TheSarge> Won't let me change nicks when I am in there
<TheSarge> Or maybe it is #Ubuntu
<azul_> cjwatson: hi - I've got a slew of odd mails about dpkg indonesian translations. Does this relate to the dpkg-patch-which-is-completely-unrelated-to-indonesia patch I sent you per chance?
<doko> didrocks: ping
<didrocks> doko: pong
<doko> didrocks: gnome has not so nice dependency cycles ... canberra can not be available when libgnome is built
<doko> only if you have it before
<doko> didrocks: plus: gstreamer build-depends on the *whole* gnome stack ...
<doko> (gir-repository-dev)
<doko> slomo: ^^^ can this be made simpler?
<didrocks> doko: can you open a bug report about those deps? I really won't have the time to look at it right now and before alpha week release I'm afraidâ¦
<slomo> doko: yes, should be possible without gir-repository-dev nowadays
<slomo> doko: thanks for noticing, i'll fix it later
<Daviey> Hi, should the natty-security pocket be used yet - or should it just go to main?  (for a security bug that exists in natty and maverick)
<Laney> just to release
<Daviey> Laney: thought so, thanks
<Laney> nps
<slomo> didrocks: i'm fixing it in debian (the gir-repository-dev build dependency problem)
<didrocks> slomo: thanks :)
<cjwatson> azul_: wouldn't worry about it, there's a minor flaw in id.po but it's not a big deal
<cjwatson> azul_: launchpad complains about it on each upload
<azul_> cjwatson: right - filing to dev/null... :)
<cjwatson> azul_: I thought I remembered passing it up as a Debian bug a while back, but maybe that was a different package
<cjwatson> for things where I have Debian commit access I just fix them
<\sh> hmmm..there is something really nasty inside /etc/cron.daily/apt .. apt-key net-update won't work when there are machines which don't have direct internet connections...and it doesn't timeout somehow
<slomo> didrocks: fixed versions are gstreamer/gst-plugins-base are in experimental now
<didrocks> slomo: thanks, I'll pend merges on my TODO :)
<late> s
<ari-tczew> could someone sponsor this one? bug 663343
<ubottu> Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343
<spaetz> Any plan on when LibreOffice will enter natty repositories?
<mdeslaur> does anyone know what bug 647404 could be?
<ubottu> Launchpad bug 647404 in udev (Ubuntu) "Udev worker error during boot "worker [XX] did not accept message -1 (Connection refused), kill it" [Undecided,Confirmed] https://launchpad.net/bugs/647404
<ogra> can some archive admin accept qt4-x11 4.7.0-0ubuntu4.2 into maverick-proposed please
<pitti> ogra: I'm currently doing SRU reviews, I'll get to it
<ogra> pitti, mreci
<ogra> or merci :)
<pitti> ogra: de rnie! :)
<ogra> lol
<pitti> ogra: there are two uploads
<pitti> ogra: should I reject 4.2 and keep 4.1? or did you actually change something in 4.2, and I should reject 4.1?
<ogra> pitti, 4.1 was already uploaded before and removed from -proposed
<pitti> ah
<pitti> it was reuplaoded 15 mins ago, so I'll reject it
<ogra> ScottK, just told me that the source package persists even if the binary is removed
<ogra> so i just bumped to 4.2
<ogra> without further changes
<ScottK> ogra: It's a little more subtle.  Soyuz marks the version has having been seen, so it can't be reused even though source and binary have been removed.
<ogra> ah
<pitti> sconklin: do you know who uploaded linux-mvl-dove lucid-proposed? I reject it, as there is no bug reference at all
<ogra> pitti, tim did
<ogra> pitti, https://lists.ubuntu.com/archives/kernel-team/2010-November/013532.html
<ogra> looks like a general BSP update
<tgardner> how can I find out why a package was rejected, e.g., linux-mvl-dove for Lucid
<pitti> tgardner: see three lines above ^ :)
<ogra> tgardner, see PM, i pasted them for you
<tgardner> pitti, linux-mvl-dove is not subject to SRU, so I see no reason to have a tracking bug. Eric has about the only HW in existence, so I assume he knows what he's doing.
<pitti> tgardner: really? I have two dove boards :)
<pitti> tgardner: anyway, it was uploaded as an SRU, so perhaps it should go into -backports then or so?
 * ogra knows GrueMaster and NCommander have them too 
<pitti> we at least need a tracking but for the testing
<pitti> I mean, if you say "we don't care", ok for me, but it'll just bitrot in -proposed then
<tgardner> pitti, ok, I'll add a tracking bug. Does anyone actually ever use them? Usually the developers just fire up a  new bug and report their specific symptoms.
<pitti> tgardner: those are a much preferable indeed
<pitti> tgardner: if this upload closes any "real" bug report, please use that
<testi__> How do you get blueprints discussed? What if you have a feature idea that doesn't need to be in the next release? Where do you start, other than placing a blueprint or brainstorm idea?
<tgardner> pitti, I'll have to ask Eric about that. I'm just doing the packaging for him.
<testi__> How that workflow works
<testi__> *I wonder
<siretart> kees: ffmpeg uploaded
<apw> pitti, how often is the work-items tracker running now that maverick is gone ?
<apw> are we back to hourly ?
<apw> pitti, ignore me, i can tell for myself now :)
<pitti> apw: we aren't; I'm not sure how long the tracker needs these days, we might be able to switch back to hourly
<pitti> but now it has the maximum number of charts it needs to generate
<apw> pitti, i'll find out how long it takes
<apw> i suspect what we should do is make it trigger hourly with a lockout, so that it doesn't step on itself
<jdstrand> Daviey: hey. did you get an answer for natty-security/
<jdstrand> ?
<Daviey> jdstrand: i did, thanks!
<jdstrand> cool
<jdstrand> I thought I saw it, but then couldn't find it, and then wasn't sure if I imagined it :)
<jdstrand> pitti: hi! what is the process for resetting the work items tracker for our team? we didn't get all our blueprints done until the 17th
<jdstrand> pitti: it is no biggie, but would be nice to have fixed (eg http://people.canonical.com/~platform/workitems/natty/canonical-security.html)
<pitti> jdstrand: just change it yourself, "sudo -u platform -i" on lillypilly
<pitti> I sent that around to platform some weeks ago
<jdstrand> pitti: k, thanks
<pitti> jdstrand: is the sudo thing working for you?
<jdstrand> pitti: I am in as 'platform', yes. I am just trying to figure out what to do (I don't see a README or similar, but I only just started looking)
 * jdstrand wonders if it is 'trend_start'
<pitti> jdstrand: it's in work-items-tracker/config/natty.cfg
<jdstrand> yeah, that is what I am looking at
<pitti> jdstrand: you need to change the "trend_start" map
<jdstrand> pitti: so trend_start will override whatever is already in there?
<pitti> there are some examples already
<pitti> jdstrand: right; by default it uses "#open WIs" from the first day
<jdstrand> pitti: cool. ok, then it is pretty self-explanatory. I got there pretty quickly :)
<jdstrand> pitti: thanks!
<pitti> great! you're welcome
<pitti> jdstrand: there you can also check if it's currently running, or run it manually once for an urgent update, etc.
<sladen> vish: so what's the difference between papercutters and papercut-ninja
<vish> sladen: the papercut ninja is more for fixing the bugs , the papercutters is for triaging the bugs..
<vish> sladen: kinda like MOTU and BC
<sladen> vish: k, *nods*
<vish> sladen: and the papercut-ninja will hopefully have the upstreams joining in as well, so that they can help the new folk..
<cyphermox> hey, I'm considering getting wpasupplicant 0.7.3 from Debian SVN uploaded to natty -- I've been testing it on my system for a few days now with no issues -- 0.7.3-1 is marked as UNRELEASED though, is there any issue with leaving that as is in changelog for an upload, with a further 0.7.3-0ubuntu1 on top, and then strip that one out later once 0.7.3-1 gets released (assuming it gets sync'ed)?
<sladen> cyphermox: no, you can leave the "UNRELEASED" entries in
<sladen> cyphermox: see  http://changelogs.ubuntu.com/changelogs/pool/universe/o/openbve/openbve_1.2.7.3-0ubuntu1/changelog
<sladen> but somebody might suggest using a ~somewhere in the version as that 0.7.3-1 is still in flux and hasn't actually been released yet
<cyphermox> right, but that's why I set my revision as 0.7.3-0ubuntu1
<cyphermox> I was mostly curious to see if there was an established better way to do this, afaik the only side effect is a lintian warning ;)
<cjwatson> UNRELEASED is basically a safety catch
<cjwatson> only the top entry actually matters though
<cyphermox> yeah, and that gets rejected
<cyphermox> thanks.
<tgardner> pitti, linux-mvl-dove re-uploaded for Lucid/Maverick with tracking bug in the changelog
<pitti> thanks
<pitti> marjo: can I just add something to "new features" on https://wiki.ubuntu.com/QATeam/NattyTestPlan, or should this be coordinated?
<marjo> pitti: if you don't mind, please tell jibel before adding?
<pitti> marjo: ah, will do that; thanks!
<marjo> just so he's not surprised?
<pitti> jibel: does it sound ok to you if I add the applications that we ported to Gtk 3.0/gobject-introspection to "New features" in https://wiki.ubuntu.com/QATeam/NattyTestPlan ?
<pitti> jibel: the introspection stuff is still in heavy flux, and thus prone to break
<pitti> jibel: I'd like to add things like "apport - try "ubuntu-bug audio" and select the "record" case, then follow the steps, and finally check if you get a reasonable output and behaviour of the details window"
<jibel> pitti, yes please go ahead, this is a live document. I'm subscribed to it so we can always talk about the changes later.
<pitti> that will exercise various dialog types, the details view, and thus cover quite a bit
<apw> pitti, fyi i've just worked out why the graphs don't seem to have enough items.  the counts are being made on the DISTINCT descriptions so if you have two items with the same text anywhere they are collapsed
<pitti> aah
<apw> pitti, my graphs just jumped about 20 itemes, you don't want to know about foundations
<apw> i'll push the change shortly :)
<pitti> apw: but the by-user view lists them all?
<pitti> apw: odd, why do we have so many identical WIs?
<apw> yeah the db and the views are all right, its just the graphs
<apw> some wording is common, i have a lot which are 'review personal patches and upstream'
<apw> one for each person with patches
<pitti> apw: it needs to take care of not counting the WIs from other days, though
<apw> pitti, its doing the loop by day though
<pitti> I'm not quite sure why I added the distinct back then
<pitti> apw: right
<pitti> apw: if it's "more" correct without, just kill it :)
<apw> will do
<pitti> thanks
<jdstrand> pitti, didrocks: hey. so it only just now dawned on my that the security team won't be able to test security updates in VMs for natty with a representative install. aiui, unity won't run in kvm or other virtualized systems
<pitti> jdstrand: it should automatically fall back to gnome/2d, though
<jdstrand> pitti: right, but we like to test on a default install with a representative desktop
<didrocks> jdstrand: yeah, that will be an issue (I don't now the support on virtualbox + acceleration works there)
<jdstrand> pitti: to try to cover as many bases as possible
<didrocks> know*
<jdstrand> pitti, didrocks: I know that the desktop will be downgraded if the unity experience is not deemed "great", but what does that mean exactly?
<jdstrand> ie, is "great" just performant?
<didrocks> jdstrand: there are four "layer"
<didrocks> jdstrand: first one is software rendered -> metacity + gnome-panel
<didrocks> second one is compiz can run, but not unity at all -> compiz + gnome-panel
<didrocks> the third is compiz and unity can run, but unity will do some GL check for tooltips and places at startup, there will be unity in a degraded mode with less beautiful GL effects
<didrocks> and the fourth layout is  compiz with unity and full gl effects
<ion> cyphermox: Hi. Regarding packageselection-n-network-stack, has Teredo been considered? For instance, Windowsâ¢ uses an implementation of Teredo by default, resulting in IPv6 connectivity even behind IPv4-only NATs. Miredo seems to be a fire-and-forget-type implementation, one only needs to install the package and it Just Worksâ¢.
<jdstrand> didrocks: I see. the 3rd would be acceptable for the security team, but that sounds infeasible with curent technologies
<jdstrand> didrocks: since so much of the platform team's work is done in virtualized environments, is work being done to get unity to work ok in a VM?
<didrocks> jdstrand: let's see, I know that hw acceleration doesn't work at all on kvm, I really don't know about virtualbox + accel support
 * jdstrand would *love* it to work in kvm
<didrocks> jdstrand: well, I guess most of the desktop team is working directly on a natty install
<jdstrand> didrocks: sure, but maintenance is an issue. SRUs, security updates, the next devel release before you upgrade...
<didrocks> it's better to test what you deliver directly, that's why we are on installed version and don't rely on vm
<didrocks> jdstrand: I personnaly get separated installation on spare box for SRU (and I upgrade very early in the process), not sure about others
<jdstrand> didrocks: well, it sounds like our team is going to get provisioned new machines and just figure out how to deal with it... :/
<didrocks> jdstrand: yeah, I'm afraid hard install will be neededâ¦
<cyphermox> ion, I didn't know about it. Please, tell me more, but maybe we can do that in pm.
<ion> cyphermox: I added the comment to https://blueprints.launchpad.net/ubuntu/+spec/packageselection-n-network-stack along with a link to more info.
<cyphermox> ion, awesome, thanks
<cyphermox> ion, I see. we haven't exactly talked about this kind of stuff in the UDS session, but miredo is available in universe, have you used it?
<ion> Yes, iâve verified it to provide working IPv6 connectivity both behind an IPv4-only NAT and with a public IPv4 address.
<apw> pitti, ok the issue comes down to that the lists are distinct in (description milestone assignee) in most places, but this one only in (description).  i assume you were trying to avoid the 'postponed' in previous milestone and 'done' in this one thing, to try and get only one ... except it 1) doens't do that, and 2) is inconsistant
<apw> (in implementation)
<apw> i suspect they are all 'wrong' but there are such a lot of them i am a little wary
<pitti> apw: ah, perhaps; it's been a while :)
<apw> will do a bit more validation
<cjwatson> BlackZ: your dropping of upgrade handling in rsyslog has meant that a freshly-installed natty system (e.g. a live CD) has no /etc/rsyslog.d/50-default.conf
<cjwatson> BlackZ: can you please put back the ucf bits of that?
<cjwatson> BlackZ: this means that e.g. there's no /var/log/syslog, which makes the installer something of a pain to debug!
<cjwatson> BlackZ: you also removed the code to create the syslog user, so the whole thing is probably pretty broken.  do you want me to fix it up?
<cjwatson> I think you just nuked a bit too much from the maintainer scripts
<BlackZ> cjwatson: please do as I can't right now :)
<cjwatson> BlackZ: ok, will do, thanks
<BlackZ> cjwatson: I thought all the upgrade handling were unnecessary as sysklogd â rsyslog upgrade was done pre-lucid
<cjwatson> BlackZ: but lots of the code you deleted wasn't upgrade handling
<hallyn> cjwatson: so... is debian-live@ the right mailing list to send proposed casper patches?
<cjwatson> hallyn: casper patches should go to Ubuntu - Debian uses live-initramfs, which is a descendant of it but different.  It's worth sending patches to debian-live, but they should be based on live-initramfs not on casper
<hallyn> feh
<hallyn> idon't quite understand - so is casper occasionally re-based on top of live-initramfs?
<cjwatson> it ought to be, but isn't
<cjwatson> they're divergent
<cjwatson> at some point I plan to throw away casper and use live-initramfs, but the divergence is substantial so I need a spare week for it
<cjwatson> it's a historical mess
 * hallyn goes to look at the live-initramfs git tree
<BlackZ> cjwatson: ok, so if I removed what you said not related to the upgrade handling I did that accidentally :) thanks for noting this
<hallyn> cjwatson: ok, so i guessi'll consider whether i dare just 'port' the patches to live-boot.  kinda scary, though, as that'll be far less tested.
<hallyn> cjwatson: thanks
<cjwatson> BlackZ: ok, fixed now, thanks
<statik> aloha micahg! do you know if a separate package of spidermonkey is still out of the question for Ubuntu even though debian is still shipping libmozjs? I'm still hearing complaints about couchdb depending on xulrunner, and trying to figure out if any improvement is possible
<micahg> statik: we're considering it again actually
<statik> micahg: orly? cool. this is kind of relevant, looks like debian is versioning libmozjs: http://packages.debian.org/search?suite=all&searchon=names&keywords=libmozjs I haven't looked to see where they are pulling the "releases" from though
<statik> oh, source package is iceweasel and they build a libmozjs binary package
<micahg> statik: the problem is upstream isn't versioning
<statik> yeah, it's so odd
<statik> micahg: i guess the thing to do would be to use the xulrunner versions since those are the tarballs that include the spidermonkey source? Mozilla has all these articles that are in favor of people embedding spidermonkey so it's kinda odd that they stopped releasing spidermonkey tarballs
<micahg> statik: nope, that's not the issue, its the ABI version that's the issue
<micahg> statik: the 1.9.2.11 release might not be compatible with the 1.9.2.12 release
<statik> micahg: so does that mean that couchdb should not be using spidermonkey?
<micahg> statik: well, idk of another library that's as convenient
<micahg> statik: another problem is we can't just follow Debian's lead since we'll have 2.0 in natty and experimental has 1.9.2, also we push out the releases as soon as mozilla does and there's no guarantee Debian will do the same
<statik> micahg: the thing that is tough for me is it's harder to use spidermonkey on ubuntu than it is on debian, and I don't understand the benefits of that decision well enough to defend it.
<statik> couchdb also can't embed their own copy of spidermonkey because of mpl and apache license incompatibilities
<micahg> statik: have you seen the bug?
<statik> micahg: I was searching in bugzilla but have not found anything yet, if you have a pointer to the past discussions that would be awesome! I'm not meaning to complain at you, just got the energy to try and understand the issue better :)
<micahg> statik: bug 286906
<ubottu> Launchpad bug 286906 in xulrunner-1.9.2 (Ubuntu) "provide and support a top-level library package for libmozjs (Was: Unable to use libmozjs.so in an application, because of library path problem.)" [Wishlist,Triaged] https://launchpad.net/bugs/286906
<statik> thx
<micahg> statik: np, it's a problem for Ubuntu in general since xulrunner isn't needed on the CD anymore except for mozjs
<statik> v8 doesn't seem to have any of these problems, I'm so curious whether switching to v8 is an option for couchdb
<statik> it's bsd license so embedding into an apache project is possible, and it seems to have nice clean simple packaging and releases
 * jpds thought we were talking about IP versions for a moment there.
<micahg> statik: well, that will mean more regression testing for chromium then upgrades then
<micahg> statik: actually not, nm
<statik> micahg: thanks for the help, this bug history was quite helpful
<micahg> statik: np, let me know if you need anything else
 * cody-somerville isn't sure how distributing the debian changelog satisfies the "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change." section of the gplV2. :S
<smoser> cjwatson, are you around ?
<smoser> cjwatson, i tried to verify the fix for bug 581760 but apparently missed something. see my comments there.
<ubottu> Launchpad bug 581760 in grub2 (Ubuntu Lucid) "[Wubi] when updating it advices to install grub on all partitions" [High,Fix committed] https://launchpad.net/bugs/581760
<SpamapS> hrm.. I'm debugging some issues with /lib/init/upstart-job .. seems like there's a giant race condition there where it runs 'status $JOB' and then acts based on that response later.. but status may change
<SpamapS> its a pretty tiny window...
<SpamapS> seems like it should check the return code of the action instead of using status
#ubuntu-devel 2010-11-20
<SpamapS> for instance , if I have a maintainer script that stops a service which takes a long time to stop said service, and then tries to stop it again.. it shouldn't fail if the service is already stopped.. but mysql seems to fail this way all the time.
<SpamapS> the scenario is prerm stops job, then preinst stops job ...
 * SpamapS realizes its friday night and he's mostly typing into the emptiness of space
<smoser> cjwatson, so, if you see this, i've now (i think) sufficiently verified bug 581760
<ubottu> Launchpad bug 581760 in grub2 (Ubuntu Lucid) "[Wubi] when updating it advices to install grub on all partitions" [High,Fix committed] https://launchpad.net/bugs/581760
<smoser> now we can get on to important bugs like bug 671097
<ubottu> Launchpad bug 671097 in grub2 (Ubuntu Lucid) "update-grub needs to ignore linux-ec2 kernels" [Medium,Triaged] https://launchpad.net/bugs/671097
<anon^_^> this is probably a question that's been asked a few times, apologize if it is.
<anon^_^> What's the status on [RFC/RFT PATCH] discussed on LKML being backported to Ubuntu 10.04?
<anon^_^> http://lkml.org/lkml/2010/10/19/123
<Pici> anon^_^: Likely not, see http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch
<psusi> stop reading linux tabloids ;)
<ebroder> Why is everybody so excited about this patch all of a sudden?
<psusi> because Phoronix is hyping it
<Sarvatt_> (and slashdot)
<psusi> with videos of the amayzing difference it makes when you are stupid enough to run make -j64
<ebroder> (and slashdot)> Ah, that makes sense
<psusi> yea, that too
<ebroder> I've never heard of Phoronix and I stopped reading /. about a year ago :)
<Pici> Only a year ;)
<psusi> I've not bothered reading /. in a few years unless I'm board, and I finally checked out phoronix once or twice before this broke because I keep hearing so much about it
<ebroder> I spent longer thinking about stopping :-P
<maco> phoronix is a benchmarking software maker who uses their software to benchmark OSes and hardware and people care about the results
<psusi> I was fairly certain it was crap before this story broke... now I'm sure
<Pici> Anyway, that askubuntu link above has comments by a bunch of our kernel people in it.
<psusi> in this case, they are showing a test case involving make -j64, which is absurd, and the uneducated masses see it and generalize it to achieving the same results for normal desktop loads
<anon^_^> ebroder, because desktop responsiveness is an issue are load
<psusi> I've been meaning to high five Kees when I see him on irc for his comment pointing out that this will have no effect for the average desktop user
<anon^_^> whether this patch actually addresses that issue is a different question
<psusi> anon^_^, sure, but your average Ubuntu user does not typically have a load avg of 64 ;)
<ebroder> It's not just that. Your average Ubuntu user doesn't have non-trivial processes associated with more than one tty
<psusi> exactly
<anon^_^> well and then there's the issue of what constitutes load.
<anon^_^> try running an luks lvm encrypted system moving writing files to disk and watch a desktop crawl to a halt when multitasking
<psusi> the NT kernel has always had a feature where it boosts the scheduling priority of the thread that owns the foreground window.. I've long wondered why we don't have something like that
<Sarvatt_> the userspace implementation of it very noticeably helps while dist-upgrading or building packages while browsing the web on an atom :)
<psusi> you know... I've been running dist-upgrades a lot lately testing out lvm snapshots and don't have bad lag on gui apps while that goes on... I've also been playing with the apt options to make more use of triggers and avoid re-triggering the same things 12 times during the dist-upgrade, as well as using libeatmydata to stop the damn fsyncing dpkg normally does that slows things down so much for the last release or two
<superm1> would it maybe make sense to use libeatmydata during initial install when using d-i?
<superm1> but still leave default fsync behavior otherwise
<psusi> there's a patch working its way into dpkg to add a switch to stop the extraneous syncs, but yes, it would
<superm1> well a proper patch to turn it off sounds much better than hacking in an additional library
<psusi> yep
<psusi> either way, I'm happy to dist-upgrade in 10 minutes or less instead of 20 or more
<cody-somerville> Omg. Call of Duty Black Ops ships zork in it as an easter egg.
<cody-somerville> along with a 'linux console'.
<d_ed> cody-somerville: just found a video of it...ooh
 * psusi fires up tonight's dist-upgrade to natty
<cody-somerville> d_ed, apparently you can do all sorts of stuff in it - even rlogin into other systems, lol.
<d_ed> I've not played the game, but I feel I should get it now.
<cody-somerville> Its an easter egg, hidden in an easter egg, hidden in an easter egg. Its bloody brilliant.
<cody-somerville> Anyhow, back to my xbox. :)
<d_ed> and back to hacking
 * psusi has proposed an updated lvm2 for merge
<ScottK> Nice to see Canonical has taken over dealing with sponsorship.
<geser> cjwatson: how far up in your TODO queue is the review (and sponsoring) of bug #617885? The current suggested "fix" from other bug comments are links to the natty debs
<ubottu> Launchpad bug 617885 in gparted (Ubuntu Maverick) "gparted crash at start: glibmm-ERROR **" [High,Triaged] https://launchpad.net/bugs/617885
<asac> here is a tool (perf) that doesnt properly resolve symbols from dbgsym it seems ...
<asac> how can i manually resolve it?
<weasel> is there some system that has sources of older packages (akin to snapshot.debian.org)?  specifically I'm looking for openssl_0.9.8k-7ubuntu8.3.dsc
<elmo> weasel: https://launchpad.net/ubuntu/+source/openssl/0.9.8k-7ubuntu8.3
<weasel> thanks
 * weasel goes to interdiff 8.3 and 8.4, since you broke all tor relays
 * weasel hates libssl
<elmo> jdstrand/mdeslaur/kees: ^-- fyi (since sbeattie is away)
<weasel> [ http://archives.seul.org/or/talk/Nov-2010/msg00128.html ]
<mdeslaur> weasel: if you downgrade to 0.9.8k-7ubuntu8.3 it starts working again?
<weasel> hard to tell, I don't have an ubuntu system :)
<weasel> guess I'll set up a chroot somewhere
<weasel> but several people have reported that their relays stopped working after upgrading libssl, so /something/ is going on
<mdeslaur> weasel: well, that distro are you running? the 8.4 release adds the same upstream security fix that everyone else used
<weasel> mdeslaur: yup, so it appears
<weasel> so the next step should probably be reproducing it in an ubuntu chroot and reproducing it with 0.9.8p from upstream
<mdeslaur> weasel: could you please open a bug and track your progress in it? or ping me again if there's something we need to do?
<weasel> mdeslaur: should it turn out to be ubuntu specific I'll complain some more.  and I'll try to keep you updated
<mdeslaur> weasel: thanks
<weasel> debian sid should have the same patch.  /me goes to check that
<mdeslaur> weasel: yes, sid has the same patch, I just checked
<weasel> yup
<weasel> ok, not ubuntu specific.
<mdeslaur> weasel: well, let me know if there's anything I can go to help
<mdeslaur> s/go/do/
<weasel> will do
<mdeslaur> thanks weasel
<weasel> I suspect our (Tor's) libssl guru will have to add yet another work around to work everywhere
<gaurava> Hi All ..  I am a newbie here
<gaurava> I am trying to create a sample patch file following this article <https://wiki.ubuntu.com/Bugs/HowToFix>  but facing some issue ..
<gaurava> nyone .. can help me out .. or point me to the right channel
<ScottK> gaurava: #ubuntu-motu is probably more active on a weekend.
<gaurava> thanks Scottk ... will try my luck over there .
<gaurava> #join ubuntu-motu
<buxy> cjwatson, pitti: should ubuntu switch to use data.tar.xz by default instead of stripping changelog and all that kind of intrusive changes?
<ebroder> buxy: The issue isn't in the size of the .debs. It's the size of the unpacked .debs - the desktop CD is all of the CDs unpacked, and then squashfs'd
<ebroder> buxy: And using lzma to compress the filesystem is infeasible because it breaks zsyncing from one daily CD to another (zsyncing becomes basically equivalent to re-downloading the whole CD, which isn't feasible for some of our QA procedures)
<ScottK> lzma does help on the alternate CD though.
<ScottK> (not that it particularly needs it)
<JanC> ebroder: zsyncing is only relevant for daily builds though, so it shouldn't be an issue for final builds?
<ebroder> JanC: But you can't switch from one compression algorithm to another for the final build. That defeats the point of doing the testing
<ebroder> (Keybuk was very proud of having found a bug in squashfs's gzip compression in the past)
<JanC> well, you can still test both
<JanC> but use the zsync'able version for "daily tests" with testdrive
<JanC> and people who don't care about bandwidth can use the lzma version
<JanC> it would require changing the build process of course
<JanC> and testing how much more space we get that way  ;)
<ebroder> Well, I can at least give an estimate for the space savings. I'm rolling custom live CDs at work, and I tried building one with lzma just out of curiosity. lzma image was about 83% the size of the gzip image
<ebroder> I was working with a custom set of packages, so your mileage may vary
<ebroder> But in any case, the people at the UDS session were fairly adament that we only generate one desktop spin, and that it must be incrementally updatable
<JanC> ebroder: so basically this is dictated by the QA people (which I understand)
<ebroder> JanC: Yeah, basically
 * penguin42 wonders what % of users actually install from a physical CD these days
<JanC> penguin42: depends on if I have a live-USB with me or not  ;)
<penguin42> JanC: Are you more likely to have a spare USB thumb or a blank CD with you?
<JanC> penguin42: I almost always have an official CD with me  ;)
<penguin42> I was just wondering that given the minimum spec of machines these days very few can't boot off USB, heck there are probably more machines with no-optical drive rather than ones that can't boot off USB
<JanC> as I have our locoteam's box of official-CDs-for-redistribution at my home...  :P
<JanC> penguin42: when we are at computer fairs we also distribute free CDs/CD-Rs, not free USB sticks  :P
<JanC> so I imagine a lot of people install from CD still
<ebroder> penguin42: That came up at UDS, too. cjwatson made the point that even if people aren't using CDs, the size of a CD presents *some* limitation to keep the image size from ballooning out of control
<penguin42> ebroder: Yeh that is true
<JanC> of course if they bring an USB stick, we'll make it a bootable live-USB for them
<ebroder> And also, with the rise of netbooks, you can no longer assume that computers have arbitrarily inflated specs. Disk space post-installation is a legitimate concern for netbooks, and controlling the CD size also conveniently controls the post-install size
<penguin42> ebroder: Indeed post-install size is as important
<JanC> IIRC Windows 7 is about 20 GiB post-install now...  :P
<ebroder> Hmm...I don't think it's actually that bad. More like 10
<JanC> maybe depends on what version of Win7
<JanC> and maybe what options you install
<JanC> oh, and that was after all the updates
<penguin42> heck, apparently you can get 1GB usb sticks for 59p now :-)
<JanC> (and after more than 3 hours of installing updating)
<ebroder> penguin42: Sure, but you can get CDs for a fraction of that
<penguin42> ebroder: Indeed, I was just being pleasently shocked by what they had come down to
<JanC> fortunately it took only 15 minutes to install + update Ubuntu  ;)
<JanC> Pendulum: where do you find 1 GB USB sticks still?
<JanC> penguin42: where do you find 1 GB USB sticks still?
<JanC> (sorry Pendulum ;) )
<penguin42> JanC: Google found me http://www.kikatek.com/product_info.php?products_id=34487&source=froogle
<penguin42> bah, if you click check availability it says sold out
<JanC> penguin42: cheapest I can find are 5-6 Â£
<JanC> taht's like 10Ã more...
<JanC> well, cheaper too, if you order a 1000 of them  :P
#ubuntu-devel 2010-11-21
<kees> stgraber: oooh, nice work with the app sandbox!
<stgraber> kees: thanks. I hope it'll help getting more people to play with containers and become aware of them.
<sl33k_> when i am build/compile a project, object codes for amd64 and x86 are mixed up?
<sl33k_> i am on x86 machine
<ggeorgy> hi  ;)
<ggeorgy> can you help me with something please ? i try to install a -.bin file !!!
<ggeorgy> can help me somebody please??thanks!!!
<bluefoxicy> whatever happened to magic updates
<bluefoxicy> we're still downloading 13 packages when one (produced from the same source) changes
<bluefoxicy> on every single distro out there
<bluefoxicy> I thought Ubuntu had a proposal and a plan for downloading incremental updates so a 250MB openoffice update would ship down the two changed files
<printf_1> nigger
<mrenouf> simple debian packaging question. when I build my package (git-buildpackage) with -S my .changes file doesn't list the .orig.tar.gz what might I have wrong?
<Hobbsee> because you didn't use -sa
<Hobbsee> (as well)
<mrenouf> thanks!
<Hobbsee> no problem
<mrenouf> how can I set that in gbp.conf ?
 * Hobbsee --> afk again
<Hobbsee> err...i've no idea.  probably the same place you set -S
<mrenouf> yay, my ppa package is building.
<mrenouf> anyone here familiar with CMake and cdbs? I need to point to a subdir to build (where the CMakeLists.txt is).
<gusnan> mrenouf, you don't have your CMakeLists.txt in the project "root"?
<mrenouf> no... not my project, trying to 'adapt' it as best I can.
<mrenouf> or is there something I can put in a CMakeLists.txt in the root?
<mrenouf> I've never used it
<mrenouf> got it.... DEB_SRCDIR=subdir
<vadi2> http://packages.ubuntu.com is being unreliable again
<vadi2> The page doesn't load most of the time.
<weasel> mdeslaur: [fyi] tor upstream found a workaround/fix for the openssl change within tor.  building new tor packages atm.
<mdeslaur> weasel: oh, good. Thanks for letting me know.
#ubuntu-devel 2011-11-14
<pitti> Good morning
<dupondje> pitti: i'll check papyon somewhere today, something went wrong :(
<dholbach> good morning
<pitti> hm, yesterday's dailies grew by 7 MB, due to adding fonts-nanum
<pitti> fixed seeds and uploading new -meta, that should do it
<cjwatson> pitti: thanks
<pitti> cjwatson: FYI, nanum is actually expected to be there, it just looked a bit weird because some ttf-* got renamed to fonts-*; but it replaced ttf-unfonts-core which is still on the imags
<cjwatson> pitti: right, I knew about the ttf-* -> fonts-* renaming
<cjwatson> still need to process some removals for that
<bdrung> broder: debug-symbols-directly-in-usr-lib-debug?
<cjwatson> pitti: https://launchpad.net/ubuntu/+source/eog/3.2.1-0ubuntu2 - could you please use libjpeg-dev rather than libjpeg8-dev for such changes, per http://lists.debian.org/debian-devel-announce/2010/02/msg00006.html ?
<pitti> cjwatson: ah, ok; I used 8-dev | -dev
<pitti> cjwatson: I thought the first alternative should always be preferred
<cjwatson> That will make future transitions require a source change
<pitti> cjwatson: pushed to bzr
<cjwatson> For this library we're just having only one provider to make it easier to transition
<pitti> cjwatson: do you want me to upload that now to satisfy some report scripts, or is it not that urgent?
<cjwatson> thanks
<cjwatson> it's not urgent
<cjwatson> I just wanted to catch it quickly in case you were making the same change to lots of packages
<pitti> I only really caught it because I was using it for testing the new scour
<pitti> but good to know for other cases
<Daviey> cjwatson: Does anyone on your team have prior experience with bonding interfaces?
<Daviey> cjwatson: trying to work out if bug 889423 would be better worked on my server or foundations.
<ubottu> Launchpad bug 889423 in ifupdown (Ubuntu) "802.3ad bonding not configured correctly" [Undecided,Confirmed] https://launchpad.net/bugs/889423
<cjwatson> not that I know of for certain, although I wouldn't put it past StÃ©phane
<Daviey> I have /some/ experience, but don't claim to be an expert.
<Daviey> stgraber: When you see this, can you chime in please? :)
<cjwatson> there were some ordering changes in ifupdown 0.7~beta2 (not yet in precise) although I don't know if they're relevant here
<cjwatson> (just saw Debian mail about that yesterday)
<Daviey> cjwatson: thanks
<djszapi> Hi! Where can I find the source of the kdeedu 4.7 package ?
<Riddell> djszapi: launchpad.net/ubuntu/+source/kdeedu
<djszapi> Riddell: I do not see 4.7 there.
<stgraber> Daviey: this looks a lot like a potential SRU regression we currently have on lucid, sadly I can't easily reproduce the bug here (need to setup all the hardware, reinstall, ... first)
<iceroot> cjwatson: hi, you have a minute? (imo you are a patch-pilot)
<stgraber> Daviey: bug 823366 is the potential SRU regression on 10.04.3 (the SRU in 10.04.3 is based on what we had in natty/oneiric IIRC)
<ubottu> Launchpad bug 823366 in ifenslave-2.6 (Ubuntu) "bond_primary is ignored in /etc/network/interfaces" [Undecided,Incomplete] https://launchpad.net/bugs/823366
<Daviey> stgraber: ah, i thought it might have been a regression of bug 482419
<ubottu> Launchpad bug 482419 in ifenslave-2.6 (Ubuntu Lucid) "802.3ad interface bonding fails if started too early" [Medium,Fix released] https://launchpad.net/bugs/482419
<Daviey> FWIW, Debian experimental package without ubuntu delta also has the bug.
<stgraber> Daviey: right, bug 823366 has been filed as a potential regression of the bugfix from bug 482419
<ubottu> Launchpad bug 823366 in ifenslave-2.6 (Ubuntu) "bond_primary is ignored in /etc/network/interfaces" [Undecided,Incomplete] https://launchpad.net/bugs/823366
<ubottu> Launchpad bug 482419 in ifenslave-2.6 (Ubuntu Lucid) "802.3ad interface bonding fails if started too early" [Medium,Fix released] https://launchpad.net/bugs/482419
<cjwatson> iceroot: patch-piloting is a one-morning-a-month duty for me; I'm not patch-piloting at the moment
<cjwatson> there should be another pilot along in a bit, announced in the channel topic ...
<iceroot> cjwatson: ok :)
<stgraber> the problem being that the fix got taken as-is from a more recent version of ifupdown, so it's not totally clear how we should fix it. Pulling the SRU in lucid will get us back to the previous not-always-working state, keeping the current one is a different kind of not-always-working AFAICT
<Daviey> stgraber: We've been discussing it in #ubuntu-server, one user suggested that gets 10% success rate, and modprobing (!) gave him reliable setup
<Riddell> sladen: where do I report uses of the old ubuntu logo?
<stgraber> Daviey: that could be explained by the fact that all of /proc/sys/net/ipv4/*/bond* only appears once the module is loaded (same with /sys/class/net/bonding*)
<sladen> Riddell: http://launchpad.net/ubuntu-branding/+filebug?field.title=XYZ+uses+pre-2010+Ubuntu+logo
<stgraber> Daviey: so we may have some kind of race condition between ifupdown/ifenslave and the kernel module being loaded
<Daviey> stgraber: I've been given access to an env where we can reproduce it, do you want me to try and get you access?
<stgraber> Daviey: that'd be great
<stgraber> Daviey: so if you add "bonding" to /etc/modules, does it then work reliably?
<stgraber> (trying to figure out a quick test/workaround for the guy who reported the SRU regression so we can confirm it's the same issue and "fix" his setup for now)
<smoser> pitti, you touched libtasn1-3, right?
<pitti> smoser: yes, I debugged this weird NEWS.gz issue this morning a bit
<smoser> pitti, sorry. i was going to say it didn't seem to fix it for me
<smoser> but it was user error downloading wrong deb from launchpad (mirror doesn't have it yet for me)
<smoser> all better now it seems.
<pitti> smoser: you need ubuntu1, not build1
<smoser> right.
<pitti> build1 was more or less a check whether it still happens
<pitti> it seems to happen consistently on ubuntu buildds
<smoser> but then when i downloaded that, i accidently downloaded the wrong thing
<smoser> and it didn't help
<smoser> :)
<pitti> but not anywhere else
<smoser> now i'm square. yeah, a gzip bug is a bit strange.
<cjwatson> pitti: I was working through a gdb session on that over the weekend
<pitti> cjwatson: oh, you have a way to reproduce it locally?
<cjwatson> will be getting back to it this week ...
<pitti> I tried local builds, chroots, porter boxes, PPAs, all deliver the "correct" checksum
<cjwatson> pitti: not as such but the difference is in alignment slack near the end of the file, so I'm prepared to bet that it's uninitialised data somewhere and I think I may be able to track it even without being able to reproduce it directly
<pitti> cjwatson: ah, so perhaps the ubuntu buildds do use a different fs than ext4 for /build ?
<cjwatson> I wouldn't have jumped to the filesystem being at fault
<cjwatson> but I haven't ruled out anything in particular
<pitti> not necessarily "at fault", I just can't think of any other significant difference
<pitti> more like "triggers this bug"
<pitti> perhaps truncate() zeroing vs. not, or something
<cjwatson> could also be kernel differences
<pitti> as the kernel, chroot, architecture shoudl more or less match
<cjwatson> not in distro build chroots
<cjwatson> the kernel is often several releases older than the chroot, and the degree of difference itself differs across architectures and also isn't necessarily the same as (virtualised) PPAs
<cjwatson> personally I think that's the most likely cause, although I don't have a particular mechanism in mind and it probably amounts to a gzip bug anyway
<pitti> cjwatson: ah, I had assumed that the buildds run lucid kernel
<cjwatson> definitely not true across the board
<pitti> ok, that's another possibility then
<cjwatson> in fact I think lots of them are still on hardy, since they still need to build hardy-security packages
<pitti> I tried precise on lucid kernel, but not precise on hardy or so
<cjwatson> some are newer since hardy didn't support the relevant machine
<ct529> hi! I am trying to compile the kernel, but 1) I am not certain about the numbering of the ubuntu kernel: does it follow the numbering of the kernel? 2) is it possible to compile the kernel by using the output of cpuid, or /proc/cpuinfo?
<cjwatson> pitti: https://launchpad.net/ubuntu/+source/haskell-dummy/1:6/+build/2906774 looks like a pkgbinarymangler bug to me.  Shouldn't pkgstriptranslations only walk over the list of control files once, no matter how many times it's called for a given package?
<cjwatson> pitti: I suspect this isn't doing kernel builds any favours in terms of performance either
<cjwatson> (I'm not sure why it's exiting 1 in the haskell-dummy case; perhaps a lockfile timeout)
<bdmurray> dobey: any idea what happend to the fix for bug 791927?
<ubottu> Launchpad bug 791927 in desktopcouch (Ubuntu) "apport hook in source package not installed" [Medium,Fix committed] https://launchpad.net/bugs/791927
<dobey> bdmurray: looks like it was fixed in upstream, but maybe the packaging didn't get updated to actually include it?
<dobey> bdmurray: i can fix that after lunch probably
<bdmurray> dobey: okay, thanks for looking at it
<dobey> bdmurray: should we SRU it, or just put it in precise?
<bdmurray> dobey: I'd think SRU'ing it makes sense but I'm don't know how many bugs desktopcouch gets ...
<dobey> bdmurray: ok. will do then
<asac> smoser: I remember that our lucid cloud images had issues to boot on high mem amazon instances. do you know if was that fixed at some point or are better off sticking to maverick still?
<smoser> asac, i think it is fixed, but dont know for sure the exact bug.
<asac> thanks. we might try :)
<asac> will let you know if folks can spare some time testing this
<smoser> do you remember the bug ?
<dobey> bdmurray: https://code.launchpad.net/~dobey/ubuntu/oneiric/desktopcouch/include-apport/+merge/82197
* cjwatson changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | 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:
<zul> slangasek: Ping what do you think of bug #873423 is it a good idea?
<ubottu> Launchpad bug 873423 in net-snmp (Ubuntu) "please enable multiarch for net-snmp" [Wishlist,Triaged] https://launchpad.net/bugs/873423
<slangasek> zul: all libraries should be converted for multiarch
<zul> slangasek: so yes :)
<cjwatson> not after feature freeze; but it's open season at the moment
<slangasek> zul: certainly - that one's low priority from my POV though, since it's not part of the replace-ia32-libs critical path
<zul> slangasek: gotcha thanks
<roadmr> SRU-related question, are string changes SRUable? Our trunk has updated strings having to do with Unity and g-c-c changes and we'd like to have those changes in 11.10 as well
<broder> bdrung: I'm looking at our outstanding lintian diff and trying to understand the "Drop debug-symbols-directly-in-usr-lib-debug from binaries-general." change you made
<slangasek> roadmr: generally not, since this would result in a worse user experience for those who aren't using English rather than a better one
<roadmr> slangasek: ok, so unless it's a major snafu on the string it's not likely to be accepted right?
<slangasek> yes
<roadmr> slangasek: ok, thanks! exactly what I wanted to know :)
<slangasek> no prob
<slangasek> debfx: bug #889475> you know you can use syncpackage to sync mozc yourself these days, it doesn't need to go through an archive admin?
<ubottu> Launchpad bug 889475 in mozc (Ubuntu) "Sync mozc 1.2.855.102-3 (universe) from Debian sid (main)" [Undecided,Triaged] https://launchpad.net/bugs/889475
<slangasek> (and indeed, syncpackage is recommended )
<stgraber> slangasek: hey, I just noticed http://packages.qa.debian.org/i/ifenslave-2.6/news/20111114T104742Z.html in Debian, which looks a lot like our current ifenslave bug. bug 823366, bug 482419 and bug 889423
<ubottu> Launchpad bug 823366 in ifenslave-2.6 (Ubuntu) "bond_primary is ignored in /etc/network/interfaces" [Undecided,Incomplete] https://launchpad.net/bugs/823366
<ubottu> Launchpad bug 482419 in ifenslave-2.6 (Ubuntu Lucid) "802.3ad interface bonding fails if started too early" [Medium,Fix released] https://launchpad.net/bugs/482419
<ubottu> Launchpad bug 889423 in ifupdown (Ubuntu) "802.3ad bonding not configured correctly" [Undecided,Confirmed] https://launchpad.net/bugs/889423
<stgraber> I'm tempted to just try a merge in a PPA and test on the server that Daviey and I are using for testing
<stgraber> slangasek: I noticed you're the touched-it-last, is there anything weird with merging that one from Debian or should I just go ahead and do it myself?
<slangasek> stgraber: feel free to take it, though I doubt Debian actually has a fix for any of this since these are mostly issues specific to event-driven boot
<slangasek> maybe some of the code has been streamlined to reduce the need for duplicating information
<hallyn> SpamapS, do you mind pulling the libvirt-bin from lucid-proposed?  (it failed to build, I marked bug 863629 wontfix for lucid)
<ubottu> Launchpad bug 863629 in libvirt (Ubuntu Natty) "libvirt-lxc: virFileOpenTtyAt can't be called on /some/other/dev/pts" [Undecided,New] https://launchpad.net/bugs/863629
<stgraber> slangasek: yeah, looking at it, the change in Debian is basically what was pushed as an SRU in lucid (and then lost a bit later on in Ubuntu for some unknown reason)
<stgraber> slangasek: basically just re-ordering the lines at the bottom of the pre-up script
<stgraber> slangasek: doing a few tests now, my guess is that we should have the upstart job do nothing at all if an interface is in a bonding setup as bond0 will bring up the interfaces anyway
<SpamapS> hallyn: hmmm?
<SpamapS> hallyn: heading to lunch, do you mean revert it or try it out?
<SpamapS> hallyn: or is it just in queue ?
<hallyn> SpamapS, i mean pull it out of the -proposed queue
<slangasek> stgraber: "lost a bit later on"?
<slangasek> grr
<SpamapS> hallyn: "The unapproved queue is empty"
<SpamapS> hallyn: figure out what you need me to do, I'll be back online in about 45 min
<stgraber> slangasek: yeah, the SRU for lucid basically looks like what has been uploaded in Debian this morning. So it looks like we thought changing the ordering was a good idea, got that as an SRU but didn't apply it to later versions of Ubuntu.
<stgraber> I'll look at that once I have something that works and push the needed SRUs
<slangasek> stgraber: that's not what I see in the current version of ifenslave-2.6 in precise
<slangasek> add_master
<slangasek> early_setup_master
<slangasek> enslave_slaves
<slangasek> setup_master
<slangasek> that's what we currently have... which is intuitively correct
<hallyn> SpamapS, it was approved for -proposed.  It should be pulled out of -proposed.
<hallyn> "figure out what I want" depends on what 'revert it' means.  it's not in -updates yet, so I didn't think revert would have applied.  But if revert means pull it from proposed, then yes.
<stgraber> slangasek: right, lucid has:
<stgraber> add_master
<stgraber> setup_master
<stgraber> enslave_slaves
<SpamapS> hallyn: if it has already been pushed out to mirrors, its better to upload a new package with the change reverted
<hallyn> SpamapS, huh?  for something only in -proposed?
<SpamapS> hallyn: no if it hit -proposed users will be affected
<slangasek> stgraber: yes; that's different not because precise doesn't include the fix, but because precise includes a *further* fix to split setup_master into setup_master + early_setup_master
<SpamapS> hallyn: many devs (myself included) run with -proposed enabled all the time.
<hallyn> SpamapS, it didn't build, so users won't be affected
<slangasek> because presumably some bits need to be done before enslavement, and some after
<SpamapS> hallyn: ahh if it FTBFS then just upload a new one with the fix.
<stgraber> slangasek: -19 to -20 in Debian is: http://paste.ubuntu.com/738533/
<hallyn> i thought things got pulled from -proposed all the time when verification wasn't done by anyone, or failed.
<slangasek> stgraber: that looks to me like the maintainer is flip-flopping; I don't believe that's going to be a correct fix
<SpamapS> hallyn: they do, but I don't believe I can do that as I don't have direct "cocoplum" access.
<slangasek> stgraber: I think this needs more investigation rather than just a simple merge
<hallyn> ok, thx
<slangasek> because it will probably reintroduce the other bugs that led to the early/setup split to begin with
<SpamapS> hallyn: I'm no help at all I know. :-P
<stgraber> slangasek: yeah, agreed on that point (once I actually saw what the change was in Debian). Looking at tweaking the upstart job to not run ifup when the interface is in a bond
<stgraber> which means only bond0 will be brought up and it should then bring up the interfaces, making everything work (hopefully)
<slangasek> stgraber: I think we need a clearer statement of what problem you're actually trying to fix.  That also sounds like a wrong change to me
<hallyn> and i'm just a cranky jerk who hates mondays.  i think i'm less fun to be around.
<slangasek> bond0 will not be brought up correctly
<slangasek> don't do that :)
<slangasek> the bonding bring-up *must* be initialized starting from the physical interfaces
<slangasek> because those are the only things we get events for
<slangasek> we need to properly handle hot-adding of interfaces to an already-up bonding interface, and we need the bonding interface to be brought up when the first physical interface is brought up; there's no other way to do it reliably
<stgraber> ok, let me start a clean precise install on a machine that uses bonding and that's not in Montreal (the one I'm currently working on had way too many changes done to it to still be trusted :))
<slangasek> ok
<slangasek> fwiw, with a complete config here, I'm not reproducing any of these issues
<stgraber> slangasek: that machine in Montreal is failing at every boot but I'd like to see it happen on a perfectly clean system
<slangasek> stgraber: can I see your /e/n/i?
<Daviey> stgraber: that is a volatile machine that can be re-installed if you need it to be?
<stgraber> slangasek: http://paste.ubuntu.com/738559
<cjwatson> slangasek,debfx: syncpackage doesn't support sponsorship yet, though, so the requestor wouldn't get credited; that's one situation where the old-style workflow is still recommended
<slangasek> cjwatson: ah
<slangasek> stgraber: right, so, the design of the current code is such that you need to reproduce the 'bond-mode' and 'bond-miimon' options in the stanzas for each of the physical interfaces, or else they don't get picked up
<slangasek> stgraber: I expect that if you copy those down, the interface will come up reliably
<slangasek> and it's a design defect of the script that this is required
<Daviey> cjwatson: sync bugs don't exactly work well, when they bake in the queue and another developer comes along and does a sync whilst waiting for the bug based sync, so the reporter gets credit.
<cjwatson> Daviey: I'm not saying they're ideal - they aren't.  But syncpackage has no way to assign credit to somebody else right now, so it's a difference between some chance and no chance.
<slangasek> stgraber: /etc/network/if-pre-up.d/ifenslave-2.6 probably needs to use 'ifquery' to extract the details for the bonding interface; this is inelegant, but ifup is obviously not going to know to inject variables from a different interface (bond0) when bringing up the physical interface, so the script would have to do the work
<stgraber> slangasek: rebooting now, I also think I reverted most of the changes that happened to that machine (thanks to debsums)
<slangasek> ifquery also being Ubuntu-specific for the moment
<cjwatson> (Of course the availability of syncpackage has meant that there's less general pressure to process the bug queue regularly ...)
<cjwatson> I'd do it now while thinking about it but I'm being called away
<stgraber> slangasek: machine just finished rebooting, still not working
<slangasek> stgraber: hmm, ok
<stgraber> back to installing a clean precise server :)
<SpamapS> slangasek: think you will have time to upload from the mysql-5.5 svn tree again today?
<Daviey> cjwatson: ack
<SpamapS> slangasek: 5.5.17-3 implements Multi-Arch: foreign for libmysqlclient18
<slangasek> SpamapS: not sure if I'm going to get to it today; if not today, then tomorrow
<SpamapS> slangasek: ok thats great. I am also preparing an upload to make 5.1 stop building libmysqlclient-dev, libmysqld-dev, libmysqld-pic, mysql-common, mysql-server, and mysql-client
<bdrung> broder: that's needed to work around bug #808767
<ubottu> Launchpad bug 808767 in binutils (Ubuntu) "objdump --only-keep-debug cause the resulting binary to be statically linked on i386 arch" [Medium,New] https://launchpad.net/bugs/808767
<bdrung> broder: i would be happy, if you can find a fix for it
<broder> bdrung: ...huh. that is *bizarre*
<stgraber> slangasek: same problem with a clean precise install
<slangasek> stgraber: phooey
<stgraber> slangasek: /etc/network/interfaces => http://paste.ubuntu.com/738619/
<stgraber> slangasek: dmesg => http://paste.ubuntu.com/738620/
<stgraber> lots of complaining going on in dmesg
<stgraber> including some complaints (also visible when doing ifup eth0/eth1) that bond-mode can't be changed from an interface definition (as it can only be set when the bond is down)
<slangasek> stgraber: hmm.  so results may be driver-dependent
<slangasek> it's possible that my own testing in kvm is inadequate :P
<stgraber> in that dmesg (50.) is roughly the time where I fix stuff manually
<stgraber> yeah, test environment here and in Montreal is using e1000 + cisco/hp switches doing actual LACP
 * slangasek nods
<slangasek> well, I know it's working for me because my interface is dhcp-configured and successfully gets an IP, and I can route traffic out
<Fusionite> Hey all
<slangasek> but I'm not using bonding mode 802.3ad
<stgraber> slangasek: ok, so I tried something very ugly but that seems to work pretty well. Added "ifup bond0 || true" to /etc/init/network-interface.conf (before the ifup call)
<slangasek> strange
<slangasek> oh, network-interface, not networking
<slangasek> less strange, just ugly :)
<bdrung> broder: yes, it's a weird i386 bug
<stgraber> yeah, at least that confirms the theory that we need to make sure we always bring up the bond before the slaves
<stgraber> now to find the right place to do it
<slangasek> I'm not sure it does that
<broder> bdrung: does that mean that all i386 dbgsym packages are statically linked?
<slangasek> because /etc/network/if-pre-up.d/ifenslave-2.6 would trigger in both cases
<slangasek> just with different environment variables set
<bdrung> broder: IIRC not all, only that specific file
<stgraber> slangasek: oh, also something that's wrong in most configs I've seen so far, bond-primary only applies to active-backup mode, not to 802.3ad or any of the other bonding modes
<slangasek> ah
<stgraber> slangasek: so that seems to be a minimal valid 802.3ad config: http://paste.ubuntu.com/738645/
<stgraber> at least it works fine (with that hack in the upstart job) and I don't see anything weird in dmesg anymore
 * stgraber just finished reading http://www.kernel.org/doc/Documentation/networking/bonding.txt again
<bdrung> tumbleweed: question.py doesn't seam to be the right place for class EditFile
<tumbleweed> bdrung: it seemed about right to me. Better suggestions?
<bdrung> tumbleweed: where is it used?
<tumbleweed> bdrung: submittodebian, and in the subclass EditBugReport
<tumbleweed> (which is used by requestsync, requestbackport)
<bdrung> tumbleweed: maybe put those two classes into a separate pyfile
<stgraber> slangasek: I'm starting to think these scripts should be split between bond and slaves. Then have the code for the slaves check if the bond exists and if it doesn't call ifup on it so we go through the usual stack instead of bypassing half of it
<YokoZar> I have concluded that the proper way to stop regular kernel panics is to install the kernel-crashdump package
<stgraber> YokoZar: I noticed a similar fix for apache a while ago, if you want it to stop crashing, just turn on debugging
<YokoZar> stgraber: maybe we should put the debug packages in the default install then
<broder> and, of course, the best way to fix race conditions is to have a debugger attached :)
<hallyn> SpamapS, looking at bug 625882 - we are at 0.8.4 of libdbi, does that mean that anything compiled against libdbi can go back to being build-depends on libdbi0-dev instead of libdbi-dev ?
<ubottu> Launchpad bug 625882 in rrdtool (Ubuntu) "libdbi0: ABI breakage without package name change" [High,Fix released] https://launchpad.net/bugs/625882
<SpamapS> hallyn: no, libdbi0-dev is deprecated, it needs to be libdbi-dev
<SpamapS> hallyn: if its coming in as a merge from Debian, then there needs to be a bug opened against the debian package.
<hallyn> SpamapS, with rationale 'libdbi0-dev is deprecated'?
<SpamapS> hallyn: I assume the intention of the maintainer is to drop the provides after a time...  in 0.8.4-1 " Renamed libdbi0-dev to libdbi-dev"
<hallyn> SpamapS, d'oh, nm, i was misreading anyway.  it has 'libdbi0-dev | libdbi-dev'
<SpamapS> hallyn: then in 0.8.4-2 he did 'Adds a Provides: libdbi0-dev' presumably because the API was still compatible
<stgraber> slangasek: I have a working hack on top of ifenslave's pre-up script that seems to work great here (except for the part where both interfaces come up at the exact same time, that I worked around with a sleep for now :))
<slangasek> stgraber: heh, right - plenty of race conditions to be watched after here
<slangasek> stgraber: also, what's the right behavior if one of the interfaces is unavailable (never comes up at boot)?
<stgraber> slangasek: http://pastebin.com/irAA6erR
<stgraber> slangasek: with that code, only the first interface will be added to the bond, which should still work fine
<stgraber> going back home now, will look at backlog later
<bdrung> tumbleweed: bug #890464
<ubottu> Launchpad bug 890464 in ubuntu-dev-tools (Ubuntu Natty) "Ubuntu 12.04 LTS "Precise Pangolin" is unknown" [Undecided,New] https://launchpad.net/bugs/890464
<Laney> that diff does more than the changelog says
<slangasek> bryceh: ping re: bug #889226
<ubottu> Launchpad bug 889226 in xserver-xorg-input-evdev (Ubuntu) "X fails to correctly find my USB input devices" [Medium,New] https://launchpad.net/bugs/889226
<tumbleweed> bdrung: right, that was on my queue, but nobody was verifying distro-info SRUs
<tumbleweed> err udt
<tumbleweed> bdrung: please go ahead. Also, we should come up with a long-term solution to this before precise freezes.
<bdrung> tumbleweed: SRUing distro-info should be easier to SRUing ubuntu-dev-tools
<broder> stgraber: is there a ppa or something with a new version of arkose? i want to play with some of the dbus filtering stuff :)
<tumbleweed> bdrung: I suppose that works for tzinfo...
<bdrung> tumbleweed: there are some weeks between the announcement and the release, so we should have enough time for the SRUs
<tumbleweed> usually, the last one was a bit tight
<stgraber> broder: yes, ppa:arkose-devel/stable
<bryceh> slangasek, yeah
<slangasek> bryceh: hey; followed up on the bug, if you want to debug this I suggest we do so in realtime
<slangasek> as this is a one-off situation that happened *during* an X session that was previously fine
<slangasek> and I don't expect it to be reproducible if I restart the X server
<bryceh> slangasek, I'm reading up on Cypress TetraHub
<slangasek> why?
<slangasek> it's just a USB hub
<slangasek> I can see the kernel events just fine
<slangasek> the devices are there
<slangasek> it's only X that's confused
<stgraber> slangasek: so, I think that the diff I pasted earlier should work and seems to do the right thing. Only thing that needs fixing is the code bringing up the bond interface if it's not there.
<bryceh> slangasek, I won't argue that X may not be doing something stupid, however we've not yet updated the X stack in precise, so what you're running right now should be pretty similar to what you were running in oneiric.
<stgraber> basically whatever is the first slave coming up needs to do the ifup on the bond, any other interface needs to wait for the bond to be up, then add itself to the list of slaves
<slangasek> bryceh: sure; so it could be a latent bug in the oneiric stack, or it could be related to the kernel in some unidentified fashion
<bryceh> slangasek, also there appear to be a lot of usb subsystem error messages in your dmesg; possibly unrelated but also make me wonder at kernel problems
<slangasek> stgraber: my understanding was that the ifup on the bond was already being done by the previous code
<bryceh> slangasek, also I've found a linux-usb thread discussing this particular USB hub and issues with devices not detecting properly
<slangasek> bryceh: heh; I've been using it for a couple of years now with no such problems
<bryceh> the hub appears to have some usb 2.0 / 3.0 switching behaviors that I gather confused the kernel in the case being described in this thread
<bryceh> slangasek, yeah the thread is very recent (nov 12)
<slangasek> ah
<bryceh> http://www.spinics.net/lists/linux-usb/msg54013.html
<bryceh> not sure if it's relevant though.
<stgraber> slangasek: kind of, the previous code was creating the bond and doing all the sysctl configuration, but never actually doing an ifup on it (so you'd have to wait till the ifup -a at the end of the boot to get an IP and run the other post-up scripts)
<slangasek> stgraber: no, you shouldn't have to wait for ifup -a; creating the device causes a udev event for bond0
<slangasek> which (asynchronously) triggers /etc/init/network-interface for bond0
<bryceh> slangasek, last paragraph on this email suggests some known issues exist with this hw - http://www.spinics.net/lists/linux-usb/msg54377.html
<slangasek> stgraber: maybe instead of calling ifup explicitly, we can just cause the interface to be created?
<slangasek> (which I think would probably be cleaner)
<slangasek> bryceh: checking to see what happens if I plug the mouse in directly
<slangasek> stgraber: I guess it depends whether there's additional setup that needs to be done on the slave interface after ifup is called on the master
<slangasek> bryceh: same problem when I plug the mouse in directly
<slangasek> device shows up in lsusb, lsinput, input-events shows the events are being received, nothing useful out of X
<stgraber> slangasek: I need a way of waiting for bond0 to be done initalizing because only then the other interfaces can be added as slaves to that bond
<slangasek> stgraber: I don't think it's very clear what "done initializing" means in all cases
<stgraber> slangasek: currently what's creating bond0 is the pre-up script for bond0, so not sure how to trigger the udev event without running the whole pre-up script
<stgraber> slangasek: I need to have the bonding module loaded, have the bond interface created, have it's mode set and the interface up so /sys/class/net/bond0/bonding/slaves is writable
<bryceh> slangasek, let's pop over to #ubuntu-x
<slangasek> stgraber: oh; I was mistaken, there apparently *aren't* any udev events for bonding interfaces
<slangasek> stgraber: arguably a bug, but I guess we shouldn't design to rely on it
<stgraber> I don't think calling ifup on the master interface is a big problem, as long as we can be sure never to do it twice at the same time because of some race condition
<slangasek> no, ifup itself guards against that
#ubuntu-devel 2011-11-15
<slangasek> (and has to, because /etc/init/networking always races /etc/init/network-interface)
<stgraber> ok, so the problem is the second interface trying to join the bond before it's done being brought up by the ifup triggered by the first interface (when both eth0 and eth1 appear at the exact same time)
<slangasek> stgraber: yeah, that's probably one of the problems, at least
<haakon_n> So do all new packages in Debian get automatically attempted to be added to universe in ubuntu, or do they need to be requested to be synced? It was a little foggy on the matter on the ubuntu wiki.
<tumbleweed> haakon_n: They don't need to be requested, but they do need manual review by the archive-admins. If they are lagging on the review, or it's urgent, they can be poked, or a sync can be requsted.
<haakon_n> so they do automatically get reviewed just from being in debian?
<tumbleweed> if they make it to testing (because it's an LTS, so we are syncing from testing), yes
<haakon_n> get to be reviewd, that is
<haakon_n> ok
<haakon_n> So is there a public page where you can follow the current state of pending packages, etc?
<tumbleweed> No, unless it's been synced by a developer, in which case it shows up in the NEW queue
<haakon_n> ok :)
<slangasek> pitti: why did udev move to /lib/udev?
<slangasek> stgraber: so now that I've isolated a udev upgrade bug here (udevd not actually running), I do get udev events when bond0 is brought up
<slangasek> s/brought up/created/
<stgraber> slangasek: ok, so I guess we could do 'echo +bond0 > /sys/class/net/bonding_masters' which should create the bond and trigger udev
<slangasek> stgraber: yep
<SpamapS> slangasek: I'm putting forth a plan to drop mysql 5.1 entirely as soon as we've transitioned to libmysqlclient18 entirely.. do I need to even bother uploading a new mysql-5.1 that does not build libmysqlclient-dev (and the other bits) ?
<slangasek> SpamapS: I wouldn't bother unless you think you're going to need to upload it in the meantime for other reasons
<slangasek> the package would simply not be uploadable without that change, which isn't a major problem if you're not uploading it :)
<SpamapS> slangasek: right, thats what I was thinking. I've got a branch with it on deck if the need arrises.
<stgraber> slangasek: so current plan sounds like: http://paste.ubuntu.com/738823/
<stgraber> slangasek: should be doable with only limited changes to the current scripts so we don't divert too much from Debian
<slangasek> stgraber: "wait for" - that implies polling...
<slangasek> if you have to poll, you might as well just call ifup instead
<slangasek> but you might be able to have the slave added from the pre-up master when triggered?
<stgraber> well, I'd have to call ifup + poll anyway as in my tests, the second NIC comes up before ifup is done loading the kernel module and preparing bond0
<stgraber> I'd rather not have a different code path for the first interface and for the second, trying to keep things simple :)
<slangasek> stgraber: wouldn't both slaves end up waiting for ifup in that case?
<stgraber> slangasek: yes, whichever gets to the ifup part first actually starts it (the second one will just fail doing so), then they both wait for /sys/class/net/bond0 to appear and then add themselves to the list of slaves (that part shouldn't be racy, so it's fine having both doing it at the same time)
<slangasek> ah, I didn't think it would fail, I thought it would wait for the lock
<slangasek> you've tested this?
<stgraber> I'm getting a:
<stgraber> ifup: interface br0 already configured
<stgraber> (tested with a bridge instead of bond because I'm on my laptop :))
<stgraber> that's while another ifup br0 is running waiting for 10s (sleep in the pre-up script)
<slangasek> stgraber: ah, that's pretty conclusive then :)
<hallyn> SpamapS, so to fix my bad upload of libvirt that ftbfs for lucid-proposed;  should i push fix with incremented version # ?  Or can I just as well push with same version # since it failed to build anyway?
<slangasek> hallyn: new version number needed, launchpad already knows about that source version
<hallyn> slangasek, thanks
<hallyn> slangasek, one more q though :)
<slangasek> shoot
<hallyn> does that mean that I should do -v<version-2> ?
<hallyn> so that if/when it goes to -updates, launchpad catches the '(LP: #xxxxxx)' from the previous commit msg?
<slangasek> hallyn: preferably, yes
<hallyn> cool, thanks
<pitti> good morning
<pitti> cjwatson: haskell-dummy> whoa, I'll have a look at that one
<pitti> cjwatson: rather, it should just operate on the current binary, as it's called through dpkg-deb; there used to be a reason why it does that double interation, though
<pitti> slangasek: I'm not sure, upstream decision; but I figure they wanted to have the daemon out of $PATH
<slangasek> pitti: upstreams frequently get the FHS wrong; I would suggest we put it back in sbin
<slangasek> (udev upstream in particular is clue-impaired where the FHS is concerned ;)
<slangasek> pitti: I noticed this because of bug #889226, fwiw
<pitti> oh, does it say that daemons should be in $PATH?
<ubottu> Launchpad bug 889226 in udev (Ubuntu Precise) "X fails to correctly find my USB input devices" [High,Triaged] https://launchpad.net/bugs/889226
<slangasek> pitti: sbin is "system binaries", which certainly covers udev
<pitti> so, I don't mind much where it lives; we can just revert the commit that changed the path and change the .install
<pitti> but AFAICS bug 889226 needs to be fixed anyway
<ubottu> Launchpad bug 889226 in udev (Ubuntu Precise) "X fails to correctly find my USB input devices" [High,Triaged] https://launchpad.net/bugs/889226
<slangasek> agreed on both counts
<pitti> okay, will do today
<slangasek> pitti: ok, cheers :)
<broder> can i get an archive admin to run the backport-helper script? we've had a bunch of pending backports for a little while now
<pitti> slangasek: I'm not actually sure why Keybuk added "restart udev || true", i. e. whether it was expected to fail sometimes; but I guess it really shouldn't fail
<pitti> and why it's using --no-start with dh_installinit
<slangasek> pitti: probably to work around the behavior when trying to call 'restart' in a chroot
<slangasek> (but this is the wrong solution; chroots that shouldn't have services started inside of them should have a policy-rc.d, or a diversion)
<pitti> *nod*
<pitti> slangasek: so invoke-rc.d is still the right thing to call, despite it's verbose "this is not the script you are looking for" warning?
<slangasek> that warning isn't from invoke-rc.d itself, and yes it is the right thing to call :)
<slangasek> (the warning is from /lib/upstart-job, and is explicitly suppressed when called from maintainer scripts)
<slangasek> /lib/init/upstart-job, even
<pitti> slangasek: something like http://paste.ubuntu.com/738960/ ?
<slangasek> pitti: no
<slangasek> lose the conditional
<slangasek> invoke-rc.d is always present, and is always the right interface
<pitti> . o O { checking for -x invoke-rc.d really seems antique, but is still common pracice in Debian }
<pitti> slangasek: okay (also, s/rsync/udev/ of course)
<slangasek> heh, right :)
<slangasek> as for it being common practice in Debian, I'm pretty sure I chased that out of policy and debhelper a little while ago ;
<slangasek> )
<slangasek> yeah, February of this year, Debian bug #610340
<slangasek> :)
<ubottu> Debian bug 610340 in debhelper "dh_installinit should not call init scripts directly, even as a fallback" [Minor,Fixed] http://bugs.debian.org/610340
<pitti> ah, so the existing scripts like rsync's just haven't been rebuilt since then
<pitti> slangasek: thanks; building/testing now, will upload in a bit
<slangasek> pitti: yay, thanks :)
<dholbach> good morning
<pitti> cjwatson: I filed the "too many iterations" part as bug 890595
<ubottu> Launchpad bug 890595 in pkgbinarymangler (Ubuntu) "pkgstriptranslations loops over all binary packages instead of just the current one" [Low,Triaged] https://launchpad.net/bugs/890595
<pitti> and the FTBFS part as bug 890596
<ubottu> Launchpad bug 890596 in pkgbinarymangler (Ubuntu Precise) "causes haskell-dummy FTBFS" [High,Triaged] https://launchpad.net/bugs/890596
<pitti> Laney: ^ FYI, if you got spammed with the haskell-dummy FTBFS log; I'll fix this in pkgbinarymangler and retry
<cjwatson> pitti: I started out saying "it should just operate on the current binary" but I assumed that it was operating on all of them because it wanted to produce a single tarball
<pitti> cjwatson: right, it should merge them together if it already exists; it already does that with the _translations_static.tar.gz stuff
<cjwatson> ok, if you think that'd be reasonably performant :)
<pitti> but anyway, it's producing a lot of output, but that's not what's breaking the build, and if the translations tarball already exists it doesn't do much
<pitti> (that's why I set it as "low")
<brendand> anyone know how to make python look in a particular location for a module before looking in /usr/lib/python2.x/dist-packages ?
<cjwatson> sys.path.insert(0, ...)
<brendand> ah, yeah - i saw that somewhere before. thanks
<nigelb> Alternatively, try virtualenv if the package is available in PyPI.
<pitti> brendand: or call the program with $PYTHONPATH if it's temporary and you don't want to modify the source
<cjwatson> Although I'm currently converting a package from using private modules to using public modules, because it's more useful that way.
<brendand> pitti - so if a module is on the PYTHONPATH it should be taken from there first?
<pitti> yes
<pitti> brendand: cjwatson's suggestion is the right one if you want to use private modules in your project
<pitti> $PYTHONPATH is right if you want to test somethign with a local version of a system module
<pitti> I often do things like "PYTHONPATH=. ./gtk/apport-gtk" to test the apport modules from trunk
<brendand> pitti - my problem is solved now. but it seemed like my script was using the system version of lazr.restfulclient even though i had a local version in the PYTHONPATH.
<brendand> which i thought was strange
<Laney> pitti: ah, hadn't noticed â actually, how can I subscribe to build failure notifications? I only know how to get bug mail.
<pitti> Laney: usually it mails the uploader and the Maintainer:, but perhaps not for Debian syncs
<Laney> maintainer will be the team
<Laney> (and I've never seen a mail like that for a sync, indeed)
<cjwatson> there's a bug about that I think
<Laney> or even a manual upload (to the maintainer), I don't think?
<Laney> I suppose the lists swallow them though
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/876594 is basically the same
<ubottu> Launchpad bug 876594 in Launchpad itself "rejected builds for synced packages send mail to Debian maintainer" [Critical,In progress]
<cjwatson> I definitely get notifications for failed builds that I've uploaded ordinarily
<Laney> as /uploader/, yes
<Laney> but I do not think I have ever seen anything as Maintainer except from MoM
<cjwatson> generally it's complicated by the need to avoid spamming Debian developers with Ubuntu build failures
<Laney> right, it is probably the right thing to do. I was after a way to explicitly subscribe to build failures :-)
<pitti> cjwatson: argh, xubuntu failed to build, sorry about that; I'll fix the seeds to drop gnome-codec-installer (same like ubuntu)
<pitti> cjwatson: oh, seems you beat me to it, thanks
<cjwatson> pitti: yep, already done, also ubuntustudio
<jcastro> slangasek: do you have old-powertop in a PPA somewhere?
<cjwatson> perl busted on amd64, my fault, I'm working on it as top priority
<kirkland> mvo: ping
<mvo> kirkland: pong
<kirkland> mvo: howdy!  mtaylor just noticed a really nasty new behavior with apt-add-repository
<Daviey> bug 890708
<ubottu> Launchpad bug 890708 in software-properties (Ubuntu) "add-apt-repository: confirmation question is a CLI UI regression, breaking scripts" [Undecided,New] https://launchpad.net/bugs/890708
<kirkland> mvo: it appears to always require an interactive confirmation
<kirkland> mvo: it's breaking all automated scripts and utilities that test from a PPA
<Daviey> it seems that -y isn't silently ignored pre-oneiric.
<kirkland> mvo: is this just a benign regression, or some new behavior we're going to have to work around?
<mvo> kirkland: hm, so it does check is sys.stdin.isatty() - in what env do the scripts run?
<mvo> Daviey: indeed, the fact that the old scripts do not have it is pretty nasty
<kirkland> mvo: well that depends... juju runs in a tty env, i think :-(
<mordred_> kirkland: hey. I'm here
<kirkland> mtaylor-xchat: howdy :-)
<kirkland> mtaylor-xchat: what env did you notice this in?  juju?  or something else?
 * mtaylor-xchat punches smuxi
<Daviey> mvo: I think the following should be expected to work:
<Daviey> #!/bin/sh
<Daviey> add-apt-repository ppa:davewalker/ifupdown
<Daviey> :)
<mtaylor-xchat> yes
<mtaylor-xchat> that's kindof how I noticed it.
<mtaylor-xchat> for instance:
<mtaylor-xchat> http://www.yorba.org/shotwell/install/
<mtaylor-xchat> shows how to get the latest shotwell
<mtaylor-xchat> if you cut and paste those commands as a sequence, it won't work (ok, bad example - there are $'s there) ... I could find another example though
<mvo> mtaylor-xchat: well, I think its fine that it asks you in a interactive scenario, we do want to ensure that people have a vague idea what they are adding and that they thing about it. I do agree that in a script env this is bad though
<mtaylor-xchat> mvo: it's the script env I'm most concerned about, tbh
<mtaylor-xchat> mtaylor-xchat: but I personally find the interactive prompt quite intrusive and would love a systemic config way to disable it
<mtaylor-xchat> wow. I'm bad with tab completion :)
<mtaylor-xchat> mvo: I'm open to and will be happy with anything that solves Daviey's use-case above though :)
<Daviey> mvo: I suggested perhaps have an env variable to have the old behaviour?
<mvo> ok, let me think about it for a second, if a env var works fine, then I'm happy to add it
<mtaylor-xchat> mvo: I could live with env var ... I'd personally LOVE something in a config file that could be driven by debconf questions so it could be preseeded
<mtaylor-xchat> mvo: and would be happy to help do some of that work if we could get it landed in updates
<hallyn> hm, help2man is unintallable on (my) precise (schroot) because of perl-base version mismatches?
<hallyn>  liblocale-gettext-perl : PreDepends: perl-base (>= 5.14.2-3) but 5.12.4-6 is to be installed
<cjwatson> hallyn: yes, working on it
<cjwatson> I tried to avoid this but got something wrong
<hallyn> cjwatson, cool, thanks.  just making sure i didn't mess something up
<cjwatson> I bet you're on amd64?
<hallyn> yup
<hallyn> woudl it work on i386?
<cjwatson> yes
<hallyn> cool, that might tide me over, thanks
<cjwatson> although some other things might break, it's a big transition and it wasn't practical to stage it all
<cjwatson> precise/amd64 will be very broken for about the next hour
<hallyn> cjwatson, thanks for the info
<mvo> mtaylor-xchat: http://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/oneiric/revision/729 <- this is what I can offer right away, let me ponder a bit about Daviey example, it would be ideal if the a-a-r would detect that its run inside a script
<Daviey> mvo: hah, linaro are disucssing the same issue right now, bug 886209
<ubottu> Launchpad bug 886209 in LAVA Dispatcher ""Add apt repository" action broken on oneiric images" [High,Triaged] https://launchpad.net/bugs/886209
<mtaylor-xchat> mvo: awesome
<mvo> Daviey: :/ but their </dev/null seems to be a good workaround, I'm a bit anoyed that there is no better way to detect if run from a script or not, in shell I could (ab)use $- I guess, but not from within the a-a-r context
<Daviey> mvo: Well the mtaylor-xchat use-case is using the same script on pre-oneiric and oneiric, and it seems adding -y breaks pre-Oneiric
<mvo> Daviey: yeah, so the force environment or < /dev/null will both fix the problem. I'm sorry for the trouble this change is causing, we did it because it seems like the recommended way in a lot of blogs and we want people to be aware what its doing
<stgraber> slangasek, Daviey: Updated patch for ifenslave, works great on my system here: http://paste.ubuntu.com/739257/
<Daviey> mvo: Oh, don't be sorry - i thought it was a logical change.
<stgraber> so that should work even if some slaves don't come up or come up really late in the boot sequence
<stgraber> it also properly removes the bond interface when running ifdown (for some reason the older code didn't do that at all, basically leaving unused interfaces...)
<Daviey> stgraber: More stuff had to be migrated to the function fired earlier?
<Daviey> stgraber: TREllis would be happy to validate an SRU for Oneiric btw.
<stgraber> Daviey: nope, I actually moved a big chunk of code to a function that's called after enslavement
<Daviey> oh!
<stgraber> the old code expected all the slaves to be ready before setting up the master, we can't guarantee that with our event based system
<stgraber> so instead I moved that code to a function that's fired every time we add a slave
<stgraber> also, there was a race condition where slaves would be added before all the sysctl were done running on the master
<stgraber> caused by ifupdown not tracking "starting to configure" and "done configuring" separately
<stgraber> so I had to add a /run/network/ifenslave.* file for each bond, that I can check before trying to add a slave
<stgraber> (that "race condition" was basically happening every time I was booting my server here, with the kernel deciding to just block all the trafic on the bond :))
<Daviey> stgraber: Is that a local server, or the one you were on yesterday?
<stgraber> local server
<stgraber> DELL 750 (dual intel gigabit) and a cisco switch with a 802.3ad setup
<stgraber> I'll just wait for slangasek to have a look and test in his VM setup (using some non-802.3ad bonding), if that works there too, I'll push to precise first, then look into SRUing for >= lucid (anything that uses the event-based interface setup jobs)
<Daviey> groovy
<stgraber> I was hoping ifstate would actually save the state of the interface, but apparently it's just storing the interface name as soon as it's done anything
<stgraber> so I had to implement an ugly "touch" to track when it's actually done configuring the interface...
<slangasek> jcastro: old-powertop is in a precise somewhere; powertop-1.13
<jcastro> ta
<mterry> Riddell, heyo.  Would you mind processing precise NEW a bit?  trying to fix some FTBFS that are waiting on packages (notably libbison-dev and python-scikits.statsmodels)
<jelmer> slangasek: hi
<slangasek> jelmer: heya
<jelmer> slangasek: I was wondering if you'd seen my comment on bug 890529 ?
<ubottu> Launchpad bug 890529 in bzr-svn (Ubuntu) "bzr crashed with AssertionError in add(): adding busy connection in pool" [Low,New] https://launchpad.net/bugs/890529
<slangasek> jelmer: hmm, I replied, didn't I?
<slangasek> jelmer: it's an issue with the repository perms
<slangasek> so we just don't get a very friendly error message when that happens
<jelmer> slangasek: you adjusted the importance to low, but didn't reply to my comment with a traceback
<jelmer> slangasek: which is what I'm after mostly :)
<slangasek> jelmer: oh, well, I can provide the traceback if you still need that, I just thought "server perms screwed" would be sufficient :)
<jelmer> slangasek: if you can, that would be useful. I'm curious about the code path - we should already be handling permission dnied errors
<slangasek> jelmer: no traceback now, just an error message - posted to the bug
<jelmer> slangasek: thanks
<stgraber> slangasek: did you have a chance to look at the diff I posted earlier?
<slangasek> stgraber: not yet, sorry
<slangasek> it's still pre-coffee-AM here :)
<stgraber> hehe
<slangasek> mr_pouit: have you seen the xubuntu build failures?  sessioninstaller now conflicts/replaces/provides gnome-codec-install, so gnome-codec-install will need unseeded
<smoser> http://paste.ubuntu.com/739317/ build failure make sense to anyone ?
<smoser> hm.. i guess we need a newer libc6  maybe for perl-base which provides perlapi.
<cjwatson> smoser: that should be fixed once the archive mirrors
<cjwatson> smoser: don't worry about the build failures, I'll fix them all up in bulk
<cjwatson> slangasek,mr_pouit: I fixed that this morning
<cjwatson> oh, not a live-build failure I won't ...
<smoser> cjwatson, no problem. just wanted to let someone know if it was the first report.
<smoser> it'll get sorted out once you sort out packages.
<cjwatson> smoser: we're in the middle of the perl transition, see ubuntu-devel.  I'll let you know once it's a bit further along for you
<smoser> cjwatson, nightly will just keep trying and succeed at some point
<smoser> :)
<cjwatson> we don't need a newer libc6, that was my screwup while staging the first step of the transition
<mr_pouit> cjwatson: yep, I saw the change, thanks :)
<pitti> ah, seems packages gradually get installable again, thanks cjwatson
 * pitti re-retries pkgbinarymangler
<stokachu> has anyone seen this type of error when attempting to build a deb package? http://dpaste.com/656897/
<infinity> stokachu: See the file it points you to.
<stokachu> on reporting the bug?
<stokachu> infinity, ^
<infinity> stokachu: Yes.
<stokachu> ok i did that and it's not a common error with gcc
<infinity> stokachu: Unless you feel the urge to diagnose and fix the segfault yourself, in which case, thanks. ;)
<stokachu> not exactly , didnt know if anyone has run into this issue before
<infinity> stokachu: "this issue" is a segfault in the compiler.  There are many.
<stokachu> ok so no you haven't run into this issue
<stokachu> thanks
<infinity> stokachu: On the other hand, you're using gcc-4.4, it may well be fixed in 4.6.
<stokachu> im building for 10.04
<infinity> stokachu: I run into GCC ICEs all the time.  I don't know if I've seen yours. :P
<infinity> stokachu: What you can do to perhaps work around your specific issue is try different optimisation levels (-O1 or -O0, assuming you were building with -O2 before)
<stokachu> ok ill try that
<mterry> wgrant, hello!  do you know where the source for the ftbfs page is?
<stokachu> vanhoof, im staring through your window, put some pants back on
<cjwatson> pitti: yeah, making decent progress now
<mterry> bdmurray, can you look at bug 459730?  i just had a user bug me about it
<ubottu> Launchpad bug 459730 in rsyslog (Ubuntu) "rsyslog doesn't create /dev/xconsole " [Undecided,Confirmed] https://launchpad.net/bugs/459730
<bdmurray> mterry: yes
<mterry> bdmurray, thanks!
<smoser> mterry, does someone actually want xconsole entry ?
<smoser> or are they just annoyed at the warning
<mterry> smoser, they seem to actually want it?
<seb128> speaking about rsyslog: https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/841085
<ubottu> Launchpad bug 841085 in gnome-utils (Ubuntu Precise) "log viewer lists not log by default (incompatible with rsyslog)" [High,Triaged]
<seb128> if anyone feels like working on that ;-)
<mterry> seb128, if it builds, I don't care about it this month  ;)
<mterry> seb128, find a way to break the build such that I'd have to display the logs to fix it
<seb128> mterry, I can break the build for you if that helps :p
<seb128> ok
<seb128> mterry, yes sir! ;-)
<mterry> seb128, this team isn't having the effect we'd hoped  ;)
<seb128> hehe
<seb128> mterry, you exercice other people creativity toward bug fixing, that's good as well ;-)
<seb128> mterry, I've a new theory "given time any bug can be turned into a build issue", I need to verify if it's true ;-)
<mterry> hehe
<vanhoof> stokachu: :)
<gmargo> I've noticed a problem on the packages.ubuntu.com site.  Someone on #ubuntu-website suggested I ask here.  The problem is that package descriptions are not provided for the Oneiric (or Precise) packages.  For instance, compare http://packages.ubuntu.com/oneiric/coreutils against http://packages.ubuntu.com/natty/coreutils and the omission is immediately obvious.
<slangasek> gmargo: yes, this is because we now ship package descriptions in separate files on the server; please see the contact link on packages.ubuntu.com
<slangasek> (I don't know if this has been reported to the maintainer of that site yet at all; I know the issue is being discussed for packages.debian.org)
<gmargo> I have tried to contact frank@lichtenheld.de (listed address on packages.ubuntu.com) a few weeks back but no reply.  And I don't know about packaging the descriptions - it just simply doesn't make any sense to _not_ describe a package on that package's page.
<slangasek> gmargo: yes, it's a bug not by design
<slangasek> contact> good to know; let me see what I can figure out
<dobey> is the perl brokenness in P fixed up now?
<slangasek> dobey: it's going to take some time before it's fully fixed, because it's a rolling rebuild
<slangasek> it's fixed to the point that the autobuilders can continue making progress, at least
<dobey> slangasek: ok; i uploaded an ubuntuone-client this morning, apparently right as it broke, and it failed to build. was wondering if i could tell it to rebuild, but i don't see how to do that on LP
<micahg> there's also the ubuntu-build utility in ubuntu-dev-tools
<slangasek> I presume there'll be a mass-giveback for packages having ftbfs during the critical window, but let me have a look
<slangasek> micahg: what's that?
<micahg> you can give back builds with it
<slangasek> micahg: presumably only if you also have access to do so from the website, dunno if dobey has that and if that's why he's not seeing the button
<micahg> well, it should work as long as you can upload it
<micahg> if it doesn't, that's a bug
<slangasek> dobey: intltool is known to still be broken AIUI
<micahg> same for th eretry button
<micahg> *retry
<dobey> slangasek: ah, ok
<slangasek> though I've entirely lost the reference to this
<dobey> micahg: i don't have the retry button; i also have issues with edit buttons not appearing next to upstream series links on packages
<slangasek> ah no, found now
<slangasek> dobey: you don't have the retry button here? https://launchpad.net/ubuntu/+source/ubuntuone-client/2.0.0-0ubuntu3/+build/2927706
<slangasek> dobey: but you do have upload rights?
<dobey> yes
<slangasek> dobey: bug in launchpad, please file
<dobey> oh
<dobey> on each arch there is a retry button
<slangasek> ah, yes :)
<micahg> right, since each arch is a separate build
<dobey> there isn't one to rebuild on all archs though :(
<micahg> dobey: ubuntu-build from ubuntu-dev-tools :)
<dobey> micahg: ok, i'll try that
<dobey> but i guess i still have to wait for intltool to be fixed
<slangasek> dobey: oh, it looks like intltool is fixed now after all, so I think you should go ahead and give them back for building
<dobey> oh ok
<slangasek> (tested in a chroot, apt says I can install intltool+perl; that cjwatson works fast)
<slangasek> ok, so what bloated my /usr by 200MB in the last week in precise?
<slangasek> probably something that's not good for the CDs
<dobey> you didn't install the webkit debug lib did you? :)
<slangasek> pitti: ^^ do you happen to know of any major package size increases?  I did see some printing-related package upgrades in the run that ate the space
<slangasek> cups, ghostscript, PPD updates
<slangasek> dobey: webkit debug> heh, certainly not
<dobey> yay, u1client built
<dobey> slangasek: can you accept ubuntuone-client into oneiric-proposed? :)
<cjwatson> dobey: I will be doing mass-retries once I get far enough, yes
<dobey> cjwatson: ubuntuone-client is built successfully in precise now. i already retried it. but thanks, and thanks for fixing the breakage :)
<slangasek> dobey: looking
<slangasek> dobey: no, not possible, you need a different version number for the upload to oneiric-proposed than was used for precise; rejecting instead
<dobey> slangasek: oh really?
<slangasek> dobey: please reupload as ubuntuone-client 2.0.0-0ubuntu2.1
<slangasek> yes, each upload accepted into the archive has to have a unique version number
<dobey> bugger. ok, 2.1 it is
<dobey> slangasek: 2.1 uploaded
<slangasek> ok
<slangasek> bryceh, doko: surely someone else can reproduce bug #863761 without me having to use my primary laptop for it? ;)  From what I can see, it should be reproducible on any system with a sufficiently recent processor and an intel graphics chip
<ubottu> Launchpad bug 863761 in eglibc (Ubuntu) "X crashed with SIGBUS in __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:820" [High,Confirmed] https://launchpad.net/bugs/863761
<SpamapS> slangasek: so, I was looking at but 440179 .. and thinking that there is a simple solutoin.
<SpamapS> solution even
<slangasek> SpamapS: if we want the semantics of 'service $foo restart' to be the same as 'invoke-rc.d $foo restart' wrt job start/stop, I'm ok with that
<slangasek> though it seems low priority to me, since 'service' is a user interface rather than a programmatic one
<SpamapS> slangasek: I think that would help quiet a lot of the "WTF" we see from automated systems.
<slangasek> and users can well do "service $foo stop; service $foo start"
<SpamapS> slangasek: that was going to be my next question. Should we be making 'invoke-rc.d' the recommended automation tool?
<SpamapS> slangasek: many users seem unsatisfied with the "just use stop ; start" answer.
<SpamapS> which has been my default as well
<slangasek> there are times when invoke-rc.d should be used and times that it shouldn't
<SpamapS> so
<SpamapS> we need to have one place to recommend that an automated system use
<SpamapS> /etc/init.d/xxx was that place before
<slangasek> I think you need to clarify what you mean by "automated system"
<slangasek> maintainer scripts are automated; they must use invoke-rc.d
<SpamapS> puppet, chef, cfengine, my wonky bash scripts
<juliank> AFAIK; invoke-rc.d blocks scripts from being run in the chroot, the others don't
<slangasek> /etc/logrotate.d is automated, and must not use invoke-rc.d
<slangasek> juliank: invoke-rc.d doesn't block chroot execution unless you've set it up to do so
<juliank> slangasek: Yes, you can set it up like this. You can't do the same for the rest, right?
<slangasek> standard chroot setup should involve creating /usr/sbin/policy-rc.d that returns 101, and diverting initctl and start-stop-daemon
<slangasek> there's no reason you can't reroute all of these interfaces
<SpamapS> can we ignore chroots for now?
<slangasek> but in general there's nothing running in your chroot that will try to use any of them besides invoke-rc.d *anyway*, so that's sufficient
<slangasek> SpamapS: definitely
<SpamapS> There was a time where puppet could reliably expect that a service named "foo" would be controlled only by /etc/init.d/foo
<juliank> slangasek: With "can" I mean in normal cases. You can obviously do it, but that's not the expected way to do it.
<slangasek> yes it is ;)
<SpamapS> And in turn, that /etc/init.d/foo restart would lead to a service that had just been started (whether by stop/start or by just failing to stop, then starting)
<SpamapS> That is still true for anything carrying the /etc/init.d/foo symlink to upstart-job
<slangasek> others expectations may be flawed in various ways, but if you expect services to be guaranteed not to start in your chroot, you should touch all three of those points
<SpamapS> I had hoped that the service command would be suitable as a place to focus all future service control around.. automated or user-driven.
<SpamapS> With the exception of maintainer scripts which are special.
<slangasek> SpamapS: I think it's right to make /etc/init.d an implementation detail and move this up to the 'service' abstraction
<slangasek> SpamapS: so please go ahead :)
<SpamapS> alright, cool. :)
<SpamapS> I think I'll do some man page tweaking too.
<SpamapS>        service runs a System V init script in as predictable environment as possible, removing most enviâ
<SpamapS> thats not exactly true. :)
<stokachu> how does a deb package build without placing any files in the packages even though they were defined in their respective install files?
<SpamapS> slangasek: assuming we'll skip the merges with Debian for now since they're all related to kfreebsd?
<stokachu> so it sees the files or it would've errored saying so
<mterry> doko, mind if I grab ocaml merge?
<bryceh> slangasek, I'll give it a try once I get a couple of my intel systems on precise.  got a few other things to take care of first
<slangasek> SpamapS: merges of what? sysvinit?
<slangasek> SpamapS: I'm deferring sysvinit merges until I finish my own NMU of it (upstart support in Debian)
<slangasek> SpamapS: you're still on point for the lvm merge, right?
<slangasek> bryceh: ok, no hurry from my side :)
<SpamapS> slangasek: yes, still assigned. :)
<slangasek> SpamapS: ok.  I'm sitting on my hands, but would really like a version of lvm that doesn't complain about /proc/misc on every invocation :)
<SpamapS> slangasek: I'll push the lvm merge up a bit on the stack then. :)
<slangasek> ta :)
<apw> cjwatson, pitti, it seems that some of our kernel binaries are in universe again, at least 2.6.38-13.52 for amd64 and i386
<slangasek> apw: should all the binaries from that version (all flavors, all archs) go to main?
<slangasek> if you don't know, I can work it out
<apw> slangasek, from linux yes all are the same currently
<slangasek> apw: fixing
<apw> slangasek, i am a little confused as i thought rmadison listed /universe aginst things in the wrong place, yet they are in the wrong place in the pool
<slangasek> apw: I can't speak to rmadison's behavior here
<cjwatson> rmadison will reflect what's in dists/
<cjwatson> (by definition; that's its data source)
<apw> slangasek, i suspect this error may be systemic as 2.6.35-31.62 also seem to be over in universe in the pool
<cjwatson> pool/ may contain symlinks between components so you shouldn't treat it as authoritative for this purpose)
<cjwatson> it is systemic, it's a problem with copying out of PPAs
<cjwatson> somebody has to override them into main afterwards :-/
 * micahg thought there was a kernel helper for publishing
<apw> cjwatson, i thought that the helper did that now, clearly not
<apw> looks like 2.6.32-36.79 has fallen in there too
<apw> and 2.6.24-30.96
<apw> no scratch that i think 2.6.24 is ok, as we do have odd ones in there
<apw> bah now i am unsure, i think 2.6.24-30.96 may be wrong for the generics at least, but there are some which belong there
 * slangasek also wishes we had better cleanup of stale binary packages from -proposed
<slangasek> cjwatson: shall I get those other versions as well?
<slangasek> micahg: the kernel helper for publishing set the overrides when we used to send them through the unapproved queue - I don't think we have a new helper that handles the ppa copying
<cjwatson> slangasek: please
<micahg> slangasek: ah, I thought pitti had something for that
<slangasek> well, maybe he does
<slangasek> hasn't been shared with me :)
<micahg> slangasek: copy-proposed-kernel.py in ubuntu-archive-tools
<slangasek> micahg: I don't see anything in that script that fixes the component
<micahg> ah, ok
<Randolph> hi all
<slangasek> Randolph: hello
 * SpamapS takes the plunge and upgrades "the big laptop" to precise
<broder> slangasek: if you're archive-admining at the moment, can i try harassing you again to run the backport-helper script in ubuntu-archive-tools?
<broder> (it's been about 2 weeks since somebody ran it last, based on the outstanding requests)
<slangasek> broder: sorry, I briefly took a look at that last night and found the interface entirely bewildering
<slangasek> I've never seen this program before and can't say my first interaction with it has been pleasant
<micahg> SpamapS: you might want to wait until the perl transition is finished (close to finished)
<broder> slangasek: hmm, ok. i wrote it to match the interface of sync-helper
<slangasek> what's sync-helper? :P
<broder> i see :)
 * slangasek has another look
<broder> as i understand it, backport-helper writes out a file of instructions which you then pass to...mass-sync.py, maybe?
<slangasek> ah
<slangasek> I've never used sync-helper, I just run mass-sync manually
<slangasek> I vaguely recall someone mentioning they were writing a wrapper and also vaguely recall being put off by the interface ;)
<cjwatson> sync-helper is fasntastic
<cjwatson> *fantastic
<slangasek> fÃ¢ntastic
<cjwatson> maybe the UI is a personal thing
<broder> slangasek: i'd be happy to implement whatever interface would make it more likely to get run, if you tell me what such an interface would look like :)
<cjwatson> SpamapS: yeah, I would wait 'til tomorrow, sorry, this is a slightly rough day
<cjwatson> I know it's supposed to work at all times, my powers of archive persuasion slightly failed me today
<broder> slangasek: alternatively, if you'd like, i can run backport-helper and tell you what you need to pass to mass-syncs
<slangasek> broder: well, I run the command and the first thing it shows me is http://paste.ubuntu.com/739628/
<slangasek> which seems to give me 8 options and no guidance
<slangasek> broder: you running it and feeding me commands sounds more likely to result in a favorable outcome :)
<broder> hmm...ok. yeah, that does seem confusing
<broder> the intent is that, because backport requests don't have anything resembling a standardized form, the script has to rely on heuristics to figure out things like package names and such - this is an opportunity to fix when the heuristics go wrong
<broder> of course, since i know what the heuristics are, i always make sure to form the requests in such a way that they will pass :)
<cjwatson> so you hit 's', read the report, use the options to fix up anything that's wrong, hit 'b' to emit backport instruction
<cjwatson> it writes out a file that you pass to mass-sync.py
<broder> it does look like you have a slightly out of date copy of the script - i know cjwatson added rmadison output that's not in your paste
<cjwatson> it automates the "oh my god I have to open 73 firefox tabs and then close all the bugs manually" bit
 * slangasek bzrpulls
<cjwatson> also broder fixed the bad handling of hyphens in package names
<broder> and full stops
<broder> both of which are relevant for the current queue
<broder> the bit in parens is the information that will actually be used in the instructions; i guess that's also not very clear
<slangasek> ah, so 'activity' shows that I'm using the buggy version :)
<broder> yeah
<cjwatson> yep
<slangasek> and does the helper automatically only look at bugs in the correct state indicating the backports team has approved the backport?
<broder> yes. it actually goes one step further and requires that a member of the backports team be responsible for it being in the correct state
<slangasek> nice
<slangasek> ok, backport-helper success
<slangasek> and mass-sync fail
<slangasek> debugging
<broder> oh, crud. i bet you're hitting the issue with multiple backports of the same source package
<slangasek> doesn't look like it
<slangasek> http://paste.ubuntu.com/739641/
<slangasek> running into the error on a package with only one backport
 * broder blinks
<broder> ah. that happens if the url is None
<slangasek> yes
<slangasek> trying to work out why it's none :)
<broder> ...which means that sp.changesFileUrl() didn't return anything
<slangasek> could it be an adverse interaction between the new syncing stuff and the backporting?
<slangasek> the API resource in question is https://api.launchpad.net/1.0/ubuntu/+archive/primary/+sourcepub/2026865
<broder> that seems likely
<slangasek> https://launchpad.net/ubuntu/precise/+source/activity-log-manager/0.8.0-1 states "No changes file available"
<broder> and that looks like a syncpackage'd sync
<slangasek> yes
<slangasek> so I'll skip that one for now
<broder> let me see if i can adjust the backport script to not rely on the changes file, because i don't think we need to anymore
<slangasek> broder: yes please :)
<broder> especially since it's just looking for the .dsc - that should be in .sourceFileUrls()
<slangasek> apw: lucid,maverick,natty kernels all overridden back to main; hardy sounds like it needs more tweaking?
<slangasek> broder: libgdata also affected, skipping
<slangasek> *now* I'm hitting the bug with backporting to multiple suites ;)
<broder> i don't really understand that bug, only that it exists, but if you can describe it and it's something i can help with, i'm always interested in making the backports process smoother
<slangasek> I think it's that the scripts get upset when the .orig.tar.gz it's trying to write to the staging directory on cocoplum already exists
<slangasek> so it could be smarter about checking if it's the same file instead of aborting
<slangasek> not sure if/where the backend code is published however
<broder> it looks like the stuff in u-archive-tools just ssh's to cocoplum and runs /home/lp_archive/bin/sync-backend, so it sounds like that might not be something i can really help with
<slangasek> yeah, it's /home/lp_archive/bin/backport-source-backend for the relevant bits here
<broder> i think bzr:~broder/ubuntu-archive-tools/backpoirt-without-changes-file should fix the syncpackage issue
<bdrung> broder: backpoirt?
<broder> uh, typo on my part - the branch itself os spelled correctly :)
<slangasek> narf poirt
<broder> i'm not IRC'ing from my ubuntu dev box at the moment, so i have to re-type everything :-P
<slangasek> broder: I assume you also meant lp:~ rather than bzr:~ ?
<broder> indeed
<SpamapS> cjwatson: heh, no worries, pre-alpha1 I'll be happy if nothing catches on fire. :)
<SpamapS> and also, I'm dist-upgrading from a local mirror about 24 hours behind
<SpamapS> might have just missed the start of the perl transition
<SpamapS> anyway, time for the dentist
<bdmurray> If I found 2 debian bug reports that are duplicates what is the process for merging them?
<wgrant> mterry: lp:lp-ftbfs-report
<slangasek> bdmurray: if you have devscripts installed and the bts command configured, you can do 'bts forcemerge $bug1 $bug2 # these are the same bug because $reason'; or you can manually send the same command, 'forcemerge $bug1 $bug2' to control@bugs.debian.org.
<slangasek> broder: backports finished, branch merged
<bdmurray> slangasek: thanks what kind of confirmation will I get?
<slangasek> bdmurray: email acknowledgement
<apw> slangasek, thanks for that, i'll get with pitti et al tommorrow to make sure things are ok
<broder> slangasek: thanks. i'll also make a note to try and make the initial UI a bit more friendly and informative
<slangasek> broder: well, I'm over it now so maybe that's no longer an issue ;)
<broder> yes, but you and colin aren't the only archive admins
<slangasek> maybe the others already know how to use it too, dunno
<broder> i think this is the first time since i wrote the script that i caught anybody but cjwatson running it
<doko> slangasek, well, maybe. I don't have this hardware
<doko> mterry, not at all
<slangasek> cjwatson: that libdbd-sybase-perl upload will surely ftbfs
<slangasek> I have 1.14 staged in bzr, dunno if you want to pull it: bzr+ssh://bzr.debian.org/bzr/users/vorlon/libdbd-sybase-perl/trunk/
<cjwatson> slangasek: bulk uploads :)
<cjwatson> slangasek: it's not critical path for anything particular, so it can wait until you have it in Debian
<slangasek> cjwatson: right-o
<SpamapS> slangasek: odd .. doing the lvm2 merge.. tons of conflicts on things that don't appear to be documented changes in the changelog.
#ubuntu-devel 2011-11-16
<SpamapS> I guess so many patches have been applied.. most of upstream's changes are already there. :-P
<slangasek> SpamapS: heh, no clue I'm afraid
<SpamapS> slangasek: this is.. the worst merge ever
<slangasek> my condolences ;)
<SpamapS> half the patches have been upstreamed, half haven't
<SpamapS> all centered around the same 4 or 5 files. :-P
<TheMuso> Does anybody know how often status.ubuntu.com refreshes?
<Riddell> mterry: libbison-dev and python-scikits.statsmodels accepted, sorry for the delay I'm on holiday this week
<SpamapS> rmdir: failed to remove `/var/lib/nfs/rpc_pipefs': Device or resource busy
<SpamapS> slangasek: seen that on trying to upgrade nfs-common?
<cjwatson> Daviey: could you please merge libapache2-mod-perl2 from unstable (or tell me I can do it)?  I think http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636651 is what's causing current build failures with perl 5.14
<ubottu> Debian bug 636651 in src:libapache2-mod-perl2 "libapache2-mod-perl2: FTBFS with perl 5.14: -D_FILE_OFFSET_BITS stripped from CFLAGS" [Serious,Fixed]
<slangasek> SpamapS: gnar; yes and no
<slangasek> SpamapS: I thought I had that upgrade path stable
<slangasek> SpamapS: do you have nfs-kernel-server installed?
<TheMuso> Anybody using irssi in gnome terminal running precise? If so, are you able to use alt + 1-0 and alt q-o to switch between channels?
<StevenK> TheMuso: I've been using Esc-1-0 and Esc-q-o for a long while
<StevenK> But I'm on Oneiric
<TheMuso> StevenK: Right, it worked for me in oneiric. :)
<StevenK> TheMuso: alt-1 and so on switch terminal tabs for me
<TheMuso> StevenK: Right, but I have irssi in a separate terminal window on a separate workspace, and since there are no other tabs, irssi's keyboard shortcuts worked.
<TheMuso> That was oneiric.
<TheMuso> Same setup in precise, but no shortcuts to move between channels.
<TheMuso> StevenK: Turns out something in gtk 3.2.2 in precise changed, requiring a patch to vte.
<TheMuso> So back to normality for me at least, and hopefully for other users of vte if the patch gets committed upstream.
<TheMuso> At which point I'll upload to precise.
<SpamapS> slangasek: yes
<SpamapS> slangasek: I have nfs-kernel-server installed, and I'm still unable to rmdir even with it stopped and portmap and idmapd and basically everything stopped
<pitti> Good morning
<pitti> slangasek: no, none of cups etc. should have increased; the 20111114 images increased by 8 MB compressed due to some duplicated fonts, though; we added fonts-nanum and removed ttf-unfonts-core, but that's 7.5 MB delta only
<pitti> slangasek: yesterday's daily images were back to 702 MB
<pitti> slangasek, micahg: no, I don't have a magic script to check and fix for kernel overrides; in the PPA they are all in "main", and when copying they sometimes randomly go to universe
<pitti> the kernel team has a cron job which yells at us if there are uninstallable packages, but apparently it doesn't pick this up (it looks at universe, too?)
<micahg> pitti: I realized after I said that that it was fixed at one point copying from native PPAs to apply overrides, but it seems to selectively break
<slangasek> pitti: hmm, ok; maybe it was part of something I have here that's not part of the default install then
<slangasek> guess I'll investigate further :)
<pitti> slangasek: perhaps you can salvage your /var/log/dpkg.log before it gets rotated?
<slangasek> SpamapS: should only be nfs-kernel-server, gssd, and idmapd that might need to be stopped; nfs-common's postinst not handling the nfs-kernel-server part of that however
<pitti> I'm not tracking installed size here really, it's well possible that some package grew a lot uncompressed, or some postinst is creating lots of data
<slangasek> pitti: I certainly have plenty of logs, it's sorting through them to figure out what changed in size that's arduous
<slangasek> pitti: revert the workaround> yep, my thinking exactly :)
<pitti> slangasek: haven't had tea yet :)
<pitti> hm, seems I lost my ability to target bugs to a release
<slangasek> !
<infinity> !!
<nigelb> Needs coffee.
<pitti> "You do not have permission to nominate this bug."
<JackyAlcine> nigelb: +1 aye
<nigelb> Expired from some team?
<pitti> not that I know of
<slangasek> pitti: what URL?
<infinity> pitti: Which bug?
<pitti> bug 828415
<ubottu> Launchpad bug 828415 in gnome-themes-standard (Ubuntu Precise) "package gnome-accessibility-themes 2.32.1-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/icons/HighContrast/index.theme', which is also in package gnome-accessibility-themes-extras 2.32.1-0ubuntu1" [Medium,In progress] https://launchpad.net/bugs/828415
<slangasek> pitti: weird
<pitti> I could target it to precise just fine, though
<slangasek> pitti: and you didn't accidentally get logged out?
<pitti> nope
<slangasek> oh
<slangasek> you can target but not nominate?
<slangasek> that's not new then
<infinity> "The Ubuntu release manager is Ubuntu Drivers"... I can't wait for all that to get fixed.
<pitti> just tried to target bug 865199 to lucid, which works
<slangasek> or do you mean that you can target to precise but not to other releases?
<ubottu> Launchpad bug 865199 in apport (Ubuntu Lucid) "apport crashes when /etc/apport/native-origins.d contains any files." [Undecided,New] https://launchpad.net/bugs/865199
<slangasek> ok weird
<pitti> so either it's special to oneiric or to that bug
<slangasek> pitti: worked for me
<pitti> slangasek: ok, thanks; at least I have a task to play with now :0
<micahg> pitti: did your original target to release leave you with lucid in the URL?
<pitti> https://bugs.launchpad.net/ubuntu/precise/+source/gnome-themes-standard/+bug/828415
<ubottu> Launchpad bug 828415 in gnome-themes-standard (Ubuntu Precise) "package gnome-accessibility-themes 2.32.1-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/icons/HighContrast/index.theme', which is also in package gnome-accessibility-themes-extras 2.32.1-0ubuntu1" [Medium,In progress]
<pitti> micahg: yes, indeed; that might be it?
<micahg> pitti: yes, I think there's a bug for it
<pitti> I targetted it to precise before
<pitti> ah, good
<infinity> pitti: Yeah, need to be on the "raw" bug URL.
<infinity> (Or the parent task, or whatever you want to look at it as)
<pitti> at least next time I know where to look
<lathiat> <broken record risk> security.ubuntu.com is having problems .. is this known / where is the right place to report it?
<micahg> pitti: I can't seem to find the bug ATM
<slangasek> lathiat: what's the problem?
<lathiat> slangasek: well i was having no connection.. now it seems to be working but going slowly.. another guy said the same in #ubuntu so wasnt just me
<lathiat> not responding again now for me
<slangasek> (this is a reasonable place to report it)
<lathiat> thought that might be the case
 * micahg is also getting a 500 error
<slangasek> micahg: are you rousing IS or do you want me to?
<micahg> oops, not a 500 error
<micahg> slangasek: if you could please, I'm trying to finish some stuff up
<micahg> it's a connection timed out error
<slangasek> lathiat: believed to be sorted now
<lathiat> slangasek: ok thanks
<pitti> wow, xz FTW; I recompressed langpack-locales orig.tar.gz (3.6 MB), now it's 1.2 MB
<slangasek> pitti: oh, I found my 200MB; it was being eaten by deleted files belonging to running processes ;)
<pitti> hah!
<pitti> "Reboot now and win an extra 200 MB"
<slangasek> never seen it quite that extreme on a daily update
<pitti> who could resist that
<pitti> sabdfl: reducing ccsm unity settings and put the most common one into a "real" settings dialog> +1000!
<mvo> didn't we had "simple-ccsm" at some point for exactly tihs?
<mvo> this
<didrocks> mvo: indeed, but it's not compatible with 0.9 and still, it has too many options
<mvo> didrocks: aha, yeah, I noticed it got removed
<dholbach> good morning
<broder> could i get an archive admin to accept the pdns-recursor packages in hardy bin NEW? (it's just a -dbg package that wasn't there before)
 * broder is going to have to take a backports break after this to earn his archive admin brownie points back
<infinity> broder: Waiting on the PPC build.
 * broder looks again
<broder> oh, huh. i thought everything had finished, but i must have been distracted by the sparc/hppa failures
<broder> sorry about that, then
<infinity> broder: Although, the sparc failure is interesting, since the same version built on lucid/sparc...
<infinity> broder: Oh well.  Backports are a big "who cares" in that arena, I suppose.
<broder> they were certainly much weird failures than i care about as a backporter
<broder> *weirder
<infinity> broder: Without really looking (and now being unable too, thanks LP), I'm going to guess from parisc/sparc failing that it's endian-related, and ppc will also fail.
<infinity> broder: We'll find out, I guess.
<infinity> broder: (I scored up the ppc build to see)
<infinity> broder: But sparc and parisc also have other oddities in common that aren't shared with powerpc...
 * broder nods
<infinity> broder: PPC good, accepting all 5.
<mvo> ev: I haven't used usb-creator in a long time, but the test-disk feature with kvm is just such a awsome idea!
<Daviey> cjwatson: Erm, libapache2-mod-perl2 - slangasek touched it last in Precise.  For future, unless i have a "please merge foo" bug opened and assigned to me indicating it's a complex merge and something is in-progress.. i'll never object to a hijack.
<Daviey> Not quite sure why slangasek did the merge TBH, it was a no-change merge.. :)
<Daviey> Oh no it wasn't, my bad.
<Daviey> I'm a plum.
<Daviey> (Doing the merge now.)
<cjwatson> Daviey: thanks.  I ask because I sometimes get annoyed when people don't ask me so it would be hypocritical not to. :-)
<Daviey> cjwatson: Yeah, you are on my "must ask list" :)
<cjwatson> I just end up with a lot of merges I guess, so higher chance ...
<ev> mvo: you can thank kirkland for the idea :)
<ev> but cheers!
 * Daviey looks at component-mismatches, and cries.
<cjwatson> Daviey: most of it's due to (AIUI) one package pulling in maven; jamespage said he was going to clean that up
<Daviey> cjwatson: Yeah, i imagine it won't be looked at until next week - he's sprinting.
<cjwatson> ah
<Daviey> cjwatson: BTW, the testsuite failed for libapache2-mod-perl2 failing the build.  Annoyingly, it worked in local pbuilder before uploading
<Daviey> Another sample of pbuilder env not matching buildd :(
 * ogra_ wonders what cjwatson did ... i get build failures for x86 images etc but apparently all armel images built just fine tonight .... thats a true novum \o/
<cjwatson> Daviey: I noticed the failure, although have no particular ideas to offer about it :-/
<cjwatson> ogra_: heh
<cjwatson> I assure you it wasn't deliberate
<ogra_> i wonder why though ... armel shouldnt differ in content from x86 and x86 failed on perl stuff
<cjwatson> Ubuntu desktop x86 images built
<cjwatson> there was an x86 build attempt from last night when the perl transition was at a point when it couldn't possibly have worked; ignore that
<ogra_> yesterdays didnt ... i got failure mails from 23:48 here
<cjwatson> yes, that was somebody unidentified doing a manual build for some reason
<ogra_> ah, k
<cjwatson> maybe I should put $SUDO_USER in the log :-)
<ogra_> good idea :)
<ogra_> though its over anyway, who cares :)
<Daviey> cjwatson: i gave back and it worked, non-determinisitic builds \o/
<cjwatson> joy
<Drakeson> Alt no longer sends "Meta" in gnome-terminal since two days ago. Which is frustrating. Alt-f, Alt-b, etc. no longer work.  Is it the same for you?
<brendand> Drakeson - in precise?
<infinity> Drakeson: Fix already uploaded.
<infinity> Drakeson: https://launchpad.net/bugs/890555
<ubottu> Launchpad bug 890555 in gtk+3.0 (Ubuntu) "Alt stopped working as Meta in gnome-terminal with gtk+3.0 3.2.2-0ubuntu1" [Undecided,Confirmed]
<kirkland> mvo: ev: hey guys, thanks for revisiting that idea ;-)
<Drakeson> infinity: Thanks. I looked into gnome-terminal and gtk-3.0 in bugs.launchpad.net, and couldn't find anything related. Guess I should have searched more before complaining here.
<cjwatson> $ change-override.py -c universe -y libperl5.12
<cjwatson> whee
 * ogra_ applauds
<pitti> cjwatson: ah, we can't move everything to 5.14 in precise?
<pitti> I had thought it was NBS now
<pitti> or was that to say "main is done now", and a milestone?
<pitti> (congrats!)
<cjwatson> pitti: precise will be entirely 5.14
<cjwatson> pitti: and yes, that was just to say that all the libperl5.12 users in main are now on libperl5.14 - still universe to go
<pitti> nice
<cjwatson> libperl5.12 is uninstallable so it has to go :-)
<didrocks> congrats cjwatson (and yeah, no more spam in precise-changes ;))
<cjwatson> I wouldn't go that far
<didrocks> :)
<ogra_> didrocks, wail until he does the next haskell run :P
<didrocks> ogra_: heh ;)
<pitti> ev: just updated https://code.launchpad.net/~ev/apport/disable-core-removal/+merge/81974 again with a question, FYI
<stokachu> what package needs to be installed in order to have /usr/lib/pymodules available
<stokachu> in my package build ive enabled dh_pysupport -- does that not put the python libraries in their appropriate directories?
<stokachu> i see them listed in /usr/share/pyshared which is odd to me
<tumbleweed> stokachu: that's how pysupport shares modules between python versions
<tumbleweed> stokachu: you should use dh_python2 these days, pysupport is deprecated
<stokachu> will dh_python2 create /usr/lib/pymodules?
<stokachu> in my chroot that directory doesn't exist and is not in the python sys.path
<stokachu> im using pbuilder to attempt to build this package that has python libraries
<stokachu> so far everything is placed in /usr/share/pyshared but then fails because its not listed in python path
<tumbleweed> it shouldn't be in sys.path. It's a python helper implementation detail
<tumbleweed> stokachu: the maintainer scripts, should provide symlinks into the python path
<stokachu> and dh_python2 will do that?
<tumbleweed> so does dh_pysupport
<stokachu> so dh_pysupport places files in /usr/share/pyshared but where does /usr/lib/pymodules come into play
<pitti> stokachu: just forget that /usr/lib/pymodules/ exists :)
<stokachu> ok
<stokachu> so at what point does sys.path get updated to look in /usr/share/pyshared?
<tumbleweed> stokachu: it doesn't
<tumbleweed> does your package have maintainer scripts, which don't have #DEBHELPER# in them?
<stokachu> yea in my rules file
<tumbleweed> stokachu: no I meant postinst. Can I see the source package? Also maybe this should move to #ubuntu-packaging
<stokachu> ok
<ev> pitti: ah, cheers. I've been knee deep in porting the crash reporter to C.  Will have a look after my team meeting.
<pitti> ev: oh, you are porting the client side apport parts?
<broder> barry: if you want a citation for your port, dbus strings are required to be utf-8 as per the table at http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures
<broder> (the dbus-daemon does verification and will replace code points that don't validate)
<barry> broder: thanks!
<ev> pitti: I had to write a parser for the RFC822 stuff, but this is just the daemon that takes the report and sends it over the wire to the crash database frontend
<ev> you had requested that if it must live forever, that it not be written in python :)
<pitti> ev: right, but I thought we could start this on demand
<pitti> by upstart or cron
<ev> that doesn't appear to be the case
<ev> upstart doesn't have support for inotify watches yet
<ev> or an Internet connectivity event
<ev> I'm happy to spawn it from that with a --single-shot or whatever flag once we have those bits in place
<sladen> on default-route ?
<ev> but I didn't want to block on them
<pitti> ev: or just have a small daemon doing the inotify and spawning the python process
<ev> on actual path to crashdb.ubuntu.com or what-have-you
<pitti> ev: but either way, your call
<ev> pitti: no need to do it that way around - I've already written it (except for the n-m dbus bits, but that's a cakewalk)
<ev> the apport crash format isn't sufficiently complex that I'm worried about having to constantly tune a C parser
<stokachu> _jmp_, :X
<igetroot> what up all
<igetroot> anyone alive in here?
<slangasek> frequently so
<igetroot> i got a quick question..not exactly a development question, for of a glitch i found
<igetroot> atleast i think it's a glitch lol
<igetroot> lets say im an unprivileged user, working on the terminal. if i enter this specific string and hit enter, the console freezes for a second and then gives it a /bin/sh shell w/ root
<igetroot> but it wont respond to commands afterwards
<igetroot> any cmd i enter at the prompt after, just gives me another blank prompt
<igetroot> looks like it only works on ubuntu thus far
<mdeslaur> igetroot: what string?
<igetroot> it'll flood the channel bad if i post it
<igetroot> ill put it on a pastie.org post in 1 sec
<mdeslaur> igetroot: please send an email to security@ubuntu.com
<mdeslaur> igetroot: and this is the wrong channel, please join #ubuntu-hardened if you want to continue talking about it
<igetroot> okay definitely
<igetroot> yeah it will give me a /bin/sh root prompt but no commands seem to do anything
<igetroot> okay thank you :D
<bjsnider> doko_, can we discuss binutils-gold on lucid for a minute?
<dobey> can someone approve my ubuntuone-client upload for oneiric-proposed please?
<mbiebl> bjsnider: binutils-gold can have very negative effects, if the autotools* files aren't very recent
<mbiebl> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554821
<ubottu> Debian bug 554821 in libtool "[libtool] Says that binutils-gold doesn't support -version-script" [Normal,Fixed]
<bjsnider> mbiebl, i have a potential fix for a longstanding bug
<Randolph> hi all
<Fusionite> Hey
<angelo-c> Hi guys, I'm trying to solve bug 773841, I wrote the unity part
<ubottu> Launchpad bug 773841 in unity-place-files (Ubuntu) "\\192.168.1.x opens http:\\192.168.1.x in firefox as opposed to smb://192.168.1.x in nautilus" [Low,Confirmed] https://launchpad.net/bugs/773841
<angelo-c> but when I try to open the smb:// or ssh:// I have this error: Error showing url: The specified location is not mounted
<angelo-c> the same error could be easly reprodeced whit xdg-open smb://192.168.1.2
<angelo-c> bith Unity and Xdg open uses the g_app_info_launch_default_for_uri
<angelo-c> have you any hunts?
<angelo-c> hints?
<angelo-c> there are many bug in lauchpad involving xdg-open
<angelo-c> I tought that xdg-open sould open nautilus, but nothing happens
<angelo-c> anybody out there?
<angelo-c> anybody out there?
<broder> angelo-c: i think most of the people that work on unity hang out in #ayatana, so that might be a better place to ask
<broder> oh, hmm...i missed that xdg-open does the same thing as well
<angelo-c> it's not a bug reletad to ayatana, but xdg-open
<broder> right, i see that
<angelo-c> or better, gnome-open which is called by xdg-open
<broder> actually, it sounds like an issue with gvfs, which is what gnome uses for its "virtual" filesystem stuff
<angelo-c> yes, I think so, I'm digging hard the source but I'm stuck
<broder> i don't know gvfs very well, but i am able to access an smb server if i run "gvfs-mount smb://my/share", and then xdg-open
<broder> i don't know whether you're supposed to have to explicitly mount it first like that
<angelo-c> I think the bug is here, xdg-open should open nautilus for smb or ssh, or mount in advance the
<broder> it seems to me that somebody had a design in their head when they set this up. i would personally try and figure out what that design was before trying to make any changes
<broder> it might be a good idea to ask around in, say, #gtk+ on irc.gnome.org
<angelo-c> the bug is located in this function g_file_query_default_handler in gfile.c, it should mount the path if not mounted
<angelo-c> good idea!
<broder> i think you're making assumptions about somebody else's design
#ubuntu-devel 2011-11-17
<TheMuso> Anybody seen this error with schroot on a recent fres precise install? E: Access not authorised
<broder> TheMuso: is that the thing where you need to generate a key for the temporary local apt repositories?
<TheMuso> broder: No.
<TheMuso> Thats for sbuild, this is trying to use schroot.
<broder> ok. no idea then :)
<TheMuso> Ah right, seems in Oneiric and earlier I was a member of admin, which is listed in the valid groups for my schroots, but I am no longer in that group for precise, so adding myself to sbuild fixed it.
<broder> are we changing the semantics of the admin group or something, or was that just a personal choice on your part?
 * micahg things admin is no longer created in precise
<TheMuso> I don't remember ever adding myself to admin, and I used a schroot.conf snippet from mk-sbuild a while back, so other than adding chroots/overlays to my schroot.conf, I have not changed groups etc.
<TheMuso> micahg: I think you're right.
<micahg> https://launchpad.net/ubuntu/precise/+source/user-setup/1.39ubuntu1
<broder> cool, i had been wondering if we were going to do that at some point
<CrazyThinker> Where can I find ubuntu source code?
<pitti> Good morning
<doko> bjsnider, ?
<dholbach> good morning
<janimo> pitti, morning this ARM kernel SRU has been tested, but I just recently (now) commented on it being validated https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/874264
<ubottu> Launchpad bug 874264 in linux-ac100 (Ubuntu Oneiric) "Sound from speakers does not work" [Undecided,Fix committed]
<janimo> can you please push it to updates when your time allows? thanks
<pitti> janimo: done
<janimo> \o/
<CrazyThinker> What tool can display the inode structure of a system beautifully?
<hrw> does someone know how to force udisks to refresh list of block devices?
<hrw> bug 601351
<ubottu> Launchpad bug 601351 in udisks (Ubuntu) "Does not detect hotplugged storage device" [Undecided,Confirmed] https://launchpad.net/bugs/601351
<pitti> ev: btw, you know that you can reconstruct .crash files pretty easily from LP bugs, using python-apport?
<pitti> ev: we can even get .crash files with core dumps if you get the bugs tagged "apport-failed-retrace"
<ev> ah brilliant, though I do think it would still be worthwhile to have some that are retraceable
<ev> (as mentioned, whether these are manually constructed or come from that data set is up to you)
<pitti> ev: for example, bug 754358 is not exactly bad for testing, it's just not considered good enough for automatic duplication (the way we do it right now)
<ubottu> Launchpad bug 754358 in tomboy (Ubuntu) "Tomboy.exe crashed disabling spell checking: with SIGABRT in g_type_check_instance_cast()" [High,Confirmed] https://launchpad.net/bugs/754358
 * pitti checks the retracer logs whether they already picked up a dupe since yesterday
<pitti> right, seems so; bug 891503 is one example
<ubottu> Error: Bug #891503 is a duplicate of bug #834291, but it is private (https://launchpad.net/bugs/834291)
<ev> pitti: ah, fair play.  I'll just work with that data then.
<pitti> hmm, I looked at a few, and the addresses are differing a lot :(
<pitti> ev: I changed the DC retracer to keep ProcMaps.txt as well; working with offsets in the libraries instead of with absolute addresses might be better after all
<ev> hm, okay
<pitti> I'll do some research, I have nothing urgent to do this afternoon
<pitti> ev: ah, so it seems addresses in the actual executable remain stable, but libraries get relocated at each run; that's what misled me on my quick try at UDS
<pitti> but it's not really a surprise indeed
<ev> phew
<pitti> ev: \o/ offsets FTW (http://paste.ubuntu.com/741116/)
 * pitti goes to turn that into code
<ev> YAY!
<pitti> doing this stuff with a calculator is a bit tedious
<ev> :D
 * cjwatson attempts to construct a reproduction case for bug 891257 that's smaller than "upgrade Steve's laptop"
<ubottu> Launchpad bug 891257 in doc-base (Ubuntu Precise) "package doc-base 0.10.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127" [High,Triaged] https://launchpad.net/bugs/891257
<ev> lol
<cjwatson> I guess if I C-z at a particular point ...
<hyperair> pedro_: ping
<pedro_> hyperair, hello
<hyperair> pedro_: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/744257 <-- please verify if the fix in oneiric-proposed works.
<ubottu> Launchpad bug 744257 in banshee (Ubuntu Oneiric) "banshee crashed on rescanning the library" [Undecided,Fix committed]
<pedro_> hyperair, ok I'll check it in a minute
<hyperair> thanks
<pedro_> you're welcome
<zul> can someone review python-keystoneclient for me please?
<doko> jamespage, do you an idea about the java component mismatches?
<Kalidarn> hi quick question, is thunderbird major releases maintained in between releases?
<Kalidarn> ie 7.0.1 to 8.0 or would i need to wait till Precise Pangolin for support?
<Kalidarn> it appears ppa:mozillateam/thunderbird-stable does not support oneric, and ppa:mozillateam/thunderbird-next as of this morning replaced 8.0 with 9.0b1
<Kalidarn> according to the release notes for 8.0 a couple of security fixes occured
<Kalidarn> Thunderbird 8 closes six security holes. Three of these were rated as critical issues: memory corruption while profiling using firebug, code execution via NoWaiveWrapper and miscellaneous memory hazards have been fixed. The remaining high-risk vulnerabilities include two cross-origin theft bugs and a potential cross-site scripting (XSS) hole.
<jdstrand> Kalidarn: for 11.10, we are following the rapid release, so it will get tbird 8. updates are being prepared.
<Kalidarn> I'd assumed so especially as the I don't like outstanding security issues with my system :)
<jdstrand> indeed
<Kalidarn> thanks for answering my question even though #ubuntu-devel may not have been the correct place nobody seemed to know in #ubuntu or in #thunderbird on irc.mozilla.org :P
<jdstrand> Kalidarn: if you have questions about security, please visit #ubuntu-security (or #ubuntu-hardened, which is the same channel)
<Kalidarn> hmm i might add that to my znc idle listing :)
<Kalidarn> because that is of interest to me.
<feldgendler> hello!
<feldgendler> I'm Alexey Feldgendler from Opera Software
<feldgendler> mvo: I was told I should talk to you about this issue
<feldgendler> I'm responsible for packaging Opera for Debian and Ubuntu.
<feldgendler> i'm currently struggling with the following problem: on every distribution upgrade done by the upgrade manager, our third-party package source that we add to /etc/apt/conf.d gets disabled
<feldgendler> I know it's deliberate
<feldgendler> if the rationale behind this problem is to prevent third-party packages from breaking the upgrade due to e.g. outdated dependencies, fair enough, but is there a way for us to bypass this mechanism?
<feldgendler> we routinely test in all new Ubuntu releases and take care that our dependencies are correct
<feldgendler> worse still, not only do upgrades of Opera get disabled, but also the existing Opera package gets removed as âobsoleteâ, in the worst case leaving the user without a browser
<mvo> hey feldgendler, I'm on the phone right now, but I come back to you in some minutes (once the call is over). ok?
<feldgendler> mvo: sure, thanks a lot!
<jamespage> doko: libcommons-discovery-java switched build system from ant -> maven
<jamespage> I'll fix it up next week - sprinting this week
<Chipzz> feldgendler: if it gets disbaled deliberately, maybe you're simply not *meant* to work around it?
<bjsnider> doko, still there?
<rye> kenvandine, ping, re: bug #874501 - it looks like the SRU for Oneiric for that specific bug is blocked. What's the bug for "Return password results with the most recent result first"?
<ubottu> Launchpad bug 874501 in gnome-keyring (Ubuntu Oneiric) "couldn't prepare to write out keyring" [High,Confirmed] https://launchpad.net/bugs/874501
<kenvandine> rye, ugh...
<kenvandine> rye, there isn't a bug referenced in the upstream Changelog
<kenvandine> however, I would imagine that returning the older entry should never been what is intended and if anything this fixes stuff
<kenvandine> but i am not an expert on gnome-keyring
<rye> kenvandine, mmm... is there atestcase? So that we could file it, test it, provide the test result and give the info on regression potential
<kenvandine> rye, not sure if that would really help in this case... the problem would be determining if anything is actually expecting the older entry
<kenvandine> i think the regression potential is the change in behavior, and maybe other apps depended on the broken behavior
<kenvandine> i doubt that is the case, but it is hard to determine that
<kenvandine> rye, all the other fixes in this release are clear wins... and i suspect this fix could be a good thing too... i doubt anyone expects to get the older result... if they even know that multiple entries are created
<rye> kenvandine, true, I will file a separate bug which can be referenced to
<kenvandine> rye, there was a test included in the upstream commit for it... but I am sure it is just to ensure the latest is returned
<kenvandine> that doesn't help us measure risk of regression
<seb128> you have two options there, revert the commit in the sru or do a "check that nothing you use get broken"
<seb128> the number of keyring users is a reasonable set, the default desktop contains a good part of it
<feldgendler> Chipzz: maybe I can take that as an answer, but not until I understand the rationale
<feldgendler> Chipzz: still, something is wrong if the user installs Opera, then upgrades Ubuntu and loses Opera in the process. I fail to see how this benefits the user.
<dobey> feldgendler: the updater doesn't know whether or not the new release is supported by those archives that were added; or that the packages in the archive for the previous release will necessarily install/work/notbreaktheworld on the new release
<dobey> feldgendler: also, packages shouldn't be adding archives when they get installed
<feldgendler> dobey: I see. so the updater doesn't know if our source is prepared for the new release. but is there a way for us to indicate that?
<dobey> feldgendler: no there isn't
<feldgendler> dobey: before we had automatic addiing of archives, we used to recommend the user a manual prodecure with the same result, and which would have the same problem
<feldgendler> dobey: also, we ask a debconf question before we add our acrhive, so I don't believe we're violating anything
<OdyX> .oO(Making Opera distributable by others would helpâ¦)
<feldgendler> we're working on that
<feldgendler> still, some Debian-based distributions never accept non-free software, so it's a non-option for them
<OdyX> feldgendler: then make Opera DFSG-free. .-p
<Laney> the user can set an environment variable or condifuration option to turn off the disabling
<Laney> and from reading the source I just noticed that the env var has a typo(!)
<Laney> "RELEASE_UPRADER_ALLOW_THIRD_PARTY" in os.environ
<feldgendler> mvo: what can you say about it?
<feldgendler> Laney: I know. that's equivalent to setting AllowThirdParty=True in the update manager config overrides
<geser> feldgendler: have you tried to get opera into the Ubuntu partner archive? that could be one option to avoid getting opera deinstalled on upgraded
<Laney> indeed
<dobey> is the precise release schedule not final yet?
<feldgendler> Laney: however, I tried it and it didn't work. looking at the code, I see that it only keeps the entries that mention the name of the current release as the distro name.
<feldgendler> Laney: the name gets changed to the name of the new release
<Laney> that is what i would expect, yes
<feldgendler> Laney: the whole AllowThirdParty feature seems to be designed for local Ubuntu mirrors (that would use Ubuntu release names) rather than third-party software sources.
<feldgendler> geser: yes, we're working on that. still, Opera would then only appear in multiverse, right? which means that by default, if you download and install Opera by clicking âdownloadâ on the official website, you'll end up with no updates
<mvo> feldgendler: sorry for the delay, indeed, there is a global way to override it
<feldgendler> geser: using a browser which doesn't get updated is risky because of the vulnerabilities that get fixed all the time
<feldgendler> mvo: I'm currently considering the following as a workaround; enable AllowThirdParty=True and mention the current distro name in our source lines
<feldgendler> mvo: that way, the updater will change the distro name to the new release name but otherwise keep our sources intact
<mvo> feldgendler: so there is currently no really good answer, I would *love* to see opera in e.g. archive.canonical.com or integrated via the new developer.ubuntu.com archive so that it could become part of the "official" archive in some way, but I understand that this is not easy from your side
<feldgendler> mvo: we're working on that
<feldgendler> mvo: but see above about downloading Opera from the official website
<geser> feldgendler: the partner repository (partner.ubuntu.com) is different from the multiverse component of the main repositories
<mvo> feldgendler: indeed, that will work, but this will enable third party archives globally, let me have a look at the code to see if we can hve a more fine grained solution. I think the distro release name in the sources.list is a good step, essentially you need a way to tell update-manager that opera is a official mirror
<feldgendler> mvo: I've exlored that possiblity
<mvo> feldgendler: if opera would be in partner/multiverse for all users that have multiverse/partner enabled (that is the default) it would just work, when there is a update that is newer than the version downloaded from the web you would get it
<feldgendler> mvo: but the list of mirrors comes in /usr/share/update-manager/mirrors.cfg which is not a conffile
<mvo> feldgendler: indeed, but I can add you code for 12.04 to make it possible to have additional mirrors :)
<feldgendler> mvo: I would love that!
<feldgendler> mvo: while you're at it, maybe you could remove the disabling of those sources that don't mention an Ubuntu release?
<mvo> feldgendler: do you have a example what your current deb line looks like for me?
<feldgendler> mvo: things like Opera, Skype, Google Chrome don't usually make different builds for different Ubuntu releases. in fact, Chrome has its own releases, and uses âstableâ, âtestingâ and âunstableâ as the release name
<feldgendler> mvo: deb http://deb.opera.com/opera/ stable non-free #Opera Browser (final releases)
<feldgendler> the word âstableâ we use there is arbitrary
<feldgendler> we only have one Opera
<mvo> thanks feldgendler
<feldgendler> we also have this one:
<feldgendler> deb http://deb.opera.com/opera-beta/ stable non-free #Opera Browser (beta releases)
<mvo> feldgendler: thanks, I check the source in u-m now to see what I can do about this and get back to you, ok?
<feldgendler> mvo: sure, thanks!
<Chipzz> mvo: maybe the distro upgrade should output a question along these lines "Hi. You haz 3rd party repository enabled. We recommendz you to disable it in orde nt to break upgrades. Disable yes/no?"
<Chipzz> with a default "Yes"
<pitti> cjwatson, stgraber, mdz, kees, soren: TB is still at 1800 UTC today, i. e. an hour earlier now with winter time?
<cjwatson> damn, I haven't had time to process the doodle output
<cjwatson> yes, I guess so
<stgraber> pitti: I assumed so. Hopefully we'll have a new meeting time after this meeting
<stokachu> _jmp_, o/
<soren> cjwatson: Are my e-mails to the mailing list not getting through? I sent one earlier today about this.
<stgraber> soren: only e-mails I saw today were from Steve and Kate
<pitti> I did a moderation run today
<cjwatson> soren: I've approved your mail now
<pitti> debfx: fontforge-extras> please note that we dno't need to keep a delta for Section: changes, we can fix that in our archive overrides
<SpamapS> slangasek: seen the fervor around bug 856810 ? Seems like people aren't getting /run symlinks maybe?
<ubottu> Launchpad bug 856810 in Linaro-Ubuntu "Boot hangs at "Booting system without full network configuration..."" [Medium,Confirmed] https://launchpad.net/bugs/856810
<debfx> pitti: so I should revert the diff, file a bug and subscribe ubuntu-archive?
<pitti> debfx: I don't actually think that the section will change if you change it in an upload
<pitti> sections are defined when binNEWing
<pitti> (or changing manually)
<pitti> not with every upload, AFAIK
<pitti> at least that's how Debian works, and I'm 90% sure that LP works the same
<pitti> debfx: it's not urgent, just wanted to point out that next time you can just sync :)
<debfx> pitti: if it's not done automatically, who handles section/priority mismatches (especially for packages synced from Debian)?
<cjwatson> nobody :-/
<cjwatson> well, priority mismatches are handled by a script and synced up with seeds
<cjwatson> section mismatches are regrettably unhandled right now
<cjwatson> and pitti is correct AFAIK, changing the section in an upload achieves nothing
<Laney> why isn't the package just used for sections?
<cjwatson> more wrong than average, I think
 * debfx wonders why there is a need to have a different section in the archive vs. package control file
<cjwatson> I believe Debian ftpmasters wanted to be able to shift packages about between sections in bulk without having to wait ages for a load of uploads
<cjwatson> it dates back well over a decade, what do you want of me ...
<pitti> cjwatson: ah, Mon 21:00 UTC -- somehow I was afraid it would be during sleep time :)
<pitti> but oh well, it's only biweekly, no biggie
<slangasek> SpamapS: hadn't seen that one, but <sigh>
<cjwatson> it's not ideal for me either, but it was the best available
<pitti> cjwatson: thanks for doing the poll
<SpamapS> slangasek: it looks like a grouping of dupes around the dbus problems (fixed right?) and a few upset about not being able to use /etc/network/interfaces for certain things
<slangasek> SpamapS: which dbus problems?
<SpamapS> slangasek: I thought there was a problem with dbus and the /run transition
<SpamapS> slangasek: but I may be conflating things :-P
<slangasek> sure, there are a number of things that fail miserably if /var/run isn't properly transitioned, dbus being the most obvious
<infinity> cjwatson: Hrm.  So, debootstrap is still brain-dead in the face of multiple versions of a package, isn't it?
<infinity> cjwatson: (the archive skew fix/workaround means multiples exist in indices, leading to, for instance, armel not being debootstrapable right now)
<cjwatson> oh, hah
<cjwatson> possibly.  although Debian has that same fix/workaround so I'm surprised it hasn't been noticed there ...
<infinity> cjwatson: I'm testing on amd64 right now, cause you'd think it would have the same problem.
<infinity> cjwatson: But basically, debootstrap is picking perl 5.14 and perl-modules 5.12 (despite both versions of perl-modules being in the index).
<infinity> cjwatson: And yeah, amd64 just failed the same way.
<infinity> cjwatson: Which makes sense.
<infinity> cjwatson: (--variant=buildd required to pick up perl, I guess)
<cjwatson> how come old perl-modules is still in the index anyway?
<cjwatson> new perl has been built everywhere for some time
<cjwatson> is it upset that armhf hasn't done it yet?
<infinity> You'd think not, since there's no build record for armhf.
<infinity> But Julian might be in a better position to answer that.
<infinity> Either way, the cruft issue aside, this should probably work.
<cjwatson> agreed ...
<infinity> Or, since dependency resolution is hard at that stage, at least fail in the other direction (always pick the package with the higher sort order)
<cjwatson> it should just pick the newest, yes
<cjwatson> however we don't yet have dpkg --compare-versions ...
<cjwatson> we could pick the last in Packages and trust that it's version-sorted
<cjwatson> (which it apparently is, at least in this case)
<infinity> It's LC_COLLATE=C sorted.
<infinity> As in, it's the order they appear on the filesystem.
<infinity> Which is wrong for certain version comparisons, but 99% right. :P
<cjwatson> we could fix that in LP
<cjwatson> or rather in apt-ftparchive
<cjwatson> it's much better-placed to do version-sorting than debootstrap is
<infinity> Oh, actually, yeah, I was thinking of a raw apt-ftparchive scan without a config and pre-gen indexes.  In LP, it might actually be correct.
<dobey> cjwatson: is the precise release schedule supposed to still be a draft?
<cjwatson> LP presumably gives it a file list
<cjwatson> dobey: -> skaet
<dobey> ah right
<infinity> Yeah, LP gives file lists, so it might be doing the right order anyway.  Would have to dig.
<dobey> skaet: is the precise release schedule supposed to still be a draft? :)
<infinity> But "latest is highest" is normally true for Packages files, except for oddball corner cases anyway. :P
<skaet> dobey, yes,  I still need to apply the changes discussed at UDS
 * skaet getting blueprints wrangled first
<cjwatson> infinity:         files.sort(key=package_name)
<dobey> skaet: ah ok; do you know when that should be done by?
<cjwatson> infinity: so any version sorting is either in apt-ftparchive or by luck
<skaet> dobey:  will be done by planning freeze.   Is there a specific date or some info you need before then?
<infinity> cjwatson: Assuming that maps back to a SQL lookup (and everything in LP does), it's going to end up with a FIFO of versions as they appeared in the tables.
<infinity> cjwatson: But yeah, that's pure luck, not design.
<SpamapS> slangasek: any chance you can upload mysql-5.5 5.5.17-3 to experimental today?
<cjwatson> infinity: files is a python list
<infinity> cjwatson: Yes, but the list came from a table.
<infinity> cjwatson: And since it's only sorting on package name, the version order would remain intact, as retrieved from the DB.
<infinity> cjwatson: I'd assume.
<SpamapS> slangasek: I'd like for it to land there before I upload the merged version to precise and start the libmysqlclient transition.
<infinity> cjwatson: (Still, pure luck)
<cjwatson> infinity: ah, yes, since Python 2.3 list.sort() is guaranteed stable
<infinity> cjwatson: I'm trying to decide if that was sarcasm, or quoting an API ref.  Or both. ;)
<dobey> skaet: i need to set up milestones on all the u1 projects, for releases we're going to make for the cycle, and don't want the dates to change out from under me right after i finish doing it :)
<cjwatson> infinity: the latter :)
<cjwatson>         result_set.order_by(
<cjwatson>             BinaryPackagePublishingHistory.id, BinaryPackageFile.id)
<cjwatson> is what the file list is actually sorted on in the SQL lookup
<cjwatson> (about five levels up)
<cjwatson> so, uh, first published will be first in Packages?  I guess.
<infinity> cjwatson: Yeah.
<skaet> dobey, gotcha. :)  will ping you when I finish with the updates.
<cjwatson> so that should in practice match version ordering
<infinity> cjwatson: Which is more or less right.  But again, only accidentally.
<cjwatson> well, guaranteed right because versions can't go backwards
<cjwatson> although I'll grant you accidental
<infinity> cjwatson: No, but IDs can.
<cjwatson> oh
<dobey> skaet: ok thanks. planning freeze == feature def freeze?
<skaet> dobey, yup.  :)
<infinity> cjwatson: Well, I don't know if they have.  But there's no reason they can't. :P
<cjwatson> can or actually might?technically
<cjwatson> bah
<cjwatson> "technically can or actually might?"
<infinity> Technically can.
<infinity> Actually, dunno.
<dobey> skaet: ok
<infinity> Still, tiny corner case, not terribly concerned.
<infinity> It's also probably possible to publish out of order.
<infinity> But I don't really want to think about that right now.
<slangasek> SpamapS: yeah, I can do that today - can you update the changelog in svn?
<SpamapS> slangasek: done
<SpamapS> wait
<SpamapS> oops
<SpamapS> slangasek: ok, committed now
<mterry> doko, I'm going to merge pari if you don't shout
<adam_g> is there some dh magic that takes care of creating link from /etc/init.d/$somejob -> /lib/init/upstart-job if it hasn't been created in postinst or rules?
<hallyn> adam_g, I think if you just do dh_installinit --upstart-only it does it automatically yes
<adam_g> hallyn: ahhh, will check that. thanks
<hallyn> adam_g, and if you do 'dh_installinit --name xy -pz' I assume the same
<hallyn> iow, I've never had to worry about it.  it's always done it for me
<hallyn> np
<roaksoax> adam_g: if you using dh7 and have the upstart job in debian/<package>.upstart should be done automatically
<adam_g> im looking at a pkg that, via rules, installs both an upstart and a script to init.d.. was scratching my head how the /lib/init/upstart-job gets there
<roaksoax> adam_g: its a symlink that gets handled by dh
<adam_g> yup
<slangasek> adam_g, hallyn: --upstart-only means "there was never an init script with the same name as this upstart job"; it has no effect on whether the symlink is created
<hallyn> slangasek, thx, yeah, that's what i started to think after i spoke up
<slangasek> SpamapS: <cough> test build done; now would you like to update the changelog to point to experimental instead of precise? ;)
<SpamapS> slangasek: HAHAHHA ok ;)
<slangasek> SpamapS: would be best if you also updated the uploader line to be you instead of nobse
<SpamapS> slangasek: did that too
<slangasek> ok cheers
<SpamapS> slangasek: commit just finished
 * SpamapS shakes svn... GO FASTER
 * slangasek shakes svn... BE something else
<SpamapS> slangasek: I will bring up migrating to bzr once the 5.5 dust has settled. :)
<slangasek> :)
<slangasek> SpamapS: OOI, why does libmysqlclient-dev ship /usr/lib/*/mysql/plugin/ha_*_plugin.a?  Is someone going to statically link these plugins?
<SpamapS> slangasek: oh that may be a mistake
<SpamapS> slangasek: I'm not entirely sure
<slangasek> ok
<slangasek> 5.5.17-3 uploaded now
<SpamapS> slangasek: thanks, I'll take a look at the plugin bits
<SpamapS> slangasek: I mean, THANKS!!! btw. ;)
<slangasek> :)
<SpamapS> slangasek: Hm, it seems all those plugin archive files are missing from 5.5 entirely...
<slangasek> heh
<SpamapS> slangasek: may have to ask to have them installed somehow.
<slangasek> pitti: sorry for the procps breakage yesterday, btw... reuploaded now with a better fix
#ubuntu-devel 2011-11-18
<slangasek> SpamapS: Reject Reasons:
<slangasek> libmysqlclient18: lintian output: 'missing-pre-dependency-on-multiarch-support
<slangasek> +', automatically rejected package.
<slangasek> forgot that svn-buildpackage doesn't use debuild so doesn't call lintian :P
<slangasek> SpamapS: so, bumping the debhelper build-dep and setting Pre-Depends: ${misc:Pre-Depends} per http://wiki.debian.org/Multiarch/Implementation is needed here
<Daviey> infinity: Do you think you'll be able to look at bug 759545 before a1?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<slangasek> given that infinity is still bootstrapping armhf, I wouldn't count on it
<Daviey> slangasek: thanks.
<SpamapS> slangasek: ACK, will fix and make sure to run lintian
<slangasek> SpamapS: ta
 * SpamapS slogs through missing/broken perl deps...
<SpamapS> slangasek: so, can we re-use 5.5.17-3 or do we need to bump to 5.5.17-4 ?
<poolie> does USC have an option to install stuff from tarballs or is this user just confused about tarballs vs debs?
<SpamapS> slangasek: anyway, bumped to 5.5.17-4. I'll be in the mountains for the next 3 days, so hopefully this one works. :)
<slangasek> SpamapS: thanks, building
<slangasek> SpamapS: btw, Pre-Depends: ${misc:Pre-Depends} should have been sufficient here, the substition gets expanded to multiarch-support
<slangasek> (so the explicit declaration is a redundant no-op)
<SpamapS> slangasek: *ahhh*
<slangasek> SpamapS: lintian doesn't think much of your debian/copyright. ;) uploading anyway
<infinity> Daviey: What vorlon said.  I might find time, but armhf is everything right now.  And she'll hit me if I say otherwise.
<pitti> Good morning
<pitti> slangasek: no worries, it wasn't a bad breakage; but I thought it was a good candidate/exercise for reversion, as per Rick's new policy
<ScottK> What policy is that?
<pitti> ScottK: "never break precise"
<pitti> ScottK: well, less of a policy, more a set of best practices
<ScottK> So all those times when we broke the development release before were on purpose?
<ScottK> Good thing we have the new policy to avoid it...'
<pitti> if we introduce a regression that breaks daily images or upgrades, and reverting it doesn't make things worse, we sohuld revert
<ScottK> ;-)
<ScottK> Right.  I remember something about that now.
<pitti> and for bigger transitions, we need to come up with a staging area solution (such as using -proposed and running automatic tests against that), but that hasn't been fleshed out fully yet
<ScottK> We could all is "Unstable".
<ScottK> all/call
<pitti> ScottK: we'll never get this perfect anyway, but there have been several situations in the past where breakage has been sitting there for days and weeks, so a little more rigor there is certainly adequate
<ScottK> I agree with that.
<dholbach> good morning
<freeflying> slangasek: procps (1:3.2.8-11ubuntu4) failed again
<slangasek> freeflying: failed how?
<freeflying> slangasek: Errors were encountered while processing: procps
<freeflying> E: Sub-process /usr/bin/dpkg returned an error code (1)
<slangasek> freeflying: not reproducible, need the full error message please
<pitti> I ran my oneiric VM, switched apt to precise, apt-get install procps -> fine
<pitti> freeflying: locally modified conffile perhaps? as a workaround to the previous failure?
<pitti> precise(yesterday) -> precise(today) on my workstation also worked, FTR
<freeflying> slangasek: http://paste.ubuntu.com/742035/
<slangasek> freeflying: is this a chroot?
<freeflying> slangasek: no
<slangasek> hmm
<freeflying> pitti: fresh installation with today's daily build iso, previous was 3.2.8-11ubuntu3
<slangasek> well, that's a pretty generic upstart failure.  What happens if you try to manually run the command from /etc/init/procps.conf?  cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
<freeflying> slangasek: manually run is fine
<slangasek> freeflying: is it a locally modified conffile maybe, like pitti asks?
<slangasek> oh, you said it's a fresh install
<freeflying> slangasek: no
<slangasek> so probably not
<slangasek> :)
<slangasek> freeflying: can you do 'initctl log-priority info', try to configure the package again, and then check /var/log/kern.log for any information from upstart?
<freeflying> slangasek: nothing output to kern.log
<broder> slangasek: ...kern.log? do we even still use that?
<slangasek> don't we?
<pitti> sure we do
<broder> i thought we rolled everything into syslog
<broder> huh. i stand corrected
<slangasek> no, only the things that it's reasonable to merge :)
<pitti> broder: we got rid of /var/log/messages
<pitti> which was really redundant, given sys/auth/kern logs
<slangasek> freeflying: please post a copy of whatever file you have as /etc/init/procps.conf currently; also, please show 'initctl list | grep procps'
<freeflying> slangasek: http://paste.ubuntu.com/742046/
<freeflying> slangasek: initctl list | grep procps
<freeflying> procps stop/waiting
<slangasek> freeflying: well, that looks correct
<slangasek> freeflying: when you ran the command by hand, did it return 0?
<freeflying> slangasek: which one
<slangasek> freeflying: the 'cat ... | sysctl' one
<freeflying> slangasek: yes, return 0
<infinity> cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p - || echo Bollocks.
<cjwatson> SpamapS: which missing/broken perl deps did you run into?  (I have a full report, I'm just interested in which of the 14 remaining problems bit you)
<Mirv> does someone know the definitive list of needed kernel config options to have ureadahead working?
<Mirv> google is not much of a friend this time, or the information is obsolete, or I'm having some unrelated problem. for example it seems CONFIG_ENABLE_DEFAULT_TRACERS is no more.
<dbarth> rickspencer3: ping?
<rickspencer3> hi dbarth
<rickspencer3> s'up?
<dbarth> hi
<ev> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | 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: ev
<highvoltage> dholbach: hey there, edubuntu.org is down and I filed a ticket on RT, do you know if there's anyone in particular I could (or should) poke about that?
<dholbach> highvoltage, #canonical-sysadmin
<dholbach> I'd simply ask in there
<dholbach> highvoltage, and http://edubuntu.org/ works for me
<highvoltage> ah, and so it does for me now. that was fast :)
<zumbi_> ogra_: hi!
<ogra_> hey :)
<zumbi_> ogra_: re ubuntu core, I wonder how gcc cross fits, as it is multiarch, so it links to system libraries
<zumbi_> ogra_: so imagine my product uses distro suite N and my host is suite N+2
<zumbi_> ogra_: if I cross compile my app against multiarch system libraries, it will link to suite N+2
<ogra_> oh, i think that might get you into probs
<zumbi_> ogra_: thats why a sysroot enabled cross tool migh tbe useful
<ogra_> not sure though, hrw is our cross toolchain specialist
<ogra_> and riku 8as i said in the other channel) works on porting packages to cross buildability
<zumbi_> yes, I have contact to these people, I follow what they do too
<ogra_> we also have a spec for that for 12.04 to get a subset of packages cross functional
<ogra_> but i fear you need to use the same release version for both atm
<zumbi_> I just wanted to point out a possible pitfall, now that you seem to be going commercial with it
<zumbi_> I have to say I am very please to see it happening
<ogra_> yeah, it was overdue
<zumbi_> *pleased
<ogra_> we will still go on building the distro natively on the buildds though :)
<zumbi_> sure, cross compiling the debian core from scratch is not easy task
<ogra_> well, its a future target for linaro
<ogra_> some day they will make it :)
<zumbi_> ogra_: as a hobby project, which I have no time for, I wanted to create a mini-core based around busybox and uclibc
<ogra_> well, that will surely get you a lot of trouble if you start using "normal" packages ... the busybox tools are to different in many earas
<zumbi_> that might be interesting for a future milestone too
<ogra_> *areas
<ogra_> iirc that was discussed at UDS ...
<zumbi_> ogra_: surely it would be incompatible with normal packages, but maybe we could find a way to upgrade from uclibc minimal core into eglibc core
<ogra_> what i would do to get a minimal system would just be using update-initramfs turn it into a tarball ;)
<hrw> zumbi_: if you want sysrooted cross toolchain then you can build it ;D
<ogra_> +and
<zumbi_> hrw: yep, thats for sure
<zumbi_> hrw: but I dont think thats the binary based distro mindset
<hrw> yep
<zumbi_> ogra_: uhm.. initramfs rootfs tarball, might be kinda of curious
<ogra_> the prob with these minimal fses is that at some point you want a package tool ...
<ogra_> which in the end forces you to have perl (dpkg) and pathin (apt)
<ogra_> *python
<ogra_> which then bloats the rootfs, no matter how small it was initially
<zumbi_> ogra_: yes, but busybox has dpkg replacement
<ogra_> which doesnt help with maintainer scripts :)
<zumbi_> I got mini python, kernel and uclibc minimal system in 2.5MB :)
<zumbi_> ogra_: indeed, it would require another pool of packages, not compatible with main pool
<ogra_> indeed, but at what compatibility level ?
<hrw> I got x11, wifi, bt, pim, glibc, kernel in 16MB
<hrw> with package management - but not debian/ubuntu
<zumbi_> hrw: thats huge :P
<hrw> zumbi_: ok, I got ~2MB free in this flash too ;d
<zumbi_> hrw: hey.. you and your open embeddish hat :)
<zumbi_> well, I'll have a look to ubuntu core stuff, its great to see it happening
<ogra_> :)
<dantti> cnd: ping
<ogra_> pitti, poke
<ogra_> pitti, looking at http://status.ubuntu.com/ubuntu-precise/ubuntu-arm.html i'm wondering why all WIs from foundation team members show up for https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades in our chart
<ogra_> doko__ and infinity are in ubuntu-arm, but why do mvo's items show up there ?
<herton> pitti: hi, I noted some packages are on universe instead of main, if you can take a look: http://archive.ubuntu.com/ubuntu/pool/universe/l/{linux,linux-lts-backport-natty,linux-lts-backport-maverick} and http://ports.ubuntu.com/pool/universe/l/{linux-ti-omap4,linux-fsl-imx51,linux-ports-meta,linux-meta-ti-omap4,linux-lts-backport-natty,linux-lts-backport-maverick} and http://ports.ubuntu.com/pool/universe/l/linux/ (this last one only the hardy 3
<herton> 0.96 pkgs)
<cnd> dantti, pong
<pitti> herton: meh, one of these days we need to fix this more permanently
<pitti> herton: do you happen to have an automatically generated report for this somewhere, which includes the corresponding releases?
<mterry> doko__, you around?  Curious whether you were going to grab the ocaml merge or whether you want to hand it off
<herton> pitti: unfortunately no, I'm thinking about writing a tool to verify it and produce a report though
<pitti> jdstrand: ^ for example, the security team has a script which yells "archive is broken" on ABI inconsistencies, but unfortunately it doesn't check components
<cjwatson> pitti: there's pocket-mismatches in cocoplum:~lp_archive/dak/, although it has kind of noisy output and I haven't got round to putting it somewhere public yet
<cjwatson> if that helps
<jdstrand> mdeslaur has that script these days
<pitti> herton: I think I caught them all, but might have missed some; need to check again later/after meeting/Monday
<herton> pitti: ok, thanks
<pitti> then pocket-mismatches should have a more useful output again, too
<pitti> and in fact the very ones I just moved aren't even in there
<dantti> cnd: hi, I'm trying to probe the battery status of my apple trackpad/keyboard, and I saw you were the one that added support for it, I see it has a feature 71 that seems to be battery stuff, do you have any hints on how to probe that?
<pitti> ah, it's split by release, nevermind
<dantti> cnd: do I have to code this on hid or is it possible to write some app that can talk to hid directly?
<doko__> mterry, ok, I can do that, will look at it tomorrow
<mterry> doko__, oh sweet, thanks
<mterry> tomorrow is saturday!  I don't want it that bad  :)
<doko__> yeah, have to take care about my mobile contract which was terminated without reason while I was in the US ...
<cjwatson> doko__: bug 891720 needs to be fixed quickly; can you do it, or want me to?
<ubottu> Launchpad bug 891720 in icedtea-web (Ubuntu Precise) "missing replaces between icedtea-next-common, icedtea-netx" [High,Triaged] https://launchpad.net/bugs/891720
<cnd> dantti, I don't really know
<cnd> that comment in the code was from the guy who wrote the magic mouse support
<cnd> I just added magic trackpad support onto it
<cnd> if you have a mac, you can sniff the hid packets and maybe figure it out
<cnd> that's what I did to reverse engineer the input protocol for the trackpad
<cnd> by "have a mac", I mean if you "have OS X"
<dantti> cnd: hmm I don't :P
<dantti> I tried to run it on VBox but didn't worked...
<cnd> dantti, you could try poking at it with different feature report values, but I have no clue how successful you would be :)
<dantti> cnd: right but how do I do that?
<cnd> dantti, modify the hid-magicmouse module
<dantti> as it really seems that if I ask the feature 71 it would report that but I have no clue on how to do that :P
<cnd> or maybe use hidraw somehow
<doko__> cjwatson, need to run to the shop. will do it within the next hour
<dantti> hmm right there is no such nice hid lib.. :P
<dantti> cnd hidraw can be used by an user space app?
<cjwatson> doko__: thanks
<cnd> dantti, I think so
<cnd> I've never used it myself
<dantti> cnd: hidraw or the mouse? :P
<dantti> well probaly the former..
<cnd> hidraw
<cnd> I have both a mouse and a trackpad :)
<dantti> cnd: I have a keyboard and a trackpad, the keyboard I received broken from my boss but it stopped working and I'm not sure if it was because of the batteries, that's why I want this to work...
<hallyn> zul, oh hey, are you piloting this afternoon?
<hallyn> zul,  today is my first turn.  can i co-pilot with you if you do this afternoon?  :)
<pitti> ev: accepted https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-crash-signatures for precise, so that it'll appear in the WI tracker
<hallyn> eh, maybe i'll just focus on virt patches
<Daviey> hallyn: Have you seen, https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch_Pilots ?
<hallyn> Daviey, yup
<hallyn> its what i'm looking through this morning
<SpamapS> cjwatson: I'm still not entirely sure, but one was libsvn-perl .. I did start my dist-upgrade right before the transition, so it was likely a transient problem
<ev> pitti: cheers!
<cjwatson> SpamapS: libsvn-perl is fixed
<SpamapS> cjwatson: update/install forcibly fixd it
<cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/perl5.14.html <- remaining problems
<cjwatson> there's a doc-base upgrade bug (awaiting perl sync) and possibly an update-inetd problem with samba which will be a replay of the previous one; fixes for both in progress
<SpamapS> cjwatson: yeah it seems all of it is working now.
* Topic unset by hallyn on #ubuntu-devel
<hallyn> wtf
* cjwatson changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | 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: ev
<hallyn> cjwatson, thanks
<cjwatson> ~praise topic-diff.pl
<SpamapS> cjwatson: I think the other one was libdbi-perl
<cjwatson> that's fixed too
<SpamapS> cjwatson: which I just now got back by re-installing mysql-client
<cjwatson> you must have been fairly early in the transition
<SpamapS> slangasek: About that copyright file and dep5 ... I think I want to raise a bug in the dep5 format that encourages hyper redundancy.
<SpamapS> slangasek: the missing paragraphs are identical to all the other paragraphs of the same type... so I'm thinking we should be able to just say "Standard GPLv2 header md5sum affaed8daf7af7faf8..." or something like that.
<slangasek> SpamapS: you're supposed to be able to have a stand-alone License: paragraph that other paragraphs can refer to?
<slangasek> SpamapS: but the spec is currently not clear about this, which is one of the things that needs fixed before I'll personally bless the spec
<SpamapS> slangasek: definitely not clear, I read it as License: is always attached to Files:
<SpamapS> slangasek: its possible I could have put this Comment: as the paragraph I suppose..
<SpamapS> Comment: These files fall under the blanket license specified in the file COPYING
<SpamapS> License: GPL-2
<slangasek> SpamapS: Standalone License Paragraph (Optional, Repeatable)
<slangasek> SpamapS: please raise this issue on debian-project, this ambiguity is critical :)
<SpamapS> slangasek: is that new?
<SpamapS> I admit I have not tracked changes to it since I first read it over a year ago.
<slangasek> it may have been rearranged, but it's not new in the past year
<Daviey> dep-'s having ambiguity shocker.
<SpamapS> slangasek: hrm.. ok, well I totally missed the standalone license bits. I think I could save 500 lines in the copyright file with that.
<SpamapS> given that it is 762 lines.. thats significant. :)
 * slangasek nods
<SpamapS> actually I think I already made that optimization
<SpamapS> I just forgot the bit about the standalone license paragraph
<broder> slangasek: gah. vmware just released an update to vmplayer that still has the buggy insserv call
<slangasek> \o/
<slangasek> yes, I meant to buttonhole them at UDS about it and never got a chance
<broder> no, no. it's still broken
<slangasek> that was an ironic \o/, see how the hands list a little bit to the left
<broder> ah, i see that now :)
<broder> the worst part is that the shell script has a comment "# Ubuntu will spew unrelated warnings..  Hide these."
<SpamapS> hrm is there a way to run a single lintian check outside of lintian?
<broder> SpamapS: there's a --tags argument to lintian
<SpamapS> broder: no I just want to run a single check standalone
<SpamapS> broder: like not against a .dsc ..
 * SpamapS curses svn-buildpackage for not being able to build w/ local changes
<broder> SpamapS: i haven't dug into it enough to know for sure, but i don't think lintian is architected to allow that
<broder> but not really sure
<SpamapS> yeah
<SpamapS> easier to just workaround svn-buildpackage's deficiencies
<cjwatson> I'd tend to agree with broder; at the very least you'd have to somehow arrange to run the appropriate collection scripts as well and put their output somewhere
<slangasek> broder: unrelated warnings! awesome
<slangasek> SpamapS: svn-buildpackage --svn-ignore-new
<broder> slangasek: do you remember off the top of your head the LP bug about this? i'm having a hard time finding it
<slangasek> or, bzr branch svn+ssh:// [...] && bzr bd ;P
<slangasek> broder: not off the top of my head, just off the middle of my mail; one sec
<slangasek> broder: bug #858122
<ubottu> Launchpad bug 858122 in sysvinit (Ubuntu Precise) "incomplete migration to /run (shutdown script order has been demolished)" [High,Triaged] https://launchpad.net/bugs/858122
<broder> thanks
<SpamapS> slangasek: does that actually keep local changes?
<slangasek> SpamapS: yes; you do have to 'svn add' any new files before calling it, I think
<zul> hallyn: sure
<dantti> cnd: I'm compiling the mouse module, I'm just not sure about what u8 features means, do you know why it has two values?
<cnd> dantti, they are magical values that make the devices change modes
<cnd> you'll have to figure out the magical values for getting battery information
<dantti> cnd: right my guess is that the value is 71, so it would be __u8 features[] = { 71 };  ?
<cnd> I don't know :(
<cnd> well, yes, what you wrote is correct
<cnd> I meant I don't know if 71 is the value
<cnd> sorry if I sound confused, I'm juggling conversations :)
<dantti> cnd: ok, the features the device returns seems to be so..  also from a report from hadess 71 is reported as Battery_Strength
<cjwatson> jdstrand: we seem to be carrying a patch to iptables introduced by you which installs .la files when Debian doesn't.  this seems like the wrong direction and causes a build failure in collectd (after I fix the first thing it's failing on) - can you explain why it's needed?
<dantti> cnd: the min and max goes from 0 to 100 ... :P hopefully this will work ..
<cnd> cool
<jdstrand> cjwatson: that didn't originate with me, but I merged it. I am assuming you are talking about 9001-build-libipq_pic.la.patch?
<cjwatson> no, I'm talking about one that did originate with you, according to the changelog
<cjwatson> +  [ Jamie Strandboge ]
<cjwatson> [...]
<cjwatson> +  * debian/iptables-dev.install: install lib/*.la in usr/lib
<cjwatson> those files should in general not be installed unless there is a reverse-dependency that hasn't been weaned off them yet
<cjwatson> in this case one of the dependency_libs entries is wrong
<jdstrand> I actually that is from 1.4.3.2-2ubuntu1 in karmic
<jdstrand> from nxvl
<cjwatson> really?  it's not changelogged there
<cjwatson> 9001-build-libipq_pic.la.patch is not a problem
<nxvl> that was a FTBFS IIRC, right?
<nxvl> back around barcelona
<jdstrand> let me put it this way. my intent was to just pull what came before along. If I messed up, please correct it :)
<cjwatson> it's not in http://patches.ubuntu.com/by-release/atomic/ubuntu/i/iptables/iptables_1.4.3.2-2ubuntu1.patch.bz2 either
<cjwatson> (well, there's a .la entry there but it's commented out
<cjwatson> )
<jdstrand> cjwatson: the bottom line is I'm happy to fix it. I can't really explain why it is there
<cjwatson> jdstrand: ok, well, I can take it out and test collectd with the fixed version if you're cool with that
<jdstrand> I should have looked at that more closely during the merge
<cjwatson> just wanted to check it wasn't deliberate
<jdstrand> cjwatson: I'm totally cool with that :)
<cjwatson> ideally I'd like to scan to check it isn't used ...
<jdstrand> cjwatson: ah I remember the history of that changelog entry (1.4.10-1ubuntu1). someone submitted a merge request, but didn't merge a bunch of stuff. I was attempting to give the submitter as much credit as possible, but the parts he missed I put under me
<jdstrand> cjwatson: that doesn't mean that I didn't screw up or that I shouldn't have looked at that bit more closely of course :)
<doko> mterry, ocaml uploaded
<mterry> doko, cool, thanks
<jdstrand> cjwatson: looking at a debdiff between lucid and natty, it looks like I did goof
<jdstrand> cjwatson: and inverted the .a and the .la
<cjwatson> ok - I'm just getting hold of aba's script to test whether it's safe to remove the .la entirely
<cjwatson> or whether we need to just take out dependency_libs
<jdstrand> cjwatson: k, sorry about that
<cjwatson> so I can sort it out once I've done that
<cjwatson> np
<hallyn> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | 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: ev, hallyn
<hallyn> zul, all right, i guess i'll take another stab at this libvirt migration on lucid one
<zul> sweet
<dantti> cnd: do you know where hid_output_raw_report store the return data?
<cnd> dantti, no, sorry
<cnd> I really don't know much about hid
<dantti> cnd: k, thanks
<cnd> I only knew the very least amount to be able to sniff packets using OS X software and then take what was already in hid-magicmouse and rework it for the trackpad
<cnd> dantti, you can ask on the linux-input mailing list
<cnd> that is the best source for answers to questions about hid and input in general
<dantti> cnd: right thanks, if I can't find anything in google or on any other hid driver I'll try that
<dantti> cnd: ok, it's was not output_raw... I should use get_... now I have Gï¿½Dp as %s what do you think?
<hallyn> jdstrand, for bug 869553, are you working on the patch for upstream (and precise), or should I push/test that?  Is regular qa-regresion-testing (with -m to test migration) sufficient, or were you planning to write some new test for it?
<ubottu> Launchpad bug 869553 in libvirt (Ubuntu) "Apparmor prevents KVM tunnelled migration" [High,Triaged] https://launchpad.net/bugs/869553
<hallyn> i'd be nice if I could push the fixes for that and bug 869590 into lucid-proposed together :)
<ubottu> Launchpad bug 869590 in libvirt (Ubuntu Lucid) "KVM migration fails when tunnelled due to parsing error in qemu monitor" [Medium,In progress] https://launchpad.net/bugs/869590
<hallyn> maybe a silly question...  is verifying verification-needed bugs in SRU queue an ok thing to do on patch pilot time?  :)
<hallyn> (it does hold up patches, so I assume so...)
<jdstrand> hallyn: I am not actively working on it
<hallyn> jdstrand, cool, thanks.
<jdstrand> hallyn: feel free to push it upstream
<jdstrand> (and into precise)
<hallyn> ok, will do.
<jdstrand> thanks! :)
<hallyn> (want to finish up with the 0.9.7 merge first;  but that sort of conflicts with the patch piloting way;  so it feels weird :)
<slangasek> hallyn: I don't think anyone's going to slap you for doing SRU verification, though it isn't actually in scope for patch piloting
<hallyn> slangasek, ok, thanks.
 * hallyn biab
<ivacco> help
<slangasek> ivacco: this is not a help channel; you probably want #ubuntu
<ivacco> not, i like information about how contribute for development of ubuntu
<ivacco> i like information about how contribute to development of ubuntu.
<slangasek> ivacco: this is probably a good starting point: https://wiki.ubuntu.com/ContributeToUbuntu
<slangasek> pitti: I think someone in the session for https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-power-consumption volunteered to look into the black/white screen question, do you recall who?
<hallyn> so i gather once i'm done with a patch, i shoud unsubscribe ubuntu-sponsors?
<infinity> hallyn: Doesn't really matter if the bug gets closed.
<infinity> hallyn: (And, on the flipside, if the bug is reopened, only sponsors are in a position to do anything about it, since the original patch submitter obviously doesn't have access to)
<hallyn> well its ending in sru, so closing could still take awhile
<hallyn> ok
<hallyn> won't do that then, thx :)
<infinity> hallyn: See second point.  If the SRU team finds the fix defficient, a sponsor may still need to be involved.
<infinity> ;)
<broder> i'd prefer if sponsors were unsubscribed if a bug isn't blocking on sponsor action
<broder> i think the SRU team generally resubs sponsors when necessary
<infinity> broder: I'm not sure if that theory holds up in practice, but *shrug*... That workflow also sounds sane, if it happens.
<broder> leaving them subscribed clutters the queue, which generally causes the sponsorship process to take longer
<hallyn> right, i was thinking of reducing the clutter;  but OTOH we don't want bugs to get lost...
<broder> when i'm worried about that, i usually subscribe to the bug myself
<hallyn> that's what i was just thinking
<broder> it might not be ideal, but it is generally effective
<hallyn> so i think that's what i'll do.  thanks guys
<hallyn> i can always re-subscribe sponsors if it turns out i failed :)
<hallyn> oh i was worried aobut nothing - i can't do it anyway :)
<broder> i may be unusually allergic to cruft in the queue, though
<tumbleweed> whenever I unsubscribe sponsors, I add a comment saying "if you need us, please re-subscribe us"
<tumbleweed> (well, a little more fleshed out...)
<infinity> "Thank you for using our sponsorship services.  We hope you were satisfied with our product today, and should you need us again, please don't hesitate to re-subscribe us"?
<tumbleweed> heh
<dupondje> pitti: kenvandine: Uploaded fixes for papyon: https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
<ubottu> Launchpad bug 887349 in papyon (Ubuntu Lucid) "Can't login in Windows live acount using empathy" [High,Triaged]
<SpamapS> slangasek: FYI, silenced the lintian warnings about the copyright file for the next upload...
<SpamapS> slangasek: speaking of that.. should the next thing be to merge experimental into precise, and start the libmysqlclient transition?
<SpamapS> slangasek: or do we need a DD to start all the binNMU rebuilds in experimental first?
<slangasek> SpamapS: well, binNMU rebuilds in experimental aren't going to happen on their own, you'd need to talk somebody into doing such a rebuild test; maybe it's more straightforward to do your own rebuild testing, and then discuss with the +1maint team how and when it's best to add that to precise?
<hallyn> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | 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: ev
<SpamapS> slangasek: sorry, I don't really grok the debian release process yet. I'll gladly do a full rebuild test on my own.. but then who is this +1maint team and how would I contact them?
<slangasek> SpamapS: https://wiki.ubuntu.com/PlusOneMaintenanceTeam
<SpamapS> AHHH that
<slangasek> SpamapS: the reason binNMUs don't happen automatically for experimental is that packages don't transition from experimental to unstable without an upload
<slangasek> which means everything would be binNMUed again once the lib hits unstable
<SpamapS> slangasek: right so I'd need to do my own tests, file bugs for things that need changing, and then give people time to fix them in experimental before moving 5.5 to unstable?
<slangasek> that's considered best practice, yes
<SpamapS> sounds reasonable. I'll start a mass rebuild tonight...
<slangasek> because mysql-5.1 is a separate source package, it's technically possible to transition mysql-5.5 to testing before all the revdeps are converted, so I don't think you need to coordinate with the Debian release team on this one
 * SpamapS wonders if Lucas Nussbaum's tools are available for reporting on the results
<slangasek> but for precise, coordination with +1maint is a good idea
<slangasek> SpamapS: I guess you should ask lucas :)
<SpamapS> Yeah I'll do that all next week. Just getting the list of what FTBFS will be useful.
<slangasek> cjwatson: libdbd-sybase-perl and unixodbc-gui-qt both uploaded to unstable
<cjwatson> slangasek: thanks, I'll sync those once LP notices them
<cjwatson> SpamapS: I think we will have space for another transition in precise early next week, if that works for you
<SpamapS> cjwatson: Yes, I'll try to get an intial test rebuild done on my box over the weekend so we can skip obviously broken stuff.
<SpamapS> assuming the wind stops blowing at 40mph tomorrow I won't need my box as I'll be sailing down mammoth mountain.. ;)
<SpamapS> ok no more working ,time to enjoy holidaying
 * slangasek waves
#ubuntu-devel 2011-11-19
<lucas> SpamapS, slangasek: documented in http://wiki.debian.org/qa.debian.org/ArchiveTesting
<Daviey> Anyone around that can bump PPA build scores?
<cjwatson> Daviey: yes, +build URL please?
<Daviey> cjwatson: Two fast building any packages, https://launchpad.net/~davewalker/+archive/cobbler-testing/+build/2937057 / https://launchpad.net/~davewalker/+archive/cobbler-testing/+build/2937080
<Daviey> Thanks muchly
<cjwatson> Daviey: done
<Daviey> cjwatson: \o/ thanks
<SpamapS> lucas: thanks btw. :)
 * SpamapS has decided with 50+mph winds outside and everyone else sleeping, the best way to enjoy the holiday is poking at code :)
<dantti> cnd: the id 71 does not return anything, if I get a mac os how do I get the hid ids?
<cjwatson> SpamapS: geek
 * cjwatson says, doing 63 uploads
<Hobbsee> So, as a future SRU, can someone force the unity plugin to on in ccsm after a dist-upgrade?  Just wasted far too much time asking WTF did unity do with my desktop...
<Hobbsee> apart from that, shiny, well done guys
<Eren> what's the state of this bug: https://bugs.launchpad.net/ubuntu/+source/silc-client/+bug/655311 ?
<ubottu> Launchpad bug 655311 in silc-client (Ubuntu) "Loading silc plugin crashes with error "undefined symbol: server_setup_find_port"" [Medium,Fix released]
<Eren> althought it's said that fix is released, I cannot see it in the repositories (using 10.10)
<slangasek> what is it you're trying to see in the repository?
<Eren> slangasek: the actual fix, as I thought that the fix was put into repository
<slangasek> Eren: the bug log says that it was.  What leads you to think it wasn't?
<slangasek> Eren: note that you have to pull the version of the package from maverick-updates, 1.1.7-1ubuntu0.1
<Eren> slangasek: opps ok :)
<Eren> slangasek: thank you
<rostayob> The fact that --as-needed is default on ubuntu 11.10 breaks the build of half of the software out there. is there a way to revert that?
<Adonai> Satan, El diablo, Shaytan, Sofia Rosengren 32 years, World Class city GÃ¶teborg, she lives in protekted adress,
<Adonai> her father name is Johansson, adress WestmarksgrÃ¤nd 21, 44435 NÃ¶dinge. blond hair, Satan, El diablo, Shaytan,
<Adonai> Jesus is Lord, Tsidkenu the lord of rightoutness
<fishor_> hallo all, i work on uvcvideo driver. my primer interest is troubleshooting some video
<fishor_> issues with uvc devices
<fishor_> are here any one who manage bug for some thing like this?
<fishor_> are there some wishes you have, which will help to manage this kind of bugs?
<fishor_> currently we added debugfs interface to collect some statistic. now i work in "report" interface.
<fishor_> this will give information about state of webcam (running/idle), video format of stream, resolution, frame rate, error count
<fishor_> so if you have some wishes or ideas, you are wellkomme :)
<Chipzz> fishor_: I think #ubuntu-kernel might be a more appropriate place to ask
<fishor_> Chipzz, ok, thanks
<tumbleweed> cjwatson/other archive admins who care: poke to process archive admin syncs
<tumbleweed> should we move these process bugs to using Triaged rather than Confirmed, now that launchpad marks things confirmed by itself?
<cjwatson> I care but have to go out now
<cjwatson> will deal with them later today if nobody else has
<tumbleweed> np, thanks
<slangasek> kirkland: were you involved in making do-release-upgrade run in screen by default?
#ubuntu-devel 2011-11-20
<orogor> hi here
<orogor> anyone would know why after an upgrade to last version i have nor unity nor a taskbar or app menu ?
<orogor> basically i can t launch anything in the gui , i currently tun irssi
<orogor> humm
<broder> orogor: we generally don't do that kind of bug hunting in here. #ubuntu-bugs might be better
<broder> but it's also very late evening for the US and very early morning for europe on a weekend, so there just aren't that many people around
<orogor> haa sorry
<orogor> also do yu know how to swith tab in irssi ?
<orogor> i think i have pm , just can t remember what s the shortcut
<broder> sorry, i've never used irrsi
<broder> *irssi
<orogor> ok
<iceroot> orogor: alt + 1, alt +2 or alt + q to go to the last hilight
<iceroot> sorry, alt + a instead of alt + q
 * lamont pounds his head on the desk trying to figure out (again) how to get firefox out of full screen mode
<Daviey> lag: F11 ?
<Daviey> lamont:
<lamont> Daviey: turns out that if the window is bigger than the screen, well, life sucks since you can't grab the top of the window and drag it down to resize...
<lamont> all of which just confused things with whether it was in full-screen mode, or bigger-than-fullscreen-and-needing-to-be-resized mode
<Daviey> lamont: sucks to be you :)
<Daviey> <-- helpful++
<lamont> heh
<lamont> I just resized the second monitor back to being bigger than the first, and fixed things up by manually resizing.  and once I finish waking up, I'll file a bug
<GG_> Hi, where can I talk to someone about pygtk?
<rptr> GG_: #pygtk ?
<GG_> thanks
<cjwatson> lamont: alt-drag to move, then resize the window once you have a grab handle available?
<ion> In addition to that: F11? Alt-middle to resize? Alt-F5? Alt-F7 to move? Alt-F8 to resize?
<ion> Alt-space or alt-right and âMove Titlebar Onscreenâ?
<hallyn> All right, TODAY is the day that I figure out why ureadahead is the only thing running (beside plymouthd) for 20 seconds
<penguin42> and that is.....
<shnatsel> hello everyone
<shnatsel> since documentation on creating large-scale ubuntu derivatives is severely lacking, I've tried to write down all I learned from you about seeds and germinate and stuff
<shnatsel> here is the result
<shnatsel> OK, looks like I've written down all I know: https://docs.google.com/document/d/1RPPF14h1Sw2gQjGTuZjUIlNHnGrafS8ekhFjJM9MT00/edit
<shnatsel> oops, I was supposed to post just the link
<shnatsel> anyway
<shnatsel> could you please please please have a look at it and correct anything that I got wrong?
<shnatsel> and, the ISO building section is still lacking, because there seems to be no docs on ubuntu iso builds, the blueprint has no activity
<shnatsel> I'd really appreciate any info about it
<shnatsel> added info about specifying repositories just now
<shnatsel> forgot about it initially
<shnatsel> I wonder if Ubuntu CD image team members have a mailing list
<shnatsel> or an IRC channel
<shnatsel> or something
<shnatsel> I want to contact those guys directly so much
<shnatsel> cjwatson: I've tried to write down everything you told me about seeds into a doc, could you have a look at it and correct me where I'm wrong, please? https://docs.google.com/document/d/1RPPF14h1Sw2gQjGTuZjUIlNHnGrafS8ekhFjJM9MT00/edit
<shnatsel> infinity: docs on ISO building are needed badly. I've made a stub, could you please fill in the missing parts? See doc link above.
<tsdgeos> tkamppeter: ping
<mwhudson> \o/ for the offlineimap sru
<lifeless> bdmurray: yo
<lifeless> bdmurray: you are basically the only user of edge.launchpad.net left. Please stop :) Please?
<broder> what's our stance these days on srus for network-protocol updates?
<broder> i'm trying to figure out what to do with bug #852603
<ubottu> Launchpad bug 852603 in Oneiric Backports "Please backport hedgewars (0.9.16-1) from precise to oneiric" [Undecided,Incomplete] https://launchpad.net/bugs/852603
<broder> on the one hand, it's comparatively invasive
<broder> (for an sru, that is)
<broder> on the other hand, appraently network play is broken
<slangasek> broder: I know we do backports for compatibility with network services, but I don't know that anyone's asked for an SRU of that sort yet
<infinity> slangasek: Have we never done an SRU of telepathy/purple/pidgin/etc for broken IM protocol issues?
<infinity> I'd be shocked to discover we haven't.
<broder> i thought i remembered seeing an sru for youtube-dl to deal with youtube changing, but i can't find it
<infinity> broder: I'd say it still needs to apply SRU common sense.  Massively invasive changes usually aren't required for protocol breakage (usually), there may be simple fixes one can backport without picking up new upstream versions.
<broder> apparently they are in this case, because the hedgewars folks break network compatibility pretty regularly
<broder> "Just as an example of just what can change network play. Changing one pixel on one theme object requires a protocol bump, since a hog's movements could be slightly changed."
<infinity> Special.
<infinity> If that's actually true, it may need some deliberation and a rolling SRU exception.
<infinity> I really hate that we even have a precedent for that, though. :/
<infinity> For a network game, however, I suppose I could see the argument.
<broder> i guess i can bounce the bug to ubuntu-sru and see what they think
#ubuntu-devel 2012-11-12
<infinity> slangasek: Drat.  Remember when I said your mountall magicall fixes my "/tmp not ready yet" bug?
<infinity> slangasek: I must have just had a few lucky reboots in a row, cause it's back.
<infinity> slangasek: Which indicates it's a race of some sort, but I'm not sure why there's a race to find a filesystem for something without a mountpoint in the first place. :P
<slangasek> infinity: very good question
<mah454> Hello
<mah454> I need confirm new distro template to apt-add-repository
<mah454> I changed lsb_release
<pitti> Good morning
<FourDollars> pitti: Could you help to review https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595 ? Thanks.
<pitti> FourDollars: yes, can do today
<FourDollars> pitti: Thanks.
<FourDollars> pitti: Could you also help https://bugs.launchpad.net/precise-backports/+bug/1076901 ?
<ubottu> Launchpad bug 1076901 in Precise Backports "Please backport ubuntu-online-tour 0.11-0ubuntu4 (universe) from raring to precise" [Undecided,New]
<pitti> I'm not a backporter, sorry
<FourDollars> pitti: Do you know who can help or what should I do next?
<pitti> AFAIUI the backporter team regularly reviews pending requests
<FourDollars> pitti: I see. Thanks.
<didrocks> hey, can anyone reject https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 please?
<pitti> didrocks: fini
<didrocks> pitti: thanks :)
<pitti> jibel: so, cjwatson and I didn't talk about britney integration of adt yet; however, I spent quite some time to fix two handfuls of failing adt tests
<jibel> pitti, ok. I thought about it last week, and I think I'll have to split the job that triggers the tests in 2 parts, one part which identifies packages to test and the other part will deal with jenkins.
<dholbach> good morning
<jibel> pitti, this way, britney can start the jobs without any dependency on lab's specific bits, and will know which tests have been started.
<pitti> @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: pitti
<zequence> Isn't there a ubuntu sys admin channel here somehwere?
<lifeless> zequence: #canonical-sysadmins perhaps ?
<pitti> $ bzr merge lp:~obounaim/ubuntu/raring/virtualbox/debian-merge
<pitti> Unapplying quilt patches to prevent spurious conflicts
<pitti> bzr: ERROR: Unable to unapply quilt patches for 'other' tree: rmdir: failed to remove `.pc/cve-2012-3221.patch': No such file or directory
<ubottu> Unspecified vulnerability in the Oracle VM Virtual Box component in Oracle Virtualization 3.2, 4.0, and 4.1 allows local users to affect availability via unknown vectors related to VirtualBox Core. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3221)
<pitti> did anyone happen to run into this before and knows how to fix/workaround?
<xnox> pitti: yes.
<apw> do i recall correctly that build essential in raring is now 'correct' that we have less extraneous things in the chroots by default
<xnox> pitti: in the ~/.bazaar/builddeb.conf set "quilt-smart-merge=False"
<xnox> pitti: and then unapply patches yourself in the old branch & the new branch. Commit in both, then merge.
<xnox> pitti: re-push quilt series.
<pitti> what could be easier...
<pitti> so I need to check out two full virtualbox branches, fun
<xnox> probably the package is in 1.0 source package and builddeb got it wrong.....
 * pitti screws it, downloads the diff, applies manually and lets the package importer sort it out
<xnox> pitti: bzr init-repo virtualbox; cd virtualbox
<OdyX> win 23
<xnox> then it's only half the download =)
<xnox> pitti: i tend to always upload and let the package importer sort it out. But I do use bzr for auto-merging most of the stuff for me.
<pitti> xnox: pre-applied patches and I have a deep hate for each other
<xnox> heh
<pitti> I yet have to find a person who gets along with those without sacrificing chicken and screwing it up from time to time
<cjwatson> I do :)
<cjwatson> Not that I think the importer's approach is ideal, but
<xnox> doko_: the reason for python-imaging and python-reportlab is hplip
<xnox> on the cd, that is.
<apw> cjwatson, i think you were working with benc on linux-ppc, i see it ftbfs and (if you arn't already) was planning on trying to fix that to release linux
<cjwatson> apw: I was just processing it through the archive
<cjwatson> apw: Be my guest, though I see he has his own git branch for it
<zequence> lifeless: That's the one. Thanks
<apw> cjwatson, i have his branch indeed, will use that as a base and send it back to him
<pitti> . o O { sponsoring merges as Ubuntu MPs is about as far away from "fun and efficient" as it could be }
<cjwatson> Sponsoring merges is hopeless
<cjwatson> One of the reasons I discourage people from doing that until they can upload directly
<pitti> a nice and clean "current debian - merged ubuntu" debdiff attached to a bug is fine IMHO
<pitti> but hopping through all that "checkout ubuntu, merge, fight with teh quilt patches, etc." until you get to that debdiff is a pain
<xnox> huh?! if you are sponsoring you checkout the sponsoree branch and diff against the tags within that branch.
<xnox> unless it's a horrible mess with forgotten $ bzr add .pc
<pitti> xnox: ah, I guess you could do that if you don't push it back to the official branch anyway
<xnox> pitti: yeap. and you can do $ bzr bd -S to get a source package out of the sponsoree branch. If that doesn't work, throw it back.
<seb128> pitti, I found the launchpad diff mostly useful for those, it's the ubuntu->ubuntu diff basically, so you see "ok, few revisions from debian added, looks good"
<xnox> and there you have your source package with the pristine-tarball regenerated.
<seb128> you just need to filter you the quilt noise when debian added new patches
<pitti> seb128: yeah, but I do want to verify the d->u debdiff, as that's the one which we should minimize
<xnox> pitti: $ bzr diff -rtag:1.0-2
<seb128> pitti, then you are going over sponsoring in fixing it yourself mode ;-)
<pitti> xnox: right, thanks
<seb128> pitti, well I usually read the changelog summary to see the diff
<seb128> "diff", e.g what changes we carry
<pitti> seb128: not necessarily fixing, but I don't want to sponsor merges which have obsolete stuff in them
<seb128> right, I found that the changelog was enough to check the changesets and their validity usually
<seb128> but maybe I check less into details than you do
<cjwatson> pitti: clean debdiff> It depends what you're checking.  That's still a royal pain if the merge is at all complex and you're trying to check whether the merged debdiff actually matches what used to be in the Ubuntu delta
<cjwatson> pitti: I've had too many instances of well-intentioned newcomers dropping patches they don't understand to skip that kind of verification, and it ends up being significantly more work than doing the merge myself
<pitti> cjwatson: I look at both, but the more interesting one is the d->u one for me usually
<pitti> so I guess I go with xnox's approach to only checkout the proposed branch, check the diffs against the tags, and never push it back
<pitti> did that with one branch now, and it's a lot easier indeed
<seb128> pitti, what tag do you check against? the vcs from contributor doesn't have the current debian versions right? e.g no way to do "current debian to proposed update" from the vcs?
<xnox> well. to address cjwatson's concern and pitti's usability I do this. Checkout proposed branch. generate the new d->u diff and u->u diff. But also pull the old d->u diff (with pull-lp/debian-source & debdiff). and then review old d->u & new d->u.
<pitti> seb128: they do have the current Debian version
<pitti> seb128: I guess because the creator of the branch actually used "bzr merge lp:debian/foo"
<pitti> that imports all the tags etc.
<seb128> oh ok, nice
<seb128> quite some don't
<xnox> with the last step, I catch a few "overzealous" preservations: double application of the same patch due to fuzz, and keeping the changelog entries for "actually merged in debian long time ago".
<xnox> seb128: if there is no debian tag, throw the branch a way. It was not a bzr merge, I will not trust it.
<pitti> seb128: e. g. I check out lp:~logan/ubuntu/raring/desktop-base/debian-merge, and "bzr diff -r tag:7.0.0ubuntu2" gives me uâ u, and "bzr diff -r tag:7.0.3" gives me dâ u
<seb128> pitti, xnox: nice tip, thanks
<xnox> (e.g. if the importer is lagging, atleast bzr import-dsc should have been done)
<Laney> why do you need to pull-*-source if you have the old tags in vcs too?
<seb128> I usually end up dgetting the ubuntu and debian versions and doing debdiffs locally
<pitti> that's what I did before, and download the diff from the MP, clean it, and apply it locally
<seb128> when the merge is not trivial, when it's trivial (like most of those from "logan" I usually can ack it from the launchpad diff)
<xnox> seb128: dgetting or pull-[lp|debian]-source $pkg [version|release] ? =)
<pitti> (clean: throw away the "applied patches" portions)
<seb128> xnox: I'm too old school, dunno about those pull tools :p
 * seb128 notes to try those
<xnox> I also do ` | filterdiff -x '*.pc*'
<seb128> pitti, oh, I usually bzr branch the vcs from the submitter and bzr bd --source it
<seb128> pitti, then work from the source package, dput that
<pitti> seb128: yeah, that's what xnox told me as well; I initially tried "bzr merge" and tried to push that back, but that's too brittle
<seb128> take from the discussion: everybody is working using a different workflow
<xnox> pitti: the problem with $ bzr merge, is that it always try to do "merge from debian" e.g. auto-unappy quilt patches. Which doesn't make sence when merging a proposed to-be-sponsored branch.
<xnox> pitti: with those, if they are actually clean. I push them to lp:ubuntu/$pkg. Or do pull/merge with quilt-automerging turned off.
<cjwatson> seb128: Heh, even as an old-schooler, pull-{lp,debian}-source are the best things ever
<seb128> cjwatson, no doubt, I just didn't know about them ;-)
<seb128> too many scripts and I don't keep up with everything which is available there
<seb128> seems like I should ;-)
<pitti> +1 on pull-*-source
<xnox> generally, if the utility is shipped in ubuntu-dev-tools it generally means that "all of your aliases and scripts suck compared to this shiny command line toy"
<cjwatson> Heh
<pitti> I go through dpkg -L ubuntu-dev-tools every 6 months or so, and so far it never failed to surprise me with at least one new cool thing :)
<mlankhorst> xnox: or it's too ugly for ubuntu-dev-tools ;)
<rbasak> pitti: what's the rationale for autopkgtest/dep8 to treat a zero exit status but output to stderr as a failure? Eg. wget prints progress to stderr, so script that calls wget is treated as a failure by default. I guess we could wrap it, but is there a more general answer?
<xnox> rbasak: currently implementation.
<xnox> as in, that's what the currently implementation does from historic reasons dating back to 2007
<pitti> rbasak: I'm not quite sure TBH; it's nice to detect new warnings that weren't there before, but of course it's a bit pointless if your tests are expecting to write stuff to stderr
<xnox> e.g. for desktop apps, launching and having output on stderr is bad, means some errors are present.
<rbasak> How about a "writes-stderr" "restriction"?
<pitti> rbasak: for Python unitest I usually use "unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2))"
<pitti> to fix python's unfortunate default of writing the regular output to stderr
<cjwatson> Or wrap in a script that does 2>/dev/null if you know you never care
<pitti> yeah, a lot of tests do that, too
<rbasak> The thing is if the test does fail, then the output that went to stderr may be useful
<pitti> rbasak: writes-stderr> not sure whether upstream likes that, but seems fine to me
<pitti> rbasak: oh, we do keep that; if stderr is nonempty, you see it as an artifact in jenkins
<rbasak> Yes, but if the workaround is to >/dev/null, then it won't be :)
<pitti> rbasak: 2>&1 is better really
<cjwatson> stderrfile="$(mktemp)"; cleanup () { rm -f "$stderrfile"; } trap cleanup EXIT HUP INT QUIT TERM; run-tests 2>"$stderrfile" || cat "$stderrfile" >&2
<xnox> wget has --quiet option
<cjwatson> Or something
<cjwatson> But yeah, it's often less effort to silence the spurious errors in the first place ...
<rbasak> xnox: yes, but the script that we're calling doesn't (currently) have a --quiet option, so it won't pass through to wget. We're not testing wget - we're testing a script that calls wget
<pitti> if I get along with fixing the output fd of unittest, I usually prefer that; for others, debian/tests/foo doing 2>&1 seems the next best approach
<xnox> rbasak: I see. ok.
<rbasak> cjwatson: that's exactly what I'm suggesting that a "writes-stderr" restriction might do :)
<xnox> I did patch guilt package test-suite to be sensitive on $ADTTMP, which means roughly - we are in autopkgtest environment, use system install, don't do silly things on stderr, but do fail on stderr.
<rbasak> OK, thanks all
<xnox> thinking about the hash-sum missmatch from apt (which I just had on my laptop) - shouldn't apt be smart about those & requeue and try updating that repo again (with custom delta-t & #-retries) before giving up?
<rbasak> It's pretty awkward to fix that within apt
<rbasak> I'm hoping to fix it for good with the by-hash stuff this cycle
<xnox> rbasak: explain why it's awkward to fix that within apt? does it return a different error code on hash-sum missmatch? if it does a wrapper script around apt-get update installed with dpkg-divert, which loops around apt-get update should do it.
<xnox> rbasak: although by-hash stuff is nice, I feel cautious that not all mirrors will support it any time soon.
<rbasak> xnox: inside apt, the code that manages the downloads is extremely twisted and laden with more tech debt than any other project I've ever seen
<xnox> 8) ok.... scary
<rbasak> xnox: an outside wrapper would definitely be far easier. I'm not sure if apt returns a unique return code, but that probably wouldn't be too hard to do (or to parse the stderr)
<xnox> parse the stderr sounds dirty =)) but why not ;-)
<rbasak> Yeah mirrors might take a while to pick it up. Including our own. But the nice thing is that if you care you can implement your own by-hash mirror without upstream support :)
<rbasak> (admittedly that still doesn't solve the problem in the general case)
<xnox> rbasak: where/how are the cloud images generated? I'd like to tinker with a few settings to improve performance and reduce size those.
<rbasak> xnox: utlemming and smoser manage those
<xnox> rbasak: thanks.
<rbasak> I think the scripts that generate them are in LP somewhere
 * xnox wishes lp had "show all activity bzr/revisions/pushes for a person", cause I bet the branch has team owner.
<xnox> rbasak: https://code.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds
<xnox> looks about right?! it's referenced in the build-logs of the cloud-images available for download.
<rbasak> xnox: seems likely. smoser can confirm when he comes online
<xnox> rbasak: yeap, it is right. Referenced in https://help.ubuntu.com/community/UEC/Images
<pitti> @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:
<smoser> xnox, that is not correct any more. unfortunately that document is out of date.
<smoser> https://wiki.ubuntu.com/UbuntuCloud/Images/Publishing is *better*, but still out of date.
<xnox> smoser: hm.. ok. where is _the_ source?
<smoser> well, that url above references just about everything except for reference to live-build branch that we use
<smoser> lp:~ubuntu-on-ec2/live-build/cloud-images
<xnox> ok...
<xnox> thanks
<smoser> http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/misc/ec2-build-on-ec2 does much of it.
<smoser> what were you looking to fix/change?
<xnox> default apt & dpkg settings.
<smoser> as in?
<xnox> maybe it should be in cloud-init instead, I am not sure.
<xnox> do not download description translations, disable i386 multiarch on amd64 images.
<xnox> possibly set lang to C and purge all translations.
<xnox> unless all of this is already done on the recent images.
<xnox> cut's down apt-get update time by more than a half.
<smoser> weell..
<xnox> maybe,  not the lang bit =)
<smoser>  - translations: i dont know enough about how they work to decide if its ok or not. i'm not opposed to it, but it would be a regression for some users i'm sure (being uncultured american, it "works for me")
<xnox> well the fact is that currently you are downloading normal package list & then the en_US translation of the same package list.
<ogra_> why dont run the cloud builds oem-config on first login ?
<xnox> doubling your package list.
<xnox> ogra_: no oem-config. ever on cloud.
<ogra_> xnox, right, but why ?
<xnox> ogra_: we don't want to manually configure 100 instances I spin up for my haddoop. ever.
<ogra_> oh, just have a default preseed
<smoser>  - i386 on amd64 images: i think i've actually tried to do this unsuccessfully.  in the maas ephemeral image (http://bazaar.launchpad.net/~smoser/maas/maas.ubuntu.com.images-ephemeral/view/head:/maas-cloudimg2ephemeral line 251)
<ogra_> only if you dont use that preseed you can manually configure
<xnox> ogra_: well, think of cloud images more as if they are pre-installed for automated usage.
<ogra_> yes, i do
<smoser> ogra_, cloud-init does what you want it to do.
<xnox> ogra_: there is cloud-init which allows you to change settings on first boot.
<cjwatson> You don't download a separate package list for translations, only files containing the different descriptions.
<cjwatson> (point of information)
<ogra_> well, oem-config uses a statndardized way also the installer uses so you get changes automatically
<smoser> - setting lang to C: i'm probably not opposed to that, setting it as a default. cloud-init will change it to en_US on first boot though.
<smoser> unless we also change that.
<smoser> cjwatson, the translation downloads are annoying, though if not needed. especially with S3 mirrors, where the serial small file requests are quite painful.
<xnox> cjwatson: true. but it's a lot of queries to see if they are updated for each component/pocket, isn't it? plus they are useless waste on auto-spinned up instances...
<cjwatson> I don't really care either way.  I was just taking issue with the description.
<smoser> rbasak, was/is going to make apt able to do parallel there, which will allow us to blast S3 very unfriendly-like.
<rbasak> smoser: that a separate thing that I hope to do this cycle to. apt happens to have the logic in there that should make this change easy
<rbasak> that's a separate thing that I hope to do this cycle too.
<smoser> i hope so too
<smoser> :)
 * rbasak learns to speak English
<smoser> for the reader, each http connection to S3 has a large overhead (on the S3 side). as a result, the average download time across some large get like 'apt-get --download-only install ubuntu-desktop' tops out at like 8M/s (maybe 12).
<smoser> but if we parallelize that (with apt-fast), we can saturate a gigabit link.
<smoser> and if S3 doesn't stand up, thats their fault. (especially since amazon explicitly told us that S3 was not designed for lots of little files like apt is doing... after they told us to put mirrors in S3 and ignored my complaints about speed).
<smoser> (and for the record pipelining there has just about zero affect)
<smoser> xnox, so in general, i'm not opposed to any of your changes, but i'm careful in all changes.
<xnox> smoser: I understand. I want to play around with these settings and see if I can still generate images and launch them & check the performance differences.
<smoser> speed of 'apt-get update' is a pretty important thing in my opinion
<smoser> and i'd love for the images to not use i386 on amd64.
<xnox> ack.
<smoser> ogra_, fwiw, you can feed debconf preseed to cloud-init just like you would the installer.
<smoser> cloud-init does not recondifgure anything alreadyy installed (arguably a bug), but new packages installed would then get those preseeds.
<ogra_> does it use the udebs ?
<xnox> no =)))))
<ogra_> link ubiquity/oem-config does
<ogra_> aha
<ogra_> that was actually my point :)
<ogra_> so you dont have to re-implement all these bits all the time when something changes
<smoser> i'm probably just being ignorant, but i have no idea why i would want to use udebs.
<smoser> example of change?
<ogra_> the sudo group
<xnox> hmm... oem-config is meant to be run with tty, where as cloud-init is always unattended.
<ogra_> the point is, by using the udebs you dont have to care for the backend stuff at all, whatever the distro changes will happen there and you just inherit
<xnox> not sure it would be wise to mix the two.
<smoser> i'm not opposed to getting "free stuff"
<ogra_> oem-config runs fine on serial tty's etc and you can preseed it as well as you can any other bit
<ogra_> in which case it wont need a tty
<xnox> amazon cloud does not give you serial tty =)
<ogra_> well, you dont need one if you prseed
<ogra_> but if you can have one and dont preseed you would get a proper fist login configuration
<ogra_> and everything for free without having to poke at backend code ;)
<ogra_> anyway, just wondering ... its not my work area :)
<smoser> i'm not opposed to it in principle, but not convinced of the merrit. the sudo group change sucked, but generally we have very few such things "baked in".
<xnox> ogra_: well.. the "first login" is the problem that cloud-init solves. By default you can't login into ec2 image. You have ssh, but then your ssh key needs to be in the user-account pre-setup.
<ogra_> xnox, right, but where doies the functionality of cloud-init differ from what a reseeded oem-config does ?
<xnox> and clound-init does that funny grub booting as well.
<ogra_> i dont think it does
<ogra_> (differ i mean) ...
<xnox> the way the first user is done and the hostname is different, and apart from locale choice nothing else is common between the two.
<toabctl> can someone please have a look at #1077938, please? maybe that's something for an SRU, too.
<xnox> such that, sure cloud-init can use oem-config, but it would still require to calculate all the values & preseed them to the oem-config which then hopefully will succeed in setting them.
<xnox> it already does the calculation bit, and simply sets them straight away, instead of generating pressed & feeding it to the oem-config.
<xnox> so oem-config would be an extra (un-necessary) layer.
<ogra_> well, it seems just like a lot less work to rely on oem-config/ubiquity/d-i
<ogra_> (which are the same backend wise)
<xnox> but d-i is not used at all on cloud images.
<xnox> so why _add_ it?
<ogra_> ?
<ogra_> i didnt say you shoudl add d-i
<ogra_> just that the backend functions of d-i and oem-config or ubiquity are identical
<ogra_> its all coming out of the same usebs, so you would get distro code changes for free
<ogra_> instead of chacing a rabbit and trying to keep up with what the distro does
<ogra_> less error potential
<ogra_> *chasing
<xnox> i am not aware of any distro changes that are being chased.
<ogra_> well, bits like dropping groups from the default set and the matching transitions for example
<xnox> smoser: did ^^^^ need manual intervention on cloud-init side to handle?
<ogra_> to be consistent you simply need to know exactly what changed in distro plumbing to have it in your code as well
<smoser> we were affected (and had to realize) the sudo group.  it didn't really affect anything though.
<smoser> but there is very little *distro plumbing* baked in to the images, and anything that is, is probably specifically done with intent.
<smoser> the group thing sucked. but creation of that default user is now moved to cloud-init.
<smoser> the images themselves actually have no local user now.
<xnox> smoser: none of which is needed nor wanted in the oem-config.
<xnox> smoser: ok. that's what I was thinking that if $ adduser is used, no need to hard-code the default groups.....
<smoser> xnox, well, its configurable. it has a default list
<xnox> and the default groups come from the deboostrap
<xnox> hmm..
<smoser> i dont really remember. we did (and do) have a hard coded list of groups that the default user is present in. and we were making the 'sudo' group.
<smoser> i forget.
<xnox> ogra_: maybe there is point to dig into cloud-init and see how much stuff can be refactored.
<ogra_> xnox, well, i'm not really after oem-config in cloud setups ... but more after the functionality that ubiquity uses to make use of the udebs
<ogra_> i.e. if you look at the user-setup udeb you wil find it dfoes a lot more than just aclling adduser
<ogra_> *calling
<ogra_> or rather user-setup-allpy which does the actual user creation
<ogra_> *apply
<pitti> jodh: hey James, how are you?
<jodh> pitti: good thanks - you?
<pitti> jodh: fine, thanks!
<pitti> jodh: you said in bug 1075976 that eatmydata was a red herring, so do you still need the --no-eat option?
<ubottu> Launchpad bug 1075976 in upstart (Ubuntu) "test-suite fails in autopkgtest environment" [Undecided,New] https://launchpad.net/bugs/1075976
<ogra_> xnox, wrt default groups ... http://paste.ubuntu.com/1353260/
<pitti> jodh: I'll take the typo fixes in any case of course, thanks!
<xnox> ogra_: well on cloud, we have: ubuntu:ubuntu with password ubuntu, no auto-login, no encryption, system groups + inject ssh key fingerprint into ~/.ssh/authorized_keys.
<jodh> pitti: I think not, so feel free to ignore that MP (sorry - forgot to cancel it)
<pitti> jodh: I like "Lauchpach"!
<ogra_> xnox, right, does printing work ? :)
<jodh> pitti: :)
<pitti> jodh: I'll use it for the typos then; thanks!
<jodh> pitti: thanks!
<xnox> ogra_: the bits about the groups, yes are correct. but creating lpadmin & sambashare is very "desktop" like
<xnox> ogra_: and these are done by those packages anyway.
<ogra_> xnox, right, but the udeb would inherit that stuff even from debian, you would have to care if i.e. debian decides to rename lpadmin to lpadmins
<xnox> ogra_: so the only useful bit in the whole script (from cloud perspective) is the passwd/user-default-groups
<ogra_> -*wouldnt
<xnox> which notice, it does not create the user-default-groups first (unless I missed something)
<ogra_> xnox, i'm talking about maintenance overheard
<ogra_> someone would have to knwo debian renamed the group
<ogra_> and would have to change the cloud-init code manually for it
<ogra_> instead of just inheriting the change
<xnox> the maintainence overhead of keeping the rest of the script working in the cloud image, which doesn't have apt-install and the rest of it.
<xnox> is what I think will be more.
<ogra_> k
<xnox> but we don't know for sure, unless we try =/
<cjwatson> Yeah, I think the duplication is justifiable in this case.
<cjwatson> It doesn't seem worth all the effort of reengineering that, to me.
<toabctl> pitti, can you look at bug 1077938?
<ubottu> Launchpad bug 1077938 in ubuntu-release-upgrader (Ubuntu) "Can not upgrade to development release" [Undecided,New] https://launchpad.net/bugs/1077938
<pitti> toabctl: deferring to mvo, who is our upgrade master
<toabctl> pitti, thx
<pitti> bdrung: hey Benjamin, how are you?
<pitti> bdrung: I have a question for you in bug 1073390
<ubottu> Launchpad bug 1073390 in libarchive (Ubuntu) "libarchive-dev needs a compile/link/run test" [Undecided,Fix committed] https://launchpad.net/bugs/1073390
<toabctl> xnox, any news for bug 1037588 ?
<ubottu> Launchpad bug 1037588 in icu (Ubuntu Raring) "Provide pkg-config pc files" [Wishlist,Triaged] https://launchpad.net/bugs/1037588
<xnox> toabctl: no news, it is ok for this be sponsored in debian-experimental + sync into raring, or upload into raring.
<xnox> heck, it's one liner. can be done.
<toabctl> xnox, seems that the debian maintainer wants to wait until wheezy is released. so we can fix it in ubuntu.
<toabctl> right?
<OdyX> toabctl: or in experimental
<toabctl> OdyX, sure.
<bdrung> pitti: ask.
<seb128> hum, I managed to screw my apt/dpkg dunno how
<seb128> $ LC_ALL=C sudo apt-get install linux-firmware
<seb128> dpkg: error processing linux-firmware (--configure):
<seb128>  package linux-firmware is not ready for configuration
<seb128>  cannot configure (current status `half-installed')
<seb128>  
<seb128> does anyone know how to get out of that state?
<xnox> seb128: $ sudo dpkg --configure -a
<xnox> ?
<seb128> xnox, tried that, no luck
<xnox> =(
<seb128> that returns without doing anything
<xnox> $ sudo apt-get install --reinstall linux-firmware
<xnox> ?
<cjwatson> find the .deb for linux-firmware, dpkg --unpack it, continue
<seb128> xnox, oh, that worked, thanks!
<OdyX> (check disk space on the various partitions inbetween
<seb128> OdyX, did that before ;-)
<xnox> seb128: it's a slightly fancy way of doing what cjwatson suggested ;-)
<seb128> OdyX, I stopped an upgrade my-unpacking by close the wrong win
<seb128> xnox, cjwatson: thanks
<cjwatson> apw: looks like that linux-ppc upload still fails?
<apw> cjwatson, yeah benc is on the case
<BenC> cjwatson, apw: Since it only takes me about 30 minutes, I'm doing a full binary-arch build to make sure this one works (my mistake for messing with d-i related things without testing that on the .3 upload)
 * cjwatson nods
<apw> BenC, thanks
<janimo> slangasek, the consensus seems to be we need to prompt the user with the written license statement when installing nexus7 wifi/bt firmware. Is something better than debconf note to do that?
<shadeslayer> chrisccoulson: got a moment?
<shadeslayer> chrisccoulson: I wanted to talk about ubufox
<soren> pitti, kees, stgraber, cjwatson, mdz: TB meeting in a couple of minutes, right? Wiki says 2000 UTC.
<stgraber> soren: ah yeah, dst change. I'll be there
<cjwatson> soren: available whenever anyone else shows up :)
<slangasek> janimo: if it's an after-install package install, a debconf note is the right way to do it
<slangasek> janimo: not a 'note' actually, but a debconf (boolean) question
<kees> anyone know a good javascript CLI like OSX's "jsc"?
<highvoltage> something doesn't feel right about that sentence
<kees> agreed
<mlankhorst> I guess it makes sense that at one point js replaces bash..
<kees> I was just watching https://www.destroyallsoftware.com/talks/wat again and wanted to see the javascript bits myself
<janimo> kees, nodejs? Not sure what you mean by good though :)
<kees> just stuff where I can type   {} + []  and laugh
<highvoltage> kees: I guess you've seen http://bellard.org/jslinux/ already :)
<mlankhorst> that one was so amusing and scary to run for the first time..
<kees> highvoltage: heh yeah
<pitti> bdrung: I asked on the bug
<pitti> soren: here now
<kees> janimo: yeah, nodejs does the trick!
<pitti> soren, kees, stgraber, cjwatson, mdz: but it's winter time again, so 2100 UTC?
<pitti> I'm still at Taekwondo an hour before
<kees> pitti: not sure. I'm fine to move it later
<stgraber> 2100 UTC works fine for me too
<pitti> perhaps we should define it as 21:00 London time
<kees> yay, my day is complete:
<kees> > Array(16).join("wat" - 1) + " Batman!"
<kees> 'NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman!'
<lifeless> kees: the WAT talk ?
<lifeless> kees: ah yes, classic
<kees> lifeless: yeah, I watch it every few weeks. I got curious about what I could use on Ubuntu that was like "jsc" on OSX
<lifeless> kees: question for you - the bug that the libguestfs FAQ points at about -r mode'd kernels
<kees> though it looks like v8 is less "fun"^W^Wmore consisten
<kees> t
<lifeless> kees: he claims you can read the live kernel, but I wanted to verify - that requires root already, right ?
<kees> yup
<kees> lifeless: if he's got a way to real kernel addresses on a default ubuntu install NOT as the root user, I would consider it a bug.
<kees> s/real/read/
<lifeless> kees: I wonder if we should mark libguestfs as bad somehow then, since installing it lessens security.
<lifeless>  / undoes your hard work
<kees> hrm?
<slangasek> kees: heh, people were criticizing that talk in CPH on the grounds that the examples don't work in nodejs
<kees> slangasek: haha
<lifeless> kees: installing it alters the settings you documented, making vmlinuz world readable
<kees> slangasek: it's clearly undefined behavior manifesting as humor.
<kees> lifeless: O_O
<kees> lifeless: bug #?
<slangasek> so their defense of the language is that the behavior isn't defined, yes :)
<lifeless> kees: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725
<ubottu> Launchpad bug 759725 in linux (Ubuntu) "The kernel is no longer readable by non-root users" [Medium,Won't fix]
<lifeless> is the one where your thing is discussed
<lifeless> do I need to make to libguestfs so that when a sysadmin installs it, it will
<lifeless> change the permissions back to 0644 automatically?
<lifeless> ^ is the author of libguestfs
<lifeless> I am making an assumption that he has followed up and made those changes
<kees> lifeless: well, the act of installing libguestfs shouldn't do the dpkg-statoverride changes -- that's up to an admin.
<kees> as such, if an admin uninstalls, they should undo that fix.
<lifeless> kees: ack
<geofft> Is there an Ubuntu analogue of debian-keyring for PGP keys of individuals (for validating source packages)?
<lifeless> geofft: ubuntu-keyring ?
<geofft> lifeless: ubuntu-keyring looks like the analogue of debian-archive-keyring (PGP keys for signing the archive itself)
<geofft> or am I misreading?
<ScottK> No.  You aren't.  There's no exact analogue.  You'd have to find the key in Launchpad and see if it's owned by a developer.
<BenC> cjohnston, apw: 0.5 ready and uploading
<BenC> cjwatson: ^^
<BenC> cjohnston: oops
<cjohnston> exit
<YokoZar> How do I figure out why my package has been sitting in raring-proposed for over a week?
<tumbleweed> YokoZar: you look in http://people.canonical.com/~ubuntu-archive/proposed-migration/
<infinity> YokoZar: Is this wine, or something else?
<YokoZar> infinity: it is indeed wine, I'm not sure why it is claiming unsatisfiable depends there.  In fact I'm having trouble understanding the output of both of tumbleweed's pages linked.
<infinity> YokoZar: It has unsatisfiable depends because it depends on things outside its architecture.
<infinity> YokoZar: We'll have to hint it one when we're satisfied that it's otherwise sane.
<infinity> YokoZar: As discussed elsewhere, we certainly don't want to allow cross-arch depends as the rule, rather than the exception, or it pretty much breaks the world.
<infinity> YokoZar: (Since you could be out-of-date on an arch, but still migrate due to the dep being satisfiable from another, etc)
<infinity> YokoZar: As it stands, britney has no concept of multiarch (it only examines the packages files for each arch as a self-contained unit), and I'm pretty sure it would be wrong to teach it otherwise.
<infinity> YokoZar: Anyhow.  We'll sort out wine, and see if maybe there's some clever way we can make it an exception to the norm without breaking anything or having to do it manually every time.
<infinity> YokoZar: (Talk to me about it tomorrow, when it's not a day off for me?)
<YokoZar> infinity: That sounds reasonable, thanks.
<bdrung> mdeslaur: libav got a security update, but libav-extra didn't. will it get a security update?
#ubuntu-devel 2012-11-13
<xnox> barry: editor clash? =)
<mdeslaur> bdrung: yes, I was waiting for it to finish building. I'll release it now.
<mdeslaur> bdrung: ok, released now. Sorry for the delay.
<geofft> raof: By any chance do you have a PPA or something with apitrace? or a source package?
<Sarvatt> geofft: https://launchpad.net/ubuntu/raring/+queue?queue_state=0&queue_text=apitrace and http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/apitrace.git
<geofft> Sarvatt: thanks! ... why does pad.lv/u/apitrace not find that? (Was I supposed to be able to find that on my own?)
<RAOF> geofft: Probably because it's in the NEW queue at the moment, so it's not technically in the archive.
<BenC> infinity: How will the indep package(s) get built for linux-ppc?
<pitti> Good morning
<pitti> cjwatson: hmm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html seems stuck?
<pitti> cjwatson: no process seems stuck, and running "bin/run-britney --debug" manually finishes and yields no error; but above page doesn't get updated still
<pitti> cjwatson: is that script now also generating the excuses, or still only generates raring_probs?
<ScottK> pitti: re #u-m you were apparently supposed to chair the non-meeting yesterday, so I was making a poor attempt at a joke.
<dholbach> good morning
<pitti> ah, all channels lighting up, must be dholbach :)
<pitti> dholbach: guten Morgen!
 * dholbach hugs pitti
<soren> pitti: I remember we "left the meeting at the same time slot" last when we switched to DST, but whether that was respective to UTC or to our local time... I'm not sure.
<pitti> soren: binding this to UTC doesn't seem to make much sense really; noone in the TB team is in the southern hemisphere, so binding it to London time seems more sensible
<soren> I'm fine either way.
<pitti> or we really have to make a new time
<pitti> at least for me we keep switching between "impossible" and "really inconvenient"
<pitti> soren: I mailed TB, let's collect some opinions
<cjwatson> pitti: the entry point is run-proposed-migration, not run-britney, and you don't need to run it by hand for this since it logs to proposed-migration/logs/; it's crashing due to (probably) yet another partial-suite-merging bug which I'll look into once I've properly started work
<cjwatson> proposed-migration/log/, sorry
<pitti> cjwatson: ah, thanks! good to know
<cjwatson> I'll probably have to sit down with pdb again
<pitti> rbasak, cjwatson: wrt. our conversation yesterday, it just so happened that I saw a rather good example yesterday why failing on stderr is good at least sometimes: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-libarchive/
<pitti> it succeeds on amd64, so the creator of the test didn't see a problem
<pitti> but it fails on i386 only due to some type incompatiblities
<pitti> (gcc spits out unexpected warnings)
<cjwatson> Agreed
<pitti> rbasak: of course at other occasions it's still unnerving, so one needs to 2>&1 them
<rbasak> pitti: it is certainly useful here. But I'd argue that gcc should be told to fail on warnings here (there's an option for that, right)? In the general case I still think that Unix convention is that the exit status alone tells you whether something succeeded. I'd even go as far as to argue that if anything stderr=failure should be a test option, rather than the default or a requirement for the reverse.
<rbasak> (since status printing to stderr is common)
<pitti> rbasak: yes, it can certainly be refined; I just found it funny that on that very day I found such a case :)
<rbasak> :-)
<pitti> rbasak: so, please feel free to file a Debian bug, so that we can dicuss it with the autopkgtest maintainers
<rbasak> OK, will do
<rbasak> (I do accept that it's debatable)
<didrocks> cjwatson: hey
<cjwatson> Hi
<didrocks> cjwatson: jibel and I are looking at experimenting the workflow with daily automated upload of the PS stack
<didrocks> cjwatson: we need a user logged in into launchpad, its ssh key and the gpg keys for signing and pushing to distro
<didrocks> (even if the last step is disabled until the tests are passing)
<didrocks> to avoid having too many bots, do you think we can use one?
<cjwatson> You don't need a GPG key capable of pushing to distro
<didrocks> ah?
<cjwatson> We agreed you could do that with copies
<cjwatson> Remember?
<didrocks> right
<cjwatson> You need a GPG key capable of pushing to a PPA, but that process should be divorced from copying to the distro
<didrocks> but the source package should be signed in the ppa, with someone having upload access?
<didrocks> oh nice
<cjwatson> So I would actually prefer two bots here
<didrocks> I agree :)
<cjwatson> One to deal with your PPA, and one running as ubuntu-archive@lillypilly that deals with copying into the distro
<cjwatson> If you run launchpadlib as that latter user, it'll run as ~ubuntu-archive-robot
<cjwatson> Which can copy anything into Ubuntu
<didrocks> cjwatson: the copy was part of a jenkins job, so I guess it's getting a little bit more complex
<xnox> and a recipe cannot create the source packages they way it is needed? (to even avoid the gpg key signing bit)
<cjwatson> I'm not at all convinced it would be safe to copy recipe packages into the distro; I'd rather we didn't try to break ground that's quite that new
<xnox> ok.
<cjwatson> didrocks: You could queue it up somewhere for a cron job to process
<didrocks> cjwatson: yeah, we are going that way I think
<Daviey> Not to mention crappy changelog messages. :)
<cjwatson> xnox: It's an interesting idea, certainly, but let's experiment on something that doesn't matter first :)
<xnox> cjwatson: sure.
<cjwatson> Daviey: Well, you could construct a recipe that just worked off a single branch, without the automatic Debian package merging stuff
<cjwatson> (At least in theory; I don't know if that's actually implemented)
<Daviey> cjwatson: true, didn't consider that
<lu_zero> hi
<lu_zero> pitti: ping
<pitti> hello lu_zero
<xnox> persia: thanks for cryptsetup translations =)
<rbasak> "package libldap-2.4-2 2.4.31-1ubuntu2 failed to install/upgrade: trying to overwrite shared '/etc/ldap/ldap.conf', which is different from other instances of package libldap-2.4-2:i386" -- is this a multiarch issue? I've read https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent_files_in_multiarch_packages but am not sure
<cjwatson> Sounds like it.  Any files in Multi-Arch: same packages shared between different architectures at the same version must be bitwise-identical
<lu_zero> pitti: mind if I query you a bit?
<lu_zero> siretart pointed me to you to discuss about udev in ubuntu
<rbasak> Anything special for conffiles?
<cjwatson> I don't think so
<rbasak> OK, thanks
 * rbasak pokes
<cjwatson> But slangasek would know better
<pitti> lu_zero: sure, just ask
<slangasek> rbasak: however, I think I remember there being a bug in dpkg not doing the sensible thing in the event the conffile has been modified on the system
<cjwatson> I don't know if there might e.g. be a bug with locally-modified conffiles
<cjwatson> Yeah
<rbasak> That seems likely here
<rbasak> This is bug 1074777
<ubottu> Launchpad bug 1074777 in openldap (Ubuntu) "package libldap-2.4-2 2.4.31-1ubuntu2 failed to install/upgrade: trying to overwrite shared '/etc/ldap/ldap.conf', which is different from other instances of package libldap-2.4-2:i386" [Undecided,New] https://launchpad.net/bugs/1074777
<rbasak> I presume /etc/ldap/ldap.conf is likely to be locally modified
<slangasek> this was Debian bug #684776
<ubottu> Debian bug 684776 in dpkg "dpkg incorrectly complains about conffile contents being different for MA packages" [Serious,Fixed] http://bugs.debian.org/684776
<slangasek> rbasak: which release are you seeing this on?  Looks like we might want a dpkg SRU
<rbasak> slangasek: 12.04.1 -> 12.10 I think. Just checking now.
<slangasek> rbasak: right; the fixed version of dpkg is only in raring
<rbasak> Ah
<slangasek> rbasak: bug state munged
<toabctl> xnox, can you have a look at bug 1037588 again? and sponsor the package if that's ok for you?
<ubottu> Launchpad bug 1037588 in icu (Ubuntu Raring) "Provide pkg-config pc files" [Wishlist,Triaged] https://launchpad.net/bugs/1037588
<rbasak> slangasek: thank you!
<xnox> toabctl: ok.
<toabctl> xnox, thx
<apw> cjwatson, linux-ppc only build on powerpc, not on 'all' as well is that a packaging error or something outside the package
<cjwatson> apw: all is only ever built on i386
<cjwatson> Why does linux-ppc need to build Architecture: all binaries?
<apw> cjwatson, it has a common headers which seems to be marked : all.  i guess there is no good reason for that in this case
<apw> cjwatson, but does that imply that if a package has no :i386 packages it will not build its :all packages
<slangasek> it doesn't imply that; but the source package does need to successfully build on i386
<cjwatson> There is an argument that this is an LP bug
<cjwatson> It wasn't tried on i386
<slangasek> oh, and that's not due to P-a-s?
<cjwatson> However, in this specific case, it would probably be simplest to just make all the binaries architecture-dependent
<slangasek> yp
<slangasek> e
<slangasek> Ãª
<cjwatson> I'd be surprised if this were due to P-a-s, given that this is an entirely new source package
<apw> cjwatson, right i cannot see why they need to be as it is actually single architecture
<apw> i am just supprised it didn't build there anyhw
<cjwatson> But do file an LP bug about this; right now, it only considers "all" in the .dsc's Architecture field if it doesn't find any other architectures it can build
<cjwatson> I don't think that interpretation is supported by policy, although it's not desperately clear
<apw> cjwatson, will do
<apw> cjwatson, bug #1078266
<ubottu> Launchpad bug 1078266 in Launchpad itself "launchpad only considers architecture: all in a .dsc when there is no other architecture to build" [Undecided,New] https://launchpad.net/bugs/1078266
<cjwatson> ta
<cjwatson> pitti: fixed proposed-migration (britney2-ubuntu r319)
<cjwatson> apw: BTW I don't know if you noticed but linux migration is also blocked on linux-lowlatency
<AquaL1te> i'm running ubuntu 12.04 on a lenovo x220. i can't properly shutdown/power on if there is no network connection and AC power connected. downgrading the network manager worked to fix the power on. shutdown problems still persist, i changed the timeouts in /etc/init/failsafe.conf to max 15 seconds. no result. it keeps hanging in the plymouth animation. any help? is this a known problem? no logs can be found since it probably hasn'
<AquaL1te> kernel upgrade didn't work either
<Sweetshark> doko: anything from my side blocking to proceed with bug 1017125 as a SRU for quantal?
<ubottu> Launchpad bug 1017125 in boost1.49 (Ubuntu Quantal) "[SRU quantal] boost::unordered_multimap<>::erase(iterator, iterator) broken in boost1.49" [High,New] https://launchpad.net/bugs/1017125
<Sweetshark> pkg is on chinstrap
<doko> Sweetshark, I did upload
<Sweetshark> doko: ah, awesome. sorry.
<Sweetshark> doko: I was drowed in upstreaming our stuff so did watch it.
<doko> Sweetshark, or did you already prepare the quantal package?
<Sweetshark> doko: ETA this week.
<doko> it's uploaded to raring only afaics
<Sweetshark> ah,
<Sweetshark> doh
<Sweetshark> the boost quantal package
<Sweetshark> yes, the boost quantal package is on chinstrap and the debdiff is on the bug
 * Sweetshark thought you were talking about a libreoffice 4.0 upload for raring first.
<AquaL1te> i guess i'll just use debian...
<doko> Sweetshark, now uploaded to quantal ... I think you did only ping me about the raring upload, or I didn't see the second ping
<xnox> doko: is it _both_ boost1.49 and boost-mpi-source1.49 packages?
<Sweetshark> doko: yes, sorry for the confusion, I should have been more explicit.
<doko> xnox, no. Sweetshark: ^^^
<xnox> otherwise uninstallable mpi package are introduced.
<xnox> Sweetshark: doko: cjwatson had to upload the matching boost-mpi-source1.49 into raring to migrate it.
<xnox> Sweetshark: doko: which is not ideal.
<BenC> cjwatson: How will the "all" packages get built for linux-ppc?
<pitti> cjwatson: \o/ thanks!
<Sweetshark> I didnt see anything about the boost-mpi-sources.
<Sweetshark> xnox: what would be a better way to handle it then?
<xnox> Sweetshark: boost1.49 is split into two source packages in ubuntu.
<xnox> Sweetshark: the one in main builds all package, but those that build-depend on mpi.
<xnox> Sweetshark: the boost-mpi-sources is an exact copy of the boost1.49, except it builds those bits that build-depend on mpi.
<cjwatson> BenC: apw and I talked about this a couple of hours ago
<xnox> Sweetshark: as we keep mpi in universe.
<xnox> Sweetshark: so grab the boost-mpi-source1.49 package and apply your boost1.49 debdiff & adjust changelog to keep them matching.
<Sweetshark> xnox: yikes. nasty.
<xnox> Sweetshark: see raring's boost-mpi-source1.49 as an example.
<Sweetshark> xnox: will do.
<slangasek> fortunately that split can go away once ArchiveReorg is done
<xnox> s/once/if/ =)))))
<BenC> cjwatson: I wasn't on IRC then..what was the verdict?
<slangasek> xnox: your skepticism in the face of resourced blueprints wounds me
<xnox> slangasek: well... depends how we will agree to keep the build-closure. cause my understanding was that we still want mir-like process to be included in the supported set which needs closed build-dependency loop.
 * Sweetshark translates that to: .oO( slangasek: I find your lack of faith disturbing ...)
<slangasek> xnox: no, the closure will be over binary packages only
<xnox> slangasek: so "once" sounds very automatic, "if" makes more neutral, as in some work will still be needed to remove the split.
<xnox> slangasek: oh, in that case it's all good.
<xnox> slangasek: ok. thanks for correcting me.
<cjwatson> 13:20 <cjwatson> BenC: It's LP bug 1078266, but really there's not a lot of point in those binaries being architecture: all in the first place
<ubottu> Launchpad bug 1063188 in Launchpad itself "duplicate for #1078266 Launchpad doesn't try to build the "all" packages if i386 isn't in the Architecure field" [Low,Triaged] https://launchpad.net/bugs/1063188
<siretart> xnox: that sounds similar to libav / libav-extra
<cjwatson> BenC: ^- dunno if you saw that - I was disconnected
<BenC> cjwatson: There is in the main package, but I can see it isn't really needed for the architecture specific one like linux-ppc
<BenC> Going to require some rewiring to make it binary-arch for just the non-master builds...
<slangasek> BenC: there's probably prior art here, in the form of the various arm-specific kernel sources
<slangasek> linux-ti-omap4, for instance
<BenC> slangasek: I'm hoping for something I can push back to the linux master branch so alternate kernels don't have to reimplement this again :)
<slangasek> (and hmm, why is that source package still present in raring, sigh)
<slangasek> BenC: right, having it sensibly merged in master would be nice :)
<apw> BenC, i believe this is already coped with ... specifically for arm etc
<seb128> hum, https://launchpad.net/ubuntu/+source/gegl is "interesting"
<seb128> "0.2.0-2ubuntu1 	release, proposed (main)"
<seb128> the build on armel failed
<seb128> so it didn't migrate out of proposed
<seb128> the armel builders got removed since
<seb128> is it ok to let it in this state?
<cjwatson> seb128: let me debug that please - that shouldn't matter
<cjwatson> because proposed-migration isn't considering armel at all
<seb128> cjwatson, ok, thanks
<cjwatson> eh
<cjwatson> no, you've misdiagnosed that :)
<seb128> oh?
<seb128> well, it's both release and proposed
<cjwatson> it *has* migrated out of -proposed, but there's a set of LP timeouts that mean it can't currently be removed from -proposed
<seb128> so something happened :p
<cjwatson> those are being worked on
<seb128> oh ok
<seb128> good
<cjwatson> but you can entirely ignore this
<seb128> great, thanks!
<cjwatson> once the timeouts are gone I'll clean everything up
<bdrung> mdeslaur: thanks.
<BenC> cjwatson, apw: linux-ppc with the arch-all override has been uploaded
<cjwatson> Thanks
<cjwatson> apw: Is somebody handling linux-lowlatency, do you know?
<barry> mterry: toabctl was pinging me about bug 1076186.  last week i uploaded an sru fix to quantal-proposed (though it's still sitting in the unapproved queue).  i see that you applied the patch to lp:ubuntu-release-upgrader trunk, thanks for that!  should we upload 1:0.192 (trunk) to raring or were there other things you wanted to get into that branch (i ping you instead of pitti or mvo 'cause you touched it last :)
<ubottu> Launchpad bug 1076186 in ubuntu-release-upgrader (Ubuntu Quantal) "not possible to upgrade to raring" [High,In progress] https://launchpad.net/bugs/1076186
<mterry> barry, I don't have other queued up fixes.  Though it's not urgent itself for raring (though I guess you're asking because SRUs like to see it fixed in devel version?)
<barry> mterry: yep
<barry> mterry: i'm happy enough to upload from lp:u-r-u
<mterry> barry, OK, thanks!
<barry> mterry: np!
<smb> barry, Now this is scary. I just was falling over the same and had the same resolution... :-P
<barry> smb: synchronicity is a weird thing ;)
<roaksoax> jdstrand: howdy! So we have started looking into SRU'ing maas features in precise to completely drop the use of cobbler. However, we have to SRU two new packages to precise-updates. So I was wondering what's the process I should follow to satisfy the security team?
<smb> barry, Especially when you start to ping about it just while I am not looking while searching launchpad (well google) for a already reported bug and ending on the very same... :)
<barry> smb: blame toabctl :)  he pinged me on it, and i had to restore those brainbits from backup tape ;)
 * smb expects the agents any time soon...
<barry> mterry: pre-build.sh requires apt-btrfs-snapshot :( :(
<mterry> barry, just to have it installed, I don't think you need btrfs
<barry> mterry: yeah, i'm just grousing.  i remember weird apt-get update complains when apt-btrfs-snapshot was installed.
<xnox> barry: non-fatal =)
<xnox> mterry: well in ubiquity we have pre-build that downloads source packages and extracts / repackages them, such that it's not needed to be installed.
<xnox> mterry: and then the embedded copy is also in the source tarball of ubiquity =))))
<mterry> barry, oh yeah, you'll get a warning during apt-get upgrade
<xnox> (well we do a lot more than just copy the files we do monkey-patching as well as other stuff....)
<barry> mterry: yep
<cjwatson> We don't do any monkey-patching in the versions in ubiquity's source tarball; that's all done at build time
<cjwatson> (Well, apart from removing some large files we don't need)
<xnox> there is always small print =)))))
<Laney> stgraber: did you forget to remove the templates from the 'lxc' package?
 * Laney got a file conflict upgrade failure :-)
<stgraber> Laney: hmm, let me check... I triple-checked the package replaces/breaks/... but not so much the actual content...
<stgraber> ah, and my test machine had my PPA enabled so I never actually tested the new packages... that'd explain why I didn't notice it...
<Laney> heh
<stgraber> Laney: yep, confirmed, files are in both packages... fixing
<stgraber> Laney: uploaded
<Laney> \o/
<Laney> ta
 * mightyiam azzking wherez his Raring kernelz
<BenC> How do I amend a bzr commit so it shows my correct commuter?
<BenC> *commiter
<cjwatson> BenC: uncommit, fix config, recommit
<apw> cjwatson, yeah i will be handling it
<infinity> BenC: Oh, regarding your question earlier about how a ppc-only package will build indep packages, the answer is "it won't".
<mfisch> seb128: ping
<infinity> BenC: Does linux-ppc need to be generating indep bits? :/
<apw> infinity, we have that prob. under control i believe
<infinity> apw: Ahh, good.
<BenC> infinity: That's been resolved
<infinity> BenC: Check, just catching up on nick hilights. :P
<BenC> cjwatson: I'm hoping I did this right. I committed e500/e500mc powerpc bits to base-installer for proper kernel detection along with a test case, ran all powerpc tests, pushed to my own branch and requested a merge with lp:~ubuntu-core-dev/base-installer/ubuntu
<BenC> cjwatson: Is that all up to spec?
<cjwatson> BenC: That sounds fine - something will probably mail me about it in a bit then
<sunweaver> davidbarth, fyi, I changed nick from m1k3 to sunweaver (realname Mike Gabriel) as sunweaver will be my login ID on Debian machines once I am through NM frontdesk process of Debian.
<BenC> cjwatson: What other packages should I look into (cd creation and such)?
<sunweaver> cjwatson, still have my GPG key at hand? Would love it to be signed. THANKS!!!
<infinity> cjwatson: As to the LP bug/misfeature, I had considered a simple algorithm where if we see arch all in the list, but not i386, we pick the first non-all arch to do a -b build on.  That would neatly solve the affinity issue in some cases too.
<infinity> cjwatson: But it would mean some reworking of some bits, I think, since we just assume the nominated indep arch is the only place arch all binaries will spew forth from.  I think.
<infinity> apw: I don't support the resolution was to stop building the common headers entirely, which just plain makes more sense for out-of-tree builds?
<infinity> apw: Oh, except in this case, where there are 4 flavours.  Nevermind.
<sunweaver> cjwatson, 0x25771b31
<cjwatson> BenC: debian-installer is the main other one for now
<cjwatson> sunweaver: oh yeah, doing now
<sunweaver> cjwatson, awesome!
<BenC> cjwatson: I need to arrange for the correct kernels to be installed on the cd image, in the correct locations
<BenC> And to make sure that the rootsquashfs has the modules for them too
<cjwatson> BenC: There's a little bit in lp:~ubuntu-cdimage/debian-cd/ubuntu, and you'll need to change livecd-rootfs too
<BenC> # and the bastard stepchildren
<BenC> *sniff*
<cjwatson> BenC: Ignore livecd.sh
<cjwatson> BenC: live-build/auto/* is the stuff we actually use now
<BenC> Oh, crap
<seb128> mfisch, hey
<BenC> cjwatson: I don't see anything in those files already related to powerpc. Is there some place I have to add this?
<cjwatson> BenC: the kernels might actually be done with defaults in live-build instead - ah, yeah, see debian/patches/ubuntu-powerpc-smp.patch there
<BenC> Ok, thanks
<cjwatson> (you'd need to add a conditional based on the distribution)
<cjwatson> (er I mean the release - whatever lb calls it)
<BenC> cjwatson: ubuntu-cdimage is a huge pile
<sunweaver> cjwatson: signed keys have reached me. THX!
<siretart> slomo: do you intend to update gstreamer0.10-ffmpeg to a newer upstream any time soon?
<mterry> bryceh, hello!  I see some MIRs filed for the various VAAPI drivers (gstreamer, nvidia, intel).  Is this something we want?  Is it suitable for main?
<mlankhorst> didn't know nvidia had vaapi support? :p
<bryceh> mterry, hi
<mterry> mlankhorst, apparently  vdpau-video provides it
<bryceh> mterry, no objections offhand, more video acceleration is probably good
<bryceh> mterry, I'd guess the only reason it's not already in main is it's newness.  afaik there's no patent issues, it's an open standard and there's no fees or other nonsense.  Should be good.
<mterry> bryceh, ok
<mterry> bryceh, speaking to newness, do you know where they are quality wise?  Like if we include them, are people going to see problems using them?
<bryceh> mterry, the drivers themselves should be fairly solid at this point; Intel has gotten pretty good at testing these days.  However issues are always possible, particularly with older or corner case hardware.  But I would expect most bugs that users would see would be due to the wrappering (i.e. in gstreamer, etc.)
<bryceh> mterry, also, often these video acceleration codecs are configurable opt-in's.  Dunno if that's the case here, but if it is that lessens the impact of regressions.
<mterry> k
<mterry> bryceh, thanks!
<bryceh> no prob
<Sarvatt> mterry: it would require gstreamer0.10-plugins-bad to be in main also..
<mterry> Sarvatt, hmm, that's a dep of gstreamer-vaapi?  seems problematic  :)
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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: barry
<mfisch> Does anyone know why we don't save the brightness setting and persist it across reboots?  I assume theres history there, but I've been unable to find it, other than an upstream bug with no activity, filed in 2009
 * TankEnMate is building wine for the first time in years, it is much bigger then he remembered
<TankEnMate> than even...
<TankEnMate> privmsg tankenmate
<TankEnMate> privmsg tankenmate foo
<cjwatson> BenC: tools/boot/raring/boot-powerpc probably
<cjwatson> BenC: but you can let me find/do it if you like, it's not a problem ...
<apw> BenC, in this latest upload you changed that variable, did you also change the control.stub.in to match?
<apw> barry, ie changing them to Architecture: powerpc
<barry> apw: did you mean me, or BenC? ;)
<apw> barry, soz, i mean benc ... i hate the way it does that
<barry> no worries :)
<apw> BenC, ^^ ... also you seem to have git cruft in the src package ... i use this incantation to keep the package clean when making: dpkg-buildpackage -S -rfakeroot -I.git -I.gitignore -i'\.git.*' "$@"
<BenC> apw: dpkg-source should naturally remove cruft (maybe not .gitignore)
<BenC> apw: Also, I did not change the Architecture: powerpc, since it seemed ok to leave it arch-all
<apw> BenC, you can say that but your src package has .git stuff in it
<apw> --- linux-ppc-3.7.0/.git/COMMIT_EDITMSG2012-11-12 21:52:41.000000000 +0000
<apw> +++ linux-ppc-3.7.0/.git/COMMIT_EDITMSG2012-11-13 15:21:28.000000000 +0000
<apw> BenC, i suspect it doesn't apply to format 1 package like us
<BenC> apw: interestingâ¦bug in dpkg-source I suspect, I'll be more careful on the follow up uploads
<apw> BenC, hmmm, doesn't that mean a binary-arch only package will produce :all packages, i suspect they won't be accepted
<BenC> apw: according to what I heard infinity say, it should not be a problem
<apw> but i guess at this stage we'll let it run, if when i wake up its still missing i'll s/:all/:powerpc/ ...
<apw> if it works, then all is good
<apw> she can be fenickerty
<infinity> Hrm?
<infinity> BenC: Did you just invoke my name?
<BenC> apw: IIRC, nothing should care, it's just that, normally, arch-all isn't built in binary-arch target, so, normally, you don't see it
<BenC> infinity: in vain, but can you confirm that an arch-all package will not make launchpad choke if it comes from what it thinks is a binary-arch build?
<infinity> BenC: Uhm, good luck making it happen at all...
<apw> infinity, he has switched our package so it will build the commmon headers on binary-arch, but not switched the Arch headers
<BenC> Well, I flipped a switch in the kernel build that made the indep package build on binary-archâ¦I suspected that this mechanism was tested with omap builds, so assumed it had been tested before
<apw> infinity, so you will get powerpc and 'all' packages out of the build
<apw> BenC, well as i said at the time "and switch the Archtecture: to powerpc in control.stub.in"
<apw> which is how we have tested it
<BenC> I missed that part :)
<BenC> Guess we'll know for sure in about 3 hours
<BenC> I confirmed it actually creates the packageâ¦but I couldn't test what launchpad would do with it
<infinity> BenC: It's not going to work at all.
<infinity> BenC: Cause dpkg-genchanges -B will ignore the _all.deb
<apw> infinity, i assume it will ignore the :all packages
<infinity> BenC: Not launchpad's fault at all.
<BenC> Well that's a right trifling bit of naughtiness
<infinity> BenC: But since there's zero point in that package being arch:all anyway...
<BenC> Right, I'll correct that on the next upload
<infinity> BenC: And since it's entirely wrong to generate arch:all packages in binary-arch. :P
<infinity> BenC: The next upload may as well be now, since this one will be broken.
<apw> BenC, just checked the logs, and we did talk about it on #u-k and you even went 'Ah' ... crap
<apw> BenC, so yeah you need to flip that bit on and change control.stub.in to : powerpc
<BenC> apw: In the interest of being more-correct, I'm going to make debian/control generation DTRT when do_binary_headers_indep is set
<apw> BenC, can we just flip those bits in this upload and then do that
<BenC> Maybe save some other architecture the trouble of dealing with this
<BenC> Will an upload now ever start building before 0.6 is done?
<apw> BenC, i had some other code to do that kind of thing, like add and remove the linux-headers if they are turned on ... i should dig that out
<apw> BenC, should do indeed
<BenC> Ok
<BenC> infinity: is there a way to permanently pin linux-ppc to only build on sulfur?
<BenC> It performs builds in about half the time (4 hours instead of 8)
<infinity> BenC: No, but I was about to do this one out of the kindness of my heart. :P
<BenC> infinity, apw: upload in progress
<BenC> infinity: my job is done
<YokoZar> infinity: poke ~wine :)
<infinity> YokoZar: I'm not ignoring you, I'm just headless chickening a bit right now.
<YokoZar> infinity: think of me as the farmer
<infinity> YokoZar: The one that cut off my head?
<YokoZar> infinity: if you want to be crass about it, yeah. I prefer "fulfilled your destiny"
<infinity> Hrm, does wine have a circular dep?  Is that actually necessary?
<YokoZar> infinity: wine (meta package) depends on latest wine (wine1.4) which then pulls in either wine-i386 or both wine-i386 and wine-amd64.   wine-amd64 cannot run without wine-i386, so it pulls in the rest.  wine1.4 contains the stuff that's relevant to its particular architecture only
<infinity> YokoZar: It was the wine1.4-$arch Depends: wine1.4 that I was curious about.
<YokoZar> infinity: this way an app can depend on either wine1.4:any (arch-inspecific dependency) or on wine-i386 if it needs an arch-specific thing
<infinity> YokoZar: Hrm, I suppose.
<infinity> YokoZar: Also, unrelated to any of this, you didn't run clean before you removed stuff from debian/control, so you ended up with cruft in your debian/ directory that dh_clean will never remove now. :P
<infinity> YokoZar: http://launchpadlibrarian.net/122507568/wine1.4_1.4.1-0ubuntu1_1.4.1-0ubuntu2.diff.gz
<infinity> YokoZar: Some substvars and directories, etc.
<YokoZar> oops
<YokoZar> good catch
<YokoZar> I forgot about that
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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: barry, TheMuso
<mterry> Any archive admins around?   Please reject my NEW upload of nexus7-dev-tools.  (will be re-uploaded later with a different name)
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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: TheMuso
<barry> TheMuso: it's all yours :)
<TheMuso> barry: Cheers, was thinking we would have to check with either other to make sure one of us didn't already have a lock on something. :)
<barry> TheMuso: yeah, there's more lag built into the qa page now that we go through -proposed, but i think the comments tend to get updated fairly regularly.  anyway, i guess that's the advantages of being on opposite sides of the world :)
<TheMuso> Yep.
<cjwatson> mterry: done
<mterry> cjwatson, thanks!
#ubuntu-devel 2012-11-14
<mfisch> robert_ancell: do you know why gnome-control-center wasn't updated to 3.6?
<mfisch> robert_ancell: could be the dozens of patches we're holding I suppose
<robert_ancell> mfisch, it has to be done at the same time as gnome-settings-daemon
<robert_ancell> and that had some side-effects I believe
<robert_ancell> the plan is to do it this cycle though
<mfisch> robert_ancell: is there a test PPA that has them updated anywhere?
<robert_ancell> mfisch, https://launchpad.net/~ubuntu-desktop/+archive/ppa
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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:
<mfisch> robert_ancell: what are the odds of me being able to install 3.6 on my dev box and then going back to 3.4 without exploding my system?
<robert_ancell> mfisch, there's also a PPA for the gstreamer migration https://launchpad.net/~ubuntu-desktop/+archive/gstreamer1.0
<robert_ancell> probably safe?
<robert_ancell> (haven't tried it myself)
<mfisch> robert_ancell: I'm trying to pick up an upstream fix that affects N7
<robert_ancell> ah
<mfisch> well, reinstalls are entertaining anyway, so I'll do it
<robert_ancell> what's the fix?
<mfisch> robert_ancell: well actually I think it's not fixed, https://bugzilla.gnome.org/show_bug.cgi?id=662117
<ubottu> Gnome bug 662117 in Screen "Brightness slider doesn't sync with the current value" [Normal,Resolved: fixed]
<mfisch> robert_ancell: I pulled that into the quantal version of g-c-c and it didn't solve the issue
<mfisch> robert_ancell: from what I can tell it was fixed in gnome in 3.4 and the 3.6 tree
<robert_ancell> yeah, looks that way
<mfisch> "fixed" in quotes
<robert_ancell> for some defintion of fixed
<mfisch> since the fix doesn't work for me, so I'll try the 3.6 and see since it should have the "fix' also
 * robert_ancell fires up his n7
<mfisch> robert_ancell: the n7 has 2 issues that I think this "fix" should fix, let me find them
<mfisch> robert_ancell: #1077096 and #1077054
<robert_ancell> mfisch, btw is it a known problem on the n7 where the input locks up and you can select but not click on anything?
<mfisch> robert_ancell: yep, thats our biggest issue
<robert_ancell> mfisch, any ideas what it is?
<mfisch> but you read the Known Issues section of the wiki, I'm sure, so you already know all about it
<mfisch> robert_ancell: #1068994 button1 gets stuck after a while
<mfisch> robert_ancell: It's an X issue IIRC
<robert_ancell> why of course I did... :/
<mfisch> Daniel D'Andrada is working on it
<mfisch> robert_ancell: the only solution is to reboot when that happens unfortunately
<robert_ancell> yeah, at least it reboots fast!
<mfisch> robert_ancell: and the unity greeter looks really good too, no scaling issues
<robert_ancell> yeah it's nice
<robert_ancell> mahjongg is the best app on the touchscreen
<mfisch> okay, rebooting with this new g-s-d
<mfisch> I guess a logout will do
<robert_ancell> yes
<mfisch> robert_ancell: gnome-settings-daemon died :(
<robert_ancell> not a good sign
<mfisch> my laptop is blindingly bright, better than too dim to read I guess
<robert_ancell> mfisch, is it in-scope to modify the theme so the window controls are clickable (i.e. win7 shaped)
<mfisch> robert_ancell: close/minimize etc?
<robert_ancell> mfisch, yes
<mfisch> I think we have a bug filed about that actually.
<robert_ancell> I couldn't see it
<mfisch> let me find it
<mfisch> robert_ancell: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075470
<mfisch> ?
<ubottu> Launchpad bug 1075470 in ubuntu-nexus7 "Titlebar buttons are unusably small for tablets/touchscreens and don't scale with the fonts/titlebar" [Medium,Confirmed]
<robert_ancell> ah, ta
<robert_ancell> was searching for window controls etc
<mfisch> robert_ancell: #ubuntu-arm is the designated channel for N7 question, but bugs like these make sense to discuss here too
<robert_ancell> oh, I thought I was in #ubuntu-desktop, didn't notice this was #ubuntu-devel
<robert_ancell> meh, too many channels anyway :)
<mfisch> robert_ancell: regarding that brightness bug, how does one go about testing the "pure gnome" version?
<mfisch> or how do you prove that it's not just the fault of the Ubuntu version?
<robert_ancell> mfisch, compile it locally. You'd have to replace the existing binary or do some hackery though
<robert_ancell> mfisch, with apps it's easy, but lower level stuff much harder. You can compile the package with the patches disabled
<mfisch> option B might be easier
<robert_ancell> as long as none of the patches are strictly required (which is generally the case)
 * robert_ancell just realized he has 5 active screens in front of him
<pitti> good morning
<hyperair> TheMuso: ping
<hyperair> regarding bug #1070631, what else is necessary?
<ubottu> Launchpad bug 1070631 in Banshee "[Sync libgpod 0.8.2-7 from Debian unstable to Raring] libgpod-cil contains arch-specific code but is declared arch:all" [Medium,Confirmed] https://launchpad.net/bugs/1070631
<hyperair> TheMuso: the debdiff contains only a debian/changelog entry, and rightly so, because no other changes are needed to backport it.
<hyperair> TheMuso: it's sitting there as a debdiff because i can't upload libgpod myself.
<TheMuso> hyperair: So its a no-change rebuild in quantal essentially...
<hyperair> TheMuso: -proposed.
<TheMuso> Yeah well of course.
<hyperair> TheMuso: it's a *backport* of -7 which is in raring, into quantal-proposed.
<hyperair> not a rebuild of -6 which is in quantal.
<TheMuso> urm... Shouldn't you then be pulling the patch from the -7 packaging?
<hyperair> yes it's to be applied against -7?
<hyperair> don't you see the context lines?
<hyperair> it says  libgpod (0.8.2-7) unstable; urgency=low
<hyperair>  
<hyperair>    * [1c86366] Make -cil packages non-arch-all (Closes: #689054)
<TheMuso> Yes I see that, but are you saying you want the entirity of -76 put into quantal-proposed?
<hyperair> yes.
<TheMuso> *the entire -7 upload
<hyperair> yes.
<hyperair> do you need a debdiff against -6 for that?
<TheMuso> Yes but I see 3 changes there that are not relevant to the SRU.
<hyperair> hang on, lemme check that..
<hyperair> TheMuso: which 3 changes?
<hyperair> oh, okay, should i remove those?
<TheMuso> Bump debhelper to 9, the standards version change, and the package section change.
<TheMuso> All of which are in -7.
<hyperair> TheMuso: they're insignificant changes that don't result in any user-visible changes
<hyperair> -6 is already built against dh >=9
<hyperair> in quantal, thatis
<hyperair> bumping that makes no difference
<TheMuso> No, but I have seen the release team raise flags over changes like that that are not relevant to the SRU.
<ScottK> Yes, but if you change compat it can change how debhelper processes stuff.
<hyperair> ScottK: i didn't change compat.
<hyperair> ScottK: it's only bumping the build-dep version.
<ScottK> Oh.
<hyperair> ScottK: it was already on compat 9, build-depping on >= 8.9~
<hyperair> 8.9~ -> 9 = no difference
<ScottK> SRU should be minimal.
<ScottK> I agree it's not needed.  So it shouldn't be there.
 * hyperair sighs
<hyperair> fine, i'll strip it
<hyperair> TheMuso: alright, i've uploaded the new patch.
<TheMuso> hyperair: Ok, I'm taking care of it now.
<hyperair> thanks
<diwic> @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: diwic
<diwic> @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
<pitti> hey dholbach
<dholbach> hi pitti
<pitti> dholbach: tu n'est pas dans #ubuntu-quality ?
<pitti> dholbach: ah, maintenant!
<dholbach> pitti, oui, je suis lÃ 
<geser> bonjour / good morning / Guten Morgen
<pitti> geser: Ð´Ð¾Ð±ÑÐ¾Ðµ ÑÑÑÐ¾!
<geser> :)
<diwic> @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: diwic
 * dholbach hugs diwic
 * diwic hugs dholbach 
<tkamppeter> Seems that I have hit a ghost dependency in apt-get making it impossible to use apt-get again. I have installed "ia32-libs' trying to install some closed-source app and ia32-libs is uninstallable as some i386 library versions did not get built. Now "apt-get install -f" insists on installing the uninstallable libraries, even after removing all :i386 packages
<seb128> to be complete tkamppeter would like to "undo" the "those new packages will be installed" and doesn't know how
<seb128> installing them fail due to what looks like cairo/avahi multiarch bugs:
<seb128> http://pastebin.ubuntu.com/1357786/
<seb128> " trying to overwrite shared '/usr/share/doc/libcairo-gobject2/README.gz', which is different from other instances of package libcairo-gobject2:i386"
<seb128> bug #1078625
<ubottu> Launchpad bug 1078625 in cairo (Ubuntu) "package libcairo-gobject2 1.12.2-1ubuntu2.1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libcairo-gobject2/README.gz', which is different from other instances of package libcairo-gobject2:i386" [Undecided,New] https://launchpad.net/bugs/1078625
<seb128> pitti, I hope that gzip bug is not back
<pitti> urgh
 * seb128 does like those README.gz being different between arches
<seb128> doesn't*
<seb128> well, the avahi error in on README (not .gz) so not like that...
<tkamppeter> seb128, pitti, I cannot even help myself by uninstalling all :i386 packages (ias32-libs I haver already uninstalled). Then "apt-get -f install" wants to install all :i386 packages again. There seems to be some hard ghost dependency on at least some of the i386 libraries making the broken libraries required.
<seb128> tkamppeter, did you try to dpkg -r them?
<seb128> hum
<seb128> /usr/share/doc/libcairo-gobject2/README.gz -> ../libcairo2/README.gz
<seb128> the file which is different is a symlink
<seb128> the README.gz in libcairo2 amd64 and i386 have the same md5 it seems (from dpkg-deb the debs)
<seb128> wonder if that's a but in dpkg/apt
<Laney> that is a tkamppeter upload
<seb128> oh, so maybe local build
<Laney> I bet he installed his self built deb which has different files
<Laney> md5sums*
<seb128> Laney, good thinking!
<Laney> same for avahi
<seb128> tkamppeter, does wget https://launchpad.net/ubuntu/+source/cairo/1.12.2-1ubuntu2.1/+build/3923069/+files/libcairo2_1.12.2-1ubuntu2.1_amd64.deb && dpkg -i it fixes the cairo error?
<seb128> Laney, thanks for pointing that ;-)
<seb128> it's a "fun" corner case situation
<diwic>  @pilot out
<diwic> @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:
<tkamppeter> seb128, pitti, no change: http://pastebin.ubuntu.com/1357813/
<seb128> tkamppeter, wget https://launchpad.net/ubuntu/+source/cairo/1.12.2-1ubuntu2.1/+build/3923069/+files/libcairo-gobject2_1.12.2-1ubuntu2.1_amd64.deb and dpkg -i it and try again?
<tkamppeter> seb128, now the libcairo error went away and only libavahi stuff is remaining.
<Laney> same fix
<seb128> tkamppeter, wget https://launchpad.net/ubuntu/+source/avahi/0.6.31-1ubuntu2/+build/3889306/+files/libavahi-common3_0.6.31-1ubuntu2_amd64.deb
<seb128> tkamppeter, wget https://launchpad.net/ubuntu/+source/avahi/0.6.31-1ubuntu2/+build/3889306/+files/libavahi-client3_0.6.31-1ubuntu2_amd64.deb
<seb128> tkamppeter, dpkg -i those
<tkamppeter> seb128, yes, now it works. Thanks.
<seb128> tkamppeter, yw!
<marga> Hi, I'm trying to mark a bug fixed for quantal but not yet fixed for precise.  I can't seem to find the correct way to do this in launchpad, can anybody please give me a hint?
<diwic> marga, you will have to nominate the bug for precise
<marga> alright, how do I do that?
<marga> I'm talking about the launchpad interface.
<diwic> marga, then someone with the correct access (possibly yourself, if you're a developer) can accept the nomination
<marga> I've seen this in plenty of bugs, a subitem inside the package (Ubuntu) with a small clock
<diwic> "Nominate for series" link
<cjwatson> Do you have a "Nominate for series" option just below the bug metadata?
<cjwatson> You have to be in a certain team (ubuntu-bugcontrol IIRC) to even see that
<marga> I don't.
<cjwatson> Then you need to ask somebody who is
<diwic> cjwatson, oh, I didn't know that
<marga> Ok. Good, I think I was going crazy or something.
<marga> s/think/thought.
<cjwatson> https://wiki.ubuntu.com/UbuntuBugControl
<diwic> marga, is there a specific bug you want me to nominate for you?
<marga> https://bugs.launchpad.net/ubuntu/+source/dropbear/+bug/834174
<ubottu> Launchpad bug 834174 in dropbear (Debian) "cannot login via ssh when using dropbear in initramfs" [Unknown,New]
<marga> It's been uploaded to raring-proposed, but I'd like this to be also fixed in precise.
<diwic> marga, done, you should now see a nomination
<marga> diwic, thanks
<xnox> marga: diwic: and nomination accepted.
<marga> tnx
 * xnox will play around with this on the weekend, unless somebody beats me to testing it.
<marga> I've changed the desc and the debdiff.  Hopefully I've folllowed SRU guidelines now.
<xnox> marga: the real test case is that you can ssh in & unlock the drive.
<xnox> marga: the bug is that above is not possible due to bugs in discovering / generating initramfs on a system with multiarch
<marga> ok, feel free to update my desc :)
<sbhw> cjwatson: The Ubuntu Studio team wants to know when will the blender python fix go into raring-main (not -proposed)
<xnox> sbhw: it's being transitioned by britney: check the output here http://people.canonical.com/~ubuntu-archive/proposed-migration/
<xnox> as to why it's possibly stuck.
<xnox> sbhw: so the armhf build has just finished, and not fully published yet for britney to attempt transition to main.
<cjwatson> sbhw: Yeah, this is all automatic
<cjwatson> sbhw: They should be a bit more patient since I only uploaded it an hour or two ago
<cjwatson> And given that none of them fixed it in the multiple days that it was broken ... ;-)
<sbhw> cjwatson, can't undetstand the system. They want to know it since that they almost just want to remove it from the seeds.
<cjwatson> That's a daft response :)
<cjwatson> It'll be fixed in an hour or two
<xnox> sbhw: "the bug will be marked fix released at the time it's migrated into the raring-release pocket."
<sbhw> yep
<scott-work> cjwatson: sorry for the noise, i had commented blender out of our meta to make sure the iso would build and was just curious on an ETA so i had a general approximation of when i needed to uncomment blender
<scott-work> again, sorry for the trouble
<xnox> scott-work: well, generally it's ~1h after fully built on all arches, that is if it's actually installable and doesn't cause other packages to become uninstallable.... but blender takes a while to build on arm
<scott-work> xnox: i'd like to use this as a teachable moment for myself; is -proposed an "in box" or queue for building then pushing into the repos?
<scott-work> i realized in uds-q there was discussion about changing how the repos are structured, i am certainly not up to date on this and the processes
<xnox> scott-work: it's the same thing as in debian: unstable -> testing transition.
<xnox> scott-work: but we _do not_ impose the "10 day delay", nor rc-bugs.
<scott-work> ah, okay. thank you :)
<xnox> scott-work: we plan to block on failing auto-pkg-test of the package or any of it's reverse-depends.
<xnox> scott-work: but that is not done yet.
<scott-work> thank you again, xnox
<xnox> scott-work: np. blender is in release now, in ~0.5h it should be pushed to the mirrors.
<xnox> the storm is over.
<pitti> cjwatson: jibel and I would like to meet with you soon to discuss adt/britney integration; when would be a good time for you?
<cjwatson> pitti: any time tomorrow would be lovely, if that suits
<pitti> cjwatson: yes, it does; how does 10:00 UTC sound?
<cjwatson> scott-work: https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html
<cjwatson> pitti: sure
<pitti> thanks
<cjwatson> just grab me and we can hop on mumble or something
<scott-work> oooh, thank you cjwatson , i will definitely read that
<rickspencer3> sforshee, wrt my USB dongle, can I run trace-cmd for a long time? it sometimes takes all day before it disconnects
<sforshee> rickspencer3, the only risk is the size of the trace.dat file getting very large. You could check it periodically and restart trace command if the file is getting too big. All I'm really interested in is the part of the trace right before the disconnect happens.
<rickspencer3> ok sforshee
<rickspencer3> thanks
<rickspencer3> it's running now
<sforshee> rickspencer3, also please grab dmesg after killing trace-cmd so I can try to correlate the two
<rickspencer3> sforshee, ack
<sforshee> (that is after the disconnect happens)
<psusi> why is the util-linux package still source format 1.0 with no patch system?
<cjwatson> psusi: ask its maintainer; 3.0 isn't a requirement and some people still like it the old way for one reason or another
<cjwatson> Or of course sometimes it's just hadn't-got-round-to-it
<Sweetshark> doko_: bug 1017125 should be good for quantal SRU. I also prepared a mpi package. both boost1.49_1.49.0-3.1ubuntu1.1.dsc and boost-mpi-source1.49_1.49.0-3.1ubuntu1.1.dsc waiting on chinstrap.
<ubottu> Launchpad bug 1017125 in boost1.49 (Ubuntu Quantal) "[SRU quantal] boost::unordered_multimap<>::erase(iterator, iterator) broken in boost1.49" [High,New] https://launchpad.net/bugs/1017125
<psusi> I mean I thought we were not supposed to just directly make changes to the upstream source without some sort of patch system?
<xnox> psusi: in general yes, but also we are not suppose to diverge from debian way of maintaining the package.
<xnox> psusi: sometimes the two conditions conflict with each other, if debian has no patch system.
<psusi> yea, but isn't it better to add a patch system than to have the upstream sources mangled?
<psusi> and would it be worth while for me to try to update the package to 3.0 (quilt) and submit it to the debian maintainer?
<psusi> or just dive in and make changes directly to the upstream source?
<xnox> psusi: dive in ;-)
<xnox> psusi: that's what we do for all native packages as well....
<xnox> psusi: or use the bzr lp:ubuntu/$pkg branches.
<xnox> if individual changes are committed you get a normal vcs history.
<geser> psusi: if you don't wand to have a mix of directly applied patches and patches from patch system, you would have to ideally transfer those directly applied patches to patch files too (and make the delta even bigger)
<geser> often those changes are bigger than the patch you wanted to apply and you have to merge it everytime
<geser> but feel free to convince the Debian maintainer to use a patch system
<cjwatson> psusi: We should never change the patch system in an Ubuntu delta
<cjwatson> That includes adding one
<cjwatson> psusi: But as geser says, feel free to try to persuade the Debian maintainer that they want to change
<cjwatson> It's not fair to describe the upstream sources as being mangled - that's why we have .orig.tar.gz / .diff.gz
<geser> psusi: and you might have a better chance to get you patch included in Debian if you don't change the whole packaging system
<cjwatson> Exactly
<psusi> yea, but doesn't having them all squashed into the diff.gz make for conflict galore when you update to a new upstream?
<doko_> Sweetshark, done
<cjwatson> psusi: Not particularly, no
<psusi> and since they aren't seaparted out, resolving them is next to impossible?
<cjwatson> Sure, you may have to know the package depending on the complexity of the changes
<cjwatson> Anyway, this isn't the point
<cjwatson> Merging a new Debian version is much more common for us than merging a new upstream directly
<cjwatson> We should therefore optimise for not creating huge numbers of conflicts against Debian
<cjwatson> (Also, I believe the util-linux maintainer uses git to maintain the packaging against upstream and does not find this to be a particular problem for his workflow; hence why you should talk to him ...)
<psusi> hrm... well, I guess I'll just make the change directly then... just thouguht that make merging a pita
<cjwatson> Like I say, it's a matter of optimising for merging against Debian vs. upstream
<Sweetshark> doko_: awesome, thanks
<cjwatson> I mean, we *could* in theory aggressively convert every non-native package in Ubuntu to 3.0 (quilt), but then we'd end up assuming significantly more merge workload
<cjwatson> It doesn't make economic sense
<cjwatson> And it doesn't make social sense either since a number of the Debian maintainers we'd like to work with would consider that very rude
<xnox> doko_: Sweetshark: thanks a lot ;-)
<ppawel> hi, I want to update upstream version for a package (geos - from 3.3.3 to 3.3.5)
<ppawel> I did 'bzr branch ubuntu:geos', then 'dch -i', updated version to 3.3.5, then bzr bd -S
<ppawel> but it complains that "unexpected upstream changes detected" and tries to create a patch
<ppawel> when I create it I can't build the package anymore...
<ppawel> dpkg-source: error: cannot read geos-3.3.5.orig.ND5giv/debian/patches/update-to-3.3.5: No such file or directory
<xnox> ppawel: did you merge the new upstream tarball?
<xnox> ppawel: cause following your instructions the diff will have the reverse between 3.3.5 -> 3.3.3
<xnox> ppawel: $ bzr merge-upstream ../geos-3.3.5.tar.gz
<xnox> ppawel: instead of `dch -i`
<ppawel> yeah it doesn't apply to 3.3.3...
<ppawel> xnox, thanks, I will try that
<xnox> ppawel: but your branch is dirty now, so move it aside and try again.
<ppawel> xnox, thanks it works now
<mterry> doko_, how do you feel about promoting libboost-filesystem-dev and libboost-system-dev (and associated 1.49 versioned packages)?
<mterry> (libunity test suite needs them)
<mterry> er, rather nux test suite needs them
<doko_> mterry, sure, why not? but I don't see these in component-mismatches yet
<mterry> doko_, no, not yet.  was planning ahead.  though, I'm not sure a branch adding these as build-depends will get through the PS landing process unless they are in main.  didrocks?
<xnox> doko_: hmm.... componen-mismatches doesn't work that well with everything going via -proposed.
<xnox> doko_: e.g. bug 1077484 doesn't show libsemanage in component-mismatches
<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
<doko_> hmm
<cjwatson> xnox: that's on the to-do lit
<cjwatson> *list
<cjwatson> I'm asking Ursula to have a look at that
<xnox> cjwatson: ok. thanks.
<bdmurray> barry: what's next with https://code.launchpad.net/~mvo/ubuntu-release-upgrader/lp1071388/+merge/132851 in your opinion?
<didrocks> mterry: so, theorically it can
<didrocks> mterry: but as we'll have soon daily upload, it's better to just merge it when we have the build-dep in main
<didrocks> doko_: ^
<doko_> didrocks, what am I supposed to merge?
<didrocks> doko_: we are talking about the merge request for the packaging adding the build-dep
<SpamapS> kenvandine: hey, did I hear you right in CPH that you were working on a new Gwibber thing?
<kenvandine> yeah
<kenvandine> the service has been rewritten
<kenvandine> the client still needs to be ported to the new backend
<SpamapS> kenvandine: ah, but the frontend is the same.. thing?
<kenvandine> but the backend is rocking!
<kenvandine> yeah
<kenvandine> for now :)
<kenvandine> well
<SpamapS> negronjl: ^^
<kenvandine> there is the unity lens too
<kenvandine> for 13.04 we'll be removing the client
<kenvandine> and just shipping the lens
<SpamapS> ah
<SpamapS> removing, or just demoting?
<kenvandine> and hopefully expanding the lens functionality a bit
<kenvandine> just not seeding it
<SpamapS> right, cool
<negronjl> nice
<barry> bdmurray: nothing, i think.
<ppawel> I uploaded a source package to my PPA. will the derivative packages be built for me?
<bdmurray> barry: so you think its okay to merge and upload?
<barry> bdmurray: check w/mvo.  he said he fixed the couple of things i mentioned, but the diff in the mp doesn't look updated.  not sure he pushed his changes.
<mterry> doko, sorry, getting back from lunch.  I think didrocks's point was that it might be easier with the PS process if the archive were ready as we test the branches.  Which means pre-promoting.
<didrocks> right ;)
<mterry> doko, so I guess the ask is to pre-promote libboost-filesystem-dev and libboost-system-dev (and associated 1.49 versioned packages), assuming they don't need a full MIR
<hallyn> slangasek: so using udevadm trigger --subsystem-match=misc --action=change for /dev/kvm, the main downside i'm seeing (beside expectec container weirdness) is that if kvm module is not loaded, but /dev/kvm was manually created, perms on it won't get fixed.  i don't know if we care about that case.
<hallyn> mahmoh: any chance you could verify bug 589063 ?
<ubottu> Launchpad bug 589063 in seabios (Ubuntu Lucid) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Fix committed] https://launchpad.net/bugs/589063
 * apw just installed a Q system from scratch and when trying to upgrade it to R i found it was in "LTS only" mode ... is that right?
<slangasek> hallyn: why would something manually create /dev/kvm?  Also, if the kvm module is not loaded, isn't /dev/kvm non-functional?
<hallyn> slangasek: correct, it wouldn't be functional.  This would be some obtuse test case.
<slangasek> hallyn: right; so when the kvm module was loaded, udev would trigger and update the permissions on /dev/kvm anyway
<slangasek> hallyn: static /dev is not a configuration we support
<hallyn> it's not?  that's too bad :)
<hallyn> slangasek: ok, i'l go ahead and push this change.  thanks!
<zyga> james_w: does pkgme support python3?
<zyga> (as in packaging python3 software)
<slangasek> xnox: so llvmpipe on panda is sufficiently horrid that running compiz at all, even just for ubiquity, is almost certain to be unusable.
<infinity> slangasek: Has anyone tested that theory this cycle?  ogra was telling me that llvmpipe on his Chromebook is actually pretty usable and the Chromebook, while certainly faster than a Panda, isn't exactly a computing powerhouse.
<slangasek> infinity: I haven't tested, but I don't see how a massive port of LLVMpipe to NEON would have magicked itself up overnight
<slangasek> feel free to test and prove me wrong :)
<infinity> My Panda's somewhat preoccupied with building glibc for 5 distributions.
<infinity> When it stops crying, maybe I'll ask it to do GUI things to a monitor.
<highvoltage> sad panda is sad
<infinity> It's a masochist, it's okay.
<chrisccoulson> is armhf busted? https://launchpad.net/ubuntu/+source/firefox/17.0~b6+build1-0ubuntu1/+build/3983790
<xnox> slangasek: *sigh* well I have a workitem to implement it and I was hoping panda will be better than VM or old-laptop. I guess i'll use one of those in development, and then smoke test on the panda.
<xnox> mterry: did you know about `pull-lp-source $package {$distro,$distro-$pocker,$version}` & `pbuilder-dist $distro {create,update,clean,build,login}` which has support for _all_ ubuntu & debian releases?
<xnox> mterry: well the first-one changes to pull-debian-source.
<mterry> xnox, you're talking about instead of pbuilder-scripts?
<xnox> mterry: yeah. Or what is unique in pbuilder-scripts which is missing in ubuntu-dev-tools.
<Laney> SpamapS: where do we stand with copying up SRUs?
<Laney> if possible I'd like to avoid uploading webkit twice ...
<mterry> xnox, I wrote those scripts when working with OEMs and needing all sorts of custom sources.  So supporting standard ubuntu and debian releases wasn't a big feature
<xnox> mterry: There is a request to backport it to precise, but I just don't see what it offers extra / on top of what ubuntu-dev-tools already offer for a very long time including stable releases.
<xnox> mterry: so if ubuntu-dev-tools add [easy] support for extra sources it will be match?
<xnox> mterry: so if ubuntu-dev-tools adds [easy] support for extra sources it will be match?
<xnox> mterry: anything else?
 * xnox wants to consolidate tools, scripts, utilities around ubuntu-dev-tools if possible.
<slangasek> xnox: even if someone did magic up an LLVMpipe port to NEON, it would still be slower than in kvm
<doko> \o/  http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00455.html  \o/
<ubottu> gcc.gnu.org bug 2012 in c "ICE when compiling the current cvs gcc as cross-compiler to mingw32" [Critical,Resolved: duplicate]
<mterry> xnox, I'm for consolidating.  I'd have to go through and figure out the various features though.  Easy sources is one.  apt-get update before building.  apt-get sourcing using the sources in one of the chroot
<xnox> slangasek: ok.
<slangasek> chrisccoulson: armhf busted> there was mention about the livefs builder having "tar errors" as well, but I don't have details
<slangasek> infinity, ogra-cb: ^^ any ideas? https://launchpadlibrarian.net/123040342/buildlog_ubuntu-raring-armhf.firefox_17.0~b6%2Bbuild1-0ubuntu1_FAILEDTOBUILD.txt.gz
<xnox> mterry: i'll open a bug about those three. If there is anything else, feel free to do wishlist bugs against ubuntu-dev-tools.
<chrisccoulson> slangasek, thanks
<Laney> that's the same kind of error we saw on celbalrai, yeah
<mterry> xnox, it also lays out the sources in a certain way & uses that layout to automatically determine which project chroot you want it to operate on (can be overridden).  Not sure if ubuntu-dev-tools can easily support that stle
<mterry> style
<slangasek> Laney: ok, it was the same bunzip2 problem?
<xnox> mterry: hmm... well pbuilder-dist already auto-supports guesing/using multiple combinations of distro's and arches.
<Laney> slangasek: I think so
<slangasek> infinity: do you have a raring panda handy?
<xnox> mterry: the whole point of pbuilder-dist was to allow easily manage chroots for all releases & cross-arches, since it's common for ubuntu developers to build against multiple ubuntu releases (sru/security/backports) and debian releases (for bug verification /forwarding to debian)
<infinity> slangasek: I could do, but like I said earlier, my Panda's a bit busy.
<xnox> mterry: so I am sure it can be extended to handle sub-types of chroots.
<slangasek> infinity: ah, still? thbt
<slangasek> ok
<slangasek> infinity: well, bzip2 hasn't changed in raring, so I guess I'll open a critical bug against eglibc in the meantime
<infinity> slangasek: Also, if this build log ever loads.. If it's bunzip2 spontaenously having a fit, that's been happening on ARM for years.
<slangasek> oh, it has?
<infinity> Yeah.  Though, it usually manifests before the build starts (when untarring the chroot).
<slangasek> I've never heard of it until Laney mentioned it happening on celebrityrye this week
<infinity> And it's so wildly unreproducible, no one's managed to hunt it down.
<infinity> celbalrai's issues seem unrelated.
<slangasek> not according to Laney
<Laney> now it has died, but before that we were seeing similar errors
<slangasek> Laney: do you have a pointer to such an error?
<infinity> Similar, or the same?
<Laney> p'raps I have a log which is nonempty
<xnox> mterry: adding all of these requests to the wishlist =)))) keep them coming.
<slangasek> infinity: similar, because the livefs builder doesn't generally go about unpacking firefox tarballs :P
<Laney> yeah that's wishful thinking
<infinity> slangasek: Well, yes.  And I would have assumed the errors were just "something from some sort of compression something or other" which is hardly "the same error".
<mterry> xnox, :)
<xnox> mterry: we are soon gonna get shiny cross-building support ;-)
<xnox> mterry: and that will want easy custom repositories as well =)
<mterry> nice
<xnox> mterry: with and without qemu execution.
<slangasek> infinity, chrisccoulson: I've saved off a copy of the logfile, so will retry the build now
<mterry> xnox, oh yeah, that's another thing my scripts did is set up qemu
<xnox> mterry: pbuilder-dist does it already, since before your script had it ;-)
<mterry> xnox, :)
<infinity> slangasek: It won't repeat, unless you're very unlucky.
 * infinity would like to know why his firefox has suddenly decided he isn't allowed to do things like look at web pages.
 * xnox would like to know why my internet decided to give we all but lp.net
<xnox> s/we/me/
 * xnox now back
<xnox> mterry: also any reason why it's based on pbuilder instead of sbuild?
<xnox> sbuild supports multiple instances easy, and mk-sbuild allows to easily create them.
<mterry> xnox, ah!  you are one of those sbuild evangelists  :)  It was based on pbuilder because that's what I was comfortable with
<xnox> mterry: I use all three: pbuilder, cowbuild, sbuild =))))
<xnox> mterry: i'm the freak that cannot get enough =))))
<mterry> xnox, hah
<ogra-cb> slangasek, the last live build logs from celab...thing all have one or the other gunzip error from dpkg unpack
<slangasek> gunzip, not bunzip2
<slangasek> so that's not the same error at all
<ogra-cb> it is definitely not limited to bzip2
<slangasek> "limited to" - there's no reason to think the two issues are at all related
<slangasek> unless someone knows of a tar bug?
<ogra-cb> well, dpkg died with a broken pipe error in all recent builds that still produced logs
<ogra-cb> during gunzip
<ogra-cb> this one seems to show similar symproms
<slangasek> bunzip2 reporting a corrupted stream and dpkg reporting a broken pipe are not meaningfully similar
<infinity> slangasek: Given how celbalrai when off the deep end, it looked more like the filesystem corruption (or memory corruption at a more fundamental level, leading to filesystem corruption).
 * slangasek nods
<kamakwazee> Hey
<slangasek> hello
<infinity> slangasek: As to the bunzip2 thing we see occasionally, retrying (or, in the case of chroot tarballs, removing the cached copy, then retrying) always "fixes" it, which points at similar potential causes.
<infinity> slangasek: Oh, it also seems to sometimes need a reboot to clear up, which is mildly disconcerting.
<infinity> s/need/needs/
<infinity> But yeah, none of this is new, it's been happening for years.  :/
<xnox> stokachu: grub2 diff (i) committed to core-dev branch & (ii) pocket sru team member of the day to commit it into oneiric.
 * xnox s/pocket/poked/
 * xnox wonders what's with my hands.....
<kamakwazee> I was wondering if someone could help me. I downloaded testdrive and synced the raring iso but it boots console. Is that normal?
<kamakwazee> Is it normal for my testdrive synced iso to boot into console?
<ScottK> kamakwazee: Ask in #ubuntu-testing.  You probably have a better chance of getting an answer there.
<kamakwazee> ScootK: Ok. Thanks. I am wanting to learn the source code a little so I can help develop.
#ubuntu-devel 2012-11-15
<james_w> zyga, I don't think it does. I'm not sure if it would be hard to add if there's a good way to detect what should be  built for python 3 vs 2. It also depends on the level of support that debhelper has for py3
 * doko never wanted to learn that much about m68k and powerpc ...
<xnox> =))) lol what did doko just do?
<doko> gcc multiarch upstream patches
<xnox> james_w: debhelper has no support for py3, but it's a mere 6 or so monkey patch lines across many packages.
<xnox> james_w: if there is ported code, I offer services of fast python3 packaging into ubuntu & debian archives =)
<james_w> xnox, in debian/rules?
<xnox> james_w: yeap.
<james_w> might be feasible to do in pkgme then
<james_w> xnox, also, go to bed :-)
<xnox> james_w: oh for pkgme..... *sigh* we should do better than monkey patching.
<xnox> james_w: currently it looks like so: http://wiki.debian.org/Python/LibraryStyleGuide
<james_w> aha, great info, thanks
<xnox> james_w: but you can get away with less.
<xnox> james_w: by supporting only python2.7 & python3 and not compiling / testing under non-default python versions.
<xnox> james_w: then it can be compressed further down.
 * xnox has no clue what pkgme does or looks like though =)
<james_w> hmm, probably quite tricky for pkgme to detect, but good to know
<james_w> it's magic :-)
<xnox> james_w: well, pure python vs non-pure python =)
<james_w> ah, yeah
<xnox> james_w: here is smaller case: http://wiki.debian.org/Python/AppStyleGuide
<xnox> ideally debhelper python3 support should be written.....
<james_w> yeah
<mahmoh> hallyn: re: LP#589063, on vaca but I can try next week when I get back?
<TheMuso> Hrm thats weird, the 3.7 kernel I have here shows overlayfs built in the kernel, according to the config, but the module is not present in the modules dir...
<TheMuso> s/built into the kernel/built as a module/
<jelmer> one of my uploads to precise-proposed was just rejected, after being pending for a couple of weeks. Is there any way to find out why?
<TheMuso> Was a comment not left in the bug?
<TheMuso> Ah, disabled in the kernel source for now.
<TheMuso> ...which means non-functioning live images from today onwards or so...
<cjwatson> TheMuso: !  I'll have to talk with the kernel team tomorrow about that ...
<cjwatson> So much for zero regressions
 * TheMuso only found out because he went to use sbuild with an overlay.~s
<sarnold> cjwatson: at least it's a big one :)
<doko> slangasek, do you think we would need unversioned Multi-Arch same libgcc-dev, libstdc++-dev, libobjc-dev, libgfortran-dev packages?
<doko> cjwatson, today I accepted new binary packages for gcc-4.7, zlib, ncurses and readline6, which did all land in main without any further interaction. is this intended?
<doko> slangasek, do you think we would need unversioned Multi-Arch same libgcc-dev, libstdc++-dev, libobjc-dev, libgfortran-dev packages?
<cjwatson> doko: Yes
<cjwatson> doko: Binaries now default to the component of the source
<cjwatson> doko: This was a long-standing irritation that we'd been begging to get fixed for ages
<doko> not sure if I like this
<cjwatson> doko: So you now get the other side of it :-)  I'm pretty certain this is a relatively rare case and in any case component-mismatches handles it
<cjwatson> doko: If you wanted them in universe you could always pay more attention when NEWing ;-)
<cjwatson> doko: It was really common for people to accidentally NEW library ABI changes of sources in main into universe, causing uninstallability
<doko> cjwatson, well, the thing is that the mir team doesn't get any notice about that
<cjwatson> doko: The MIR team is not supposed to get notice of *binary-only* changes
<doko> no, that's wrong
<cjwatson> Binaries of sources in universe still default to universe
<doko> if something is split out because we don't want to support it, it should default to universe
<cjwatson> Nevertheless, there is no MIR process for this
<cjwatson> Sorry, but you just need to catch this manually
<doko> sorry, impossible
<cjwatson> Certainly not
<cjwatson> Somebody could write a script with a blacklist, for instance
<doko> "somebody"
<cjwatson> The MIR team has never effectively communicated the list of binaries they didn't want in main to the archive team
<cjwatson> So if binaries that you didn't want stayed out of main, it was by purest luck
<doko> well, I think we should have such a list
<cjwatson> Patches to component-mismatches would be a reasonable way to implement such a blacklilst
<cjwatson> And I think it would be a good idea
<cjwatson> But I really think this Launchpad change is a very substantial net positive
<jelmer> TheMuso: no, none of the three associated bugs have a comment about it
<cjwatson> The number of binaries from sources in main that we don't want in main is a tiny fraction of the total
<micahg> +1, all the new firefox/thunderbird langpacks won't need component massaging
<cjwatson> It pretty much has to be since hardly anyone knows what it is
<cjwatson> langpacks, new libraries, kernel packages in SRUs (the kernel team had gone so far as to create a watchdog bot to make sure that overrides were right!), ...
 * xnox now if the watchdog bot is negated, doko will get the underdog bot he wants =))))
<doko> go play volley ball ...
<cjwatson> doko: It'd be worth at least filing a bug on ubuntu-archive-tools about this; Ursinha is looking for tools work to do :-)
<doko> ok, will do tomorrow
<doko> today, later
<slangasek> doko: I don't know the answer to whether we would need such unversioned -dev packages to be M-A: same; it would depend on what is going to depend on them (or build-depend on them)
<doko> well, are packages with a b-d on gfortran currently cross-built?
<slangasek> currently, no
<doko> but it works for g++, because it's assumed to be available
<doko> anway, afk now
<hallyn> mahmoh: thanks - hope you're having a blast :)
<slangasek> persia: marking your WI on https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-schedule 'done', since I understand from ScottK that this has already happened
<RobOakes> Good morning. Does anyone know where I might find an example of how to create a provider plugin for Ubuntu Online Accounts?
<RobOakes> I've been working on a desktop app that integrates with ownCloud, and would love to be able to use Online Accounts for managing credentials/integrating with other apps.
<RobOakes> I found the developer API documentation, but not a working example which I could modify to fit my own needs.
<jbicha> RobOakes: Empathy, Gwibber, and Shotwell all use UOA in Ubuntu
<RobOakes> Okay. I suppose I need direction to two resources.
<RobOakes> First, the application I'm developing integrates pretty tightly with ownCloud, which does not yet have a plugin for Ubuntu Online Accounts.
<RobOakes> Do you know if it is possible to write/install custom plugins for Ubuntu online accounts? This seems to imply that you can: http://developer.ubuntu.com/api/ubuntu-12.10/python/AccountPlugin-1.0.html
<RobOakes> But the docs are pretty sparse. I'd really like to look at an example to get up and running.
<pitti> Good morning
<ion> that
<zyga> james_w: I see, thanks
<zyga> james_w: I'm not an expert on either pkgme nor py3k packaging but I'm faced with maintaining some packages and I'd like to do it right
<zyga> james_w: there are also hybrid packages (2.*+3k) but they are more complicated and, fortunately, not my task today
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hi pitti
<zequence> I'm looking at http://dep.debian.net/deps/dep3/ and  https://wiki.ubuntu.com/PackagingGuide/PatchSystems?action=show&redirect=UbuntuDevelopment%2FPatchTaggingGuidelines#Patch_Tagging_Guidelines.
<zequence> Where does the meta go?
<zequence> Or, where do the dep3 headers go, more specifically?
<zequence> Say, I add a patch with edit-patch. How do I bake in the dep headers?
<zequence> Just add it manually to debian/pathches/<mypatch> ?
<diwic> zequence, I've always added it by manually editing the file. Maybe there is some simpler way.
<diwic> zequence, most patch tools, e g quilt, does not overwrite the headers when refreshing, which helps
<zequence> diwic: Thanks. I'm currently working on patching jackd2. Will be my first patch.
<zequence> diwic: There are a couple of upstream commits that fix the bug where jackdbus doesn't stop properly
<zequence> At least it makes qjackctl able to start jack after attempting to stop it
<diwic> zequence, that's good to hear
<zequence> So, I'm patching raring with it (don't know when next upstream version of jackd2 will arrive, which would include that fix), and then I'd like to get the fix also into 12.10 and 12.04
<mlankhorst> anyone on the sru team can help me out a bit?
<xnox> mlankhorst: as per https://wiki.ubuntu.com/StableReleaseUpdates#Publishing bdmurray ^
<mlankhorst> yeah was just loooking
<mlankhorst> bdmurray?
<Laney> you might have to wait until a bit later :-)
<mlankhorst> yeah
<mlankhorst> I want to start uploading the new version fo unrenamed packages for the lts update
<mlankhorst> https://lists.ubuntu.com/archives/ubuntu-x/2012-November/001238.html
<mlankhorst> but I don't know whether that has to go through SRU or not, and what the paperwork is I need for that. :)
<mlankhorst> sru vs technical board I mean
<doko> cjwatson, infinity: https://launchpad.net/ubuntu/+source/gccgo-4.7/4.7.2-0ubuntu2
<doko> do you understand the message? builds fine locally on p. the only thing odd is an empty Architecture field for the libx32go* packages (which are not built)
<infinity> doko: The error message seems reasonably clear.
<xnox> doko: but the Architecture field is mandatory on the binary package.
<doko> infinity, dude, I wouldn't ask if it was clear to me
<infinity> doko: It's the pkg-create-dbgsym version of dh_strip that's complaining, BTW, which is why you're not reproducing, I suspect.
<doko> ahh
<doko> pitti, trying to be holier than the pope ...
<infinity> Heh.
<infinity> But yeah, the empty Arch line is the problem, reading the code.
<xnox> doko: export NO_PKG_MANGLE=1
<infinity> xnox: Eww, no.
<xnox> doko: in e2fsprogs: # no chance that pkg-create-dbgsym can cope with this package's manual construction of -dbg
<xnox> doko: if you construct the dbg packages yourself, this should be fine.
<doko> I think that would be possible, because there are -dbg packages built anyway
<infinity> xnox: NO_PKG_MANGLE turns off more than just ddeb creation. :/
<xnox> infinity: I know, but there is no variable just to turn off ddebs =`(
<doko> and I don't care if gccgo itself has debug information
<xnox> infinity: would `NO_PGK_MANGLE=1 dh_strip` work?
<pitti> ah, that's because of my super-advanced shell parsing of debian/control :(
<infinity> xnox: Yes, that would work.
<pitti> xnox: yes
<xnox> pitti: and python-debian/apt was not around back then ? =/ I can feel your pain.
<pitti> xnox: it's more an issue of avoiding too many/circular dependencies
<xnox> yeah....
<pitti> that said, a missing Arch: line sounds relatively easy to fix
<pitti> we had packages with a duplicate Arch: line, which are really broken
<infinity> pitti: Empty, in doko's case, which seems broken anyway.
<infinity> (Missing is also broken)
<infinity> But yes, congrats on writing a tool that's more pedantic than dpkg. ;)
<xnox> infinity: I wonder if there is a message encoded in that field in whitespace: tab-tab-space-tab...... =))))
<infinity> doko: I'd either remove the libx32 stanzas from control completely, or give them a bogus arch (the former seems saner).
<brendand> aufs mount failed on todays build?
<doko> infinity, reupload gccgo-4.7
<xnox> brendand: yeap. known problem, but probably we should find a bug number and link it on the iso tracker or something.
<Laney> I pinged about that in #-kernel earlier - perhaps apw knows of a bug #
<brendand> xnox, probably isn't good either that usb-creator-gtk segfaults at the end of writing the image
<apw> Laney, i don't know of a bug number indeed (for the overlayfs/aufs issue) perhaps you could file one for me
<apw> Laney, if its not that, remind me
<Laney> tis
<Laney> brendand: could you?
<Laney> I'm not running the right kernel atm
<brendand> xnox, apw, Laney - does it have to be with ubuntu-bug??
<apw> brendand, nope, just a +filebug will do
<zequence> diwic: Would you mind reviewing my branch, and advise before I request a merge for lp:~zequence/ubuntu/raring/jackd2/fix-for-956438
<awpeter_> hey guys, i had a real problem installing nvidia drivers now because i couldn't disable nouveau no matter what i tried (purge remove package, blacklist in modprobe) the finally i disabled nouveau on the kernel line in grub with "nouveau.blacklist=yes", so my suggestion is you complement the normal blacklisting with disabling nouvau from grub so other people can avoid this problem
<awpeter_> also i mean: disable it when someone is installing an nvidia driver, and remove it again when you remove the nvidia driver, should be easy to implement and would solve a problem imo
<apw> awpeter_, i am unsure how blacklist can not work in this scenario, tseliot did you see this in your testing
<awpeter_> i tried really
<awpeter_> even the nvidia installer
<ogra-cb_> apw, it could cause issues if regenerating the initrd failed
<awpeter_> added his own file to modprobe
<ogra-cb_> or didnt happen at all
<tseliot> awpeter_: disabling it in the initramfs is usually enough
<apw> those drivers shouldn't be in the initrd for the basic case
<ogra-cb_> apw, plymouth doesnt use them ?
<apw> plymouth isn't in the initrd by default
<tseliot> awpeter_: mixing the nvidia installer with the ubuntu packages will break your system though
<ogra-cb_> no, but to get the right framebuffer device the right module needs to be loaded
<brendand> jeez, now the image isn't even booting. just the flashing cursor - same image and everything
<apw> ogra-cb_, and that occurs in the real root
 * ogra-cb_ thought we do that in initrd
<awpeter_> tseliot i had the ubuntu packages removed before i installed nvidia
<tseliot> ok
<apw> only if they have like encrypted root where we need to interact with them before root is available
<diwic> zequence, ok, will do in a little while
<apw> awpeter_, so this is installing a random nvidia download ?
<ogra-cb_> well, ir if some initrd hook sets FRAMEBUFFER_true
<ogra-cb_> *or
<ogra-cb_> FRAMEBUFFER=true
<apw> indeed, still not the default case
<awpeter_> apw well not a random, the newest nvidia driver avaiable from nvidia's site
<awpeter_> 310.19 i think
<awpeter_> was released 2 days ago or so
<apw> awpeter_, it is not clear how we are meant to have control over that ?
<zequence> diwic: No hurry. PM me if you have any suggestions, etc.
<awpeter_> apw i tried to install via jockey and it failed too
<awpeter_> so i suppose jockey had the same problem, that nouveau didn't unload
<awpeter_> i mean jockey installed but the driver didn't work
<awpeter_> let me clarify, i first tried to install via jockey
<awpeter_> then removed everything
<awpeter_> and tried via nvidia and nvidia's instller told me that nouveau was still loaded and he can;t continue
<apw> awpeter_, so if you can install the nvidia driver and then grab the blacklist it made, i would like to see that, and file a bug against, erm, well i guess kmod for now and attach the blacklist saying it doesn't work; and get me the number
<awpeter_> apw uh.. i removed the files and made the blacklist file myself to be sure.. also this is working now so to reproduce it i would have to remove the blacklist from grub, update grub, reboot, etc.. =d
<apw> awpeter_, your call, as the blacklist in modprobe should work
<awpeter_> apw just a question, if update-initramfs wouldn't work, would the blacklist do anything?
<apw> awpeter_, i believe you do need to have a rebuilt initrd to get the blacklists
<apw> hmmm, is that 100% true
<awpeter_> apw just to be clear i'm on elementary luna, but i asked there and they said that they don't change any tools from ubuntu
<apw> awpeter_, as nouveau is in the initrd you would have to rebuild that after installation of nvidia i suspect to get the blacklists included if they have changed
<apw> awpeter_, i suspect that the nvidia downloader should be doing that
<apw> if you get bored you could confirm that doing that sorts you out
<awpeter_> apw and i tried to run "sudo update-initramfs -u" but it did nothing
<awpeter_> apw so i suppose there was the problem
<apw> awpeter_, did nothing as in nothing happened at all, or nothing got better
<awpeter_> nothing happened, i hit enter and it didn't process anything
<awpeter_> just went straight back to cmd line
<apw> apw@dm:~/git2/linux$ sudo update-initramfs -u
<apw> [sudo] password for apw:
<apw> update-initramfs: Generating /boot/initrd.img-3.5.0-18-generic
<apw> well that sounds like something else is broken as it does for me
<awpeter_> yeah
<apw> so perhaps it does even do the right thing
<awpeter_> and i don't want to confuse anybody here but i asked on elementary-dev
<awpeter_> and somebody said there they don't change the tools
<awpeter_> so it should work like it does on ubuntu 12.10
<awpeter_> and updating initram clearly doesn't work for me
<awpeter_> so now i don't know if it's their problem or ubuntus =d
<awpeter_> or even mine x)
<OdyX> tkamppeter: you there?
<OdyX> tkamppeter: you know that openprinting forums are not responding ? At least the forums.openprinting.org address that is pointed at by linuxfoundation.org fails.
<OdyX> tkamppeter: do you have contacts @ Brother ? It'd be vastly better if they could release their lpr stuff in a more liberal license than "open-source distribution but you only get binaries"
<hrw> argh. eglibc now needs libselinux
<mahmoh> hallyn: np - I'm trying :)
<brendand> apw, i'm raring (:P) to raise this aufs overlay bug, but i forget what the message was and now the image is mysteriously not even getting as far as it did before. do you happen to recall the error shown?
 * brendand wonders is his netbooks hdd trashed?
<apw> brendand, nope
<apw> brendand, just file a generic bug, and i'll figure it out
<brendand> apw, crap
<brendand> apw, ok
<brendand> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1079193
<ubottu> Launchpad bug 1079193 in linux (Ubuntu) "aufs overlay error shortly after starting installer" [Undecided,New]
<cjwatson> apw,brendand: Well I mean we shouldn't be touching aufs at all - TheMuso said last night that overlayfs was missing, I assume you've got that far?
<apw> cjwatson, yes, i am on the case, i have some builds in testing right now to resolve these issues
<apw> cjwatson, the bug is mearly to allow linking to the iso-tracker
<cjwatson> Cool
<ScottK> xnox: Are you fixing python3-defaults?
<ScottK> (bad symlink)
<xnox> ScottK: I only confirmed it.
<xnox> ScottK: it is urgent?
<ScottK> I'm not sure if anything uses that link or not.
<ScottK> Should be easy enough to fix.
<ScottK> I'll do it if you aren't already.
<brendand> cjwatson, i just saw aufs mentioned in the error, sorry if that wasn't accurate
<brendand> 'aufs mount failed'
<xnox> ScottK: well if anything is using it, it's still screwed cause there is no more "mu" build, only "m" build is left.
<xnox> ScottK: and the new correct symlink should be "python3m"
<xnox> ScottK: so it's moot point.
<ScottK> Right.
<xnox> ScottK: the fix should be done in debian's svn python3-default, as it affects them as well.
<ScottK> Not yet it doesn't.
<ScottK> But you're right, it will.
<xnox> ScottK: affects "upstream" code-base, I know they didn't switch yet.
<ScottK> It looks to me trivial to fix once 3.3 is the default, but work required to make it OK with either 3.2 or 3.3, so I'll just fix Ubuntu for now.
<xnox> ScottK: i wouldn't.
<ScottK> Why?
<xnox> doko: have you seen bug 1079159 ? ScottK is eager to monkey patch it in ubuntu.
<ubottu> Launchpad bug 1079159 in python3-defaults (Ubuntu) "broken symlink to python3.3mu" [High,Confirmed] https://launchpad.net/bugs/1079159
<xnox> ScottK: as I said the fix should be done right in debian upstream.
<cjwatson> brendand: It's accurate because casper will fall back to aufs if it can't find overlayfs
<cjwatson> brendand: But the solution we want is to fix overlayfs
<ScottK> doko: moneky patch/fix debian/rules.
<xnox> ScottK: and there is no evidence it's causing any problem to anyone because (a) they shouldn't rely on it (b) it will be dropped anyway and (c) there is no rush to introduce a brand new symlink
<ScottK> Why will it be dropped anyway?
<ScottK> The current dangling symlink is definitely wrong.
<xnox> ScottK: there is no "u" build types in python3.3 anymore upstream.
<xnox> and the python3 symlink is correct and points to a working python3.3
<ScottK> xnox: Sure.  I changed it to properly be python3m -> python3.3m
<ScottK> I dropped all the "u"s (and there are several).
<ScottK> Including some "dmu"s.
<xnox> ScottK: "it will be dropped anyway" i mean the "3mu" droppped, not the general case of $python$version$abiflag
<xnox> =))))
<ScottK> Ah.  Then we agree about the proper end state.
<ScottK> I did not add a link that points python3mu -> python3.3m.  That would be wrong.
<xnox> ..
<xnox> is there an easy way to query launchpad to give me all versions of a source package ever published in any ubuntu series/pockets?
<ScottK> Fixed.
<geser> xnox: have you tried the LP API? archive.getPublishedSources() should help your further (pick source_name, distro_series, pocket as needed)
<xnox> geser: slowly getting there. Did not realise a hop from distribution["ubuntu"] -> archive[0] for primary....
<geser> I usually use distribution['ubuntu'].main_archive to get the Ubuntu archive object
<mitya57> xnox: https://launchpad.net/ubuntu/+source/PACKAGE/+publishinghistory ?
<xnox> mitya57: i need it on the command line ;-)
<xnox> geser: ah nice. thanks.
<xnox> geser: got it now.
<ScottK> Sweetsha1k: Would you please reupload boost-mpi-source1.49 with the bug in debian/changelog.
<ScottK> (quantal-proposed)
<cjohnston> Laney: ping
<Laney> hi
<cjohnston> Laney: trying to follow up on bug #1020592, it's still fix committed, but doesn't seem to be available yet?
<ubottu> Launchpad bug 1020592 in Precise Backports "Please backport django-openid-auth 0.4-1ubuntu1 (universe) from quantal" [Undecided,Fix committed] https://launchpad.net/bugs/1020592
<Laney> cjohnston: seems to be in precise-backports?
<Laney> python-django-auth-openid | 0.4-1ubuntu1~ubuntu12.04.1 | precise-backports/universe | all
<cjohnston> ahh.. nvm.. sorry.. was searching openid-auth not auth-openid
<Laney> heh
<cjohnston> in that case, it can be marked fix committed correct?
<Laney> so that bug should be fix released
<cjohnston> sorry, released, yes
<cjohnston> forgot I changed the package name too. lol
 * cjohnston needs to cleanup his backlog of trying to get things backported
<tkamppeter> OdyX, I have aded you to the printing team on LP now.
<OdyX> tkamppeter: yeah; I don't really know what it can be useful for, but well :-) Did you see my request about Brother above ?
<tkamppeter> OdyX, I have contacts to Brother, but for me it seems that they have driver code which they want to keep secret (partially bought from third parties) and open source wrappers to integrate the drivers into Linux environments.
<GunnarHj> SpamapS: ping?
<doko> ScottK, xnox: thanks
<ScottK> doko: You're welcome.
<OdyX> tkamppeter: it would be already better if they put all these binaries in nice tarballs that we could package to non-free e.f
<OdyX> tkamppeter: same for the cupswrappers, which are free software.
<OdyX> tkamppeter: I kinda-understand the need to keep driver stuff private, but it makes their printers x86-limited and badly supported in Linux currently.
<OdyX> tkamppeter: the best would be for them to hire someone to do some linux'ish / FLOSS consultancy for the handling of these drivers; I think they can see an interest in having their printers work out-of-the-box on Linuxes.
<tkamppeter> OdyX, yes, my HP printers work even on an ARM-based Nexus 7 running Ubuntu.
<OdyX> tkamppeter: anyway, to make longs things short: if we can get them release non-free stuff in a better way than hidden in rpms and behind useless GPL click-through, we could have their stuff packaged and shipped in non-free/multiverse, for their benefit.
<OdyX> tkamppeter: if you have contacts, I'd be grateful if we could get in touch with them in that direction, I'd be happy to be involved on the technical side.
<OdyX> (as installing a Brother printer using stupid  debian packages today annoyed me highly)
<OdyX> tkamppeter: ah, my other concern was the forum.openprinting.org, linked from linuxfoundation.org, but not accessible :)
<tkamppeter> OdyX, I need to re-install that.
<OdyX> tkamppeter: ah okay, as long as you're aware.
<OdyX> tkamppeter: for this Brother thing, is that something you plan to do or you'd prefer to let me handle it (using your sicritz contacts) ?
<OdyX> you have the linuxfoundation lever, probably longer than my debian lever :)
<_val_> Hi. Thanks for packaging the spice-xpi plugin for mozilla firefox. There seems to be a bug. Is someone aware of this bug?
<smartboyhw> _val_, then report a bug against it......
<_val_> smartboyhw: Problem is that it only shows to dismiss or report the bug. When clicking on the link to report the bug it explains what a bug is.
<smartboyhw> _val_, what?
<_val_> smartboyhw: going to make another attempt :>
<achiang> hi, in general if a lower level library gets updated in the archive, does that necessarily imply a rebuild for all its rdepends?
<achiang> question applies for things like SRUs, security updates, etc.
<achiang> jdstrand: ^^
<SpamapS> Laney: re copying webkit.. its my understanding that we shouldn't be copying packages that have arch: any binary packages because the toolchain is newer in raring.
<OdyX> achiang: afaik no.
<jdstrand> achiang: not unless there is an abi change
<SpamapS> Laney: I assume this is especially important for armhf binaries
<jdstrand> achiang: and we very much try to avoid those in updates
<achiang> ah, that's good to know.
<achiang> so is that different from the early days of a release when the archive is rebuilding then? what is that all about?
<jdstrand> achiang: sometimes it is unavoidable, like with how we are updating webkit, but by and large, that is not the norm
<SpamapS> GunnarHj: pong, whats up?
<achiang> jdstrand: makes sense. but we do rebuild the archive for days at a time usually right before UDS, and i'd like to know what that's for. :)
<jdstrand> I think that is more bootstrapping the toolchain and libc and stuff
<achiang> so everything built afterwards *does* have the proper ABI, yeah?
<jdstrand> but yeah, there are abi changes in that process, so things have to be rebuilt
<SpamapS> achiang: thats for ABI library transitions too
<SpamapS> but sometimes there are library transitions later, and thats where you see smaller rebuilds
<jdstrand> achiang: but that is the dev release, not a stable release. different rules and processes there
<achiang> is there a convention in d/changelog or package name if an ABI change occurs?
<jdstrand> not that I know of
<achiang> hm, ok
<GunnarHj> SpamapS: Hi Clint, and thanks for uploading the fix of bug 875435 to quantal-proposed yesterday. There are branches with identical changes in the Precise and Oneiric queues. Would you mind to upload also those, in order to simplify the verification process?
<ubottu> Launchpad bug 875435 in OEM Priority Project precise "iBus indicator does not show on the panel" [Medium,In progress] https://launchpad.net/bugs/875435
<SpamapS> achiang: the convention is to name the library package after the ABI version. so for instance libmysqlclient18
<achiang> ah!
<achiang> ok
<SpamapS> achiang: and thats actually fairly important so that you can have the old one around to maintain installability
<achiang> jdstrand: SpamapS: thanks, makes sense
<SpamapS> GunnarHj: sure I'll review those now
<jdstrand> oh, that, yes :)
<GunnarHj> SpamapS: Great, thanks!
<Laney> SpamapS: hmm, I'm not sure, but anyway I've uploaded a new version to raring now
<Laney> thanks for considering it
<SpamapS> Laney: a lot of what I said is just my own perception. Others with more intimate knowledge of the archive state may have other opinions.
<micahg> _val_: I'm not aware of spice-xpi actually being in the archive
<mitya57> ScottK, xnox: I don't see why that shouldn't be committed to Debian. That affects only the default version ($(VER)), which is 3.3 in bzr version.
<mitya57> Also, as nobody wants to review my python-defaults merge, I've subscribed ~ubuntu-branches there.
<ScottK> mitya57: Sure (re Debian), but there's no rush.  Since I'm one of the maintainers there, I'll take care of it eventually.
<mitya57> OK.
<apw> cjwatson, just uploaded linux and linux-lowlatency with the union mounts issues fixed, building now; ppc is being prepared
<Laney> yay
<xnox> \0/ apw
<cjwatson> achiang: We don't rebuild the whole archive between release and UDS anyway - what you're seeing there is just syncs/merges of new versions of packages from Debian
<cjwatson> achiang: Rebuilding the whole archive would be very expensive for mirrors and would likely lose us mirrors, so we try to avoid it
<cjwatson> apw: Thanks
<achiang> cjwatson: ack, thanks
<trijntje> hi all. Where can I find a list of all packages that are visible in the default view of the software centre (ie, not the 'technical items')?
<DaemonicApathy> http://packages.ubuntu.com ?
<mitya57> trijntje, http://bazaar.launchpad.net/~ubuntu-core-dev/app-install-data-ubuntu/ubuntu/files/head:/menu-data/
<mitya57> see all .desktop files there
<ev> bdmurray, pitti: I've filed https://bugs.launchpad.net/apport/+bug/1079285 to come up with an approach for bucketing package installation failure errors
<ubottu> Launchpad bug 1079285 in apport (Ubuntu) "We cannot group package installation failures together" [Undecided,New]
<bdmurray> ev: there is this http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/apport/raring/view/head:/data/general-hooks/ubuntu.py#L103
<ev> oh nice
<ev> I had entirely missed that
<hallyn> zul: is there anything you can do to push bug 882485 (needs-packaging for sanlock which is already in debian)
<ubottu> Launchpad bug 882485 in Ubuntu "[needs-packaging] Sanlock" [Wishlist,Confirmed] https://launchpad.net/bugs/882485
<ev> bdmurray: do we get that untranslated?
<hallyn> zul: of course i'm not denying it'll next need MIR :)
<mitya57> hm, strings from PKG_MSGS *are* translated in dpkg
<bdmurray> ev: I'm pretty sure only update-manager sets DPKG_UNTRANSLATED_MESSAGES
<hankhendrix> hello, I'm wanting to edit the behaviour of "Changed Desktop Background" on the desktop context menu. Anyone know which package contains the source?
<ev> hmm
<ogra-cb_> hankhendrix, #ubuntu-desktop might be better suited for that question, i think it is gnome-settings-daemon though
<hankhendrix> nice one cheers
<ev> bdmurray: so we're definitely getting and bucketing them then: http://tinyurl.com/blsqa3a
<ev> perhaps we should do something about those incredibly long bucket IDs/URLs though :)
<bdmurray> probably
<zul> hallyn: sure
<zul> hallyn: sanlock is already in raring
<hallyn> oh??  i thought i just checked
<hallyn> zul: cool, thanks :)  "you work fast"
<zul> hallyn:  efficeny is a hallmark
<trijntje> mitya57: thanks, I'll check it out!
<ScottK> bdrung: Would you please fix wxwidgets2.8 in raring so the quantal SRU can be accepted?
<hankhendrix> does anyone know how to rebuild and test nautilus source?
<slangasek> ogra-cb_, stgraber: is bug #1077598 something that's fixed in later casper?  There seems to be a second report of the same, bug #1079266
<ubottu> Launchpad bug 1077598 in casper (Ubuntu) "package plymouth 0.8.2-2ubuntu30 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/1077598
<ubottu> Launchpad bug 1079266 in plymouth (Ubuntu) "package plymouth 0.8.2-2ubuntu30 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/1079266
<GunnarHj> SpamapS: Did you forget bug 875435? ;-)
<ubottu> Launchpad bug 875435 in OEM Priority Project precise "iBus indicator does not show on the panel" [Medium,In progress] https://launchpad.net/bugs/875435
<SpamapS> GunnarHj: indeed I did ;)
<SpamapS> GunnarHj: right after that I went on a tab-closing rampage and lost that one ;)
<GunnarHj> SpamapS: Ok, no problem. Do you have time now?
<SpamapS> GunnarHj: You need to re-do oneiric
<SpamapS> GunnarHj: 1.20ubuntu5.1 was the version used for precise
<SpamapS> GunnarHj: so you have to do a version lower than that. I suggest 1.20ubuntu5.0
<GunnarHj> SpamapS: The release versions are the same as well.
<SpamapS> GunnarHj: does not matter. The packages have to be lower version so that on upgrade the new packages are installed (toolchains, libraries, etc. etc)
<GunnarHj> SpamapS: Ok, I'll change it then. Moving to another partition, so I 'll be away from here for a while.
<SpamapS> GunnarHj: usually when doing a "same version but different distro" SRU you need to do something like 1.20ubuntu5.12.04.1 and 1.20ubuntu5.11.10.1
<GunnarHj> SpamapS: Ok, I had no idea. Would you like me to change the Precise branch as well?
<SpamapS> GunnarHj: no, precise is already accepted.
<GunnarHj> SpamapS: Ok, I changed debian/changelog in the Oneiric branch for bug 875435.
<ubottu> Launchpad bug 875435 in OEM Priority Project precise "iBus indicator does not show on the panel" [Medium,In progress] https://launchpad.net/bugs/875435
<GunnarHj> SpamapS: I.e. I changed https://code.launchpad.net/~gunnarhj/ubuntu/oneiric/im-switch/ibus-icon-in-menu_bar, not the one in the queue since I don't have upload rights.
<RobOakes> Can someone point me in the direction of a tutorial that shows how to use Ubuntu Online Accounts Integration?
<RobOakes> I'd really like to use it for an app that I am working on.
<RobOakes> Would the examples in Gwibber be the best place to start? (I'm using Python.)
<kenvandine> RobOakes, look at lp:friends (the gwibber-service rewrite)
<kenvandine> RobOakes, and https://docs.google.com/a/canonical.com/document/d/1MVsDdwzff6LqQ6i3z-cSgg8dHjb5DaHMXFeWtIa6Cvo/edit
<RobOakes> kenvandine: Thank you! This will be really helpful. I was looking for something like the docs last night and finally resigned myself to figuring things out from the examples shipped with Ubuntu.
<RobOakes> Having good documentation speeds everything up.
<kenvandine> indeed
<kenvandine> also check out #accounts-sso
<kenvandine> that is where the developers hang out
<RobOakes> Awesome. I'll do that.
<GunnarHj> SpamapS: Did you notice that I made the changelog change in https://code.launchpad.net/~gunnarhj/ubuntu/oneiric/im-switch/ibus-icon-in-menu_bar ?
<SpamapS> GunnarHj: no I wasn't watching the branch. Do you need me to upload that to oneiric-proposed?
<GunnarHj> SpamapS: Yes, I'd appreciate that since I don't have upload rights to the queue either.
<SpamapS> GunnarHj: ok, uploaded, will approve shortly
<GunnarHj> SpamapS: Thanks a bunch, Clint!
<ogra-cb_> slangasek, hmpf, i thought that was fixed, yeah, its surely a duplicate
<stgraber> ogra-cb_: both of those systems appear to be wubi installs on lucid doing an lts-to-lts upgrade to 12.04. My guess is that the fixes that landed in casper for that kind of usecase don't exactly cover this one.
<stgraber> ogra-cb_: anyway, don't waste time on this, I'm already poking at it :)
<ogra-cb_> ah, k
<ogra-cb_> well, i dont have much to do until the nexus kernel is there and we have an arm builder again
<ogra-cb_> but i didnt plan to look right now anyway
<infinity> ogra-cb_: The nexus kernel is there.  Not sure about the progress on the livefs builder, though. :/
<ogra-cb_> infinity, well, there was a cased panda overnighted to the DC, it should be up tomorrow
<ogra-cb_> (which likely will require some cdimage changes, i doubt they'll keep the name)
<ogra-cb_> infinity, and thanks for the kernel !!!!!!
#ubuntu-devel 2012-11-16
<darkxst> Sarvatt, I fixed ppa-purge to work on multi-arch, and it works perfectly with apt-get, but when I tested with aptitude not only did it remove the ppa, but it also downgraded everything from quantal-updates
<darkxst> I think this might be a different bug, but wondering if you have ever seen that before
<dholbach> good morning
<infinity> doko_: I note that binutils-gold is falling out of main in component-mismatches.  I assume that just means nothing build-deps on it currently.  Do we want to seed it explicitly, or are you happy with it dropping to universe?
<infinity> doko_: platform/supported-development-common seems like a sane place for it, if we want to keep it in main.
<hrw> wookey, doko: good news - armhf cross compiler has most of issues solved
<diwic> If I have a package that's "Multi-arch: foreign", e g pulseaudio-utils (which only contains executables and no .so files, so I think that makes sense), how do I specify that for pulseaudio-utils-dbg only makes sense together with the same arch of pulseaudio-utils ?
<cjwatson> @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: cjwatson
<bdrung> ScottK: okay
<ogra_> would grep "^\([0-9a-z]\)\{8\}-\([0-9a-z]\)\{4\}-\([0-9a-z]\)\{4\}-\([0-9a-z]\)\{4\}-\([0-9a-z]\)\{12\}$" be a proper way to safely match a UUID ?
<ogra_> or is there any way the format of a UUID could be different than 8-4-4-4-12 on ext2/3/4 ?
<xnox> ogra_: that should be fine for ext2/3/4
<ogra_> great, i found a better fix than this insanity though :)
<ogra_> but its good to keep for the next time i need something like that :)
<xnox> ogra_: note that other filesystems generate (pseudo) uuid-like identifiers that are shorter.
<ogra_> yep, i know, at least for vfat i do
<ogra_> though luckily our installer wont allow you to install to vfat
<ogra_> (i hope at least, else the install would fail later anyway)
<rickspencer3> msf sforshee hey, would it still be helpful if I installed the mainline kernel?
<rickspencer3> oops
<rickspencer3> nice pm
<sforshee> rickspencer3, heh
<sforshee> rickspencer3, it's always good to know whether the bug still exists upstream. I suspect you'll find that it does, since this device seems to have been broken for a long time now.
<sforshee> rickspencer3, I'll probably also build a kernel for you with extra debug enabled. I could make it a raring kernel so you could also do the upstream testing at the same time.
<rickspencer3> sforshee, perfect
<gnutun> hey all; it appears there's a packaging bug introduced in quantal, where libavutil-dev depends strictly on libavutil51, instead of libavutil51 | libavutil-extra-51; this prevents both the extra libav libs and dev files from being installed simultaneously
<gnutun> yup, looks like the bug was already reported, nm
<jtaylor> siretart: ^
<xnox> gnutun: bug number?
<jtaylor> its a known issue
<jtaylor> unfortunatly I think the solution is delayed to 13.04
<jtaylor> or later
<gnutun> jtaylor, oh wow
<gnutun> bug 1038781
<ubottu> Launchpad bug 1038781 in libav (Ubuntu) "-dev packages are missing alternate depends on -extra packages" [Low,Triaged] https://launchpad.net/bugs/1038781
<gnutun> https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1038781
<xnox> gnutun: fix in raring first, then SRU into quantal.
<gnutun> ok, i think i'll throw a fixed package in my ppa for now
<gnutun> i had to write a script on my system to uninstall/reinstall these packages several times a day depending on what im doing
<gnutun> thx for the info
<roaksoax> jdstrand: howdy! So for the MAAS SRU to precise and in order to address the bugs you filed back then and get rid of cobbler, we need to SRU new packages that are not in precise. How do you feel about that (from the security team stand point)
<bdrung> ScottK: uploaded
<jdstrand> roaksoax: that is fine. I discussed this with flacoste some time ago
<jdstrand> it is unusual, but in this case, ok
<roaksoax> jdstrand: awesome then!
<roaksoax> thanks
<janimo> cjwatson, what fraction the effort for a full wubi port to nexus7 would be making a bootimg/initramfs that boots off a loopmounted file in the android data partition?
<janimo> and that boot img put in recovery so both can be selected from the bootloader
<cjwatson> the initramfs part is basically just adding lupin-casper
<cjwatson> but I think to do it sanely we need to get the grub port in first
<cjwatson> otherwise we end up in copy-out-the-kernel hell and it's all a mess
<cjwatson> and we'd want a boot menu anyway
<cjwatson> I wasn't suggesting it as a "hey, we can do this right now" thing :-)
<cjwatson> but it seems like something rather handy that might be worth a look
<janimo> cjwatson, I know, I just thought about this before, without knowing what the technical blockers are
<ogra-cb> me would be a technical blocker for raring at least :)
<ogra-cb> i think we should do it, but not this cycle
<janimo> I was just hoping there was an easy way to tell the kernel that root is not a device but a file on a filesystem and be done :)
<cjwatson> that's basically what lupin-casper arranges for
<ogra-cb> (enough other stuff to do and it needs more research and testing etc)
<cjwatson> the initramfs side is by this point fairly easy
<cjwatson> but you need the boot loader to be able to get at the kernel/initrd too
<cjwatson> which either means (a) copy it out to the containing fs (we tried this before, it more or less worked for a few cycles but was really a big bag of no fun at all) or (b) grub2 which is smart enough to unpick things
<janimo> cjwatson, but the boot images are zImage+initrd does that not mean they are already seen by the bootloader?
<ogra-cb> you can surely make it just work with abootimg somehow
<cjwatson> I guess you're already flashing them which amounts to copying them out, yeah
<ogra-cb> but if we can have a proper way typo chainload grub and adapt that across alll bootloaders some day, thats definitely better
<cjwatson> in the sense of flash-kernel
<ogra-cb> s/typo/to/
<ogra-cb> funny typo, tsk
<janimo> ogra-cb, having grub and consistency is great, I am just wondering if grub is a requirement at all. I may actually need to read lupin-casper before just assuming things though :)
<ogra-cb> so imho we should inspect the opportunity this cycle and lay the foundations for next release
<cjwatson> well, in that case it's a matter of adding lupin-casper and figuring out how to make the installer create a big file rather than a new filesystem
<cjwatson> but you still need something to offer a boot menu
<cjwatson> otherwise not a lot of point in dual-booting
<ogra-cb> right
<janimo> cjwatson, I was thinking of a less friendly way of using the device
<janimo> device's boot menu
<ogra-cb> which means hw related hacks depending on what keys your device has
<janimo> and have android and ubuntu use linux and sos partitions
<janimo> so leave android boot as it
<cjwatson> I gathered that using the recovery partition was possible; it just struck me that it'd be nicely non-invasive not to have to use that
<janimo> and put an ubuntu loader that looks for a loopmounted file in UDA to recoveyr
<cjwatson> since it kind of seems like a misuse of the recovery partition?
<janimo> cjwatson, at the moment recovery is unused 'officialy' so would be ok
<janimo> and also easy to reflash anytim
<janimo> ogra-cb, I am only thinking of the nexus7 now, not long-term dual boot which indeed should be better thought out and nicer
<janimo> just so we get many more testers who are otherwise unwilling to buy a lovely device just to have a not-yet-working ubuntu on it
<janimo> and for hw/kernel debugging having an android to compare behaviour against is a win as well
<ogra-cb> well, i wont change the image design right now
<cjwatson> janimo: right, those were very much my motivations in thinking about this
<janimo> cjwatson, right it is a misusre of recovery, but since we assume unlocked devices, we have fastboot to do recovery and random flashing
<ogra-cb> there are to many bits that rely on it (usb-creator etc) but i agree that we should have a plan ... bonus points if we can do it with the current design or something close to it
<cjwatson> @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:
<ogra-cb> the prob i see with the lupin approackh is that you have to somehow teach the android side to work with it as well
<cjwatson> Do you?
<ogra-cb> and android kind of relies on the same hardcoded crap flash-kernel assumes today
<ogra-cb> so a kernel update would be written to mmcblk0p2
<ogra-cb> overwriting your menu/initrd
<ogra-cb> iirc it looks at labels instead of device names so one could probably swap recovery and boot labeling or so
<ogra-cb> but given that the partition table is usually kind of hardcoded as GPT inside the bootloader that wont be easy either
<infinity> ogra: By the way.  You haven't filed an MIR for anrdoid-whosit-whatever, and livecd-rootfs is uninstallable.
<ogra-cb> oops, will do now
<infinity> ogra-cb: You might want to do some of the MIR legwork too, not just file it, if you have any hope of seeing it promoted this year. :P
<ogra-cb> well, i'm not in the MIR team
<ogra-cb> i'll do what i can though
<infinity> ogra-cb: Anyone can do the research and post the results, it's only the MIR team that can do the final approval, that's all.
<bryceh_> is there a way to install sru packages that are in the Unapproved queue?  (I.e. so I can test the package while it's waiting)
<mlankhorst> pbuilder-dist ?
<xnox> bryceh_: it's source only, so you can download them of launchpad, then build then install.
<patr|ck> hello, when i try to report a problem regarding the i965 "sandy bridge" graphics chip where the packages kernel, mesa, libdrm, libva-intel and xf86-video-intel are affected i want to ask, which one do i choose for the bug report?
<ogra_> infinity, bug 1079796
<xnox> bryceh_: https://launchpad.net/ubuntu/raring/+queue pick correct queue & package, download the .dsc
<ubottu> Launchpad bug 1079796 in android-tools (Ubuntu) "[MIR] please move android-tools-fsutils to main, make_ext4fs is needed for arm image builds now" [Undecided,New] https://launchpad.net/bugs/1079796
<ogra_> infinity, anything else i could add or do to speed it up ?
<bryceh_> patr|ck, just file against 'xorg'.  we'll figure it out.
<patr|ck> okay, thanks
<bryceh_> patr|ck, it's generally impossible to know ahead of time which package is the faulty one
<bryceh_> xnox, hmm, right was hoping for more magick there ;-)
<infinity> ogra_: That should do for now.
<ogra_> great
<cjwatson> bryceh_: the 'queue' tool in lp:ubuntu-archive-tools can fetch them
<xnox> cjwatson: \0/ this changes my world
<bryceh_> cjwatson, thanks
<patr|ck> i must say, the way ubuntu-bug and launchpad.net work is plain awesome. big achievement :-)
<doko> Sweetshark, the boost packages are now built for quantal. please validate these
<Sweetshark> doko: willdo
<siretart> jtaylor: yes, I'll work on that in my next upload to quantal. I'm currently busy with https://launchpad.net/~motumedia/+archive/libav9-raring/ though, help more than welcome, btw. however, since progress on that transition is rather slow, I guess I'll upload 0.8.4 to raring nevertheless soon
<doko> ogra-cb, does android-tools need seeding?
<cjwatson> livecd-rootfs already depends on it on armhf, so I shouldn't think so
<ogra-cb> doko, what cjwatson said
<bryceh_> @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: bryceh_
<infinity> bryceh_: If you change your nick to one without an underscore, can I no longer bug you to pilot?
<bryceh_> you always welcome to bug me to pilot infinity
<bryceh_> @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:
<morphias> guys i am having trouble building an application package. http://paste.ubuntu.com/1363476/ is the output from building it and i dont know what to do exactly to get the deb built...
<sarnold> morphias: I'd try again in a directory that does not contain a space in the directory name.
<morphias> kk ill try that
<morphias> sarnold, yey... now it says "secret key not available"
<morphias> but it produced the deb
<sarnold> morphias: woot. :D
<morphias> now i went through the effort of creating a gpg key last night... how do i get it built to sign it or is that not needed (something tells me its needed)
<morphias> sarnold, should i post the output of what occured?
<infinity> No need to sign local package builds.  That said, "-uc -us" should have skipped the signing bits.
<morphias> infinity, oh... but if a package gets distrubuted, should it be signed? (btw, I just figured it out, I had to add my nickname into the changelog)
<infinity> morphias: Generally, if you're distributing, you either sign your archive, or if you're uploading just the source/binaries somewhere, you sign the .changes and the .dsc.
<infinity> morphias: -uc makes dpkg-buildpackage not sign changes, -us makes it not sign the .dsc
<morphias> yeah that is what the debuild did for me
<infinity> After an unsigned build, "debsign *changes" will sign it, if you want it to be so.
<morphias> well now i got to hunt down yet another bug. hehe... this is my first time doing this
<morphias> i got a "terminate called without an active exception" error thrown
<barry> sbuild is making my cry today.  i'm trying to build a package in a sid chroot (where python2.6 is supported).  python-argparse is a b-d and i can see it getting past the "Merge Build-Depends" stage, but then apt in the chroot simply doesn't install it. :(
<barry> and yes, jumping into the chroot and `apt-get install python-argparse` works :/
<infinity> ogra-cb: Your latest livecd-rootfs upload isn't committed/tagged in bzr.
<infinity> ogra-cb: pls to fiz before I go staging something else. :)
<infinity> s/fiz/fix/
<ScottK> bdrung: Thanks.
<ScottK> bdrung: Accepted.
<infinity> barry: Are you sure it's not provided by something else that's installed?
<infinity> barry: Like, I dunno, python2.7?
<infinity> barry: A versioned build-dep would be more correct there (since it's entirely valid for both sbuild and apt to say that your unversioned build-dep is satisfied by python2.7)
<infinity> barry: Not sure if a versioned build-dep will fix it, but if not, THAT's a bug. :P
<barry> infinity: yeah, i thought about that.  but unless i'm missing it, 2.7 under sid doesn't claim to provide it:
<barry> grep argparse sid/debian/control
<barry> (returns nothing)
<infinity> barry: Oh, I wasn't looking in sid.
<infinity> Err, yes it does.
<barry> yeah.  raring is all like happy happy joy joy
<infinity> Provides: python-argparse, python2.7-argparse ...
<infinity> In my sid chroot.
<barry> oh craptasm.  i grabbed the wrong branch
<infinity> Methinks you want apt-cache show, not an incomplete control file in the source.
<barry> no, it's in there
<infinity> Oh, or just read the right source, sure. :)
<barry> yeah, so now it makes sense ;)
<bryce> are there any SRU admins here today?  There is a jockey SRU for precise stuck in Unapproved.  I think RAOF meant to approve that along with fglrx-experimental-9 but overlooked it.  The jockey change allows the driver to actually be installed.  Could someone approve it?
<RAOF> bryce: Done. Sorry, I thought we had all the jockey changes already.
<bryce> RAOF, awesome, thanks.
<bryce> RAOF, yeah we need to get more organized with these driver updates.  it's too easy for bits to get skipped
<LyzardKing> what is kubuntu's status, being passed over to bluesystems?
#ubuntu-devel 2012-11-17
<cjwatson> doko: Did libgcj-bc's dependencies intentionally get flipped from libgcj13 back to libgcj12?
<cjwatson> doko: I can't see any sign of that in the diff, which is kind of odd
<cjwatson> doko: But you can see the effects on http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html
<doko_> cjwatson, my bad. merge error. now fixed
<simplew> anyone with packaging knowledge?
<tumbleweed> simplew: no need to ask to ask, just ask a question. Also you probably want to ask it in #ubuntu-packaging, rather than here, if it's unrelated to development of Ubuntu
<tumbleweed> oh, you already did, there
<cjwatson> doko: great, thanks
<jtaylor> infinity: was https://launchpad.net/ubuntu/+source/cython/0.16-1ubuntu1 forwarded somewhere?
<sebasmagri> Hi!
<sebasmagri> Any jockey/ubuntu-drivers-common developer in here?
<ScottK> sebasmagri: Probably not on a weekend.
<sebasmagri> ScottK: I see. Thanks anyway. I will be around.
<infinity> jtaylor: No, I probably should push that one to Debian but, I think, at the time I was considering actually finding and fixing the real bug, rather than sticking with the workaround.
<jtaylor> infinity: do you have a testcase?
<infinity> jtaylor: Oh, also, it looks like 1.17 no longer has the problem (looking at experimental build logs)
<infinity> jtaylor: So, I'll just sync current experimental and wash my hands of it.
<jtaylor> infinity: k, the sync fixes 812511 too
<infinity> jtaylor: Cheers, closed.  Annoying that MoM doesn't notice that we're tracking experimental and pop those on my radar, or I'd have updated a while ago.
<jtaylor> so the issue was only seen in a buildlog?
<infinity> jtaylor: Yes.  As in it failed to build on all arched with unsigned chars.
<infinity> s/arched/arches/
<jtaylor> why doesn't it fail in debian testing?
<jtaylor> was it only 0.16?
<infinity> jtaylor: It was 1.16 and the first 1.17 beta, 1.15 was fine.
<infinity> jtaylor: See, eg: https://buildd.debian.org/status/logs.php?pkg=cython&arch=powerpc
<jtaylor> k thx
<infinity> (Replace "powerpc" with "armel" or "sparc" to see the pattern)
<demosfere> Can someone help me? i'm having problems when building this recipe https://code.launchpad.net/~kedos-project/+recipe/bottomlauncher-daily , it gives me error No package 'dbusmenu-glib-0.4' found No package 'dbusmenu-gtk3-0.4' found , this is my buildlog : https://launchpadlibrarian.net/123265587/buildlog_ubuntu-raring-amd64.bottomlauncher_0.2.0-0-1~5~raring1_FAILEDTOBUILD.txt.gz
<jtaylor> demosfere: you need to depend on libdbusmenu-gtk3-dev
<demosfere> jtaylor: i've already did that
<jtaylor> demosfere: you have libdbusmenu-gtk3-dev (>= 0.6.2) | libcairo2-dev
<jtaylor> drop the or dependency
<demosfere> jtaylor: what exactly should i do?
<demosfere> jtaylor: can you pastebin control file after you fix it?
<infinity> demosfere: He told you how to fix it...
<infinity> demosfere: s/  | libcairo2-dev//
<demosfere> infinity: the problem is that this package is used in the app
<infinity> demosfere: Uhm.  What?
<infinity> demosfere: You build-depend on libcairo2-dev, AND you build-depend on libdbusmenu-gtk3-dev|libcairo2-dev.
<demosfere> infinity: the error is No package 'dbusmenu-glib-0.4' found No package 'dbusmenu-gtk3-0.4
<infinity> demosfere: libdbusmenu-gtk3-dev gets (correctly) ignored because you're already installing libcairo2-dev, which you claimed was an adequate substitute.
<jtaylor> demosfere: the error tells you the .pc file is missing
<infinity> demosfere: Thus, libdbusmenu-gtk3-dev isn't being installed.
<jtaylor> that .pc file is provided by libdbusmenu-gtk3-dev
<infinity> demosfere: So, drop the " | libcairo2-dev"
<jtaylor> see: apt-file list libdbusmenu-gtk3-dev | grep -E ".pc$"
<demosfere> infinity: i'll try and see if it work
<demosfere> infinity: jtaylor please stay here until i let you know if it works now :)
<infinity> demosfere: Uhm.
<infinity> demosfere: That was wrong. :P
<infinity> -               libcairo2-dev,
<infinity> -               libdbusmenu-gtk3-dev (>= 0.6.2) | libcairo2-dev,
<infinity> +               libcairo2-dev | libcairo2-dev,
<infinity> ^-- That won't fix anything...
<infinity> That should read, simply:
<infinity> libcairo2-dev,
<infinity> libdbusmenu-gtk3-dev  (>= 0.6.2),
<infinity> ---
<infinity> Minus the extra space there.  My keyboard's repeating, apparently.
<demosfere> infinity: i'm confused :P , what should i do now
<infinity> demosfere: You want to build-depend on libcairo2-dev and libdbusmenu-gtk3-dev, right?  This isn't any different from any of your other build-deps.
<infinity> demosfere: Having "foo | bar" means "either foo or bar is okay, we don't need both".
<infinity> demosfere: And having "foo | foo", when you also want bar (which is what you did to "fix" it) is extra strange.
<demosfere> infinity: now i'm totally confused :P
<infinity> demosfere: The fix you committed at http://bazaar.launchpad.net/~kedos-project/bottomlauncher-pkg/trunk/revision/7
<infinity> demosfere: You completely removed the build-dep on libdbusmenu-gtk3-dev
<demosfere> infinity:and this will make it work?
<infinity> Past tense.  You removED the build-dep.  You shouldn't have done that.
<infinity> You need libdbusmenu-gtk3-dev
<demosfere> infinity: so i should re-add libdbusmenu-gtk3-dev and then ?
<infinity> demosfere: The line that says "libcairo2-dev | libcairo2-dev," should just say "libcairo2-dev," and then you also want a line that says "libdbusmenu-gtk3-dev (>= 0.6.2),"
<demosfere> infinity: i think this is what you told me to do : http://pastiebin.com/?page=p&id=50a7ce358ac86
<demosfere> infinity: is it right ^
<demosfere> ?
<jtaylor> looks good
<infinity> I'd complain about the whitespace, but yeah.  That should do.
<demosfere> infinity: i'm pushing and building ... i'll let you know if it wrks
<infinity> Assuming nothing freaks out about the space between the ) and the comma, but probably not.
<demosfere> infinity: ^ you mean it's wrong and causes failure in building ?
<infinity> demosfere: For correctness, that space really shouldn't be there.  No idea if any of the tools parsing control will care, though.
<infinity> demosfere: As in, "libdbusmenu-gtk3-dev (>= 0.6.2) ," should be "libdbusmenu-gtk3-dev (>= 0.6.2),"
<demosfere> infinity: i'll remove after i make sure building works :)
<demosfere> infinity: offtopic , do you want to join my team?
<demosfere> infinity: failed to build https://launchpadlibrarian.net/123283341/buildlog_ubuntu-quantal-i386.bottomlauncher_0.2.0-0-1~5~quantal1_FAILEDTOBUILD.txt.gz
<demosfere> infinity: any idea?
<demosfere> jtaylor: ^^
<jtaylor> demosfere: I don't see libdbusmenu-gtk3-dev being installed, what did you build there?
<demosfere> Source: bottomlauncher Section: utils Priority: optional Maintainer: Drake Miller <dakemiller@gmail.com> Build-Depends: debhelper (>= 8.1.2ubuntu2),                gnome-common,                valac-0.18 (>= 0.18.0),                libbamf3-dev (>= 0.2.92),                libdbusmenu-gtk3-dev (>= 0.6.2) , 	       libcairo2-dev,                libgdk-pixbuf2.0-dev, 	       libdbusmenu-glib-dev, 	       libdbusmenu-glib4, 	    
<demosfere> jtaylor: this is the control file of the current revision : http://pastiebin.com/?page=p&id=50a7d2a687731
<infinity> The control file doesn't come close to matching the build-deps sbuild ends up looking for.  I'm inclined to blame whitespace here.
<infinity> Perhaps wrap-and-sort(1) would unbreak your issues.  Or you could more carefully rewrite that line.
<infinity> Though, not sure if it's smart enough to fix tabs/spaces and other things.
<demosfere> infinity: spaces doesn't making an error
<demosfere> infinity: i think the problem is by configure file in the source code
<infinity> No...
<infinity> The problem is that your build-deps aren't all being installed.
<infinity> Compare this to your control file:
<infinity> Build-Depends: debhelper (>= 8.1.2ubuntu2), gnome-common, valac-0.18 (>= 0.18.0), libbamf3-dev (>= 0.2.92), libcairo2-dev, libgdk-pixbuf2.0-dev, libgee-dev (>= 0.5.2), libglib2.0-dev (>= 2.28.0), libgtk-3-dev (>= 3.0.0), libwnck-3-dev, libx11-dev, libceleste-dev
<infinity> Note that it doesn't list everything listed in your control.
<jtaylor> infinity: cython failed :(
<demosfere> why it's not installing them?
<infinity> demosfere: Like I said, my guess is bad whitespace.  You might want to test locally.
<infinity> jtaylor: Gah.
<demosfere> i'll try
<infinity> jtaylor: Oh, probably a missing build-dep on python3-all-dev
<infinity> jtaylor: Err, no, it's there.
<infinity> Hrm.
<jtaylor> its strange
 * infinity goes hunting for pyconfig.h
<jtaylor> possibly multiarch issue
<infinity> Is our python more multiarchy than Debian's?
<infinity> doko: ^
<jtaylor> I'm just guessing, let me check debian
<infinity> doko: https://launchpadlibrarian.net/123283466/buildlog_ubuntu-raring-amd64.cython_0.17.1-1_FAILEDTOBUILD.txt.gz
<infinity> doko: Ideas?
<demosfere> infinity: dammit ! still doesn't work
<infinity> jtaylor: It's not FTBFS in Debian, hence the curiosity.
<doko> infinity, yes, use python-config --includes
<doko> python3-config even
<infinity> demosfere: Replace all those tabs with spaces and see how that goes.
<infinity> doko: This is Ubuntu-specific at this point?
<infinity> doko: (Same build is fine in experimental)
<demosfere> infinity: i've removed empty spaces already and didn't work
<doko> no, same versions
<jtaylor> the pyconfig.h is in the same place in debian
<jtaylor> weird
<infinity> Oh, but this built in Debian in September.
<infinity> Multiarch python probably happened after that?
<jtaylor> I'm currently test building, I'll try to cook up a patch when I reproduced the failure
<infinity> Heh.  I'm there too. :P
<jtaylor> nice I got a different error ..
<ricotz> demosfere, better to actually rebuild the source package with the recipe than just rebuilding the old source in ppa again
<demosfere> Why dpkg is so complicated
<demosfere> ?
<demosfere> ricotz: i don't understand
<infinity> jtaylor: Hrm, looks like the right -I/foo is in CFLAGS but not CPPFLAGS.
<demosfere> ricotz: you built plank , i think you know in packaging it more than anyone else ..
<ricotz> demosfere, your pastes indicate that you are not generating a new source package containing the new packaging
<demosfere> ricotz: i just branched your deb-packaging and modified it to bottomlauncher .. and it won't work
<demosfere> ricotz: but i think the problem is by configure
<jtaylor> the configure is probably fine
<ricotz> https://code.launchpad.net/~kedos-project/+recipe/bottomlauncher-daily
<infinity> demosfere: The problem, as stated several times, is that your build-deps aren't being installed, which is due to a malformed debian/control.
<ricotz> demosfere, hi the rebuild button in there
<ricotz> infinity, the control file is fine, dpkg can handle those mix ups
<infinity> ricotz: It *was* malformed before we started helping out.
<infinity> ricotz: I'm not convinced that it isn't still, but we'll see after a rebuild. :P
<demosfere> ricotz: i've tried to rebuild a lot of times .. why build-deps aren't being installed
<ricotz> infinity, ok, but he is building the same source again
<ricotz> infinity, which doesnt include the new packaging fixes
<demosfere> ricotz: so the the deb-packaging doesn't match with the source?
<ricotz> as i said "you are not generating a new source package containing the new packaging"
<ricotz> you need to rebuild the recipe not just the already generated source package in the ppa
<doko> infinity, heh, llvm-3.2 and clang ftbfs due to missing b-d on python
<ricotz> doko, oh, hi, will this get sync asap to raring if done :)
<infinity> doko: Well, that's easy enough to fix, at least.
<ricotz> mesa git already depends on it
<doko> you should *not* depend on an unreleased version yet
 * infinity thinks that perhaps he should step away from the computer and enjoy the sunny Saturday outside for a bit.
<ricotz> doko, it isnt me depend on it but a unreleased mesa (in xedgers)
<ricotz> the mesa radeon dev introduced it, so just saying would be great to have 3.2rc1
<ricotz> doko, https://launchpad.net/~ricotz/+archive/unstable/+sourcepub/2780997/+listing-archive-extra
<ricotz> here is an earlier snapshot
<jtaylor> doko: distutils.sysconfig.get_python_inc() doesn't return the multiarch path with python3.3
<jtaylor> shouldn'T that return the same as python3.3-config?
<tumbleweed> wiki.ubuntu.com seem sto have the wrong cert today
<jtaylor> is the plat_specific flag in get_python_inc ubuntu specific?
<jtaylor> or upstreamable?
<jtaylor> can'T find anything in the patches, so I#m assuming upstream
<jtaylor> a I hate reportbug ...
<jtaylor> friggin think always crashes after I write my nice text ._.
<jtaylor> infinity: I forwarded a cython patch to debian
<jtaylor> 693555
<infinity> jtaylor: Awesome, thanks.  I'll toss that same patch at Ubuntu in a second too, many thanks for hunting it down.
<doko> jtaylor, you need to call it twice, the second time with plat_specific=1
<jtaylor> doko: yes thanks I figured that out already
<infinity> jtaylor: Do, in light of doko's comments, was there a followup patch?
<jtaylor> infinity: no, dokos comment is how I implemented in the patch
<infinity> jtaylor: Oh, check.  Kay.  I'll snag the patch from the bug and upload to Ubuntu then.
<jtaylor> you may also want to wait a bit, I'm sure the debian maintainer will do a swift upload if we ask him
<infinity> He may.  He may not.  No harm done in us uploading a fix and then syncing later.
<jtaylor> its a very long building package
<infinity> And all our buildds are idle and bored.
<infinity> Weekend are like that.
<infinity> s/Weekend/Weekends/
#ubuntu-devel 2012-11-18
<infinity> RAOF: Hrm, care to poke at https://launchpadlibrarian.net/123196289/buildlog_ubuntu-raring-armhf.attica_0.4.1-0ubuntu4_FAILEDTOBUILD.txt.gz
<infinity> RAOF: (There are a bunch more like that)
<wookey> doko_: openjdk-7-jre-headless is marked MA:same. Is that right?
<wookey> I see they can be co-installed, but tzdata for example need the BUILD arch version and can't ask for that if it's MA same (I don't think)
<doko_> so maybe these should be m-a foreign
<wookey> foreign or allowed, yes
<infinity> I think you want allowed, in that case, no?
<infinity> Following build-dep resolution from https://wiki.ubuntu.com/MultiarchCross
<wookey> allowed if you want to be able to install either BUILD or HOST, but each depending package that wants BUILD has to have a :any
<wookey> Having done this for a while I reckon allowed is best avoided, and splitting packages into foreign and same portions is better - then the default dependecnies 'just work' nearly everywhere
<infinity> Well, foreign won't let you get it at all. :P
<wookey> But yes if both arches are needed together ever then foreign is no good
<wookey> (without package splitting)
<infinity> Oh, I guess foreign lets you just build-dep on it with no qualifier, and assume you'll get BUILD by default.
<wookey> I've almost got gettext split so I can stop putting :any on about 1000 packages
<infinity> But it doesn't let you specify that either.
<infinity> RAOF: I withdraw the Mesa query, looking at a fix right now.
<wookey> hmm, actually tzdata can depend on openjdk-7-jre-headless:native to get the right version when it is M-A: same.
<wookey> A chance to test this :-)
<wookey> Not sure this is the right default though
<infinity> And there's no reason for it to not be :same, if it is indeed coinstallable.
<infinity> (And if that's desirable for some reason)
<wookey> oddly I currently get differnt results building tzdata with sbuild ('jdk uninstallable') and with apt in a chroot ('no problem'). I don't know why this difference is hapenning...
<wookey> probably due to 'clean chroot' vs 'fiddled-with chroot'
<wookey> doko_: using :native works OK, so maybe MA:same is correct - I am clueless about java and crossing and packaging.
<wookey> http://people.linaro.org/~wookey/buildd/quantal-arm64/sbuild-ma/tzdata_2012e-0ubuntu2cross2-quantal-bootstrap-arm64-20121118-022905.6937.log
<wookey> I can certainly work with it for now
<mohamedalaa98> Hello guys :D
<raavi_> Hi all
<raavi_> hi all....i have an observation but do not know the right way to escalate
<raavi_> i was directed to here....
<raavi_> ...with bug #892561....anybody?
<ubottu> Launchpad bug 892561 in ubiquity (Ubuntu) "Choosing "Delete old Ubuntu and install 11.10" during setup begins installation immediately without any warnings" [Undecided,New] https://launchpad.net/bugs/892561
<ScottK> raavi_: If you want to discuss that bug with anyone, #ubuntu-installer is probably a better channel, but probably not on the weekend.
<raavi_> ohh i see....thx
<zigo> Hi. I'm a DD, and don't know how to use Launchpad. How may I reassign a bug to a different package? (in my case, #907214 should be reassigned to the Xen hypervisor).
<jtaylor> zigo: click on the little arrow next to the package, it should open more options, incliding a package field
<zigo> Oh, cheers! :)
<maxiaojun> anyone concerned about b43-fwcutter source package?
<EXORCIST> Hello
<EXORCIST> ANyone here?
<EXORCIST> I am good developer, i am looking to contribute to Ubuntu
<directhex> (no he isn't, he's a troll who's already been banned from #ubuntu-uk)
<EXORCIST> directhex got banned from ubuntu channel for harrassing op who +q him
<directhex> yeah, i don't think making things up like that about me will work too well
<EXORCIST> directhex
<EXORCIST> stop trolling me in the channels, you are following me too.
<EXORCIST> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<directhex> everyone else can see the JOIN messages, with the relevant times on them. "following you" is pretty much trivially disproven.
<dobey> lol
#ubuntu-devel 2013-11-11
<lfaraone> The "foo has been converted to an upstart job" symlink is automatically created whenever you install an upstart job on a package that supports upstart, right?
<lfaraone> *install a package that supports upstart on a system that uses upstart
<xnox> lfaraone: no, not any more.
<lfaraone> xnox: oh, what happens these days?
<xnox> lfaraone: init.d script & upstart jobs can co-exist. and $ service command knows which one to pick
<xnox> lfaraone: use $ service, for both init.d and upstart job control.
<lfaraone> xnox: okay. What if somebody calls the init job directly?
<xnox> lfaraone: how?
<lfaraone> xnox: I don't know, somebody has muscle memory for `/etc/init.d/foobar start`
<xnox> exit 1
<lfaraone> xnox: so, we should have the script test if upstart is installed and if so exit?
<xnox> at the moment. which imho is regression from previous ways, where the real thing was still called & warning messages printed.
<xnox> lfaraone: yes, there is a guide about it. One sec.
<xnox> lfaraone: https://wiki.ubuntu.com/UpstartCompatibleInitScripts
<xnox> lfaraone: there is a helper function "init_is_upstart" and one does: if init_is_upstart; then case $1 in stop) exit 0 ;; case start|restart|force-restart) exit 1;; esac
<xnox> fi
<pitti> Good morning
<pitti> rsalveti: Ah sorry, forgot to drop Md's custom rules; will upload a fix now
<ogra_> pitti, your last systemd upload broke touch completely ... http://paste.ubuntu.com/6389687/
<ogra_> pitti, i guess you forgot to rebuild the initrd when testing it ?
<pitti> ogra_: fix uploaded this morning, sorry
<pitti> I rebuilt it on my desktop, but Debian's rules work there
<pitti> so I didn't notice at first
<ogra_> ah, k
<pitti> ogra_: the fix is in trusty, but I suppose we might not have a daily build after that yet
<ogra_> we do all builds manually, since we have a no regression policy and test the images first
<ogra_> (imagine each image is a milestone)
<ogra_> s/is/as/
<ogra_> pitti, did you test this on touch ? (we have a bunch of people out there with bricked phones from the weekend due to the issue, i would like to be 100% sure that we dont do that again)
<pitti> ogra_: no, I didn't; can do it now
<ogra_> great, thanks :)
<ogra_> if it still boots we're fine
<pitti> ogra_: dist-upgrade running (but ports.u.c. is slooow)
<ogra_> pitti, oh, i would only have installed udev
<ogra_> pitti, the rw space is very limited, dist-upgrade might make you run out of sapce
<ogra_> *space too
<pitti> that went well, but hicolor-icon-theme trigger failed because it can't write /usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/2.10.0/loaders.cache
<ogra_> yes, rw has various issues (hardlinks dont work across the loop dev mounts)
<pitti> ogra_: update-initramfs has a few complaints: http://paste.ubuntu.com/6398748/
<pitti> and lxc-android-config doens't upgrade because of the hardlink issue you mentioned
<ogra_> pitti, yeah, thats fine
<ogra_> (sounds more fatal than it is :) )
<pitti> ogra_: but with udev 204-5ubuntu5 it boots fine
<ogra_> pitti, awesome, thanks !
<pitti> (i. e. complete dist-upgrade except lxc-android-config)
 * ogra_ will start an image build 
<pitti> ogra_: sorry for ruining the weekend :(
<jamespage> apw, I discussed dropping the openvswitch dkms package with the dev's upstream; there are still some experimental features still not in the kernel tree (specifically LISP overlay networking)
<ogra_> pitti, all fine ... no worries
<jamespage> so I'll fixup for the time being - the recommendation for openstack will be to use the GRE/VXLAN support in tree though - which makes deployment might faster \o/
<Laney> doko__: seen http://paste.ubuntu.com/6398826/ ?
<zyga> good morning
<zyga> pitti, ogra_: interesting thoughts guys, thanks for sharing them
<apw> jamespage, ack, and if they are 'experimental' we can care less about temporary breakage in that package too
<jamespage> apw, ack
<arrun> Hello and greetings to all the sir/maam here , I  wanted to ask a question for language stuffs , please help me fix those
<knocte> arrun: don't ask to ask, simply ask your question and wait
<arrun> I wanted to add a new language having code ISO 639-3: the in the Language support , how can I do that ??
<xnox> arrun: what language is it? to add translations to launchpad, a new language may need to be added there. For installer it should be enabled in Debian. Once there are some translations language packs can be generated for it.
<arrun> xnox: the Language is ISO 639-3: the Chitwania Tharu , I have created the po and mo files by translating the pot in the Launchpad ...
<arrun> xnox: I have the both po and mo files downloaded from the launchpad for the "the" Chitwania Tharu, but how can I have it installed and named it in the Language support
<xnox> arrun: i see "the" is in launchpad already.
<xnox> arrun: at https://translations.launchpad.net/ubuntu/saucy/+lang/the there are no translations available.
<xnox> arrun: i guess we could generate an "empty" translation pack with no translations.
<arrun> xnox: yup I had requested "the" to be added in Launchpad
<arrun> xnox: I had translated the pot files, to po and mo in another sections and has already downloaded, how can I add the language packs in the Language Support ??
<xnox> arrun: you should setup "Ubuntu Translation group" on launchpad for the Ubuntu/the, then upload translations to translations.launchpad.net/ubuntu/ and then we can generate a language pack for hte language support.
<xnox> pitti: do you know how to enable a previously non-existant in ubuntu language for language packs et. al.? ^
<arrun> xnox: oh, so won't I be able to create it in it  ??
<pitti> xnox: does it have a locale already?
<xnox> pitti: looks like it's called "the" in ISO standard, locale defined where?
<pitti> arrun, xnox: in /usr/share/i18n/SUPPORTED
<pitti> there's no existing locale for that ATM
<xnox> =(
<rsalveti> ogra_: will revert the initrd revert, as that broke the emulator
<pitti> xnox, arrun: langpack-o-matic already knows about it, so as soon as we'll have a locale, it'll start building langpacks
<rsalveti> pitti: and thanks for the fix :-)
<pitti> rsalveti: no worries, sorry for breaking it; I didn't notice the regression on the desktop
<rsalveti> pitti: yeah, I wonder why debian is shipping it's own custom rules files for storage
<arrun> pitti: can I be able to produce the langpacks myself ??
<pitti> rsalveti: hysterical raisins mostly, I hope Md will eventually switch to the upstream rules too
<rsalveti> got it, cool
<ogra_> rsalveti, ah, i was planning to do that after we could test #19
<rsalveti> ogra_: I'm building the emulator from scratch to test it first
<ogra_> ok
<ogra_> i'm waiting for stgraber to enable system-image imports again
<pitti> arrun: in principle yes, but they aren't useful without a locale
<fabcal> Hi all
<fabcal> please could any of you tell me by when is the next "ClamAV" ver. 0.98 supposed to be released as an UBUNTU package?
<xnox> fabcal: it needs to be in debian first.
<xnox> fabcal: then it needs to be merged, since ubuntu has modifications on top of debian.
<ogra_> iirc in the past ScottK maintained it in both distros
<xnox> fabcal: see http://packages.qa.debian.org/c/clamav.html
<ogra_> (not sure thats still the case)
<xnox> fabcal: and the ubuntu box on the right on that page.
<fabcal> xnox, thanks alot
<diwic> pitti, hi, is /run/* not emptied on bootup?
<pitti> diwic: it's a tmpfs, so it starts as empty on boot
<diwic> pitti, if you have time, there is bug 1197395
<ubottu> bug 1197395 in pulseaudio (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged] https://launchpad.net/bugs/1197395
<diwic> pitti, people are claiming it happens after a forced shutdown
<pitti> diwic: I also have a root:root /tmp/pulse-PKdhtXMmr18n/ directory
<pitti> diwic: I have a suspicion that lightdm starts that somehow, but we never tracked it down
<diwic> pitti, ok...
<pitti> or perhaps something using pulse that you start with sudo?
<diwic> pitti, yeah, could be
<pitti> diwic: as you said, pulse itself doesn't even have that permission, so it's certainly related to logging int
<pitti> in
<pitti> or running something sudo
<diwic> pitti, could it be apport related ...I'm thinking that if the system hard shuts down, maybe apport/whoopsie/etc will come up and try to analyze the error
<diwic> pitti, and trying to take debug logs from PulseAudio or something
<pitti> diwic: on crash time apport doesn't run hooks, but certainly when you click on "report"
<diwic> pitti, also could you read https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1197395/comments/26 and see if the comment there makes sense to you or not?
<ubottu> Ubuntu bug 1197395 in pulseaudio (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged]
<diwic> pitti, right, but are those hooks run as root or as the logged in user, or as some kind of hybrid that could cause this error perhaps?
<pitti> diwic: as the user of the process that crashed, so usually not root for pulse
<ScottK> fabcal: I've almost got the package done, just a few issues to sort.
<fabcal> ScottK, this is great, thanks alot for your information
<stgraber> ogra_: sorry, didn't see the hilight up until now... enabling auto-import now
<ogra_> stgraber, i already did :)
<ogra_> stgraber, i only copied orig over config
<ogra_> so remove it to your liking
<stgraber> ogra_: ok
<jamespage> barry, whats the conventions for managing file path conflicts between python2/python3?
<jamespage> i.e. /usr/bin/jsonpatch is causing be problems right now :-)
<jamespage> bug 1250088 for reference
<ubottu> bug 1250088 in python-json-patch (Ubuntu) "python3-json-patch conflicts with python-json-patch" [Medium,Confirmed] https://launchpad.net/bugs/1250088
<barry> jamespage: looking
<jamespage> I was thinking /usr/bin/jsonpatch3 ?
<barry> jamespage: debian doesn't have strong concensus on this (we hit similar issues with things like nose and other cli-providing packages), but generally we try to use X.Y versions with symlinks for X versions.  e.g. /usr/bin/jsonpatch3.3 and symlinked from /usr/bin/jsonpatch3
<jamespage> barry, OK _ I'll hack something out and try it
<jamespage> thanks for the help
<barry> jamespage: +1.  np.  i'll follow up on the bug for posterity
<barry> jamespage: my recommendation above is a little off, but watch the bug
<jamespage> ok
<lfaraone> Ugh. Are the PPA builders in a different environment from the archive builders? I built a package for trusty locally, it FTBFS, so I tried to build it in a PPA, and it succeeded at https://launchpadlibrarian.net/156299609/buildlog_ubuntu-trusty-amd64.ogre-1.8_1.8.1%2Bdfsg-0ubuntu3_UPLOADING.txt.gz , so I assumed I just had a broken local environment.
<lfaraone> then I upload it and am greeted with https://launchpadlibrarian.net/156332270/buildlog_ubuntu-trusty-arm64.ogre-1.8_1.8.1%2Bdfsg-0ubuntu3_FAILEDTOBUILD.txt.gz ;(
<xnox> lfaraone: yes, all three are different (local, ppa, distro builders)
 * lfaraone sobs softly.
<xnox> lfaraone: your first one (PPA) doesn't have trusty-proposed enabled.
<xnox> (which is actually where all packages are built)
<lfaraone> Right.
<lfaraone> oh, it BFS on i386 and amd64, its just sad on arm.
<xnox> but from proposed only python is fethed so it can't be just that.
<lfaraone> the current version in saucy is also FTBFS on arm64
<lfaraone> so, not my fault at least :)
<xnox> lfaraone: anyway why do you care about ogre-1.8 in the first place? things should be rebuild against 1.9, and 1.8 removed from the archive.
<xnox> =)
<lfaraone> xnox: idk, just going through the sponsor queue
<xnox> lfaraone: ah, ok.
<lfaraone> xnox: Laney motivated me to actually make some uploads :P
<Laney> \o/
<mlankhorst> lucky, I'm stuck on red tape
<lfaraone> the queue is now at 64!
 * lfaraone admittedly has been sort of out of it on Ubuntu development; the last time I was seriously involved was late 2011
<zyga> mhall119: ping
<zyga> mhall119: who is handling ubuntu community translations?
<clefebvre> hi pitti, sorry for the highlight. There's a critical bug in Saucy (and most distros right now) in PAM/Systemd, I'd love to chat with you about.
<clefebvre> I left a comment at https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1197395 to explain a little (it's not related to pulseaudio in particular)
<ubottu> Ubuntu bug 1197395 in pulseaudio (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged]
<mhall119> zyga: pong
<mhall119> zyga: dpm-afk is our goto guy for community translations
<dpm-afk> hi zyga, what's up?
<zyga> dpm-afk: hey, a community member asked me about how the translation stuff works
<zyga> frecel: ^^
<zyga> dpm-afk: apparently there are 5000 translations that need to be reviewed on launchpad for the polish language
<frecel> here!
<zyga> dpm-afk: and frecel was worried that his work is not getting used because of that
<frecel> Well I'm just thinking that it kinda looks abandoned so I figured I could help
<frecel> I couldn't get in touch with the administrators of Polish Translation Team btw
<dpm-afk> zyga, I've not been in touch with the Polish translations team coordinator for a while, but I get the impression he's not very active and thus there's not much of a team atm
<zyga> dpm-afk: is there a process where a new team can be formed if the old team is (theoretically) unreachable?
<xnox> dpm-afk: have translations been moved to trusty series yet? from https://translations.launchpad.net/ubuntu all language links point to saucy.
<frecel> Is there any way to check when the last suggestion was reviewed on launchpad?
<frecel> and it got quiet...
<dpm-afk> zyga, yes, there is: https://wiki.ubuntu.com/Translations/KnowledgeBase/RoleReassignmentPolicy
<dpm-afk> xnox, they've not been opened yet, no
<hallyn_> ok, i installed a precise desktop from the desktop image.  installed qemu-kvm.  proposed is not in sources.list.  but the version of libvirt-bin is the one in -proposed (.15), not in -updates (.13).
<hallyn_> haven't yet figurd out why
<TJ-> hallyn_: "security" ?
<TJ-> hallyn_: ahh, no... but what does "apt-cache policy  libvirt-bin" show?
<hallyn_> TJ-: WTF.  there's a /etc/apt/sources.list.d/proposed.list
<Frodo> Hello all,
<Frodo> I am truly intrested to join the Ubuntu community. I am a software developer and I am looking to participate in Ubuntu development. As far as i read, I should start doing junior jobs first as i am new to Linux development.
<Frodo> I am looking for somebody to guide me what i should do to get started. And what technologies i should learn. If somebody can adobt me as a student and start assignining me homeworks until i become ready for junior jobs, i would truly appreciate it.
<Frodo> If you do not have time to help me, at least let me know what technologies i should learn and then whom to ask about jounior task.
<Frodo> Thanks for you help and kindness...
<blueyed> Frodo: you might want to start here: https://wiki.ubuntu.com/UbuntuDevelopment
<blueyed> Also, come over into #ubuntu-motu, and ask there.
<ersi> (motu stands for "Masters of the Universe" and universe is the packaging universe ;)
<Frodo> thnaks alot friends
<Frodo> :)
<melodie> hello
<melodie> does someone know if the kernel series 3.2.0-x for Precise always be PAE free until 2017 when the support for 12.04 will be ended?
<mdeslaur> melodie: that is the plan, yes
<melodie> mdeslaur thanks you! If I may, could I ask when the commit for the bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1246664 will be integrated? You could have a look at my last comment
<ubottu> Ubuntu bug 1246664 in linux (Ubuntu Precise) ""Buffer I/O error on device zram0, logical block 515067"" [Medium,Fix committed]
<melodie> if you have any idea of course... :)
<mdeslaur> melodie: perhaps ask in #ubuntu-kernel, I don't really know and it's off-topic for this channel
<melodie> mdeslaur ok, I will, thank you very much!
<mdeslaur> yw
<dupondje> jamespage: I saw you worked on Bacula. Are there eventually plans to include Bareos as Bacula replacement?
<tjaalton> hrm, is the PPA build environment somehow different from a typical sbuild one? Trying to update xmlrpc-c but it fails to run the tests on LP
<tjaalton> hmm it probably was something transient after all
<saiarcot895> If a package uses a slightly-modified version of a third-party library, should it still have the option to use the system version of the library?
<infinity> saiarcot895: Ideally, it really shouldn't use a modified library at all, and if they have fixed, we should get those into the shared system library.
<infinity> saiarcot895: But if a package absolutely MUST bundle a broken fork of a library, then that seems at odds with also being able to use the system version.  You can't really have both situations.
<saiarcot895> infinity: ok, just making sure of policy. It will be going into a PPA soon, so it's not critical at the moment, but regardless, I like to follow policy
<saiarcot895> infinity: From what I can tell, it's just additional header files and a few defines (it's C code)
<infinity> saiarcot895: Well, you could move the new bits into static definition in the application proper or, if they're generically good fixes/changes that all consumers of the library should want, get that into the upstream version of said library and into its packaging.
<infinity> saiarcot895: But yeah, both policy and common sense dictates that shipping forked libraries sort of defeats the purpose of shared libraries, so do try to avoid it unless you really can't.
<infinity> (There are many packages in the archive that ship private copies of libraries, you wouldn't be the first, it's not *forbidden*, but it's highly discouraged)
<infinity> And the security team and others will frown heavily on such things for inclusion in main, since keeping track of embedded libraries in various packages is very painful.
<saiarcot895> I believe chromium-browser is an exception, the reason being they keep their libraries up-to-date generally
<infinity> They're not an exception because we think they're a good upstream, they're an exception because maintaining their massive maze of twisty awful is painful. :P
<infinity> (Also, it's in universe)
<saiarcot895> true
<orbisvicis> I am running into an error with dh I don't understand: "dh: Unknown sequence list-missing" with the rule "%: dh: Unknown sequence list-missing"
<jtaylor> orbisvicis: how does the rules look like?
<orbisvicis> oh, "%: dh --with-quilt $@"
<jtaylor> exactly like that?
<jtaylor> its --with quilt
<jtaylor> without the -
<orbisvicis> exactly like: "%:\n\tdh --with quilt $@"
<orbisvicis> sorry about that, can't copy to the clipboard over ssh for some reason
<jtaylor> do you have dh_install call somewhere?
<jtaylor> because that takes the --list-missing argument
<jtaylor> maybe its in DH_OPTIONS?
<orbisvicis> no. it tries to run "dh --with quilt list-missing", not an "--list-missing" argument
<jtaylor> how are you calling the rules file?
<orbisvicis> pdebuild -> dpkg-buildpackage -> (trying to read the output)
<jtaylor> I don't know why it would call the rules with that argument
<jtaylor> maybe clean your environment and grep for list-missing
<orbisvicis> jtaylor: yes already grep'ed and not an env. variable
<orbisvicis> ok I see: fakeroot debian/rules clean -> debian/rules build -> fakeroot debian/rules binary
<orbisvicis> then "   dh_builddeb" as the last binary target, followed by lots of builddeb output, then "I: checking for missing files." \n "dh --with quilt list-missing" \n "dh: Unknown sequence list-missing (choose from: binary binary-arch binary-indep build clean install patch)"
<jtaylor> maybe a broken pbuilder hook
<orbisvicis> so I'm not sure if its part of the binary sequence, or a new target
<orbisvicis> jtaylor: hmm good idea, let me check
<orbisvicis> 1st time having this problem, first time using hooks....
<jtaylor> why are you even using --with quilt and not format 3.0 (quilt)
<jtaylor> list-missing is a cdbs rule
<jtaylor> possibly something tries to use cdbs with a dh-7 package
<orbisvicis> jtaylor: modification of an old package
<orbisvicis> what do you mean, dh-7 package? such as? and how could they get mixed with cdbs
<orbisvicis> anyway, it was one of the hooks. builds fine now
#ubuntu-devel 2013-11-12
<StevenK> xnox: I'll look at mpd after work.
<xnox> StevenK: thanks a lot! =)
<orbisvicis> per apt-cache policy apt seems to be ignoring my /etc/apt/preferences file w.r.t the priority of my local repository
<orbisvicis> it was a quoting problem, ftr
<pitti> Good morning
<dholbach> good morning
<pitti> hey dholbach, good morning! wie gehts?
<dholbach> hey pitti - sehr gut - wie geht's Dir?
<pitti> dholbach: prima, danke!
<dholbach> Did anyone see anything like "Failed to create secure directory (/run/user/1000/pulse): Permission denied" on saucy recently?
<pitti> dholbach: currently being discussed in bug 1197395
<ubottu> bug 1197395 in systemd (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged] https://launchpad.net/bugs/1197395
<dholbach> ah, super
<dholbach> thanks
<pitti> infinity: do you have a minute for an SRU review? (bug 1184262, systemd-shim for saucy-proposed); it's causing suspend breakage for way too many people :/
<ubottu> bug 1184262 in systemd-shim (Ubuntu Saucy) "[logind] times out too early, stuck in PrepareForSleep, causing network and other services to not resume" [High,In progress] https://launchpad.net/bugs/1184262
<pitti> brainwash: ^ FYI
<pitti> bdmurray: ^ do you have time today to process the systemd-shim saucy SRU review?
<doko> jamespage, maven ping
<Laney> doko: did you see my gcc-4.8 ping yesterday?
<doko> tjaalton, instead of using an old MIR, could you use a new one for the samba deps? ldb, faketime, libparse-yapp-perl ? (or maybe zul, jamespage)
<doko> Laney, yes, is this urgent?
<Laney> not as long as it doesn't migrate
<jamespage> infinity, are you OK for me to submit that atomic linking fix back upstream for openvswitch?
<jamespage> just sweeping up patches
<tjaalton> doko: ok, I'll file one for ldb for starters..
<doko> tjaalton, please open tasks for the others too
<jamespage> tjaalton, please can you check in with zul - he's being doing the merge and mir stuff for samba
<jamespage> not sure exactly how far he's got as yet
<tjaalton> jamespage: there was no MIR for ldb at least
<tjaalton> faketime has bug 1250102
<ubottu> bug 1250102 in faketime (Ubuntu) "[MIR] faketime" [Undecided,New] https://launchpad.net/bugs/1250102
<tjaalton> subscribed ubuntu-mir
<tjaalton> zul: I've filed a MIR for libparse-yapp-perl too https://bugs.launchpad.net/bugs/1250466
<ubottu> Ubuntu bug 1250466 in libparse-yapp-perl (Ubuntu) "[MIR] libparse-yapp-perl" [Undecided,New]
<tjaalton> doko: ^ that should be all of them
<tjaalton> ldb is bug 1250463
<ubottu> bug 1250463 in ldb (Ubuntu) "[MIR] ldb" [Undecided,New] https://launchpad.net/bugs/1250463
<doko> tjaalton, thanks
<zul> tjaalton:  thanks
<zul> how do you get something on the blacklist for merges.ubuntu.com?
<cjwatson> zul: ask an archive admin to sync-blacklist it, but blacklisting isn't necessarily the right answer
<cjwatson> zul: what in particular are you referring to?
<zul> cjwatson:  i was looking at the list and we dont merge any of the openstack packaging from debian (so things like ceilometer and python-cinderclient, etc)
<cjwatson> zul: That usually works out being a mistake in the long run
<cjwatson> Usually when I run across that it's accompanied by swearing at the way Debian packaging improvements haven't been carried over into Ubuntu
<cjwatson> So I'm pretty reluctant to entrench it
<zul> cjwatson:  right but alot of the openstack debian packaging uses debconf which we dont consider an improvement and often broken
<cjwatson> That doesn't mean other aspects aren't worth merging
<zul> cjwatson:  sure
<tseliot> stgraber: hi, can you have a look at bug #1250449 please? (new nvidia packages for trusty)
<cjwatson> In particular Python module packages that are only maintained in Ubuntu usually end up being worse off IME
<ubottu> bug 1250449 in nvidia-graphics-drivers-319 (Ubuntu) "Include the 331 driver in Ubuntu" [Medium,In progress] https://launchpad.net/bugs/1250449
<zul> cjwatson:  with regards to the merging  openstack packaging from debian we are often ahead so why dont they merge from us since the "packaging" style of the debian maintainer is not compatible with the stuff that we need to do
<cjwatson> you're reasonably reliably ahead as long as the only metric you look at is the upstream version number
<cjwatson> anyway, feel free to persuade some other archive admin, I'm not generally happy with blacklisting for this reason
<jamespage> cjwatson, fortunately we also take into account peer review on every packaging commit and continual CI of packaging and deployment against upstream trunk and stable branches as well
<cjwatson> like I say, I'm not going to agree on this, but you can try somebody else if you like :)
<mitya57> zul: upstream OpenStack maintainer is usually friendly to Ubuntu and can even merge some Ubuntu-specific changes back, i.e. http://packages.qa.debian.org/b/blktap-dkms/news/20130322T121730Z.html
<xnox> to me it seemed that debian is fairly actively up to date. But e.g. we packaged rc for release, and debian packaged final only.
<cjwatson> I'm generally of the opinion that we should blacklist as little as possible
<cjwatson> and that many of the blacklists we have so far have turned out to be trouble later
<jamespage> cjwatson, fine - tbh is fairly moot anyway - by the time we get to first milestone for icehouse stuff won't appear on merges.u.c anyway
<cjwatson> mainly because they tend to be maintenance-invisible
<cjwatson> it's not a lack of review on the packaging changes that you *do* have that concerns me about this in general; it's invisibility of the patches you don't have that Debian does
<cjwatson> and a general disdain for Debian
<cjwatson> if they're doing it wrong, persuade them otherwise :)
<jamespage> cjwatson, whoa - I never reflected that
<jamespage> and I have tried :-(
<cjwatson> it'll be better for everyone
<cjwatson> there are packages I maintain where I disagree with the Debian maintainer about something; it just means a long-term delta, but not permanently ignoring them
<jamespage> maybe a better way to have started this discussion would have been "we are divergent for a number of reasons on the openstack package set - whats the best way to manage this bearing in mind we will not ever quite sync up with debian"
<cjwatson> my general opinion on that class of question is that it's perfectly OK to never quite sync up, but it's not clear to me that that means the long-term wise thing to do is to go it entirely alone
<cjwatson> bearing in mind that long-term packaging divergence affects more than just one part of the archive; it can often have knock-on effects elsewhere with things like incomplete transitions
<jamespage> cjwatson, we've been trying to figure out the best way to flow patches between Debian/Ubuntu but its really hard to track
<jamespage> normally its a conversation in debian-openstack which works OK
<cjwatson> frex some of the obsolete packages Debian has managed to remove entirely (e.g. python-central) are still stuck in Ubuntu because of a bunch of long-term-diverged or Ubuntu-local packages where people just haven't kept up
<cjwatson> we lose out on archive-wide QA
<cjwatson> in the case of Ubuntu, this is often particularly bad for packages that were once part of the Current Great Thing for a particular team but have since been abandoned, and this is really hard to track since by the nature of these things the teams who used to deal with them have now lost interest
<cjwatson> unfortunately I see this pattern a fair bit
<tjaalton> jamespage: infiltrate debian-openstack and maintain things there? :) /me runs..
<jamespage> tjaalton, go look at the team membership list on alioth :-)
<jamespage> like I said its hard to track....
<tjaalton> can't, it's down :)
<jamespage> tjaalton, forgot
<jamespage> cjwatson, I can think of a few examples of that behaviour - yes
<jamespage> doko, libjaxen fixed up to avoid maven - looking at testng next
<jamespage> doko, think I can get rid of the testng requirement as well
<jamespage> maybe
<jamespage> doko, OK - once my upload of libhamcrest-java goes through testng can be demoted to universe
<doko> \o/
 * jamespage dodges the maven bullet again
<jamespage> doko, it was referred to in one example that neither ships or is complied during package build...
<infinity> jamespage: Woo!
<xnox> Hm... are we going to have pypy in main =/
<mitya57> For what?
<seb128> dobey, hey, could you have a look to bug #1227277? that one seems like it might be a bug in s-c and not in gnome-menus/webkit
<ubottu> bug 1227277 in software-center (Ubuntu) "software-center crashed with TypeError in exists(): coercing to Unicode: need string or buffer, NoneType found" [Medium,Confirmed] https://launchpad.net/bugs/1227277
<jamespage> infinity, Woo! == yes please go ahead?
<doko> jamespage, zul: please can you subscribe to ldb and libparse-yapp-perl (samba deps)?
<jamespage> doko, ack
<zul> doko:  done
<doko> thanks, promoting
<zul> doko:  cool thanks
<jamespage> doko, done
<doko> barry, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg, could you look at the python related component mismatches? e.g. pypy shows up for simplejson again
<barry> doko: sure.  might be a while
<doko> seb128, didrocks: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  rythmbox recommends ephiphany-browser. wanted?
<seb128> doko, no
<seb128> Laney, ^
<didrocks> I don't think it was expected :)
<seb128> Laney did the rb update I think
<didrocks> Laney: you wanted a new browser to please mdeslaur? :)
<Laney> arm64
<doko> ahh, yes, arm64 doesn't have another one
<mdeslaur> argh! :)
<xnox> doko: can we make w3m provide x-www-browser on arm64?! =)
<seb128> Laney, why does rb need to recommend a browser?
<xnox> seb128: to open u1 music store?
<mdeslaur> there's no way epiphany is going to main
<Laney> nobody's askign it to
<seb128> xnox, isn't that a "try to activate an url, how the url is handled is up to the system"?
<Laney> I assume it's from the plugin
<xnox> i wonder if dropping to suggests will just work. Since anybody that has rhythmbox installed is likely to have a graphical web-browser, and if they don't, they are probably installing everything with no-recommends and no-suggests anyway.
<Laney> Just ignore it
<seb128> Laney, well, if it's creating noise on component mistmatch it's still annoying?
<cjwatson> Best fix is to port firefox; until then it's a known false positive and you should just ignore it really
<cjwatson> No point getting exercised over it
<seb128> well, downgrading to a Suggests would make sense, I'm not sure an application needs to recommends a webbrowser just because one of its plugin has an url handler
<Laney> It is weird for a mozilla plugin to recommend epiphany-browser, mind you
<seb128> but yeah, not an important topic
<Laney> it's not a url handler
<cjwatson> seb128: if it weren't rhythmbox it would probably be something else; I don't think there's any point in focusing on rb here
<seb128> right
<mitya57> ScottK: by the way, I'm wondering if you volunteer to re-upload qtsensors with fixed arm symbols, or should I put it on sponsoring queue?
<ScottK> I'll take care of it.
<mitya57> Thanks (bonus points for uploading that to Debian as well)
 * ScottK didn't get home from working until 3AM yesterday (which was only 8 hours ago here), so I'm a bit behind today.
<ScottK> It's in the Debian Qt-KDE repo, right?
<mitya57> ... which is down
<ScottK> Good point.
<ScottK> I'll ask lisandro.
 * mitya57 didn't ask lisandro because lisandro is already busy uploading a bunch of mitya57's qt5.2
<ScottK> Right, I just don't want to step into what he's doing without discussing.
<mitya57> Ok.
<hallyn_> infinity: fwiw, qemu package with qemu-arm64-static is in ppa:serge-hallyn/virt.  (didn't manually add -lgpg-error so hadn't expectd it to build)  not sure what to test with.
<xnox> hallyn_: libnih + upstart have in excess of 6k+ tests. Also eglibc test-suite =)
<hallyn_> xnox: do we have arm64 builds of those?  id'd need to build a chroot to start i assume
<xnox> hallyn_: yes, we do have arm64 of those. we have most of main build.
<xnox> hallyn_: you can do $ mk-sbuild --arch arm64
<hallyn_> are you sure?  most builds i've seen just fail
<hallyn_> but ok, i'll see, thx
<xnox> hallyn_: if you have qemu-arm64-static, it should be able to bootstrap arm64 chroot, with qemu-arm64-static. After that builds are just $ sbuild --arch arm64 *.dsc
<xnox> hallyn_: our arm64 port rocks - https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes -  94% of the binary packages in the "main" component are available, and 69% of the binary packages in the archive as a whole.
<xnox> hallyn_: sure a few things needed to be retried a few times, but overall it mostly builds.
<hallyn_> hm
<xnox> in trusty it's even more.
<Laney> hrm, is gcc-4.7 problematic on arm64? https://launchpadlibrarian.net/156422079/buildlog_ubuntu-trusty-arm64.webkitgtk_2.2.1-2ubuntu1_FAILEDTOBUILD.txt.gz
<infinity> jamespage: The woo was for dodging the maven bullet.
<infinity> hallyn_: Grabbing the ubuntu-core tarball, untarring it, copying qemu-arm64-static to usr/sbin and chrooting in should work.
<infinity> Laney: AFAIK, it should work.  Would be hard for it to have been built if it doesn't work at all.
<hallyn_> infinity: will try that, thanks
<Laney> Mmm.
<robru> bschaefer, ping? just curious about the status of unity7 tests from friday (forgot to follow up with you then)
<infinity> Laney: autoconf's "compiler can't create executables, HALP" message is generally useless without a config.log, where you'll see that it's probably just exiting non-0 due to a missing include or -l or something.
<infinity> Laney: I can try to look at it between now and when I have a plane to catch.  Just headless chickening a bit this morning.
<Laney> infinity: If you like. I'm a bit loathe to do blind uploads of webkit
<infinity> Laney: That said, why is webkit building with gcc-4.7?
<bschaefer> robru, hmm which tests? I don't seem to remember...
<Laney> infinity: It could be dropped, that came from Debian.
<robru> bschaefer, yeah i don't remember either ;-) but didrocks says that just in general you were working towards eliminating some flaky tests and getting unity7 green.
<robru> he asked me to follow up with you
<Laney> Well, maybe could be dropped. They chose 4.7 to avoid 4.6, not to avoid 4.8.
<bschaefer> robru, oo, yeah our goal for unity 7 is get get all the AP tests working but its very hard to do, so far nothing new has happened
<robru> bschaefer, oh ok. well maybe just ping me if you make any progress today. no worries.
<bschaefer> robru, alright will do
<robru> bschaefer, thanks
<infinity> Laney: Well, if it works with 4.8 (or, rather, with the default gcc, which is currently 4.8), that would be better than hardcoding it, and doko will love you forever.
<infinity> Laney: I'm not one to talk, though, I hardcode in glibc, and sort of have to, so I'm arguably the worst offender for keeping old compilers around. :/
<infinity> Laney: Anyhow, when I get my bearings this morning, I'll do a quick test of webkitgtk on arm64 for you and see what config.log is whining about.
<Laney> Ta
<Laney> Feel free to make the 4.8 (default) change too if that works
<Laney> See my previous comment about blind uploads. :P
<mitya57> ScottK: thanks for qtsensors!
<ScottK> mitya57: YW.
<jamespage> infinity, well that was definately a woo!
<ScottK> mitya57: Want me to add you to uploaders too?
<mitya57> Ah, please do.
<ScottK> OK.  Will do.
<infinity> Laney: Wait, webkitgtk is new source?
<infinity> Laney: Does that have ancestry somewhere else?
<Laney> It's a rename from webkit
<infinity> Rename and a massive version bump...
<Laney> haha, I didn't do any arithmetic on it
<Laney> It includes new packages for the webkit 2 API
<infinity> conftest.c:1:0: error: target system does not support the "stabs" debug format
<infinity> Laney: ^-- That's your error.
<Laney> Ta, that is actually probably my error
<infinity> Laney: -g should work fine.
<infinity> Laney: If the goal is to avoid large links on 32-bit platforms, arm64 is, I'm pretty sure, 64-bit. ;)
<infinity> Laney: And I assume -g is the default for things that aren't in the two filter lists.
<infinity> Laney: Also, we're not (yet) using EGL on arm64, so adding it to the glx/egl list with armel and armhf is probably also wrong.
<infinity> Laney: We may switch that at some point, but right now, arm64 is built for standard GL (and the previous webkit was too)
<infinity> Laney: So, basically, the two things you added to be clever in the merge are the two broken things. ;)
<Laney> There's k-a there, so it's not just 32
<Laney> I did ask if there was a way I could test build it. :P
<Laney> But yeah, woe is me
<infinity> Laney: My bet is that the addition of kfreebsd-amd64 to that list was a mistake/misunderstanding, but whatever.
<infinity> Laney: if it were me, I'd probably just filter on DEB_HOST_ARCH_BITS and be done with it, but I also don't have a high carefactor here, if the current solution works.
<Laney> I think it might have done bad things to the kfreebsd-amd64 buildd
<Laney> There's a couple of buildlogs in which ld gets killed
<infinity> Laney: That could just be the kfreebsd-amd64 being shit.  The solution there shouldn't be to neuter builds.  But, like I said, carefactor low.  If the current thing works, meh.
<infinity> Laney: kfreebsd is actually becoming a usable and mature product, though, so I might start caring more very soon.
<infinity> (Once I waste a month of my hobby/spare time to help Petr get all his glibc patches upstream, I'll be even more confident in that position)
<Laney> Want to test build an upload removing my crap?
<Laney> Could also use 4.8 too.
<infinity> Laney: No need to switch compilers just yet.  We can investigate that another time.
<infinity> Laney: I can kick off a test build, but it won't be done before I'm in the air.
<Laney> Meh, can do it in the archive.
<infinity> Laney: And then I have YYC->LHR->CBG before I'll be sort of around again.
<Laney> Good ol' CBG
<seb128> bdmurray, infinity, slangasek: is any of you planning to do some saucy SRU reviews soon? ;-) (we have some fixes for high ranked e.u.c issues in the queue, I'm trying to get thing moving so we keep tackling stuff on the report)
<seb128> bdmurray, infinity, slangasek: indicator-application and telepathy-mission-control-5 are in this category (and should be straightforward to review) (lightdm would be nice as well but that's less trivial as an update)
<bdmurray> seb128: I work on SRU stuff on Thursdays
<seb128> bdmurray, do we have anyone active on other days?
<seb128> bdmurray, thanks for the work you are putting on SRUs btw!
<bdmurray> seb128: I thought I saw ScottK release some updates the other day and slangasek works on the queue on Fridays
<infinity> seb128: I'll look at the queue in a second, just on the phone with an airline.
<infinity> (Monday is my day, in theory, but I was off yesterday, so meh)
<seb128> infinity, thanks, the telepathy/indicator ones should be trivial so I would appreciate if you could review/get them through
<seb128> doh, stgraber just copied some SRUs over
<Alan-1> Does anyone know how I can get a google api that is associated with a google PAGE (not a google personal profile)?
<seb128> stgraber, can you copy ido as well? I just marked https://bugs.launchpad.net/ubuntu/+source/ido/+bug/1246536 verification-done
<ubottu> Ubuntu bug 1246536 in ido (Ubuntu Saucy) "segfault in menu_hidden()" [High,Fix committed]
<seb128> stgraber, hud as well it you can ;-)
<stgraber> seb128: finishing my current pass, hopefully the report will then update and I'll spot the other ones you just tested
<seb128> stgraber, great, thanks ;-)
 * seb128 battles e.u.c
 * seb128 wishes that mvo and dobey would help for update-manager/software-center issues that are close from top-ing now
<Laney> Grr, looks like arm64 is still busted (but likely to be fixed with the exp version, which we can probably sync)
<ScottK> seb128: I do it when I have time, which is uneven, so I don't have a specific day.  I did do a bit yesterday.
<infinity> Laney: That looks pretty spectacularly broken.
<Laney> It totally is
<seb128> ScottK, ok, thanks for the work ;-)
<infinity> seb128: bug #1217086 is marked Fix Committed for trusty, is there a pending upload for that?
<ubottu> bug 1217086 in telepathy-mission-control-5 (Ubuntu Saucy) "mission-control-5 segfaults in tp_debug_sender_add_message_vprintf()" [High,In progress] https://launchpad.net/bugs/1217086
<infinity> seb128: Oh, looks like ubuntu7 has it.  Nevermind.
<seb128> infinity, ;-)
<stgraber> seb128: ido and hud released
<seb128> stgraber, infinity: thanks!
<arrun> Hello guys, I wanted to know how to create a language package and apply on the box?
<infinity> seb128: bug #1238149 has a note that it's artificially failed until ido is released.  Does that mean we can release gtk now?
<ubottu> bug 1238149 in gtk+3.0 (Ubuntu Saucy) "Nautilus doesn't show the "Open with Shotwell" option" [High,Fix committed] https://launchpad.net/bugs/1238149
<seb128> infinity, yeah, see the comment I added at the same time you were pinging on IRC ;-)
<stgraber> infinity: I just noticed that (as I was looking at the next gtk+3.0) and released it already
<infinity> stgraber: Heh.  Awesome.  I'll close those browser tabs, then. :P
<arrun> Hello guys, I wanted to know how to create a language package and apply on the box?
<stgraber> pitti: I'm confused by bug 1211514 and its saucy SRU, what's the status of all that?
<ubottu> bug 1211514 in systemd-shim (Ubuntu Trusty) "Shutdowns fail to finish if laptop lid is closed before completely shutdown" [High,In progress] https://launchpad.net/bugs/1211514
<stgraber> the bug status would suggest it's not fixed in trusty, but what's in the queue appears to be a backport of trusty, so I'm wondering whether that upload actually fixes the bug
<stgraber> (also, it'd have been nice if we could have somehow avoided the massive autoconf diff in the SRU...)
<NikTh> Hello everyone.
<NikTh> If anyone knows, is it possible to build kernel 3.12 for precise and upload it to a PPA ?
<arrun> Hello guys, I wanted to know how to create a language package and apply on the box?
<NikTh> I tried to built it but, it failed due to dependencies problems in pbuilder. I assume it will fail in launchpad virtual builders too.
<infinity> NikTh: You'll find that there's a delta between linux/3.11 in saucy and linux-lts-saucy/3.11 in precise.  I assume that same delta would need massaging and application to 3.12
<NikTh> infinity: Thanks . I thought the same thing. Probably this would be applicable when linux-lts-trusty will be released, I presume.
<ScottK> Laney: Any idea what's up with your lilpond SRU build for powerpc?
<Laney> ScottK: Nope, mailed the upstream people who asked me to do the fix and they are looking into it
<ScottK> Laney: Thanks.
<sarnold> does anyone know more about the flood of "package <foo> failed to install/upgrade: package <foo> is already installed and configured" that we're getting these days?
<sarnold> should I be assigning them all to apt? leave them at dpkg or whatever package was selected by the bug reporting tool?
<ScottK> Got an example?
<sarnold> ScottK: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1249757
<ubottu> Ubuntu bug 1249757 in dpkg (Ubuntu) "package python-xkit 0.5.0ubuntu1 failed to install/upgrade: package python-xkit is already installed and configured" [Undecided,New]
<ScottK> No idea.
<ScottK> I vote slangasek most likely to know and be unable to resist looking.
<ScottK> infinity would know, but he'd probably resist.
<xnox> sarnold: looking and the dpkg log file attached it looks weird. user is manually installing nvidia-current, yet all the "needed" packages to be installed are already installed =/
<ScottK> xnox: but it still shouldn't get that error.
<xnox> sarnold: usually there is a bot that comes around and tells people to try something along the lines of $ dpkg --configure -a
<sarnold> xnox: hrm. I wonder if some guide published recently has lead a lot of people astray..
<ScottK> And he said this is one of a rash of errors.
<ScottK> Even if you manually install  a package that's already installed, you shouldn't get that error.
<slangasek> sarnold, ScottK: I suspect an aptdaemon bug
<slangasek> bdmurray: ^^ have you noticed this uptick in 'is already installed and configured' bugs?
<sarnold> slangasek: would it be helpful for me to re-assign the package for some of these bugs?
<slangasek> sarnold: I'd say aptdaemon is the place to start
<sarnold> slangasek, ScottK, xnox, thanks! :) I've moved a handful of recent bugs over to aptdaemon.
<bdmurray> slangasek: yes, I think so
<bdmurray> slangasek: I was looking at bug 1046856 somewhat recently
<ubottu> bug 1046856 in dpkg (Ubuntu) "package php5-suhosin 0.9.33-3build1 failed to install/upgrade: ErrorMessage: package php5-suhosin is already installed and configured" [Undecided,New] https://launchpad.net/bugs/1046856
<slangasek> bdmurray: can we pin it down to a version of some package? (aptdaemon?)
#ubuntu-devel 2013-11-13
<infinity> doko: While you're uploading FTBFS compilers, you've noticed that gcc-4.8 can't migrate because you dropped a library that all the olders ones depend on, right?
<doko> infinity, I know, I should have gone to bed
<infinity> doko: Yeah, my late night uploads usually aren't much better. :)
<doko> infinity, feel free to merge the older ones. I wanted to delay that until alioth is up again
<infinity> doko: Oh, if you already have the older ones fixed in Debian or a VCS, that's cool.
<doko> infinity, feel free to fix 4.4
<infinity> doko: I'm in no huge rush to see it all fixed migrate, just wanted to make sure it was happening some day. :)
<infinity> doko: I can replicate your 4.6/4.7 fix to 4.4 if you haven't, sure.
<infinity> doko: (After I fly across an ocean and such, so... Later)
<doko> do you work somtimes too? ;-P
<infinity> doko: Every second Thursday.
<infinity> (Hey, I worked all day while I was doing laundry!... And most of the long weekend I just had)
<infinity> I suck at long weekends.
<bdmurray> slangasek: I'm not sure we are collecting everything we need
<pitti> stgraber: 1211514> as the changelog says, version 4 fixes half of the problem, but I just figured out the other half last night (way after uploading the SRU)
<pitti> stgraber: but that bug is much less critical than the suspend failure, so I wanted to get this out ASAP
<pitti> stgraber: that bug is indeed not yet fixed in trusty
<pitti> Good morning
<pitti> @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: pitti
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<arun_> Hello guys, I didn't get any feedbacks from the glibc maintainers, I was wanting to add a new language suppport(language package) having iso code ="the" ; please  helpme !!!
<pitti> dholbach: happier with the sponsoring queue now? :-)
<dholbach> pitti, a bit, yes ;-)
 * dholbach hugs pitti
 * pitti hugs dholback
<arun_> Hello guys, I didn't get any feedbacks from the glibc maintainers, I was wanting to add a new language suppport(language package) having iso code ="the" ; please  helpme !!!
<dholbach> seb128, didrocks: salut mes amis! comment Ã§a va? could you add something to https://wiki.ubuntu.com/TimoJyrinki/DeveloperApplication-PPU when you have time? :)
<arun_> Hello guys, I didn't get any feedbacks from the glibc maintainers, I was wanting to add a new language suppport(language package) having iso code ="the" ; please  helpme !!!
<dholbach> arun_, maybe you bring it up on the mailing list instead?
<dholbach> ubuntu-devel-discuss@lists.u.c
<didrocks> dholbach: oh, with great pleasure!
<seb128> dholbach, salut, c'Ã©tait bien l'Inde ? sure, can do, adding to my list for today (in fact it was already in my tomboy todo note)
<dholbach> arun_, instead of posting this every couple of hour/half hour
<dholbach> didrocks, seb128: trÃ¨s bien, merci beaucoup
<didrocks> Mirv: you didn't add qtcore itself and all qt plugins?
<seb128> dholbach, nice to have you back ;-)
<dholbach> seb128, c'Ã©tait fantastique - j'au aucun idÃ©e pourquoi je suis retournÃ© :)
<didrocks> Mirv: I think you can add what we are upstream for (what's in cu2d)
<seb128> dholbach, don't forget to hug Laney for doing sponsoring reminder
 * dholbach hugs Laney
<dholbach> that's right! :)
<penghuan> Hello, anyone knows how the packageâs "Task" tag comes, if i want to set a package's "Task" tag, what should i do?
<Mirv> didrocks: can you be more specific? by qtcore do you mean qtcreator? it rarely needs updating other than new upstream version since now our stuff is separated from there. the qtcreator-plugin-ubuntu includes both plugins we have.
<didrocks> Mirv: Source: qtbase-opensource-src
<didrocks> Mirv: I don't see it in the first sentence :)
<didrocks> (also, we do have way more Qt components than what is listed)
<Mirv> didrocks: which sentence, and which list. since this is a different channel too, I don't have the context :) the upstream Qt modules are not suitable for daily release as is.
<Mirv> didrocks: the PPU page!
<Mirv> didrocks: right, now I understand what on earth you're talking about :)
<Mirv> didrocks: so... I thought I'd start with those special modules and QtC. I'm part of the pkg-kde team in Debian, so the official Qt modules can be easily added afterwards, while I'd certainly want to go through them with someone else for the next big 5.2 upload still.
<didrocks> Mirv: that was just 10 lines before I pinged you ;)
<Mirv> didrocks: yeah, there just wasn't highlight above that and I thought this was some sort of continuation from CI channel :)
<didrocks> Mirv: I think you are suited to have all Qt modules at least (I would add daily packages, but if you want to do that later on, I'm fine)
<Mirv> didrocks: ok
<didrocks> Mirv: you did all the packaging and we just sponsor you, so it's a strong suggestion :)
<didrocks> Mirv: I trust you to ask us if you have any question anyway
<didrocks> (which are what the upload rights are really about)
<pitti> jodh: is https://code.launchpad.net/~jamesodhunt/ubuntu/saucy/sysvinit/force-reload-configuration-for-broken-inotify/+merge/180690 still relevant? (I'd upload it to trusty instead)
 * Mirv added the rest of the Qt modules and most of cu2d packages that provide Qt modules
<didrocks> Mirv: great!
<jodh> pitti: yes, it very much is. I believe slangasek is going to merge it when he gets a chance.
<pitti> jodh: it looks fine to me, so if you want I can merge it now
<jodh> pitti: oh - sorry, wrong branch. one sec...
<pitti> jodh: (being patch pilot today)
<xnox> penghuan: tasks come from seeds in ubuntu, see http://pad.lv/p/ubuntu-seeds https://wiki.ubuntu.com/SeedManagement . So it's done post-upload, on the archive side.
<jodh> pitti: I've commented on the MP. Essentially, it's fine, but we might want to call on system actually using overlayfs.
<Riddell> dholbach: George Merkel on ubuntu-motu list being a bit non-CoC?
<dholbach> Riddell, I just replied to the mail
<Riddell> I wonder what's going on in his head
<dholbach> (but everybody else could have reminded him of the fact too :))
<dholbach> no idea - I assume somebody who signed up for the list at some stage, forgot about it and is now surprised about the traffic happening today
<arun>  Hello guys, excuse me !!!! I had some questions about the adding of new language having ISO Code = "the" , please help me anyone there !!!
<pitti> jodh: is that for the live session? I. e. could we just guard that with 'grep -q '^/cow / overlayfs' /proc/mounts ?
<pitti> jodh: (asked the same on the MP)
<xnox> pitti: live session, persistent usb, cloud-images with overlayfs. Or any other file system that happens to not support inotify, or have non-notifying inotify support as the case is with overlayfs.
<pitti> xnox: right, but that sounds like a rather similar check (just perhaps not with /cow)
<pitti> but we shouldn't make it too complicated; if it takes lots of grepping, stat'ing, and guessing, we might just as well do the reload :)
<xnox> pitti: similarly session-init is also affected, thus we maybe also should make all session init's reload configs, and that's a few paths /etc/xdg/, /etc/ubuntu-xdg/, /usr/share/upstart/session
<pitti> jodh, xnox: proposed a more generic solution on the MP
<pitti> I tested this on a live CD (says "overlayfs") and on my desktop (says "ext4")
<xnox> pitti: there is no inotify over NFS, when in root over NFS configuration - is /etc mounted local, or is that remote as well?
<pitti> xnox: as I said, I'm not trying to deal with each and every broken configuration, just with overlayfs :)
<xnox> i'm guessing in fully disk-less configurations it's remote.
<pitti> but then / would be remote, too
<pitti> so it could be extended to check for overlayfs or nfs
<jodh> xnox: re session init, maybe we should consider adding a ConfigurationReloaded signal that they can all react to. Depends how quickly the kernel team fix the overlayfs issue though :)
<xnox> pitti: in a way I agree with you. Polluting each invoke-rc.d call with reload-configuration is expensive and needless. And the actual usability bug in question is "i've installed $daemon package, it didn't start" and most commonly that's on overlayfs (live desktop iso / cloud image).
<pitti> @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:
<asac> cyphermox: i still roam to a 40/70 AP while there is a 61/70 AP available (on trusty)
<asac> cyphermox: you said that NM is the one deciding on such "policy"?
<ari-tczew> hallyn_: you've added 2 changes on package syslog-ng (https://launchpad.net/ubuntu/+source/syslog-ng/3.3.1.dfsg-1ubuntu1) but there is no explanation what do these changes. are they still needed? are they Debian-related, as well?
<asac> cyphermox: checking a bit on code there seem to be bgscan_simple and learn ... i only found that NM tweaks the simple parameters for the wpa_eap case, do you know where the "real" defaults used for wpa_psk are?
<dholbach> Riddell, he apologised in private and I took him off the list
<pitti> diwic: I read through bug 1197395 and the corresponding Fedora bug (I linked that now); I'd rather fix this in libpam-systemd, so that we don't have to apply the workaround in ubuntu's pulse, if that's ok with you?
<ubottu> bug 1197395 in systemd (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged] https://launchpad.net/bugs/1197395
<pitti> diwic: it might still make sense to apply it upstream of course, if the pam fix gets rejected upstream
<diwic> pitti, sure, go ahead and fix in systemd, I too think that's better
<pitti> diwic: we'd otherwise need the same fix in dconf, dbus, and whatnot
<pitti> upstart, gvfs too
<Riddell> dholbach: win :)
<diwic> pitti, I was hoping that my "blame systemd developers" patch would persuade Lennart to fix the bug upstream, but so far no response. Only been one day though.
<seb128> ev, hey, there is something weird with e.u.c
<ari-tczew> infinity: I was looking on the package source-highlight. (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/source-highlight/trusty/revision/21) debian has adopted similiar patch like yours. however, sequence in debian/rules is reversed. (http://paste.ubuntu.com/6410267/) anyhow package from Debian builds fine (tested only i386). is it OK and can be synced?
<seb128> ev, https://errors.ubuntu.com/problem/eac5049914041dcb1e77bd2c6437da8fa9eca096 has a total of 116 reports in that page, but it has more reports than that on the index (e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10)
<Mirv> didrocks: could you push a button to rebuild qtcreator-plugin-ubuntu 2.8.1-0ubuntu1 on armhf? its build dep was an arch-independent package that depended on arch specific package which hadn't yet built at the time of the first try.
<seb128> ev, e.g "https://errors.ubuntu.com/?release=Ubuntu%2013.10&from=2013-11-10&to=2013-11-13" has that report with a count=303 which is > 116 total for the detail view
<didrocks> Mirv: done
<Mirv> thanks
<xnox> cjwatson: libwebp has moved to main (MIR approved), is ok to upload imagemagick with webp enabled?
<cjwatson> xnox: Any chance of getting Debian to enable it first?  It's not something we currently disable in an Ubuntu delta, as far as I can see.
<xnox> cjwatson: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1117481/comments/3
<ubottu> Ubuntu bug 1117481 in imagemagick (Ubuntu) "Imagemagick lacks support for webp" [Undecided,Opinion]
<cjwatson> xnox: Right - I'd be more comfortable if it had reached the point where Debian was prepared to support it
<cjwatson> xnox: I'm absolutely not going to overrule an "OMG this is a security nightmare" from the Debian maintainer who knows imagemagick much better than I do - persuade *them* :-0
<cjwatson> :-)
<arun_> Hello excuse me guys , please help me add a new language
<xnox> cjwatson: not sure where "5" is taken from, given that public CVEs turned up only 3 in 2012 (as part of MIR). Unless it's part of imagemagick's CVEs of which there are more.....
<xnox> right, will talk with debain maintainer
<knocte> Cimi: ping
<Cimi> knocte, pong
<knocte> Cimi: hey, can you have a look at https://code.launchpad.net/~knocte/ubuntu-themes/fix-Radiance-CSS-precedence-of-state-pseudoclasses/+merge/194678 when you have time?
<Cimi> I approved, looks the same
<knocte> Cimi: cool thanks!
<xnox> knocte: omg! i wonder if that's the root cause behind "continue button is insensitive" if any class is applied to GtkEventBox by the application.
<xnox> (thus preventing the user to finish the installation)
<knocte> xnox: we're talking about CSS here, it shouldn't change behaviour in any way
<knocte> CSS==appearance
<xnox> knocte: hm. the button did go from (default, sensitive, active) -> (insensitive). Sure but GTK does hook in functionality to css classes. The button was loosing sensitive css class, and ability to be clickable as well upon CSS change.
<xnox> (all of us were mind boggled by it)
<knocte> a CSS change cannot cause an element lose its classs, if anything, it can change some atributes that are applied to that class in a rule
<xnox> i think ubuntu-themes are missing a few other bug-fixes that were applied in Adwaita (ordering, properties, etc)
<seb128> right, styling for some of the new widgets also
<seb128> e.g the nautilus cog menu
<knocte> probably, I already applied one of the fixes that gtk3 upstream is including
<pitti> diwic: http://paste.ubuntu.com/6410377/ does the trick for me
<xnox> seb128: knocte: so the GtkEventBox.fancy style and "style.add_class('fancy') had to be reverted in http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6033 because otherwise it was causing https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1240532
<ubottu> Ubuntu bug 1240532 in ubiquity (Ubuntu) "side by side install mode had disable back and install buttons" [Critical,Fix released]
<xnox> is there anything wrong that you can see with fancy class?
<pitti> diwic: doing final build/test now, and then I'll send that to the RH bug
<xnox> (it's done in application, so it would be after the theme is loaded)
<diwic> pitti, thanks. Feel free to add a pointer to my patch as well if you like (I don't think I have an account on fedora's bug tracker)
<ogra_> ScottK, i just saw your comment about qreal/double on the blueprint, that seems to have been decided upstream already (there is a discussion on the debian-arm ML about this http://lists.debian.org/debian-arm/2013/11/msg00015.html)
<pitti> diwic: already done in my reply from an hour ago
<knocte> xnox: does this involve any pseudo-class (states)?
<pitti> diwic: https://bugzilla.redhat.com/show_bug.cgi?id=753882#c57
<ubottu> bugzilla.redhat.com bug 753882 in systemd "pam_systemd should not use loginuid (at least not when used by su)" [Medium,Assigned]
<seb128> we should probably fix bugs like https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1186633 for the LTS
<ubottu> Ubuntu bug 1186633 in ubuntu-themes (Ubuntu) "gedit find box background should turn red when text is not found" [Undecided,New]
<seb128> (if somebody feels like doing some theme hacking/refresh)
<pitti> seb128: oh, that reminds me..
<pitti> seb128: we got gnome-icon-theme-symbolic 3.10 autosynced into proposed, but we still have gnome-icon-theme 3.8 in trusty
<pitti> seb128: this causes both packages to be uninstallable and e. g. breaks the deja-dup test
<pitti> seb128: do we want to merge g-i-t 3.10 as well, or stay at 3.8 and remove the 3.10 -symbolic sync?
<seb128> pitti, I've not looked at what change in g-i-t, updating to 3.10 seems fine in principle ... let me have a look
<knocte> xnox: by looking at it I don't think it's related, take in account that the Ambiance fix ( http://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-themes/trunk/revision/311 ) is only changing affecting elements that have insensitive, selected, focused or backdrop state
<pitti> seb128: AFAIR we wanted to by and large stay at 3.8 for trusty, didn't we?
<knocte> xnox: but the best way to know is if you test without that change
<seb128> pitti, yes, but icons should be on the safe side...
<pitti> seb128: certainly safe, yes; and we have our ubuntu icon themes anyway, so probably mostly relevant for ubuntu gnome
<pitti> and they certainly want 3.10
<seb128> pitti, 3.8 -> 3.10 is 4 commits
<seb128> 2 being a commit and revert
<pitti> hah
<seb128> pitti, there is actually 1 commit between those
<pitti> c'est facile
<seb128> oui
<seb128> pitti, do you want to do the update?
<xnox> knocte: right, so we did button.set_sensitive(false) -> add_class(fancy) to gtk_eventbox elsewhere on the gtkwindow -> button.set_sensitive(true) no longer worked, well it no longer made button sensitive nor made it accept any click / actions / signals
<xnox> knocte: with knowledge of subclasses and unbroken glade, let me experiment =)
<pitti> seb128: can't do right now (only shoestring/yoghurt can internet in the train), but later
<seb128> pitti, ok, thanks
<ogra_> pitti, i just heard you have a blueprint planned about TRIM support, will you include MMC TRIM too (for arm) ?
<ogra_> (got an url for me to subscribe ?)
<pitti> ogra_: is that any different than just calling fstrim on their mounts?
<pitti> ogra_: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming
<ogra_> pitti, well, you want the discard option in fstab
<pitti> ogra_: if it's any different, can you please make a note in the whiteboard?
<ogra_> (does fstrim set that)
<pitti> ogra_: I don't think we actually want that by default
<pitti> ogra_: I personally lean towards calling fstrim from cron instead of adding synchronous delays
<pitti> but deciding between discard and cron'ed fstrim is the main meat of that discussion
<ogra_> well, if it adds the same IO speedup as the fstab option i dont mind
<pitti> ogra_: but it sounds like you actually talk about the exact same thing; so yes, it'll be fixed one way or the other
<ogra_> good
<ogra_> yeah, there shouldnt be much difference in functionality, but the device naming will be mmc specific
<ogra_> (/dev/mmcblkXpY and such)
<pitti> ogra_: it doesn't care about device name; you run fstrim on mount points
<xnox> pitti: i'm also for cron option. Or anacron.
<pitti> ogra_: device names come into play if we want to set the discard option by default, though (but then we shouldn't look at device names but their properties, like "SSD?"/"can trim"?
<pitti> xnox: I just stuffed into cron.weekly; that should be anacron
<ogra_> pitti, xnox ... well, the question is, do we want to run cron by default on phones (and preiodically wake them up)
<pitti> ogra_: well, one less often deletes many files on the phone
<pitti> so perhaps we want discard on phone and cron on desktop/server
<ogra_> right, i added a topic to the whiteboard
<ogra_> (and subscribed)
<pitti> ogra_: heh, "performance boost" is a nice understatement
<pitti> at least on an SSD, not doing any trimming is outright broken
<pitti> after a few months my SSD went from 250 to 5 (!) MB/s write speed
<ogra_> MMCs usually work fine without but get a lot faster if the MMC supports it and you turn it on
<pitti> ogra_: do you have such a device at hand by chance?
<pitti> ogra_: can you confirm that "sudo hdparm -I /dev/mmcWHATEVER |grep -i trim" gives you something?
<ogra_> the ac100 has such MMCs
 * ogra_ hasnt booted any ac100 in a year or two though ... 
<ogra_> i'll make sure i have one working for next week
<pitti> ogra_: ah, so it's not for Panda/mako/maguro/etc?
<ogra_> pitti, i havent checked on the phones yet
<pitti> ogra_: ok, thanks
<ogra_> and panda uses SD cards ... that would have to be checked individually for each SD
<pitti> my cron job just calls fstrim /mount/point, that'll just fail on devices which don't support it
<ogra_> well, we should only enable it on devices where we know it works
<pitti> calling lots of hdparm/sysfs poking isn't any faster really
<ogra_> to not waste cycles
<pitti> but we need these checks if we want to set the discard option on devices
<ogra_> (on the phne thats easy to know in advance and just flick a switch)
<ogra_> (based on the device)
<pitti> sure
<Cimi> knocte, I noticed that we're missing menu separators, when this started happening?
<knocte> Cimi: in what theme?
<Cimi> ambiance
<Cimi> I don't have them
<knocte> I have them, and I have my patch applied, so I don't think my patches are related
<Cimi> knocte, I have trusty though
<knocte> ok, my only change that could have affected Ambiance in trusty is the removal of empty rules, which I consider very unlikely to be the culprit
<rbasak> ogra_: on a phone, how about doing stuff when (say) the phone is charging and hits 100%? Then there shouldn't be a power issue. I imagine there's other maintenance stuff that might be useful here, too. So no cron, then, but you do get reasonably regular maintenance
<knocte> Cimi: I have only requested "safe" patches for now, I was going to start with the risky ones now but I guess I'll wait a bit :)
<rbasak> I'm sure I read somewhere that dealing with trim works out better if you do it periodically from userspace rather than with discard
<rbasak> http://opensuse.14.x6.nabble.com/SSD-detection-when-creating-first-time-fstab-td3313048.html and http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support may be useful to read.
<ScottK> ogra_: Upstream has a view, but we have an option about whether or not to follow the switch or how to do it.  I'm aware of the Debian discussion.  They are interested in what Ubuntu decides to do.
<ogra_> rbasak, well, lets discuss it at the vUDS session i'd say ;)
<ogra_> rbasak, but indeed triggering something on 100% battery would be possible
<rbasak> ogra_: just a suggestion and fuel for discussion. It's not my area.
<Cimi> this is the broken commit http://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-themes/trunk/revision/315
<knocte> xnox: that is you? ^
<xnox> Cimi: knocte: yeap, also regression spotted on the bug report https://bugs.launchpad.net/ubuntu-themes/+bug/1181661
<ubottu> Ubuntu bug 1181661 in ubuntu-themes (Ubuntu) "Ugly separator in toolbar and Nautilus - Ambiance - 13.04" [Medium,Fix released]
<xnox> comment 7-8
<pitti> rbasak: "discard" will always keep your drive fast/clean, but it slows down file deletion quite a bit
<Cimi> xnox, there's also another bug
<Cimi> xnox, it removes separators
<Cimi> from the menu
<xnox> right, the bogus *v* got later reverted.
<xnox> Cimi: horizontal separators that is?
<pitti> what's wrong with horizontal menu separators?
<pitti> (I have them in saucy/trusty)
<Cimi> xnox, yes
<Cimi> pitti, ambiance
<pitti> oh, that's the wrong^Wdark theme, right?
<Cimi> yes
<Cimi> if it's possible, I'd like to be asked to review all branches we get
<Cimi> I know it's my fault I let this one, and many others, pass...
<Cimi> I worked on unity8 and thought nothing was touched on light-themes
<xnox> Cimi: right, so stuff from #1181661 should be reverted as it "blackens" _all_ menuitem separators, not just the vertical ones in inline toolbars.
<knocte> pitti: ambiance is the default theme
<xnox> Cimi: i'll make a merge proposal and ask you to review.
<Cimi> xnox, thanks
<Cimi> xnox, the bug should be fixed differently
<Cimi> xnox, adding a css rule for menuitems in toolbars
<xnox> Cimi: light-themes still have bugs and still need maintenance though to matches changes in gtk+ et.al. =/ e.g.
<Cimi> xnox, which is bad
<xnox> Cimi: yeap, i'm got that now.
<Cimi> xnox, because gtk should not break
<Cimi> but apparently gtk doesn't care of that
<xnox> Cimi: gtk is also "fixing bugs" =/
<xnox> i know. that's why i can't wait to ditch gtk =)
<Cimi> every new gtk release something related to theming changes
<Cimi> it's ridiculous
<xnox> also https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1053986 has been "fixed" by patching Adwaita to generate buttons the right way around. And i don't think i've managed to distill those Adwaita patches back for lighting-themes.
<ubottu> Ubuntu bug 1053986 in ubuntu-themes (Ubuntu) "GtkMenuToolButton looks odd with inline toolbar style" [High,Triaged]
<seb128> speaking of annoying bug
<seb128> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1018718
<ubottu> Ubuntu bug 1018718 in ubuntu-themes (Ubuntu) "columns width redrawn by multiple events" [Low,Triaged]
<seb128> Cimi, ^ could you look at that one, one of the recent comment explain the issue
<seb128> with our theme the columns change size on focus in/out
<seb128> easy to reproduce, go to e.g /etc with nautilus in list view mode
<seb128> and focus/unfocus nautilus
<seb128> the name column jump around while doing that
<rbasak> pitti: right, and AIUI if you do it less often, there shouldn't be any perf degradation unless you actually run out of free blocks, which is unlikely in a week of churn on a normal system.
<pitti> rbasak: exactly
<pitti> rbasak: and then it's running async in the bg instead of blocking your UI
<pitti> rbasak: so we mainly need to define sensible conditions when to run it
<rbasak> pitti: going from the SuSE pages, I'd go with 1) when power conditions are good (eg. 100% battery and on charge) and 2) if it hasn't been run in a week
<pitti> rbasak: mind to add that to the whiteboard of https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming ?
<pitti> it's good to collect this kind of links and experiences
<rbasak> pitti: done
<pitti> rbasak: cheers
<hallyn_> arti-tczew is gone, but in case he checks the online logs, the changes are still needed in precise since the libsystemd-daemon-dev pkg does not exist there.
<hallyn_> oh, hm
<hallyn_> i mis-spelled :)
<hallyn_> ari-tczew: syslog-ng change is needed in precise and quantal.  in raring, libsystemd-daemon-dev is present so the changes can be undone.
<ari-tczew> hallyn_: ok, so I'm going to sync it in trusty. thank you very much for help!
<hallyn_> ari-tczew: awesome, thanks
<gQuigs> hi there, can I get this meeting scheduled?  http://summit.ubuntu.com/uds-1311/meeting/22016/limiting-surveillance/
<dholbach> cjwatson, xnox: thanks a bunch!
<ev> seb128: sometimes the counters over/under count for the front page. The canonical count should be the number of reports you see on the problem page itself.
<arun_> guys, is the glibc responsible for the language option ??
<ev> (counters in Cassandra are not idempotent)
<seb128> ev, what does it mean if the report is way off the frontpage index?
<ev> Moving to Acunu Analytics for the front page counts will fix this
<seb128> ev, does it mean we can't trust the bucket/trend since it's loosing/not collecting most of the issues?
<ev> this happens rarely, I don't think it means we cannot trust the data
<ev> it's also something we can repair
<seb128> well, it makes difficult to trust the datas
<ev> since we just need to count the number of columns in the Bucket Column Family (each column is an instance of the problem)
<seb128> since I don't know if we drop is because we fixed the bug
<seb128> or because we are failing to collect the reports under the bucket
<ev> seb128: the bucket page itself should give you the confidence that you fixed the bug
<seb128> well, the number goes down there
<ev> because it's not appearing in high numbers on the newly released version
<seb128> but the summary page disagrees with that
<seb128> so what is creating the delta?
<ev> ^ bdmurray would you mind looking into this on your next Errors day?
<seb128> ev, bdmurray: thanks
<bdmurray> ev: looking into the bucket count being different on the index page compared to the bucket page?
<ev> bdmurray: yeah, ensuring that seb128 has something he can look at as the canonical source for knowing whether a problem still exists in new versions
<ev> and then why we're seeing discrepancies in the counters in the example he raises - though this one might be best fixed by bringing up Acunu Analytics if it's a problem with the counters themselves
<ev> I suspect it'll be easier now that we have the read-only access :)
<ev> you can just dig at the problemid in the database
<ev> and see what the real count should be
<bdmurray> seb128: do you have an example?
<ev> bdmurray:  there's one in the asana task I just created
<pitti> brainwash: hey, how are you? would you have some time to test systemd-shim 4 in my PPA? in theory that should work better than the fixed 10 min timeout
<pitti> brainwash: I'm now also able to reproduce that bug, with the instructions I put into the bug
<arun_> guys, is the glibc responsible for the language option ??
<seb128> bdmurray, http://irclogs.ubuntu.com/2013/11/13/%23ubuntu-devel.html#t11:36
<brainwash> pitti: sure, I can test the new package, but it will take some time until I'm able to report back. my system goes into sleep mode much faster at the momment, because I changed my gpu setup
<pitti> brainwash: ah, "it doesn't regress" is also worthwhile; but suspend/resume is also way below 1 s for me, I can only reproduce it with the 00break pm-utils script
<brainwash> pitti: did you test with an artificial delay of 30 or more seconds?
<pitti> brainwash: no, so far just with 15
<pitti> 30 seconds to suspend? wow, that sounds really broken
<brainwash> pitti: in this case the dbus connection did timeout, but the prepareforsleep flag got reset
<brainwash> hibernation probably
<pitti> brainwash: ah, that would be a different spot in the code, though
<pitti> but that would explain why some people still see this happening
<brainwash> pitti: I guess we need to wait for the new test results
<brainwash> oh wait, the latest comment does not look promising =S
<pitti> brainwash: well, neither did the first one after the first version :)
<pitti> so here's hope
<brainwash> :)
<seb128> shrug
<seb128> jodh, slangasek, xnox, stgraber: hey upstart friends ... "sudo restart networking" seems to take the system dbus bus down, is that a known issue? how would you go about debugging that? (as you can image it makes things really unhappy, including upstart)
<seb128> jcastro, ^ (that's looking at the email you sent me)
<stgraber> seb128: not really a known issue, it's a known consequence
<cjwatson> I thought "restart networking" was a "you get to keep both pieces" kind of thing
<xnox> seb128: is "sudo restart networking" at all supported?
<cjwatson> Why is anything doing that?
<stgraber> seb128: dbus is stop on deconfiguring-networking which is emitted by networking when going down, so that's indeed to be expected
<stgraber> seb128: you probably want: ifdown -a --exclude=lo && ifup -a --exclude=lo
<stgraber> though even that one isn't necessarily a good idea on systems that require event based network bring up (systems with complex bridges, bonds, ...)
<ogra_> couldnt we split networking and loopback-networking ?
<ogra_> in two separate jobs
<xnox> ogra_: we already do. networking is a dummy job, and you have network-interface* job instance per interface.
<xnox> ogra_: look at $ sudo initctl list
<seb128> stgraber, xnox, cjwatson: I don't know why people to restart networking, but they do
<seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1072518
<ubottu> Ubuntu bug 1072518 in gnome-settings-daemon (Ubuntu) "Restarting network crashes (apparently) the desktop manager" [High,Confirmed]
<seb128> jcastro, ^ do you know why user do network restart?
<ogra_> xnox, then dbus should probably depends on the loopback one
<ogra_> *depend
<seb128> why do we ever need to stop dbus?
<stgraber> ogra_: we could but that still wouldn't solve the other half of the problem (virtual interfaces ordering), so we'd just trade one bug for another. I think the real problem here is people recommending to use restart networking at all
<seb128> that should go away on shutdown with the system
<xnox> seb128: at shutdown for example =)
<seb128> do we need to stop it cleanly?
<seb128> rather than just going down?
<stgraber> seb128: apparently this was made so dbus would be stopped before the loopback interface actually goes away. I'm not sure there was a reason to do that though (like dbus crashing if the loopback interface disappears under its feet)
<arun_> guys, is the glibc responsible for the language option ??
<stgraber> if we had such a thing as a restart statement in upstart, I think it'd be reasonable to skip emitting that signal and have ifup/ifdown run with --exclude=lo, but since we don't, I think our best option is to make sure people don't do things we don't support
<seb128> stgraber, in any case it's not a g-s-d issue, where do you suggest reassigning?
<stgraber> seb128: to whatever documentation told the user to do that. Or mark it invalid as an unsupported user action.
<seb128> stgraber, well, why do we provide a "networking restart" if that's not supported? can't we just make that display a big warning with a type "yes I'm sure"?
<stgraber> seb128: because it's not possible not to provide it
<cjwatson> Right, we don't deliberately provide it, it's an emergent consequence
<stgraber> seb128: "restart networking" is just a standard upstart command
<seb128> well, can we make the "networking" job to not do what it's asked
<seb128> or ask for confirmation?
<stgraber> upstart jobs can't interact with the console
<cjwatson> The only way to do that would be to break "stop networking", which would break shutdown
<stgraber> right
<seb128> http://askubuntu.com/questions/98201/whats-the-right-way-to-restart-services-in-11-10
<seb128> can we fix the web to stop suggesting stupid commands to users? ;-)
<stgraber> we sure can try ;)
<cjwatson> restart is just stop then start as far as the job is concerned
<xnox> stgraber: cjwatson: well, we can do a pre-stop script, that will check upstart events. If there is none, it means user invoked it directly. And we can bail out. And we can check goal, if goal is to restart, we can again do nothing.
<xnox> or indeed execute ifdown / ifup sequences.
<cjwatson> that's true, although there's no such thing as a restart goal
<cjwatson> the goal is set to stop and then to start
<stgraber> and I'd rather not break "stop networking" since it's at least used in testing (by people who know what's going to happen when they do so)
<seb128> stgraber, how is that ever useful for testing?
<seb128> I don't want to screw my system, but I tried a bit earlier it took dbus's system bus down
<gQuigs> we specifically need a way to restart networking for enterprises, it's part of how to set up bonded interfaces in the server guide
<seb128> which made upstart enable to work properly
<gQuigs> it
<cjwatson> upstart uses a private connection, surely
<seb128> e.g I couldn't even use "status"
<slangasek> seb128: argh don't manually stop networking (i.e., what everyone else said)
<stgraber> seb128: it's useful when I test a new ifupdown as my test systems are simple containers that don't have anything to bring up/down when networking restarts
<stgraber> seb128: that lets me make sure all the network-interface instances get properly created/destroy and that all the events are emitted as expected
<slangasek> seb128: you should have been able to run 'status' still as root
<gQuigs> it's currently completely broken in 12.04;  there is a private escalation for it
<stgraber> if the server guide recommends restarting networking, then it's wrong and needs to be fixed
<cjwatson> status> won't work as a user if dbus is stopped, but should still work as root or with --system
<cjwatson> er, I may not mean --system
<stgraber> right, upstart as root always uses the private socket and doesn't depend on dbus at all
<seb128> cjwatson, I might have forgotten the sudo
<slangasek> cjwatson: AFAIK not with system because upstart only accepts connections from root on the private bus
<stgraber> seb128: I posted a comment on that askubuntu question, maybe jcastro can make sure it's more visible and that the current "good" answer is marked as being wrong somehow.
<cjwatson> yeah, that was a brainfart
<slangasek> gQuigs: can you give us a specific reference into the server guide?  the server guide should be fixed
<seb128> cjwatson, thanks ;-)
<cjwatson> but it should be fine with sudo, anyway
<seb128> google return lot of "/etc/init.d/networking restart" from the old times
<slangasek> right
<slangasek> we can file off some of the sharp points here, but fundamentally, "networking restart" was /never/ the correct interface
<seb128> right
<gQuigs> slangasek: I detail it here: https://bugs.launchpad.net/ubuntu-advantage/+bug/1210277  we through users for a loop and don't actually have a way that works...
<ubottu> Error: ubuntu bug 1210277 not found
<seb128> it's just that it bites users really since it takes the desktop fully down
<jcastro> seb128, I don't know why people do it, they apparently do it enough to bother people
<jcastro> stgraber, can you link me to the AU question with the wrong info? we can fix that.
<stgraber> jcastro: http://askubuntu.com/questions/98201/whats-the-right-way-to-restart-services-in-11-10
<gQuigs> slangasek: https://help.ubuntu.com/12.04/serverguide/network-configuration.html and in https://help.ubuntu.com/13.10/serverguide/network-configuration.html
<stgraber> hmm, that last one should just be "ifup br0"...
<cjwatson> yeah, trying to restart the entire networking stack seems like an unnecessarily gigantic hammer there
<slangasek> right
<jcastro> stgraber, ok so that's a duplicate, I can have the answer removed
<jcastro> but we need the proper way someplace on: http://askubuntu.com/questions/19320/what-is-the-recommended-way-to-enable-disable-services
<ogra_> but its a very common answer in debian and ubuntu forums
<ogra_> as wrong as it is, it is very wide spread
<jcastro> I think the issue is people don't expect their desktop to stop working when you restart networking
<stgraber> jcastro: look at my comment on the link I gave you, that should cover what people should be doing
<slangasek> enable/disable services> that seems unrelated to restarting the networking stack
<xnox> arges: ^^^^^^^ (Re: networking, one shouldn't do "restart networking", instead one should ifdown/ifup individual interfaces as needed)
<stgraber> well, also, "restart networking" won't actually restart anything on a desktop, it'll just break your machine :)
<stgraber> "restart network-manager" would be vaguely more correct :)
<ogra_> vaguely
<xnox> stokachu: ^^^^^^
<jcastro> http://askubuntu.com/questions/230698/how-to-restart-the-networking-service
<jcastro> here we go
<jcastro> ok so I added a link from the main "services" question, and I've flagged all the incorrect answers
<jcastro> so they will be removed shortly
<gQuigs> in any case; we do have enterprise customers that want to restart all of networking to updating multiple bonded configurations at once
<gQuigs> they can also use out of band management, so it does actually make sense to restart networking and not the entire machine
<jcastro> also there's plenty of old people like me who just grew up with "/etc/init.d/networking restart" as the hammer for everything network related
<seb128> yeah, same here, I used to use that before the n-m times
<gQuigs> chaining ifupdowns for 8 physical interfaces and several bonded interfaces is not usable
<xnox> stgraber: stop --all-instances job (or just stop --all job)
<xnox> (which doesn't exist at the moment)
<stgraber> xnox: sure but I usually want to make sure that they all stop on the expected events, remember, I'm testing ifupdown, not upstart ;)
<arges> xnox: yup that was my understanding. I think the only thing is we should probably fix the 'stop: Unknown instance' not defined in precise.
<arges> anyway half at lunch need to read the backlog...
<xnox> arges: that can be done. But i'm not sure if we have any ways to notify user though.
<xnox> arges: start with seb128 at 5 minutes to.
<stgraber> slangasek: I sent a MP to the serverguide, replacing the two instances of restart networking by the proper ifup/ifdown command
<slangasek> stgraber: cheers
<stgraber> gQuigs: in such case, you probably want: "ifdown --exclude=lo --exclude=... -a && ifup -a" where you list all interfaces that aren't affected (such as monitoring interfaces, ...) as excludes, then you bring the rest down and everything back up
<stgraber> though note that bonds specifically rely on the event based bring up, so this will only work if you /etc/network/interfaces has been written in the right order, if you didn't, it'll deadlock
<stgraber> (ifupdown itself is sequential, that's why we try never to use the -a option as it'll just hang if any dependency isn't there)
<gQuigs> stgraber: so how do I bring a bond up?? or reconfigure it?
<stgraber> ifdown bond0 && ifup bond0
<arges> stgraber: on a side note: bug 1065077 affects p/q and I'll be SRUing that. using ifup/ifdown on bonded interfaces take 1.5m before that patch and 5s after
<ubottu> bug 1065077 in ifenslave-2.6 (Ubuntu Quantal) "Ifenslave pre-up doesn't wait for slaves when usr is a seperate partition" [Medium,In progress] https://launchpad.net/bugs/1065077
<arges> which causes some reboots to have the 'waiting for network configuration' upon boot
<stgraber> arges: yeah, I saw that, thanks
<jcastro> stgraber, seb128: ok I've corrected nearly all the mentions of restarting networking on AU, here's the only one I am unsure about: http://askubuntu.com/questions/347687/how-can-i-enable-and-keep-wifi-without-restart-networking-service-in-ubuntu-serv
<jcastro> `ifdown --exclude=lo -a && ifup --exclude=lo -a` <-- nobody is ever going to remember that btw
<slangasek> honestly, it can probably just be 'ifdown -a && ifup -a'
<slangasek> stgraber: is there a specific reason to worry about lo?
<arges> is there a risk of loopback is brought up/down
<gQuigs> how is that better than just making that be what restart does?
<stgraber> I think newer ifupdown won't ever touch lo even if you tell it to (it even no longer needs to be in /e/n/i) but on older version, -a may bring lo down
<stgraber> gQuigs: because as we said above, there's no such thing as "restart" in upstart, we can't make restart do something different than stop+start
<slangasek> jcastro: the problem statement on http://askubuntu.com/questions/347687/how-can-i-enable-and-keep-wifi-without-restart-networking-service-in-ubuntu-serv implies he has some serious misconfiguration going on, I wouldn't hazard an answer without a clearer problem description
<stgraber> slangasek: the recommendation for that --exclude is that at least dbus seems to be specifically designed to shutdown before lo goes away, so I suspect it does something bad if lo just vanishes
<arges> stgraber: what usecase is there for doing 'service networking restart' ?
<stgraber> arges: none
<arges> or is there none ?
<arges> ok
<slangasek> stgraber: no, dbus is 'stop on deconfiguring-networking' because that's the /latest/ we can shut dbus down
<slangasek> not because taking out lo will break it
<slangasek> anyway, /etc/init/networking.conf doesn't take down lo at all, not sure why that is
<gQuigs> stgraber: umm.. so?  I'm happy with restart = stop + start... in fact isn't that the definition?
<jcastro> stgraber, ok, so I searched the site for networking restarting and all the answers now point to that question, so we should be set pending some flags getting actioned by the community
<seb128> slangasek, why do we need to stop dbus?
<mdeslaur> tjaalton: what's mod_revocator, and is the ubuntu change to nss still necessary?
<slangasek> seb128: because that's the trigger for other services like network-manager being stopped
<stgraber> slangasek: ok, then ifdown -a && ifup -a may be safe. I guess the other reason is to keep "something" around so that we don't get weird behavior from software binding to :: suddenly noticing that there's really nothing to bind at all
<seb128> hum, k
<slangasek> stgraber: well, but so what? :)  things trying to bind while you're in the process of making administrative network changes are undefined
<slangasek> seb128: if you think we should keep dbus running and stop the individual services instead, it's possible we could do that, but someone would need to double-check that dbus wouldn't hold any files open under /usr or /var
<stgraber> slangasek: anyway, the way ifup/ifdown work nowadays, -a is indeed "safe" for both as lo is now special cased in ifupdown, so I guess telling people to do ifdown -a && ifup -a is fine
<slangasek> (so that we can cleanly unmount)
<stgraber> (with the usual warning about event based bring up and the fact that if their /e/n/i isn't properly ordered, it'll just hang there)
<slangasek> stgraber: I don't believe there was ever a reason that it was unsafe even when it did handle lo
<slangasek> if you think there is one, let's figure out, concretely, what it is :)
<seb128> slangasek, I've no strong opinion, dbus is a core component and it feels like that's not something we would need to take down "that easily"
<arun_> adam_g: are u the maintainer of glibc for Ubuntu?
<slangasek> seb128: it's not "easily", it's only supposed to be stopped at shutdown, because *networking* is only supposed to be stopped at shutdown
<sarnold> arges: I've done 'sudo restart networking' before when network-mangler was Very Unhappy and I wanted a quick way to kill it and force my network configuration to happen completely fresh. I got that chance when I had to reboot. :/ I was very unhappy.
<seb128> slangasek, well, reality is that user memory/internet/old habits makes that command to be run more that it should ... and it's hard to fix the internet/old habits
<arges> stgraber: so the upstart networking script is just used/useful during boot and shutdown then?
<slangasek> seb128: and if we need to make it possible to keep dbus alive in spite of misuse of /etc/init/networking.conf, we can do that; let's not conflate that with the shutdown problem
<seb128> slangasek, you are right
<ogra_> dont we have something like "stop on stopping filesystem" ?
<ogra_> that dbus could use instead
<slangasek> no
<slangasek> nor should there be one
<stgraber> slangasek: well, I just tried on my laptop for fun, no service appear to have crashed, however for whatever reason wpa_supplicant or NM became deeply unhappy and I lost my wifi connection. Had to re-initialize it entirely after lo came back up.
<slangasek> stgraber: interesting
<ogra_> slangasek, well, it swwms likw a workaround to make dbus depend on networking while we need it stopped for unmounting
<ogra_> *seems
<stgraber> ogra_: I think the reason was because of network filesystems on desktop machines
<ogra_> ah
<stgraber> ogra_: basically for those you need NM to be running, for NM to run, you need dbus
<slangasek> it's 'stop on deconfiguring-networking' -> dbus -> N-M
<ogra_> yeah, understood
<ogra_> slangaseks statement above sounded like it would only be filesystem related
<slangasek> seb128: incidentally, dbus shows open FDs for /var/run/[...]; those should be fixed to reference /run instead
<stgraber> it's, we want NM to go away very late to avoid hanging on network filesystems but we also need NM to really go away instead of keep on running till the end as it has a bunch of files opened which prevent the remount of /
<slangasek> (not sure if following the /var/run symlink would hold /var open)
<seb128> stgraber, I'm surprised that NM copes well with the system bus going down
<slangasek> it doesn't
<ogra_> hmm, intresting ... so i upgrade my new XPS13 to 12.10 and update-mananger asks me if i want to replace /etc/init.d/casper ...
<stgraber> seb128: it doesn't
<stgraber> seb128: when we stop dbus, NM goes away, that's why we're shutting down dbus so late so we can keep NM around till as late as possible
<ogra_> i wasnt aware casper ever had a sysvinit script
<seb128> I see
<stgraber> ogra_: well, I guess the question mostly is, why is casper installed on your system? :)
<ogra_> stgraber, ask dell ... the device runs only as long as i needed to have u-m do the upgrade and to install xchat
<ogra_> like 1.5h or so
<ogra_> i havent installed any SW except xchat yet
<ogra_> (or removed)
<xnox> ogra_: do you have "dell-recovery" installed? or oem-config?
<ogra_> xnox, i think oemÃconfig uninstalled itself, but yeah, dell-recovery is indeed there
 * ogra_ allows it to replace ... 
<ogra_> i still have more upgrades to do tonight ...
<tjaalton> mdeslaur: an apache module needed by dogtag pki, although neither of those have made it to debian/ubuntu yet..
<ogra_> bah
<ogra_> it repopulated the launcher with all the default crap :(
<mdeslaur> tjaalton: is it worth me still merging those changes? I'll do what you think is best
 * ogra_ reboots 
<tjaalton> mdeslaur: hmm looks like dogtag 10 doesn't need it anymore, I'll double check to be sure
<tjaalton> mdeslaur: nah it still does, but maybe best to get that from debian along with the other pending changes I need.. so feel free to drop the diff
<mdeslaur> tjaalton: cool, thanks for checking
<tjaalton> yw
<mdeslaur> infinity: hi! libimobiledevice has an ICE on arm64...do I mash retry or do you still push it on a specific builder?
<xnox> mdeslaur: mash retry until it hits b*
<mdeslaur> xnox: thank
<arges> stgraber: hi.
<arges> in bug 1065077 you changed (seq 600) to a while loop that only counts to 50. is this a typo or deliberate?
<ubottu> bug 1065077 in ifenslave-2.6 (Ubuntu Quantal) "Ifenslave pre-up doesn't wait for slaves when usr is a seperate partition" [Medium,In progress] https://launchpad.net/bugs/1065077
<stgraber> arges: good catch. typo. I'll upload ifenslave-2.6 with a 60s timeout to trusty
<arges> stgraber: before you do, I'd like to discuss the further implications of it
<arges> stgraber: so we're seeing a bug where bringing a bonded interface using ' sudo service network-interface start INTERFACE=bond0' takes most of the timeout (60s) and obviously with this shortened timeout it doesn't delay as quickly
<arges> stgraber: this bug causes issues when booting with bonds where we are more likely to hit the 'waiting on networking' message during boot
<stgraber> well, that message in itself isn't a problem
<stgraber> so long as the network is up by the time the 3min timeout hits (otherwise services may start before the networking is ready)
<arges> so why does it take such a long time to bring up bonded interfaces?
<stgraber> it doesn't take time to bring them up, but it can take a lot of time for the kernel to detect them
<stgraber> I've seen bug reports of some systems where it'd take minutes for the kernel and udev to be done processing all the interfaces
<arges> hmm...
<stgraber> once the interface is ready to be bonded, ifenslave and ifupdown need less than a second to configure it
<arges> stgraber: so in the ifenslave pre-up script there are two waits... one for the bonding module which is 5s and the other is for the slave interfaces to join the master
<arges> does the later wait make sense to be 60s?
<arges> stgraber: anyway. if it makes sense for the delay to be 60s, then the SRUs for P/Q i'll make sure are 60s, are you going to push a fix for R/S as well? or should i take care of that
<stgraber> arges: I'm just pushing to trusty, the actual waiting time is completely arbitrary so 50s vs 60s isn't really going to make a huge difference :)
<arges> well in this case it is 5s vs 60s
<stgraber> oh indeed it's... yeah, that may fix some bugs ;)
<stgraber> not that I actually saw any report that could be tracked down to that
<stgraber> it'll also make things worse for someone who would configure a bond but not any member (or make a typo in the bridge name) as it'll now take longer before ifupdown gives up (though that'll at least match what ifupdown prints)
<arges> stgraber: yea if 5s works for people, then why the long delay in the first place?
<stgraber> because of those few weird systems where it can take minutes for hardware to be done initializing
<stgraber> (blade systems with dozen of network cards is one known case)
<arges> stgraber: it takes long times for bonding to get set up for me even in virtual machines
<arges> so i run into the 'waiting on network configruation' pretty often with basic bonded setups
<stgraber> arges: hmm, that's odd, can you pastebin your /etc/network/interfaces ?
<arges> stgraber: yea booting up the vm right  now...
<arges> so this is the original bug i was looking at, then i essentially found that raring fixed it, and found this bug... then as I was formatting the debdiff for the SRU i noticed the descrepancy
<stgraber> yeah, looks like I copy/pasted the first loop without bumping the wait time
<arges> stgraber: http://pastebin.ubuntu.com/6412656/ this is the bare-bones interfaces file i was using to reproduce
<arges> note that it reproduces intermittently (at least on kvm) for me.
<arges> anyway, i can file another bug for this one. For now how should I fix bug 1065077?
<ubottu> bug 1065077 in ifenslave-2.6 (Ubuntu Quantal) "Ifenslave pre-up doesn't wait for slaves when usr is a seperate partition" [Medium,In progress] https://launchpad.net/bugs/1065077
<stgraber> arges: wow, that config is pretty wrong ;)
<stgraber> arges: try that one instead: http://paste.ubuntu.com/6412714/
<arges> stgraber: why wouldn't the bond-slaves contain eth0?
<stgraber> basic changes are, ordering (so that ifup -a would work), emptying bond-slaves as it's meaningless on Ubuntu, moving IP configuration from the slave up to the bond as otherwise you're in undefined behavior
<stgraber> because we're doing event based networking on Ubuntu, we can't guarantee all the slaves will be present at the time you try to bring up the master, so that's why ifenslave ignores bond-slaves and instead has the master wait for a slave to appear, the slave -> master relation being done through bond-master on the slave
<stgraber> that's also why slaves should always be listed before the master in the config
<stgraber> so that ifup -a will bring up a slave which will in turn bring up the master, doing it the other way around will give you the 60s timeout
<arges> stgraber: so the interfaces file is followed sequentially?
<stgraber> when calling ifup -a, yes
<arges> which is called by the upstart scripts
<stgraber> when booting Ubuntu, interfaces are brought up independently when receiving kernel events
<stgraber> so if your interfaces file ordering is wrong, it'll likely still work at boot time so long as udev emits net-device-added
<stgraber> but if it hits the fallback (networking.conf), then it'll hang
<stgraber> (networking.conf works as a fallback in the boot sequence, calling ifup -a to bring up anything that wasn't brought up through events)
<arges> stgraber: ok more complex example here: http://paste.ubuntu.com/6412731/
<arges> with what i think it should be after my review and your comments
<stgraber> hmm, I'm not sure the mtu stanza is allowed on manual interfaces, if it's not, then you'll need to use a pre-up instead
<stgraber> but the ordering is indeed correct. I'm also not sure whether anything expect bond-slaves to be set, if so, you'll have to set it to none
<arges> stgraber: ok i'll test with that.  Is the interface ordering for /etc/networking/interface documented somewhere?
<arges> stgraber: nm man 5 interfaces, shows ifup brings the named interffaces up in the order listed
<arges> stgraber: thanks for your help!
<stgraber> right. I don't think it's actually written anywhere that ifup isn't doing parallel bring up but it can be assumed
<stgraber> arges: also, the examples in the ifenslave-2.6 packages should be correct
<stgraber> arges: https://www.stgraber.org/2012/01/04/networking-in-ubuntu-12-04-lts/ may also be ueful
<stgraber> *useful
<arges> cool thanks
<orbisvicis> how do I find out which version of ubuntu a particular versioned package belonged to?
<slangasek> orbisvicis: https://launchpad.net/ubuntu/+source/$package (for example)
<orbisvicis> i need to go further back than supported releases
<orbisvicis> is there an index in a repository (http://old-releases.ubuntu.com) that could help?
<tarpman> orbisvicis: the
 * tarpman sigh
<tarpman> orbisvicis: the "View full publishing history" link on the package page should have the complete history
<tarpman> orbisvicis: or, if you're wondering about a particular version, you can go straight to https://launchpad.net/ubuntu/+source/$package/$version and it has a publishing summary
<orbisvicis> tarpman: perfect, thank you
<orbisvicis> (I was wondering about a particular version)
<slangasek> or, if you have that version of the package available, you can just look at the top of the changelog included in the package
<doko> zul: simplejson should not build for pypy (universe). at least barry did that for beautilsoup4
<doko> jamespage, there are some java sources ready for demotion. were these intended? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<zul> doko:  ack
<doko> well, barry didn't do it yet for bs4 :-/
<bdmurray> slangasek: regarding the already installed and configured bugs I've seen some cases like bug 1250951 where one package operation crashes and then the next one runs into the already installed and configured error
<ubottu> bug 1250951 in dpkg (Ubuntu) "package linux-image-generic 3.11.0.13.14 failed to install/upgrade: package linux-image-generic is already installed and configured" [Undecided,New] https://launchpad.net/bugs/1250951
<slangasek> bdmurray: right, historically this kind of problem only shows up if something goes wrong with an earlier package operation
<slangasek> but something is sending the wrong request to dpkg in these scenarios... and it's not apt
<bdmurray> in the log files all we have is "Commandline: aptdaemon role='role-commit-packages' sender=':1.73'" which doesn't specify a version of aptdaemon
<bdmurray> slangasek: Do you think gathering information about the aptdaemon version would help or is there something else we would need?
<slangasek> bdmurray: I think that's the place to start
<slangasek> xnox: hmm, "not booting flipped"?
<slangasek> xnox: N7> AUUUUGH NOO :)
<xnox> slangasek: yes, i'm booting a tarball from system-image.ubuntu.com not from cdimage.ubuntu.com/ubuntu-touch/)
<slangasek> xnox: the N7 is absolutely not the template for android partitioning
<xnox> slangasek: sure, but i don't want to brick my N4 =)
<slangasek> the N7 is the device we can't get rid of the loop mount on, because it has broken firmware that causes its GPT to be broken in three different ways
<xnox> slangasek: what's wrong with N7? N4 partitions are semi ok.
<slangasek> all of which are N7-specific
<xnox> slangasek: ok.
<xnox> slangasek: and N4 GPT? any better?
<xnox> slangasek: so I call cdimage.u.c/ubuntu-touch-preview/ - unflipped, /ubuntu-touch/ - flipped, system-image.u.c - systemimage
<slangasek> xnox: the N4 GPT should be fine
<slangasek> xnox: right - and 'flipped' should be the current baseline
<xnox> in flipped, indeed android's system partition is mounted direct from the system one.
<slangasek> oh
<slangasek> but the difference between flipped and unflipped is whether Android is in a container, or Ubuntu is
<xnox> slangasek: i don't think so. given that (a) system-image is easier to boot and port to new devices. (*) as long as one touches /userdata/.writable_image ;-)
<xnox> and system-image is better tested model =) and boots more reliably.
<slangasek> oh, so you mean system-image rather than flipped
<xnox> yes.
<slangasek> right
<slangasek> yeah, that's what I mean by 'flipped should be the current baseline' - because calling it "flipped" implies the question, "flipped wrt what" :)
<xnox> currently it was agreed that emulator should look more like system-image. And it does mimic it rather well, the final booted state. There is no way to actually apply delta updates.
<xnox> slangasek: ok. so it is flipped+optionally-ro
 * ogra_ still disagrees with that decision 
<ogra_> (going for system-image immediately)
<xnox> ogra_: (a) final phones will be system-image (b) will-not have android sized partitions (c) we need to get there somehow
<xnox> ogra_: what do you think about bypassing CM and rebasing on top of kitkat/AOSP ?
<ogra_> right, but we dont help porters with that
<ogra_> i wish we had gone the same way we had to go for our phones and which porters have to go as well
<slangasek> we're not doing all this work on the emulator to help porters
<xnox> ogra_: phonedations can help porters ;-)
<xnox> if there is any spare time
<ogra_> not really anymore ... i have not the slightest clue about the current probs that show up when porting
<xnox> ogra_: i'll just post how to start a port direct from system-image, how about that?
<ogra_> going the same path would have helped
<ogra_> and we could have updated the docs alongside
<slangasek> no, going the same path would have just slowed us down
<ogra_> anyway, its to late now
<ogra_> we're simply leaving the community behind
<ogra_> (none of the ports is even near to functional, we gave up on them and they gave up on us)
<ogra_> i wish we had sent a sign to them with the emulator work (and updated the porting docs)
<xnox> well emulator is not functional yet - it doesn't read kernel/initramfs of the hard-drive, nor has unity painting anything on the screen.
<slangasek> any minute now :)
<ogra_> yeah
<ogra_> rsalveti rocks ... only minor details left :)
<barry> doko: i might get to it tomorrow
#ubuntu-devel 2013-11-14
<hallyn_> infinity: extracting the arm64 ubuntu core image for saucy, i get /lib/ld-linux-aarch64.so.1: No such file or directory when i try to run something.  should that exist, or does that mean my interpreter is bogus?
<infinity> hallyn_: It should and does exist...
<brainwash> is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632598 a security related issue? is does affected ubuntu and the debian report is still open
<ubottu> Debian bug 632598 in grub-common "grub-mkconfig: should set safer permissions even when hashed passwords are found" [Normal,Open]
<brainwash> woops, "it does affect ubuntu", that's what I tried to type :)
<hallyn_> infinity: huh.  it's not here in mine.
<hallyn_> wait.  now it is.  wtf
<hallyn_> a few sips of duvel must be what fixed it
<hallyn_> now i have to move everything to a vm :)   FATAL: kernel too old
<sarnold> cjwatson: brainwash asks ^^ about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632598 -- is there a reason why the grub.cfg is left world-readable? My inclination is to take the patch proposed by Francesco but perhaps forcing the mode regardless of password vs password_pbkdf2
<ubottu> Debian bug 632598 in grub-common "grub-mkconfig: should set safer permissions even when hashed passwords are found" [Normal,Open]
<rsalveti> slangasek: xnox: ogra_: the goal of the emulator is to simulate a real device, using the supported path we use
<rsalveti> as we want it to be the main "hardware" to support our CI
<rsalveti> so we want to make sure it's as close as possible with our supported solution
<rsalveti> but it also works with the old flipped model, we can have a tutorial for that if needed
<rsalveti> I tested that locally, it's just that it's not what we want to officially support
<rsalveti> and I think we can better support the porters in a different way
<rsalveti> xnox: I believe we want to support both CM and AOSP, when we rebase to kitkat
<rsalveti> as we can't just ignore the porters
<rsalveti> I still don't know how we'll manage that, but something to keep in mind
<pitti> Good morning
<pitti> slangasek: ah, I couldn't agree more to your "UDD" response wrt. "don't commit to them"
<cjwatson> sarnold: It's very irritating for debugging when grub.cfg is world-unreadable; I'm inclined to take Francesco's patch
<cjwatson> (more or less directly)
<didrocks> enjoy Debian miniconf cjwatson :)
<pitti> gnargh, alioth down for a week now :/
<cjwatson> annoying isn't it
<pitti> muchly
<pitti> does anyone know whether it's possible to exclude debian/patches/ from a Launchpad build recipe? https://help.launchpad.net/Packaging/SourceBuilds/Recipes has nothing in that area
<pitti> but my daily builds keep failing because it tries to apply the 00git_*.patch cherrypicks to trunk
<diwic> pitti, I don't think it's possible
<pitti> diwic: ah, I was afraid of that
<diwic> pitti, hmm, maybe you can take an empty branch and use the nest command ?
<diwic> pitti, like, overwriting it with an empty directory or something
<diwic> pitti, not sure it works, but could be worth a try
<pitti> diwic: I have a feeling it's additive, but it's a nice idea
<pitti> diwic: well, that branch could have an empty debian/patches/series, which shold overwrite the old one
<diwic> pitti, yeah
<diwic> pitti, it's possible it complains that the directory already exists though, in which case you have to do some ugly scripting instead (like erasing all patches first in the clean target or something)
<pitti> diwic: that's too late -- dpkg-source will complain about the patches on unpack?
 * pitti tries that "empty series" trick
<diwic> pitti, actually, if you look in the src for making recipes, there is some way to run a shell command, but it seems to be turned off on the launchpad server
<pitti> heh, it better be :)
<diwic> pitti, this is from my vague memory from a year ago or more
<diwic> pitti, anyway, since you have magical lp powers maybe it's turned on for you...
 * pitti creates the marvellous piece of two years of engineering lp:~pitti/+junk/empty-series
<pitti> ok, not that easy (https://launchpadlibrarian.net/156547038/buildlog.txt.gz)
<pitti> I'm looking for a libc function or shell tool which produces a (line-by-line) merged pipeline from two pipelines; essentially the opposite of tee; any ideas?
<pitti> use case: I want to tee stdout and stderr, and merge the combined result into a log file
<pitti> I think you can open a FIFO several times for writing, but that might potentially garble lines
<StevenK> pitti: 'paste' ?
<rbasak> pitti: could annotate-output help you here? It'll run a command, take its stdout and stderr and combine them to stdout
<rbasak> pitti: (on a line by line basis)
<pitti> rbasak: in principle yes, except for the annotation bits
<pitti> StevenK: ah, that sounds just like I was looking for, thanks!
 * rbasak wonders if socat has a suitable option
<pitti> StevenK: ah no, that does some magic tricks with joining lines with tabs, and they need to match in number
<StevenK> pitti: You might be able to get away with -d\n, but I'm not sure.
<pitti> StevenK: that still reads lines pairwise
<pitti> StevenK: I'll try with plain FIFOs
<pitti> that should by and large work; stdout/err work no different, after all
<StevenK> 2>&1 ? :-P
<pitti> I want to retain the original stdout/stderr, not merge them together
<ogra_> use tmp files ?
<ogra_> (and post-process them)
<pitti> ogra_: how would that help?
<pitti> nah, you can't open a file for writing twice
<ogra_> one for each command and then merge tzhem afterwards
<pitti> I think I'll use one tee for stdout -> stdout + FIFO, another tee for stderr -> stderr + FIFO, and a cat from FIFO to logfile
<pitti> ogra_: you don't know how to interleave them, though, and you wouldn't get realtime logfiles
<ogra_> indeed
<rbasak> pitti: for the effort that would take, have you considered writing a quick Python script?
<pitti> rbasak: that is a python script, it's called "adt-run" :)
<pitti> rbasak: I want to simplify the rather convoluted way of logging
<rbasak> pitti: I'm not sure that qualifies :-P
<pitti> I want to do it in one place, not spread over all the code
<rbasak> It looks more like a Perl script to me
<pitti> rbasak: heh, yes
<pitti> rbasak: although I spent some time to make it a little better
<rbasak> I saw the changelog entries. I appreciate it!
<pitti> rbasak: and I am doing some refactoring/cleanup to make it a bit more comprehensible
<pitti> rbasak: I still don't understand these AutoFile classes at all, but that'll be the next step after cleaning up the output/logging handling
<slacko253281> hi guys
<slacko253281> i have question about pst, do you have any idea which application can read pst files from outlook so i can use it?
<slacko253281> hi guys
<pitti> slacko253281: evolution with the evolution-plugins package allegedly can
<ogra_> dholbach, !!! congrats
<ogra_> "Condorcet-Sieger: schlÃ¤gt jeden anderen Kandidaten" ....
<ogra_> stop beating the other candidates though :P
<dholbach> ogra_, you're such a troll :)
 * dholbach hugs ogra_
<seb128> ok, so wpasupplicant is on top of e.u.c (which was expected since we cleaned the other issues) ... who is looking at that component?
<seb128> cyphermox, stgraber: is that one of you? ;-)
<seb128> mvo, update-manager is second, please help on bug #1024590 ;-)
 * ogra_ hugs dholbach 
<ubottu> bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed] https://launchpad.net/bugs/1024590
<seb128> ev, bdmurray: is there anything we can do to debug/fix non working retracings on e.u.c? e.g https://errors.ubuntu.com/problem/bbbc7a7db95644fe731284a597366bf199bae00a is not very useful without more info
<seb128> pitti, hum, for some reasons it seems http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt still isn't happy with gnome-icon-theme
<seb128> diwic, hey, in case you didn't notice, your g-c-c test ppa for that raring user failed to build, looks like a typo in the patch you added there
<mvo> seb128: hey seb128, sorry for letting you down on this, you asked me some days ago already, I just didn't mangaed to find time yet :/
<seb128> oh, a mvo
 * seb128 hugs mvo
<seb128> mvo, no worry, sorry for being impatient, I'm exited by the LTS coming and trying to clean e.u.c issues ;-)
<diwic> seb128, thanks for the heads up. I did notice, and blamed myself for forgetting to test-compile the stuff before sending to the ppa. And then other things happened and I forgot to fix and upload a new one
<seb128> diwic, np, thanks for helping debugging that one!
<ogra_> hmpf
<ogra_> software-center is really crashy for me in trusty
<seb128> ogra_, backtrace?
<ogra_> seb128, seems to be X/compiz/Gdk related
<ogra_> http://paste.ubuntu.com/6415934/
<seb128> shrug
<seb128> ogra_, can you get a stracktrace?
 * ogra_ bets it would go away after a reboot ... 
<seb128> ogra_, export GDK_SYNCHRONIZE=1
<seb128> $ gdb python
<seb128> (gdb) r /usr/bin/software-center
<seb128> ... get the issue
<seb128> (gdb) bt
<seb128> ogra_, ^
<seb128> oh, I get those as well
<seb128> webkitgtk, shrug
<seb128> ogra_, could be https://bugs.webkit.org/show_bug.cgi?id=123480
<ubottu> bugs.webkit.org bug 123480 in WebKit Gtk "ubuntu software center hits _XReadEvents() error" [Normal,Unconfirmed]
<ogra_> seb128, http://paste.ubuntu.com/6415950/
<seb128> hate webkit
<seb128> the new version seems to make things even buggier for s-c :/ (that was already one of the most reported saucy issues)
<ogra_> bah
<seb128> ogra_, yeah, it's the same stacktrace that the bug I gave the url to
<ogra_> yup
<ogra_> just looking at it
<ogra_> sigh
<seb128> I wonder why the log has
<seb128> [000:004] Using Gtk2 toolkit
<seb128> dobey, isn't s-c using gtk3?
<arun_> Guys anyone here freom dev team
<doko> xnox, looking at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt, boost demotions. how did we handle these in the past? should these be kept in universe?
<stgraber> seb128: that's usually cyphermox
<pitti> seb128: I guess it's because there's the failed deja-dup test; we need to restart it, once the DC is back
<seb128> pitti, it's weird, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate", aren't tests on that report?
<cyphermox> stgraber: I'm looking into it
<seb128> cyphermox, stgraber: thanks ;-)
<pitti> seb128: g-i-t-symbolic has the failed test
<cyphermox> the thing is, there is not one successful trace, and I wasn't able to retrace it myself either
<cyphermox> trying some more
<seb128> pitti, oh ok, that would explain it indeed, danke
<seb128> cyphermox, do you have some dumps?
<pitti> seb128: but the "private jenkins" URL now points into the void, as the IPs changed
<cyphermox> seb128: yeah
<seb128> or are you able to reproduce the bug?
<cyphermox> not able to reproduce, no
<cyphermox> I have no idea how, nothing mentions it :)
<mitya57> Mirv: hi, I just saw your PPU application â I think it'll be a good idea to create a packageset containing all qt packages so that other people (like me :P) can easily request access to it.
<doko> pitti, hunspell-br wants to demote, anything changed in the language-* stuff?
<pitti> doko: you mean it wants to *pro*mote? (because that's what c-m says)
<pitti> doko: we seed all the dictionaries, yes
<doko> ok, will do
<saiarcot895> How long does it take for a backports request to be processed?
<pitti> seb128: ah, I updated VPN config for the new DNS, I started http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-deja-dup/
<seb128> pitti, danke
<pitti> jibel, cjwatson: can we update the excuses page for the private jenkins URLs from the IP to d-jenkins.ubuntu-ci ?
<Laney> pitti: cjwatson: doing
<stgraber> are the IPs the same at least?
<stgraber> otherwise we'll need to get IS to update all the firewalls again
<pitti> stgraber: no, they all changed, hence my question
<stgraber> pitti: well, we can change our config in the scripts to use the name, but firewall rules all use IPS
<stgraber> pitti: so we still need someone from CI to send a list of old ip => new ip to IS so they can update all the firewalls accordingly
<Laney> Not sure what the path for jobs to get submitted is
<jibel> stgraber, IP changed, but I don't know yet if services that hosted autopkgtest will move or not to another server
<Laney> jibel: It should ideally get a DNS record
<jibel> Laney, there is a DNS record now, just don't have the confirmation of name of the machine
<pitti> jibel: d-jenkins.ubuntu-ci works here
<jibel> pitti, right, but the gateway with the lab seems to still be jiufeng
<Laney> Is it the same for submission and viewing?
<pitti> there's also an s-jenkins, q-jenkins, and possibly others; I read "d-" as "distro"?
<pitti> Laney: AFAICS, yes
<Laney> The IPs were different before
<pitti> yeah, I have two different IPs in my browser history, but they seemed to be aliases
<cjwatson> $ syncpackage -f grub2
<cjwatson> ^- commands that feel REALLY good to run
<mitya57> cjwatson: \o/
<xnox> doko: if it's binaries only, it should be safe to demote them. at times some get "recovered" and are usually pulled back in without much fuss. I think infinity demoted *53* ones after that transition was done. And main has transitioned to boost1.54, so it is safe to demote those that are not needed.
<doko> ok, thanks
<ogra_> infinity, http://www.mail-archive.com/u-boot@lists.denx.de/msg125968.html ... in case you want our panda images to also support the new svtronics panda ...
<infinity> ogra_: That patch is vile.  I assume someone will commit something less hackishly gross upstream at some point.
<ogra_> yeah, its not actually a beauty
<pitti> bdmurray, infinity, stgraber: can I nag you about looking at the systemd-shim saucy SRU?
<sarnold> cjwatson: thanks (re: grub.cfg, francisco's patch)
<bdmurray> pitti: I'll review it
<barry> @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: barry
<bdmurray> slangasek: bug 1241385 is interesting in that the already installed and configured message comes after an "unexpected end of file or stream" for the same package
<ubottu> bug 1241385 in aptdaemon (Ubuntu) "package syslinux-common 3:4.05+dfsg-6+deb7u2ubuntu1 failed to install/upgrade: ErrorMessage: package syslinux-common is already installed and configured" [Undecided,New] https://launchpad.net/bugs/1241385
<slangasek> bdmurray: ah; so in that case, it seems like there was an error from the dpkg --unpack command, which wasn't handled before sending a follow-on dpkg --configure command?
<infinity> barry: Why did you sponsor that memcached upload? :/
<bdmurray> slangasek: that sounds right to me
<infinity> barry: Gratuitous patch diffs, plus it's FTBFS, plus poor style in the one new patch...
<barry> infinity: i fixed it :)
<barry> well, it builds locally, at least on amd64
<slangasek> infinity: say hello to the Cambridge pub full of Debianers
<infinity> slangasek: I didn't pub tonight, I'm fluish and trying not to kill myself.
<slangasek> ah
<infinity> barry: Given that it only built on i386, I'm assuming it builds with "-b" but not "-B".
<infinity> barry: Which is likely because quilt doesn't appear to run with -B...
<slangasek> cjwatson: so I'm having a poke at kernel package cross-buildability; I'm surprised to find openssl in the list of unsatisfied cross-build-deps.  Was that not M-A: foreign at one point?
<infinity> Erm...
<infinity> Ew.
<infinity> barry: Yeah, you shouldn't have accepted this patch. :P
<infinity> barry: Mixing and matching old-style and dh(1) is unpredictable and never right.
<infinity> barry: Better to just manually call dh_autoreconf and dh_autoreconf_clean at the right parts of the series (right before configure, and right before dh_quilt_unpatch, probably)
<bdmurray> slangasek: so I think I've found dozens of bugs where dpkg tries to configure a package that failed to unpack, does consolidating them all make sense?
<slangasek> bdmurray: yes
<barry> infinity: well, let's see if this one fixes the ftbfs
<orbisvicis> is there a tool to list all uninstalled dependencies of a deb ?
<sladen> orbisvicis: not quite; but  apt-get -f install
<sladen> orbisvicis: will fix it
<sarnold> orbisvicis: apt-get install --dry-run  <packagename> does a good job, if apt knows about the package
<sladen> orbisvicis: or apt-get install -n ..   or apt-get install and Ctrl-c
<infinity> barry: The whole '%:\ndh $@' bit should have gone away when you did that too.
<infinity> barry: And autoreconf should come after quilt_patch, since some patches touch reconf bits.
<infinity> barry: How about I just fix it? :)
<barry> infinity: clearly my isp is totally f*cked this evening, so please dtrt.  thanks ;)
<infinity> barry: Done.
<infinity> Oh lolz, except now it's broken on i386.  *headdesk*
<infinity> S'pose I should test this properly instead of shotgunning a fix.
<infinity> Oh, this is probably the patch itself actually breaking with autoreconf.
<infinity> So, this wasn't even tested by the person you sponsored for, as it wouldn't have had the desired effect.
<barry> @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:
<barry> infinity: i did actually test the local builds and it seemed to do as advertised
<barry> sigh.  i give up.  maybe my intarwebs will be happier tomorrow
<brainwash> cjwatson: should I file a launchpad report for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632598 ? still not sure if this is an issue which should be addressed and fixed eventually
<ubottu> Debian bug 632598 in grub-common "grub-mkconfig: should set safer permissions even when hashed passwords are found" [Normal,Fixed]
<rsalveti> hm, seems the simplejson package is empty now
<rsalveti> can't run any lp script anymore
#ubuntu-devel 2013-11-15
<TheMuso`> @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: TheMuso`
<jtaylor> TheMuso`: as you are piloting, you may want to look at simplejson in trusty, its empty which likely to cause other fallout failures
<jtaylor> if rsalveti is not already on it
<rsalveti> jtaylor: no, and indeed, that would be helpful
<jtaylor> < off to bed
<rsalveti> issue started to happen when the new version was merged from debian, as it now uses dh-python
<TheMuso`> Its not in the queue, so what exactly is the problem, is there a bug report?
<rsalveti> didn't investigate it further
<StevenK> wgrant: ^
<rsalveti> TheMuso`: nops, just noticed because it crashed for me
<rsalveti> when using a personal lp script
<StevenK> wgrant: That could be your simplejson issue ...
<rsalveti> the package is empty :-)
<TheMuso`> Oh ok.
<TheMuso`> If nobody else is looking at it, I'll get right on it.
<rsalveti> awesome, thanks
<TheMuso`> Maybe something we need to add to auto pkg testing...
<TheMuso`> Hrm, seems Barry may have beaten me to it.
<TheMuso`> What version do you guys have?
<stgraber> nope, barry's upload is the broken one
<TheMuso`> Latest in LP is 3.3.1-1ubuntu2
<TheMuso`> Oh ok.
<stgraber> look at the content of python3-simplejson
<stgraber> it's empty
<stgraber> (as in, valid package but only a changelog.gz file)
<TheMuso`> Yup, just wasn't sure if the merge upload was the broken one.
<wgrant> StevenK: Yeah, I just downgraded.
<TheMuso`> Ok, fix uploaded, relatively simple in the end, give it an houro ro so I guess.
<TheMuso`> @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:
<sarnold> brainwash: jfyi: http://www.openwall.com/lists/oss-security/2013/11/15/2
<pitti> Good morning
<pitti> bdmurray: thanks!
<dholbach> good morning
<cjwatson> slacker_nl: openssl> doesn't seem so - must've been overlooked
<cjwatson> brainwash: well, it's fixed in trusty now.  I don't know if the security team consider it worth stable updates, you'd have to ask them (maybe sarnold since he was interested)
<cjwatson> slacker_nl: sorry, I meant slangasek
<cjwatson> brainwash: Ah, looks like sarnold is taking care of it
<JackYu> cjwatson, you are so busy:)
<doko> seb128, empathy ftbfs in -proposed
<seb128> doko, I know, I've no clue why though, if you have help is welcome
<seb128> dpkg-shlibs is not happy but I'm not sure why
<cjwatson> JackYu: yup ...
<doko> stgraber, lintian fails tests in -proposed
<seb128> dpkg-shlibdeps: error: no dependency information found for debian/empathy/usr/lib/empathy/libempathy-3.8.5.so (used by debian/nautilus-sendto-empathy/usr/lib/nautilus-sendto/plugins/libnstempathy.so)
<seb128> what does that mean?
<Laney> seb128: Oh, I looked at that a little bit
<Laney> If you remove -Xusr/lib/empathy/ from the dh_makeshlibs arguments it builds
<Laney> sjoerd added that, maybe check with him
<seb128> Laney, 3.8.4 builds fine and there is like no change between those versions
<pitti> Laney: that sounds wrong, though; we don't want the symbols of private libraries be considered in shlibdeps/
<Laney> I'm not proposing that as a fix.
<pitti> although, if a different binary package actually uses that, I guess we do
<Laney> But you need the dependency to be there somehow ...
<seb128> https://launchpadlibrarian.net/156496416/empathy_3.8.4-1ubuntu2_3.8.5-0ubuntu1.diff.gz
<seb128> do you see anything weird in that diff?
<seb128> I even diffed the build log for both locally (with a sed 3.8.4->3.8.5)
<seb128> there is no difference in the build/linking
<seb128> I don't get it
<pitti> seb128: so perhaps debhelper/dpkg got changed? does 3.8.4-1ubuntu2 still actually build?
<seb128> pitti, yes, I built both on my trusty
<Laney> I guess that's what dh_shlibdeps -Lempathy is trying to solve
<seb128> 3.8.4 builds
<seb128> 3.8.5 fails
<geser> does somebody know why the gnome-keyring build in trusty got "cancelled"? the build logs look like a successful build
<Laney> hung processes left over
<Laney> s/hung//?
<seb128> geser, the build was never finishing because the testsuit let a gnome-keyring-daemon process behind apparently
<seb128> Laney, pitti: that's the diff of both builds here on trusty: http://paste.ubuntu.com/6420396/
<seb128> Laney, pitti: I did a sed 's/3.8.4/3.8.5/g' to lower the diff
<seb128> but you can see, strictly no change in the build/linker
<pitti> -       $(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/configure.ac
<pitti> +       $(top_srcdir)/configure.ac
<pitti> the dropping of this lt~obsolete.m4 could be related?
<pitti> I don't see any other change which could potentially do this
<seb128> pitti, well, maybe that's what is creating the issue, but adding those back doesn't seem the right fix
<seb128> Laney, pitti: doh, I fixed it
<seb128> Laney, pitti: the package has a debian/shlibs.local with
<seb128> libempathy-gtk 3.8.4 empathy (= ${binary:Version})
<seb128> libempathy 3.8.4 empathy (= ${binary:Version})
<seb128> you need to update the version there
<pitti> ah
<seb128> that's a stupid thing :/
<Laney> haha
<tseliot> pitti, seb128: do either of you have the time to approve the nvidia packages in trusty? bug #1250449
<ubottu> bug 1250449 in nvidia-graphics-drivers-319 (Ubuntu) "Include the 331 driver in Ubuntu" [Medium,In progress] https://launchpad.net/bugs/1250449
<pitti> tseliot: I can have a look later (but we don't usually have bugs for NEW packages)
<tseliot> pitti: right, maybe it's something we can reuse in the future? (to backport the packages to saucy or precise)
<pitti> yes, for those you can add tasks
<tseliot> that was the idea
<tseliot> pitti: thanks
<doko> TheMuso`, was it intended to go backwards with the dotconf soname bump?
<infinity> doko: Looks like the actual SONAME changed from foo1.0.so.0 to just foo.so.0, so the package rename makes sense.
<doko> zul, jamespage: please have a look at http://people.canonical.com/~ubuntu-archive/nbs.html (msgpack-python)
<doko> pitti, I see that postgresql-server-dev-9.3 wants to demote ...
<doko> zul, jamespage: removing msgpack-python, python-msgpack provides it
<lifeless> so something weird
<lifeless> latest raring cloud image has /etc/systemd/system on it
<lifeless> which has thrown off our code for detecting systemd vs upstart
<ogra_> lifeless, looks like that came in with the enablement of syslog from systemd
<xnox> lifeless: pitti did some work on correctly detecting: logind available vs systemd available vs either not available (as in at runtime, rather than install time)
<ogra_> pitti, ^^
<lifeless> pitti: what would you recommend as the way to check? Or is there a thing you've written we can query?
<xnox> lifeless: going forward on debian sysv/systemd are co-installable, despite not actually running. Which is in part inherited by ubuntu (co-installation & config file cruft)
<xnox> lifeless: i think one should be checking cgroups. and there is one for systemd and one for logind.
<lifeless> xnox: yeah, we kinda need to figure out which to use, given directory tree on disk.
<lifeless> xnox: vs a running system
<lifeless> xnox: I should perhaps have asked this in #ubuntu-server :) - oops!
<xnox> lifeless: http://cgit.freedesktop.org/systemd/systemd/commit/?id=66e411811b8090 seems relevant and does it via /run
<slickymaster> good morning all
<infinity> xnox: Hey, boost boy.  Want to tell me why this is FTBFS: https://launchpad.net/ubuntu/+source/libpwiz/3.0.4624-3ubuntu1/+build/5233964
<xnox> lifeless: at the moment on ubuntu/debian one cannot co-install upstart with sysv/systemd. So the check for upstart can be: which initctl >/dev/null && initctl version | grep -q upstart
<ogra_> lifeless, or check which package /sbin/init installed
<pitti> lifeless, xnox: the recommended way to check for logind i access("/run/systemd/seats/", F_OK) and "systemd is pid 1" is existence of /run/systemd/system/
<pitti> s/i/is/
<xnox> infinity: something like https://bugs.launchpad.net/linaro-aarch64/+bug/1186352 ?
<ubottu> Ubuntu bug 1186352 in Linaro AArch64 cross-distro work "boost 1.5x library "context" needs porting" [Undecided,New]
<lifeless> pitti: thanks; if I have a chroot unpacked in front of me, which might be Fedora or Ubuntu, what would you do to check?
<infinity> xnox: That could be it, yeahp.
<pitti> lifeless: in a chroot there is no init nor logind..
<infinity> xnox: I wonder if that's just cargo-culted from the glibc bits that do the same thing.
<xnox> infinity: i wouldn't be surprised.
<lifeless> pitti: bah, pedant :) - I'm tired and being imprecise. Unpacked cloud image.
<xnox> infinity: boost, is kind of like nih++
<pitti> lifeless: oh, you mean you construct a bootable system in a chroot and want to see which init is *going to be* booted?
<lifeless> right
<lifeless> we download the ubuntu cloud image
<lifeless> or a fedora cloud image
<lifeless> or $os
<ogra_> lifeless,  if dpkg -S /sbin/init 2>/dev/null|grep -q upstart; then echo "running upstart"; else echo "no upstart"; fi
<pitti> lifeless: well, if it's Fedora, it's systemd; if it's Ubuntu, it's upstart; if it's Debian, there's no way to know unless there is only upstart or systemd installed, but they might still run with sysv
<lifeless> so far we've just checked the .../system dir in /etc as that was sufficient and reliable/
<ogra_> (though that wont work on fedora indeed)
<lifeless> ogra_: if which dpkg && ... :)
<pitti> /etc/os-release should give you the distro
<lifeless> pitti: and breaks on derivatives- I want to probe the feature, not the label - that scales much better.
<pitti> lifeless: tricky; then I guess trying rpm -Q or dpkg -S on /sbin/init might still be the best bet
<lifeless> kk
<lifeless> thanks!
<xnox> lifeless: ubuntu one will have /sbin/initctl, and fedora one will have /usr/bin/systemctl, on debian if there is no /sbin/initctl and there are /sbin/init and /sbin/systemd you can boot "debian" with either sysv or systemd.
<xnox> pitti: on debian at the moment, upstart package conflicts with sysv-init. so if upstart is installed on debian, then it's upstart only.
<pitti> xnox: ah, right
<lifeless> xnox: brilliant, thanks heaps!
<mardy> seb128: hi! Am I looking at the wrong place? I cannot find the most recent Ubuntu packaging for shotwell: https://code.launchpad.net/ubuntu/+source/shotwell
<seb128> mardy, the UDD importer is buggy on that source I guess
<seb128> mardy, bzr branch lp:~ubuntu-desktop/shotwell/ubuntu; bzr bd-do
<mardy> seb128: thanks!
<seb128> yw
<rbasak> I'm having difficulties with hwclock/system time being the epoch on a machine I'm working on with MAAS. Can I clarify my understanding of where the pieces fit, please, so that I can debug?
<rbasak> The installer (d-i netinst) should NTP and set hwclock before booting into the system, right, assuming ntp.ubuntu.com was available at the time of install?
<rbasak> And when booting into the system, hwclock(8) suggests to me that the kernel should copy the rtc time to the system time, so userspace doesn't need to run --systohc? Is this accurate? I can't find any reference to doing that on Saucy - just --systz.
<xnox> rbasak: hm. we have two upstart jobs on ubuntu. one to load up hwclock time and one to save.
<xnox> rbasak: at boot hwclock time is loaded, later ntp runs and ajusts time, at shutdown the time is saved back into hwclock.
<rbasak> xnox: hwclock-save and hwclock, right?
<rbasak> xnox: hwclock does: exec hwclock --systz $tz --noadjfile $badyear
<xnox> rbasak: correct. hwclock at boot, hwclock-save at shutdown.
<rbasak> xnox: so it seems that it doesn't load any more
<rbasak> xnox: no --hctosys
<rbasak> --systz is just for non-UTC RTC correction for dual boot with Windows, AFAICT from the man page
<rbasak> So I _think_ responsibility has moved to the kernel
<xnox> If you specify neither --utc nor --localtime, the default is whichâ
<xnox>               ever was specified the last time hwclock was used to set the  clock
<xnox>               (i.e.   hwclock  was successfully run with the --set, --systohc, or
<xnox>               --adjust options), as recorded in the adjtime file.  If the adjtime
<xnox>               file doesn't exist, the default is UTC time.
<xnox> ..
<xnox> rbasak: we always run with one of --utc or --localtime.
<xnox> rbasak: so we don't need hctosys.
<rbasak> xnox: right, but that's not the issue here. My problem is that the system time is (sometimes) 1970.
<xnox> unless i'm understanding this wrong.
<infinity> xnox: Eh?
<infinity> xnox: You need hctosys if the kernel isn't picking up the system time elsewise.
<rbasak> infinity: is it a bug if the kernel doesn't pick up the system time?
<infinity> xnox: --systz explicitly doesn't read the hardware clock.
<rbasak> I'm not entirely sure what's going on, since I only get to examine the system after some time.
<infinity> rbasak: In theory, the kernel should probably always have the right time these days.  In theory.  Where are you seeing it not?
<rbasak> In my failure case, the hwclock is correct, but the system time is 1970.
<rbasak> I've also had another failure case the other way round, though.
<rbasak> infinity: midway.
<infinity> midway has a hwclock that works?
<rbasak> So I think a kernel bug is not out of the question.
<infinity> highbank didn't.  This is progress.
<rbasak> Oh, really?
<rbasak> I thought it worked.
<rbasak> Perhaps that's my problem.
<infinity> highbank doesn't have a battery-backed RTC at all, so how it could have a correct time unless it had been set by a system already is a mystery.  I didn't think midway was different, but maybe.
<rbasak> Define "battery-backed". I think it retains it as long as the chassis is powered, even if a node "isn't".
<rbasak> (ie. as long as the BMC is powered I think that means)
<xnox> rbasak: and you don't have working ntp?
<infinity> Except that BMCs randomly cut/blip power occasionally. ;)
<infinity> And I'm not even sure your assertion is true.
<rbasak> xnox: the lab it's in doesn't appear to have correctly functioning ntp (firewalled off). However, the default gateway does appear to have an ntp service. So I'm trying to use that.
<infinity> Anyhow, if you're seeing a correct time in the hwclock, then this tangent in the conversation is pointless.
<infinity> And it's possible the rtc driver just sucks (or doesn't exist) for that platform.
<infinity> Which would be a "bug robher" thing.
<rbasak> infinity: not necessarily! I have cases where hwclock is wrong, too. So I'm trying to understand the whole picture so I can maybe come up with a plausible root cause.
<infinity> rbasak: From my experience with highbank, I'd say that relying on the hwclock at all is just wrong.
<infinity> rbasak: But robher would know more about if midway is better somehow, and if it has a functional rtc driver.
<rbasak> infinity: juju agents fail if the system clock is wrong.
<rbasak> infinity: so somewhere between MAAS handing off to juju, the clock needs to be fixed.
<infinity> rbasak: And do we expect to run juju/maas in an environment where we can't sync clocks sanely?
<rbasak> It's fine to require that we can sync clocks. The question is: where?
<rbasak> On every boot, with ntpdate?
<infinity> This is a solved problem in the UNIX world for, well, decades.  We can't run NFS without NTP either, why would we do anything else without it? :P
<xnox> rbasak: i thought maas server starts ntp, and all nodes that it brings up should be using ntp time from maas server. such that all of them talk the same time.
 * xnox recalls reading something about maas/ntp bug or some such..
<rbasak> xnox: nope. But perhaps we should add that.
<stgraber> doko: I know and I have no idea why
<rbasak> xnox: OTOH, it would be nice if I could just configure MAAS with the address of a working ntp server
<xnox> rbasak: if it doesn't, and network doesn't have NTP, it's doomed =)
<rbasak> xnox: you may be thinking of the MAAS datasource clock skew issue. That part is working fine.
<xnox> rbasak: so broadcast / advertise NTP?
<rbasak> xnox: that's fine. We can do that. At which stage should a node be picking it up?
 * xnox thought that should be working, unless we hardcode to ntp.ubuntu.com and somesuch.
<infinity> Do what I do, highjack DNS for ntp.ubuntu.com, so you don't have to change any default configs.
<infinity> (Don't do what I do)
<infinity> (Please)
<xnox> rbasak: it should be advertised on the network at all times & maas server should have synced from it, such that nodes are installed with ntp running already.
<rbasak> Haha. I'm perfectly placed to do that right now. Already serving a maas. domain to make juju go in this lab environment.
<rbasak> xnox: that's not enough. By default ntp will die if the clock skew is too great. It assumes that the system time is already reasonable.
<rbasak> xnox: we need to make the system time reasonable on the node at some point. I'm fine with doing that, but currently I don't believe there's a mechanism for that. I'm asking *at what point* should such a mechanism be put in? Every boot? Custom upstart job injected by MAAS? Etc.
<barry> rbasak: panic 0
<rbasak> In the meantime, I'm trying to do it with a MAAS commissioning script, which MAAS can arrange to run before d-i netinst runs.
<xnox> cjwatson: does d-i have NTP support / ovverride hwclock time, with NTP one?
<rbasak> barry: I'm fine with that too, if that's OK with everyone concerned. But we still need MAAS to arrange for ntp.conf to be changed, in that case.
<rbasak> xnox: that would be great, with a preseed. Unless the hwclock won't be maintained between d-i and the booted system, which AIUI infinity suspects is not.
<infinity> rbasak: ntpdate is run by an ifupdown snippet every time an interface comes up, if it's installed.
<xnox> rbasak: right. and we do have ntpdate running by default everywhere. I guess you just need to tweak it to force update time (if it's too far out)
<rbasak> infinity: oh, so it is!
<infinity> rbasak: Which is why I say I hijack ntp.ubuntu.com, because that's the default in /etc/default/ntpdate and I don't let that resolve outside one of my draconian networks.
 * rbasak wonders if he can preseed that
<rbasak> # Not used if NTPDATE_USE_NTP_CONF is yes.
<rbasak> NTPSERVERS="ntp.ubuntu.com"
<rbasak> NTPDATE_USE_NTP_CONF=yes
<rbasak> ntp.conf has ntp.ubuntu.com, but also ....ubuntu.pool.ntp.org.
<infinity> Note that NTPDATE_USE_NTP_CONF=yes has no effect if you have no ntp.conf
<infinity> But I guess you do.
<rbasak> So it seems that my issues are entirely due to my NTP-firewalled lab environment? Great.
<rbasak> It looks like /usr/sbin/ntpdate-debian will use /var/lib/ntp/ntp.conf.dhcp in preference to /etc/ntp.conf. If that means that I can specify NTP via DHCP then perhaps I can fix the lab at once and everything will magically work.
 * rbasak disappears for a while
<cjwatson> xnox: It has some in clock-setup, don't remember the exact details
<barry> doko: bs4 uploaded w/o pypy.  i suspect we're fighting a losing battle over time though and might be better served in the long run by mir'ing pypy
<yolanda> hi, any clue about this error? configure.ac:66: error: possibly undefined macro: AC_DEFINE
<yolanda> i googled it, it says that i check about pkg-config, autotools, etc... but i have everything installed
<tumbleweed> barry: don't scare me
<cjwatson> yolanda: I suggest putting the source package somewhere for people to look at
<yolanda> cjwatson, happens to me with couchdb, when i just added a -- with autoreconf in rules
<yolanda> i added dh-autoreconf bd in debian/control
<yolanda> do you want me to push to chinstrap?
<barry> tumbleweed: is that better than essentially disabling all *-pypy binary packages that trigger mirs?  it's Something We Should Discuss
<tumbleweed> barry: yeah, that's reasonable. I'm slightly scared about promising any support for pypy, though. Upstream is entirely uninterested in old releases
<barry> tumbleweed: yeah, there is that
 * barry might start a mlist thread
<arun> Excuse me guys, I wanted to talk with some devs , please if you are here, please help me what I need to do (steps)
<cjwatson> yolanda: The line number is misleading; if you look at the generated configure after that failure, you find that it's inside an AX_LIB_CURL call, so the problem is that whatever should provide the AX_LIB_CURL macro isn't installed
<yolanda> cjwatson, i'm looking at 1.4.0-0buntu1 version, line number looks ok: AC_DEFINE([HAVE_BUILTIN_EXPECT], [1],
<yolanda> problem seems to come from the ACLOCAL_AMFLAGS= -I m4, removing that solves the issue, but not sure if that's good idea or if there is some other way to solve it
<yolanda> cjwatson, mm, removing that breaks build anyway, so do you want me to push to chinstrap so you take a look?
<yolanda> i need to run autoreconf because i need to inject a new DISTRIBUTION var into Makefile, to display Ubuntu distribution
<cjwatson> yolanda: The line number is misleading, as I said.  It has AC_DEFINE on that line, yes, but that's not actually what's failing.
<cjwatson> yolanda: You could build-depend on autoconf-archive, or you could copy the AX_LIB_CURL macro out of autoconf-archive into acinclude.m4 in a patch.
<yolanda> cjwatson, thx
<yolanda> i'll try it
<cjwatson> -I m4 isn't relevant
<cjwatson> And removing that is very probably a bad idea
<yolanda> cjwatson, sure, just googling at the cause and trying different things. But your suggestion works for sure, i added autoconf-archive as build-depends and now builds fine
<cjwatson> Great
<cjwatson> It's a pretty generic failure so googling is probably unhelpful in this case - it'll lead you down a bunch of different paths which don't necessarily apply :)
<yolanda> cjwatson, yes, mostly they were suggesting to add dependencies that i already had, but I was unable to see the root of the problem
<cjwatson> Looking for the offending unexpanded macro in the generated configure script is the best way to debug this kind of thing
<yolanda> cjwatson, nice to learn more about that
<Laney> mdeslaur: hey, have you seen https://bugs.launchpad.net/ubuntu/+source/libcommons-fileupload-java/+bug/1251340 ?
<ubottu> Ubuntu bug 1251340 in libcommons-fileupload-java (Ubuntu) "Missing jar file in 1.2.2-1ubuntu0.12.04.1" [Undecided,Confirmed]
<mdeslaur> Laney: no, I had not, thankt
<mdeslaur> thanks
<Laney> np
<caribou> is there an easy way to have sbuild know how to fullfill a dependancy from a PPA ?
<roadmr> caribou: I usually schroot into the source image and add the ppa manually, may not be the easiest or more automated way but it works
<caribou> roadmr: that was my first idea
<caribou> roadmr: I'll do that, I don't need much automation in that context
<caribou> roadmr: thanks
<roadmr> caribou: no problem!
<BenC> Anyone ever installed powerpc packages on x86? I've setup apt, and just want to install libncurses5-dev:powerpc, but it needs debconf:powerpc, which can't be satisfied
 * BenC is unsure why libc6 needs debconf anyway
<orbisvicis> where can I find more info on $(py_setup_install_args) ?
<orbisvicis> (nevermind)
<slangasek> BenC: libc6 needs debconf to ask about restarting services on upgrade... but debconf should be Multi-Arch: foreign (it has been everywhere for a long time), so the debconf you already have installed is supposed to do the job
<infinity> slangasek: Ben and I got sorted in /msg
<slangasek> infinity: hmph
<infinity> (I didn't notice he'd asked here)
<slangasek> ah :)
<sarnold> bdmurray: do I recall that you're looking to aggregate many bugs of this sort? 1251537
<bdmurray> sarnold: nope, that kind
<bdmurray> er not that kind
<sarnold> bdmurray: whooops then :) thanks
<bdmurray> slangasek: I've also found many a VarLogDistUpgradeApttermlog.gz file with one of the following errors http://pastebin.ubuntu.com/6422642/
<BenC> slangasek: raring wasn't working properly, but saucy appears to be installing things
<slangasek> interesting
<slangasek> bdmurray: well, those are all dpkg database corruption
<slangasek> bdmurray: so it probably points back to the same general lack of sensible error handling of dpkg --unpack failures
<bdmurray> slangasek: those were independent of the --unpack failures
<slangasek> ah
<slangasek> bdmurray: did those errors immediately precede the "already configured" error, though?
<BenC> slangasek: However, why can't I have gcc-powerpc-linux-gnu and gcc installed together?
<slangasek> hum, I don't know the answer to that one :)
<slangasek> in saucy?
<BenC> Yeah
<bdmurray> slangasek: in some cases I guess so
<bdmurray> dpkg: unrecoverable fatal error, aborting:^M files list file for package 'linux-image-3.8.0-30-generic' is missing final newline^M
<BenC> I may have some mixed raring/saucy packages, so let me clear that up first
<bdmurray> dpkg: error processing apt (--configure):^M package apt is already installed and configured^M
<slangasek> BenC: ok - fwiw it works for me in a saucy chroot; a mixed install might be failing because of mismatched version of gcc base packages
<bdmurray> @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: bdmurray
<Noskcaj> mdeslaur, Is it worth merging ruby1.8?
<Noskcaj> And to anyone with buildd powers, guava-libraries failed to upload
<jtaylor> isn't ruby-1.8 being removed in debian?
<jtaylor> there is a tracker, so probably makes sense to follow with it for trusty
<Noskcaj> jtaylor, I think it is. The latest debian change just removes all the "provides", i'm not sure if it's worth the time to merge
<Noskcaj> xnox, do you mind if i change vtk's depends from tiff to tiff5? It's causing other packages to ftbfs
#ubuntu-devel 2013-11-16
<orbisvicis> do the packages @ http://old-releases.ubuntu.com ever change?
<stgraber> no
<orbisvicis> I've just started getting size-mismatch errors
<stgraber> the only thing that should happen to old-releases is new series appearing on it as releases go end of support, but besides that, no new files should appear and files on it definitely should never change (same goes for the main archive, anything in /pool that changes content is a bug)
<orbisvicis> hm ok, ill wait a few hours, then recreate the pbuild image
<bdmurray> @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:
<happyaron> stgraber: thanks for rejecting the wrong version...
<stgraber> np
<Mapley> This is a question for the devs. How did you guys (and gals) achieve a seamless transition from Plymouth to LightDM without any VT messages leaking through?
<tarpman> Mapley: not a dev, but: the lightdm side is here http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/src/plymouth.c and the plymouth side is here http://bazaar.launchpad.net/~plymouth-dev/plymouth/trunk/view/head:/src/plugins/renderers/drm/plugin.c
<Mapley> Hmm, thanks, I'll check them out.
<tarpman> Mapley: AIUI, plymouth calls drmDropMaster leaving the last frame drawn on the VT, X takes over and starts drawing right away, and lightdm tells plymouth to quit once it's started
<arun> Hello   guys
<arun> I wanted a dev or maintainer to talk to ,. please anyone online
<arun> please help me !!!!
<Noskcaj> arun, talk
<Noskcaj> people are always online, but may take some time to respond
<arun> Noskcaj: I wanted to have a new language get added in the system
<Noskcaj> !support
<ubottu> The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<Noskcaj> Assuming the language exists for ubuntu
<arun> Noskcaj: no, its not enlisted in Ubuntu
<arun> Noskcaj: Its  a language from Nepal ...
<Noskcaj> What's the language called?
<arun> its name is Chitwania Tharu with code :- "the"
<arun> Noskcaj: its listed in http://www-01.sil.org/ISO639-3/documentation.asp?id=the
<arun> Noskcaj: hello, are u there  ??
<Noskcaj> arun, yeah. I went to get dinner
<Noskcaj> arun, join #ubuntu-translators or send an email at https://launchpad.net/~ubuntu-translations-coordinators/+contactuser
<Noskcaj> They will know what to do
<arun> Noskcaj: oh ok; and does it need the locale to get in the glibc?
<Noskcaj> arun, It was added very recently to glibc
<Noskcaj> http://sourceware.org/git/?p=glibc.git;a=commit;h=HEAD
<arun> Noskcaj: yes
<Noskcaj> never mind, that was you
<arun> Noskcaj: of course yes
<Noskcaj> how many people actually use the language?
<arun> Noskcaj: so , did I do correctly , I mean shall I had to give it to glibc or its unneccessary??
<arun> around 1-2 Lakhs
<Noskcaj> i don't really know. I don't do much translation. The email i linked above is where to ask
<arun> Noskcaj: ok brother
<psusi> pitti, why does pm-suspend run pm-powersave to disable power saving on suspend, and then re-enable it on resume?
<Noskcaj> Is it possible to fix haskell:depends so it stops wanting specific versions of other haskell stuff? It's causing many FTBFSes
<psusi> is there a way to look up argv[0] outside of main?
<xnox> Noskcaj: no, haskell essentially generates new abi on small changes and everything is "kind of statically linked". That's why we have permament transitions tracker for haskell and ocaml both in debian and ubuntu
<xnox> Noskcaj: you can figure out what's next to build by looking at http://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html
<xnox> and http://people.canonical.com/~ubuntu-archive/transitions/html/ocaml.html
<xnox> Noskcaj: it's only about ~20 dependency levels, and often a FTBFS fix on one packages for one arch can cause cascade of rebuilds further down... =(
<Laney> you can fix it by fixing the compiler to not do that
<xnox> Laney: but then your uploads count will drop =)
<Laney> heh
 * Noskcaj thinks we will pretend haskell doesn't exist and be happy with that
<Laney> I haven't done much on that in a while actually
#ubuntu-devel 2013-11-17
<Noskcaj> How do i tell why the bzr branch of a debian package hasn't updated? videocut in this case
<slangasek> Noskcaj: http://package-import.ubuntu.com/status/
<Noskcaj> thanks
<slangasek> that page doesn't show any problems with videocut, though
<Noskcaj> slangasek, strange. the two latest debian releases aren't in bzr
<slangasek> hmm, quite
<slangasek> how long ago was -13 uploaded?
<Noskcaj> september 2nd
<slangasek> hmm
<slangasek> can you file a bug against the udd project about this?
<Noskcaj> I'm not sure what to do, where, and i haven't checked the package import myself. but i'll try once i've had lunch
<xnox> slangasek: Noskcaj: https://launchpad.net/debian/+source/videocut doesn't know about -13 and -14 uploads. So i'd take it up with AA, e.g. cjwatson can check via videocut didn't sync.
<xnox> and udd, only takes stuff that launchpad has imported.
<xnox> s/via/why/
<Noskcaj> ok, thanks
<mitya57> German text in videocut's 02-desktop-keywords.diff looks suspicious to me
<Noskcaj> stokachu, Do you plan to merge keepalived? If not, i could do it
<Noskcaj> (i think)
<Noskcaj> kirkland, roaksoax: I've made some progress on testdrive in debian, some DDs are willing to take a look. Could one of you try and fix up the manpage(s)?
<brainwash> so apparently nobody is able to resolve bug 1183580, why not simply distribute a working version of that library if it's not possible to build it properly?
<ubottu> bug 1183580 in librcc (Ubuntu) "librcc segfaults on latest saucy" [High,Triaged] https://launchpad.net/bugs/1183580
<brainwash> reported on 2013-05-23 :/
<Ampelbein> brainwash: Because Ubuntu can't just distribute binaries that were built on Debian. It may or may not work currently, but there is no guarantee that it will work in the future.
<Ampelbein> brainwash: For starters, this bug should have been reported to the developers of the software
<brainwash> Ampelbein: the devs? who would that be?
<Ampelbein> brainwash: According to the Homepage: field in debian/control: http://rusxmms.sourceforge.net/
<brainwash> but there is nothing wrong with the debian package
<Ampelbein> brainwash: The build environment in Ubuntu is different from Debian
<Ampelbein> And if I were the developer, I sure would want to know that my software doesn't work when compiled in Ubunut.
<brainwash> some might say it's ubuntu's fault
<brainwash> and not care about this
<Ampelbein> They are free to say what they want.
<Ampelbein> If the developers are saying that they don't care, Ubuntu would be better off removing the software from the repository.
<brainwash> the package maintainer should make sure that the package isn't broken
<Ampelbein> Yes, but apparently no-one from MOTU/Ubuntu-Dev uses this particular software.
<Ampelbein> So there isn't really a package maintainer in Ubuntu.
<Ampelbein> I'm not disputing the fact that there is a bug in the package, btw. I'm just saying that it would help to notify the developers of this bug so they can possibly provide a fix.
<brainwash> right, first we would need to test the latest upstream release I assume
<Ampelbein> Comment 12 indicates that the new upstream fixes the problem
<brainwash> maybe someone could build a new package, so we can test it in trusty and backport then
<Ampelbein> let me try
<brainwash> Ampelbein: thanks :)
<Ampelbein> brainwash: I think I've identified the patch fixing the problem: http://paste.ubuntu.com/6431321/
<Ampelbein> brainwash: I'll upload a package to my ppa, would you be available to test the resulting package?
<brainwash> Ampelbein: sure
<Ampelbein> brainwash: https://launchpad.net/~amoog/+archive/ppa will have saucy and trusty packages in about an hour (according to the build start estimate)
<brainwash> Ampelbein: alright
<brainwash> Ampelbein: your package does fix the segfault (trusty), good work :)
<brainwash> Ampelbein: do you plan to write the SRU request for bug 1183580?
<ubottu> bug 1183580 in librcc (Ubuntu) "librcc segfaults on latest saucy" [High,Triaged] https://launchpad.net/bugs/1183580
<Ampelbein> brainwash: It's on my agenda
<brainwash> Ampelbein: ok, thanks :)
<Ampelbein> But if you want to do it, I'm not stopping you ;)
<Ampelbein> Note however that the package first needs to get sponsored in trusty
<brainwash> haven't done something like this yet, so I don't want to mess up
<brainwash> right
<Noskcaj> Can someone please merge gnome-control-center? the package rygel can be synced one 3.8 is in trusty
<TheMuso`> doko: Previous versions of libdotconf didn't have a soname, and the new upstream maintainer fixed it.
#ubuntu-devel 2014-11-10
<TheMuso> pitti: I'm happy to take care of the brltty merge if you haven't already started it.
<pitti> Good morning
<pitti> TheMuso: I didn't start yet; thanks!
<TheMuso> pitti: np
<pitti> cyphermox: FYI, new isc-dhcp is held in -proposed by regresssing NetworkManager test
<pitti> cyphermox: it seems something is now spilling "Killed old client process" to stderr -- leftover debug message which shoudl be quiesced again?
<pitti> or something which we need to ignore in the tests?
<dholbach> good morning
<Saviq> pitti, hey, I wanted to confirm something... now that we have separate rtm branches/series in some projects (like unity8 and friends), what happens to the translations/langpacks? should we bring the translation updates from trunk into the rtm branches? or should we enable translations for the rtm series and rely on the translations being shared?
<pitti> Saviq: yes, translations for RTM need to be enabled, but they are at the distro level (not project)
<pitti> Saviq: through message sharing that works, we build RTM specific langpacks
<pitti> Saviq: the main (and crucial!) thing to do is that a package build builds an up-to-date .pot
<Saviq> pitti, of course
<Saviq> pitti, so, in the case of unity8, we only have project-level translations right now
<Saviq> pitti, what should we do to make this happen for rtm?
<pitti> Saviq: seems quite alright? https://translations.launchpad.net/ubuntu-rtm/14.09/+source/unity8/+pots/unity8
<Noskcaj> dholbach, Fixing webtest now, sorry for screwup
<Saviq> pitti, hmm, right, but nothing syncs to the series http://bazaar.launchpad.net/~unity-team/unity8/rtm-14.09/changes
<pitti> Saviq: I'm confused -- what do you need synced to the RTM branch?
<Saviq> pitti, the .po file changes?
<Saviq> pitti, like in trunk we're getting http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1431
<pitti> Saviq: well, you can import them if you like, but they don't get into the .deb anyway
<pitti> Saviq: as I said, the crucial thing is an up to date .pot, then LP message sharing will DTRT
<Saviq> pitti, ah so the actual langpacks get generated straight out of LP?
<pitti> right
<Saviq> ok, that's what I was missing
<Saviq> pitti, thanks, that explains things then
<pitti> Saviq: did you spot anything wrong/missing there?
<Saviq> pitti, no, just got scared we're not doing something we should be doing
<tvoss> pitti, good morning
<pitti> hey tvoss
<ogra_> dpm, how do i get my http://summit.ubuntu.com/uos-1411/ogra/meetings onto the schedule ?
<dpm> ogra_, track leads should be approving the sessions. You might need to ping them. For the development track, they are: Will Cooke, Åukasz Zemczak, Steve Langasek, Antonio Rosales, and Rohan Garg
<ogra_> ok
<ogra_> willcooke, ^^^ could you approve my sessions ?
<willcooke> ogra_, there's something wrong with my set up in summit, waiting on mhall119 to come online and fix it
<ogra_> oki
<mhall119> willcooke: let me check
<willcooke> mhall119, thx
<mhall119> willcooke: there's nothing waiting to be scheduled on the Ubuntu Development track
<willcooke> ogra_, ^^^
<mhall119> willcooke: you have some you can review on http://summit.ubuntu.com/uos-1411/review/
<willcooke> mhall119, that URL doesn't show me anything to review
<ogra_> mhall119, so how do i get http://summit.ubuntu.com/uos-1411/ogra/meetings into some review/approval queue
<mhall119> willcooke: then there might be something wrong with your account
<mhall119> willcooke: at the top, where is says "Logged in as:" what username is displayed?
<willcooke> mhall119, logged in as willcooke (and that links to my LP page)
<mhall119> hmmm....
<mhall119> ogra_: they're already in one, but something's wrong with will's account
<ogra_> ah, its all willcooke's fault then, ok
 * ogra_ knew it 
<mdeslaur> bdmurray: mind if I steal your curl merge?
<willcooke> ogra_, :)  typical
<ogra_> :)
<mhall119> shadeslayer: can you see any session pending review on http://summit.ubuntu.com/uos-1411/review/ ?
<mhall119> willcooke: well popey can he stuff for his track, so it must be just you that's broken, try logging out and back in
<willcooke> mhall119, ok :)
<willcooke> mhall119, sam,e
<willcooke> same
<shadeslayer> mhall119: looking
<shadeslayer> mhall119: there's a few
<mhall119> well willcooke....what have you done to summit?
<mhall119> oh, wait.....
<mhall119> I did it :)
<willcooke> mhall119, erm - it was like that when I got here?
<mhall119> willcooke: try that page again
<willcooke> mhall119, ooooooohhhh  - suddenly everything is different
<mhall119> now you can approve ogra_'s sessions :)
<cyphermox> pitti: perhaps. I'll take a look
<ogra_> \o/
<willcooke> I'll have to re-read the instructions
<cjwatson> doko: I think gluegen2 can be synced; your diff to it was to build with the zero VM on arm64 because it previously failed to build, but the latest version of gluegen2 built cleanly on Debian arm64 so it looks likely to be fine now.  Are you OK with that?
<ogra_> mdeslaur, pitti, i remember there was a reason why we didnt include dbus 1.6,.18 but kept .16 in rtm ...
<ogra_> mdeslaur, pitti do you guys remember what that was ? ricmm thinnks this could be related to our multiple hangs and CPU at 100% thins
<ogra_> *thigs
<mdeslaur> ogra_: bug 1362469
<ubottu> bug 1362469 in dbus (Ubuntu) "AppArmor unrequested reply protection generates unallowable denials" [Medium,Triaged] https://launchpad.net/bugs/1362469
<pitti> ogra_: I'm afraid I wasn't involved in that discussion
<pitti> ah, there we go, thanks mdeslaur
<ogra_> pitti, yeah, i just remembered one of you two was
<mdeslaur> ogra_: perhaps tyhicks made some progress investigating that
<mdeslaur> tyhicks: pingy ping ping
<mdeslaur> bdmurray: too late :P
<cjwatson> doko: Went ahead and synced gluegen2, since it's blocking something else I need.  We can always put back the diff if it's a problem.
<tyhicks> ogra_: the 1.6.18 merge came in pretty late for utopic so I didn't push to include it in rtm and then we found bug 1362469 so we decided to definitely not push for it in rtm
<ubottu> bug 1362469 in dbus (Ubuntu) "AppArmor unrequested reply protection generates unallowable denials" [Medium,Triaged] https://launchpad.net/bugs/1362469
<tyhicks> ogra_: I've looked at that bug quite a bit but haven't been able to make good progress
<tyhicks> ogra_: it is about as difficult to debug as the cpu pinning bug that others are trying to solve :/
<ogra_> thywell, ricmm suspects the CPU peging is caused by us being behind in dbus versions on rtm
<ogra_> tyhicks, ^^^^
<tyhicks> ogra_: has anyone been able to verify that 1.6.18 fixes the cpu peging?
<ogra_> i doubt that ... talk to ricmm (who is in a meetign atm)
<tyhicks> ok
<xnox> lamont: it's all in ubiquity/frontend/gtk_ui.py the vte bits, it shouldn't be that many.
<xnox> lamont: unping
<xnox> Laney: ^
<Laney> xnox: I see it - that's for the debugging mode?
<xnox> Laney: it's present and running at all times, on all gtk frontends, however most of the time it's invisible. But widget is initiated as is there.
<tyhicks> ogra_, ricmm: at this point in the rtm schedule, I'd be far more comfortable backporting the specific fix for the cpu pegging bug from 1.6.18 to 1.6.16 and I'll work on fixing bug 1362469 in the meantime
<ubottu> bug 1362469 in dbus (Ubuntu) "AppArmor unrequested reply protection generates unallowable denials" [Medium,Triaged] https://launchpad.net/bugs/1362469
<xnox> Laney: UI wise, it's accessible after one starts the installation (after clicking next in partitioning), however progress dots are in the way to actually expand it to show it.
<ogra_> tyhicks, right, i think ricmm also meant he had seen only some specific things in the changelog that could be related, but we indeed need to make out if thats actually helping
<xnox> Laney: what's changed in vte? it's only one vte specific command and the rest are regular gtk+ calls/functions.
<Laney> xnox: so this /is/ the expandered vte?
<Laney> I misremembered that this showed the usual debug output like update-manager does
<Laney> there's some random API cleanups
<xnox> Laney: yes. and there is nothing else vte in ubiquity.
<Laney> cool
<Laney> I thought there were two things when you talked about debug-ubiquity
<xnox> Laney: ctl-alt-t thing in debug mode simply launches the default terminal, as in it launches gnome-terminal
<Laney> Right, nothing to worry about here then
<xnox> Laney: so ubiquity vte code is just this: http://paste.ubuntu.com/8921321/
<Laney> yep
<xnox> Laney: which is stand-alone, just run that on your desktop with new vte and you know that vte in ubiquity will work.
<LocutusOfBorg1> hi Laney finally thanks to someone retrying itk4 have been successful
<LocutusOfBorg1> I'm trying to parse update_output to understand what is missing
<cjwatson> LocutusOfBorg1: I'm working on it, it's a complicated set of intertwined transitions
<LocutusOfBorg1> thanks!
<cjwatson> gdcm, hdf5, vdr, etc.
<LocutusOfBorg1> hdf5
<LocutusOfBorg1> ok so I'm parsing it correctly :)
<LocutusOfBorg1> I wasn't sure about the file syntax, is not so much friendly :)
<Laney> AFAICS think gdcm is done in itself, but the entagled transitions need work
<cjwatson> No, gdcm isn't
<Laney> s/think//
<Laney> why
<cjwatson> Given that I just made three uploads for that earlier
<cjwatson> nifti2dicom, plastimatch, vmtk
<LocutusOfBorg1> why nifti2dicom hasn't been picked up in the transition file?
<LocutusOfBorg1> I was mostly sure about it, but ben says otherwise
<cjwatson> no idea, don't care
<cjwatson> probably the build-depends field is wrong
<cjwatson> i.e. it picks up the libgdcm2.[24] dep despite not having a direct build-dep on libgdcm2-dev
<cjwatson> so shrug, sorting it out anyway, the transition tracker isn't important at this point
<cjwatson> something's up with plastimatch if you want to have a look at that - FTBFS on amd64 and i386 so far
<LocutusOfBorg1> wilco
<Laney> I mostly stayed out of the way once I saw that other people were looking at it, so whatever, go wild
<cjwatson> I'm also working my way up to scilab (hence the gluegen2 stuff above)
<LocutusOfBorg1> cjwatson, plastimatch is (almost) tracked here on debian #768769
<ubottu> Debian bug 768769 in src:plastimatch "plastimatch: FTBFS in jessie: Tests failures" [Serious,Open] http://bugs.debian.org/768769
<pitti> mitya57: just in case you wonder why your lintian merge doesn't land: it breaks current lintian4python; a simple dep bump of the latter isn't sufficient, I filed a Debian bug
<LocutusOfBorg1> on amd64 there are some more tests failing
<cjwatson> LocutusOfBorg1: I'd be tempted to demote that to -proposed if we get to the point where it's the last remaining blocker
<LocutusOfBorg1> the popcon is rather low... so i agree :)
<LocutusOfBorg1> in the meanwhile it will either disappear from jessie/get fixed
<seb128> whoever changes the urls on the -changes emails to not include the +serie, thanks!
<seb128> changed even
<seb128> nice to be able to click and have the diff on the page without having the mangle the url manually in the webbrowser
<ogra_> OOOH !
<ogra_> i'll pay all the drinks for one evening at the bar at the next sprint for whomever did that !!!!
<ogra_> this is AWESOME !!
<seb128> :-)
<seb128> count me in for buying $drinks for whoever did that
<ogra_> :)
<ogra_> you can take the next evening :)
<stgraber> that'd be wgrant: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/17235
<ogra_> oh, he will get sooo drunk next sprint :)
<stgraber> well, next sprint for him is next week :)
<ogra_> well, the next one we all meet :)
<slangasek> cyphermox: hi, do you understand the autopkgtest failures at https://jenkins.qa.ubuntu.com/job/vivid-adt-network-manager/lastBuild for network-manager?  I don't see anything failing except a message about qemu processes being killed; not sure if that's an issue with the NM test suite or with the infrastructure
<cyphermox> yes, I know what it is
<cyphermox> new isc-dhcp has an extra message on stderr
<cyphermox> slangasek: the test is trapping this stderr line: wpa-dhclient         FAIL stderr: Killed old client process
<cyphermox> I'll fix it shortly, but I was hoping to fix it as I was uploading the new NM
<Mirv> pitti: if you can, please find out what's wrong with calibre powerpc. this time it doesn't seem to be just "succeeds on certain machines". (I'll need a rebuild of it done for Qt 5.3.2 landing)
<Mirv> so it fails similarly in vivid archives and in my PPA now
<slangasek> cyphermox: ok, so it's safe to skip that failure for any migrations it's blocking?
<cyphermox> slangasek: yes
<doko> cjwatson, ok, there was still an ftbfs issue open, now closed
<bdmurray> slangasek: would our missing ddebs for qtcontact5-galera (on amd64, i386, armhf)  have anything to do with address-book-service being copied from a PPA?
<slangasek> bdmurray: could, but should not
<slangasek> bdmurray: you could ask pitti if there are any remaining known problems with the ddebs handling for ppa copies
<bdmurray> slangasek: its odd that if you look here https://launchpad.net/ubuntu/+source/address-book-service/0.1.1+14.10.20140930-0ubuntu1 the utopic builds are for arm64, powerpc, and ppc64el which is what we have ddebs for.
<slangasek> bdmurray: ah... so this package was built in an *ubuntu-rtm* ppa, and then binary-copied to utopic
<slangasek> bdmurray: that could certainly be a factor
<infinity> binary copied to a utopic silo, even.
<infinity> Strange workflow.
<infinity> So, both sets of builds were in a PPA, but different PPAs.
 * slangasek nods
<slangasek> so it's probably a case where the ddeb-retriever doesn't know where to retrieve from
<infinity> Or, rather, how to reconcile the refs.
<infinity> Since the ddebs themselves all come from the same big tarball regardless.
<infinity> Of all the temporary hacks I've been party to over the years, this is the one I feel the worst about. :P
<tedg> bdmurray, So seb128 convinced me we should move bugs from being on the project to being on the Ubuntu package. I was trying to write a script that would move them. But I can't seem to figure out which tasks are package and which are project. Do you have a script I can steal from?
<bdmurray> tedg: I don't know but off the top of my head if "(Ubuntu)" in task then its a package one.
<tedg> bdmurray, Do you know what property "(Ubuntu)" would be in? Just parse the title?
<bdmurray> tedg: bug_target_name
 * tedg tries
<bdmurray> tedg: and?
<tedg> bdmurray, Nope, looking at other props. Those are all "ubuntu-app-launch"
<bdmurray> tedg: Can I see your script?
<tedg> bdmurray, http://paste.ubuntu.com/8924781/
<bdmurray> tedg: and what project are you using?
<tedg> bdmurray, ubuntu-app-launch
<bdmurray> tedg: in the for btask loop you are using task
<bdmurray> tedg: lines 38 through 41
<tedg> bdmurray, Oh, man. Thanks!
<bdmurray> no problem
<ScottK> infinity: Since you TIL, any objections to adding no-human-maintainers to the tests ignored in the Ubuntu profile.  Seems highly irrelevant for Ubuntu.
<infinity> ScottK: You failed to mention a package name there...
<infinity> ScottK: lintian?
<ScottK> infinity: yes.  sorry
<infinity> ScottK: Yeah, that sounds like a reasonable change.
<ScottK> Thanks.
<infinity> ScottK: Were you asking me to make it, or to +1 you making it? :)
<infinity> ScottK: If you do the change, can you forward to Debian, that stuff is all in sync.
<infinity> (Our only delta is a nodejs build-dep avoidance thing that I'm trying to convince Debian is sort of okayish)
<ScottK> I was asking for you to +1 me making it and I'd forward to Debian, but if for some reason you want to, don't let me stop you.
<infinity> ScottK: No, no.  By all means, go nuts.  Do away!
<ScottK> Of, of course it needs merging too.
<infinity> ScottK: It was *just* merged...
<ScottK> OK.  Or I got the old version.
<infinity> https://launchpad.net/ubuntu/+source/lintian/2.5.30ubuntu1
<infinity> Seems to have made lintian4python unhappy.
<ScottK> lintian4python is dead.
<infinity> It was also never in unstable even.
<infinity> I wonder who synced that from experimental, and why.
<ScottK> Dunno.  It was handy when it was maintained, so I guess that's why, but now that it's orphaned, no point in it.
<infinity> Right, let's just remove it, then.
<ScottK> Please.
<infinity> If it ever makes it into sid, it'll come back on its own.
<ScottK> Yep.
<infinity> ScottK: Done.
<ScottK> Excellent.
<ScottK> Turns out it's easy to get confused about the current version of something when you just set up a new LTS system and forgot to point the deb-src lines at the devel release.
#ubuntu-devel 2014-11-11
<mwhudson> is there a thing that can show you which source packages build-depend on a particular package?
<mwhudson> apt-cache rbuild-depends, except existing
<jtaylor> reverse-depends -b, though it outputs binary packages
<jtaylor> source you probably have to use grep-dctrl
<mwhudson> jtaylor: good enough, thanks
<Mirv> pitti`: thanks, I see you've updated cssutils which probably means powerpc caliber build would now succeed. trying.
<Mirv> libre, even
<pitti> Good morning
<Tribaal> hi all! I'm super happy to see an update to chromium this morning :)
<Tribaal> thanks for the hard work!
<dholbach> good morning
<LocutusOfBorg1> can anybody please merge filezilla? http://paste.ubuntu.com/8936186/
<LocutusOfBorg1> I'm the previous uploader, should I open a bug?
<pitti> ^ doing (but he's offline now)
<pitti> nope, patch whitespace is totally garbled
<pitti> wgrant: https://launchpadlibrarian.net/190079241/upload_6489523_log.txt â is there any way around this except introducing a package diff and updating the date?
<infinity> pitti: Why would the *binary* packages have ancient timestamps? :/
<infinity> pitti: Sound like someone's install method is "cp -a", which is insane.
<pitti> I haven't checked yet, I just noticed this when cleaning up -proposed a bit
<wgrant> pitti: That check cannot be overridden.
<pitti> wgrant: I mean, why do we have it in the first place? being stricter than Debian means we have to carry around rather pointless deltas?
<pitti> certainly the upstream build system does something funky there, but repacking the orig.tar.gz is painful
<pitti> well, we could hack some "touch"es into debian/rules, but still painful
<mvo> infinity: good morning, I prepared this apt upload I keep talking about for vivid in https://launchpad.net/~mvo/+archive/ubuntu/apt-vivid and I think its ready now (doing some testing still but all is looking good afaict). when is a good time for you for a upload ? in my evening?
<mvo> infinity: https://launchpad.net/~mvo/+archive/ubuntu/apt-vivid/+sourcepub/4554564/+listing-archive-extra <- long changelog, this is why I'm a bit more cautious than usually
<wgrant> pitti: I'm not sure why it's there, but it's been there forever.
<pitti> wgrant: ah, so just the first time we hit this then, apparently
<wgrant> It shows up occasionally, and usually indicates upstream is broken.
<infinity> mvo: Does this still have the _apt user?
<mvo> infinity: yeah, getting rid of this is a bit more work
<infinity> :(
<pitti> xnox: do you still plan on doing your merges, or should we take over? (I could do e. g. simplejson or at)
<infinity> mvo: How much more work? :)
<infinity>   * Ensure /etc/apt/auth.conf has _apt:root owner
<infinity> mvo: I really don't like stuff like that, if we can void it.
<infinity> It's gross.
<infinity> Though, in a proper privsep world, that means root should be reading that and passing it to the backends via IPC.
<infinity> mvo: Privsep that lets non-root processes read config files isn't really privsep.
<mvo> infinity: yeah, its not the end of the road yet
<infinity> mvo: I'd almost be inclined to say just tear out the new user creation and chmodding and let the backends run as root until the feature's complete, but that's just me.
<infinity> mvo: Cause removing users and chmodding back as an upgrade path is a pain.
<infinity> mvo: Assuming the goal is to have the backends run as nobody and never need to write to disk.
<infinity> mvo: Though, I guess that might be tricky for the actual downloading bits.
 * mvo nods and thinks about it
<infinity> mvo: But, fundamentally, if I can screw with a backend enough to own the _apt user, then I can do anything that user can do, including reading private config files and poisoning the local cache.
<infinity> mvo: Which seems not entirely ideal.
<infinity> mvo: Sure, that's better than escalating to root, but most of what apt does is so close to being root anyway, that it's a pretty close hop away. :/
<infinity> mvo: Also, minor nit about the current state of affairs if you wanted to ship it that way, making /etc/apt/auth.conf WRITEABLE by the _apt user is just wrong. :P
<infinity> mvo: If you wanted to keep the user and let it be your reader of scary things, it should be in a group with read access, not the owner of the file.
<mvo> infinity: *cough* that would be a bug then
<mvo> infinity: so yeah, its pretty tricky to get it to a state that _apt can not do harm but posing the local cache should not be possible when we check the hashes indepdently, i.e. broken stuff will be detected. but yeah, the reading of config files needs to move into main apt and the method communication etc
<mvo> infinity: unfortunately other tasks keep me quite busy I wish I could devote more time to finish this work
<infinity> mvo: I'd probably just be inclined to ship it without the sandbox user set, and without the adduser and chown calls, so you don't have to undo it all later, but that's just me.
<infinity> mvo: If you think this is a big enough win as-is, and you're prepared to deal with upgrade scenarios, meh.
<mvo> infinity: right, thanks, let me ponder a bit about it but I think you have a valid point here
<infinity> cjwatson: Do you remember how to reproduce the bug that unsubmitted-dlopen-static-crash.diff was meant to fix?
<dholbach> @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: dholbach
<cjwatson> infinity: Revert it, build an x86 phone image, try to run it in the emulator, watch it entirely fail to start unity8
<cjwatson> (the nature of the beast is that I don't have a small test case)
<infinity> cjwatson: Err, wrong patch. :)
<infinity> cjwatson: I'm referring to the autoconf static dlopen segv thing we patched back in saucy.
<infinity> cjwatson: Which I'm really not sure how to reproduce to know if it's been fixed better.
<infinity> Because we cleverly never filed a proper bug for it or anything.
<cjwatson> Oh.  Give me a few minutes not to be answering from my phone then ...
<infinity> cjwatson: Heh, mostly a non-immediate-issue anyway, I was blaming a new testsuite failure on that patch, but reverting it made no difference.
<mitya57> pitti: thanks for filing the bug, now we have this in #debian-python:
<mitya57> <jwilk> [22:52] Does anyone still want to use lintian4python or should it be RMed?
<mitya57> <jwilk> [23:30] Fixing #763206 aka #768988 will be your first task. :-)
 * mitya57 uses lintian4python but doesn't speak Perl...
<infinity> mitya57: Well, I just removed it from vivid, if you want to fix it and reupload, go nuts.
<infinity> mitya57: Learning Perl isn't exactly rocket science if you know C.
<infinity> mitya57: You just get to use all the characters on the top row of your keyboard for once.
<infinity> ALL OF THEM.
<mitya57> Well, I have a Compose key :D
<mitya57> (And Shutdown)
<seb128> does anyone know if vivid translations import is active/working?
<seb128> dpm, pitti, wgrant, ^?
<wgrant> seb128: vivid translations aren't happening yet. I hope to fix them in the next week or so.
<seb128> wgrant, ok, thanks
<wgrant> seb128: Anything in particular you're concerned about?
<seb128> wgrant, no, I was wondering why https://translations.launchpad.net/ubuntu/vivid/+source/indicator-session is empty and https://translations.launchpad.net/ubuntu/vivid/+source/indicator-session/+imports is sitting on "approved" items but not importing those
<seb128> wgrant, I was trying to verify a fix for a translation bug
<seb128> wgrant, also I need https://translations.launchpad.net/ubuntu/vivid/+source/ubuntu-ui-extras/+imports to fix some touch non-translatable string issues
<seb128> but I guess I'm just going to try to land that fix in rtm without testing on vivid first
<wgrant> seb128: I hope to have it going soon. Just need to get enough off my plate that I can safely do it.
<seb128> wgrant, ok, no worry, thanks for the status update
<seb128> wgrant, I thought translations import would "just work" automatically for new series, I didn't know there was manual work involved
<seb128> wgrant, keep the good work :-)
<ogra_> ++
<pitti> mitya57: ah, I don't care about lintian4python personally, it just holds back the new lintian
<wgrant> seb128: It's still a separate manual process to get them going, and it's pretty reliable nowadays, but when it goes wrong you can usually say goodbye to a couple of days of useful work.
<mitya57> pitti: I know, and also s/holds/held/ now
<pitti> mitya57: oh, curious -- how did lintian get past this?
<infinity> pitti: It got past it by me removing it. :P
<infinity> https://launchpad.net/ubuntu/+source/lintian4python/0.28.4/+publishinghistory
<pitti> hah
<pitti> haha @ Allergy advice
<LocutusOfBorg1> bdrung_work, I fixed the vlc master-daily build for trusty and utopic
<LocutusOfBorg1> there is something that worries me now, vivid is failing because seems that the library has x11 linked https://code.launchpad.net/~videolan/+recipe/master-daily
<pitti> LocutusOfBorg1: wb
<pitti> LocutusOfBorg1: I wanted to upload your debdiff this morning, but it has totally garbled whitespace
<pitti> LocutusOfBorg1: so better attach it to a bug, please
<LocutusOfBorg1> LocutusOfBorg1> pitti, yes, I had already opened a bug :)
<LocutusOfBorg1> <LocutusOfBorg1> seems somebody uploaded it
<LocutusOfBorg1> <LocutusOfBorg1> dholbach, thanks :D
<pitti> LocutusOfBorg1: ah, good
<LocutusOfBorg1> (sorry for the double noise)
<bdrung_work> LocutusOfBorg1, thanks
<LocutusOfBorg1> thanks for what? I'm looking at the vivid build log, and I cannot find any clue, that plugin in the build log seems not built with X11 or xcb :s
<LocutusOfBorg1> so for now I'm stuck :(
<bdrung_work> for trusty and utopic
<LocutusOfBorg1> oh... it was trivial, utopic was missing a b-d, and trusty I added the multimedia ppa for the new libsa
<LocutusOfBorg1> s/libsa/libav
<bdrung_work> i haven't found the time to even look at it
<LocutusOfBorg1> I know, we are always overbusy, I'm having the same problem, this is why I'm giving up for now for vivid
<ScottK> baloo-kf5 needs the libkf5filemetadata-dev minimum build-dep version bumped to to 5.1.1
<dholbach> @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:
<tedg> jodh, So rsalveti and I are discussing the behavior of a pulseaudio job in: https://code.launchpad.net/~ted/ubuntu-touch-session/indicator-sound-override/+merge/241300
<tedg> jodh, It seems that what pulse does is that it does the forks, but then blocks until they write on a pipe.
<tedg> jodh, Is Upstart just looking for the fork command, or for when the parent exits?
<jodh> tedg: upstart counts the forks.
<tedg> jodh, When does the post-start job run? When started is emitted or when the exec is complete?
<jodh> tedg: it runs after exec and before started is emitted.
<tedg> jodh, So if I add a post-start job, even /bin/true, it would wait until the parent exits before emitting started?
<jodh> tedg: the flow is: main process (fork+exec), post-start (fork+exec), emit started.
<tedg> jodh, So when I have the "expect daemon" stanza, does the main process component complete after the second fork() is called or when the initial process exits.
<jodh> tedg: as mentioned, current upstart only counts forks. We do have a branch lingering around upstream that counts the exits (lp:~jamesodhunt/upstart/bug-530779), but that's unlikely to land now.
<tedg> jodh, Okay, I understand, thanks!
<tedg> stgraber, Saviq got some weird cgmanager errors in his log and then Unity couldn't connect to cgmanager, do they mean anything to you? http://pastebin.ubuntu.com/8942980/
<stgraber> hallyn: ^
<hallyn> tedg: possible to file a bug?
<tedg> hallyn, Sure, but we're not sure how/what to file :-) we're using bug 1377332 right now.
<ubottu> bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [High,In progress] https://launchpad.net/bugs/1377332
<hallyn> tedg: thanks, i'll look
<LocutusOfBorg1> cjwatson, wonderful the plastimatch patch! you rock man!
<LocutusOfBorg1> spoken too fast, there still are three tests failing in amd64 :(
<cjwatson> LocutusOfBorg1: I reuploaded already
<cjwatson> https://launchpad.net/ubuntu/+source/plastimatch/1.5.16+dfsg-1ubuntu2
<LocutusOfBorg1> wonderful :)
<cjwatson> reasonably sure this pile will migrate once that's done
<LocutusOfBorg1> :)
<cjwatson> then hopefully either vdr/imagemagick will migrate too or else it'll be clearer what's going on there
<cjwatson> ah, it's blocked on the pyqt5 stuff that I believe Mirv is working on
<pitti> kees, infinity, mdeslaur, slangasek, stgraber: anyone here today for TB, given memorial day?
<mdeslaur> pitti: I'm here
<kees> pitti: I'm here too
<pitti> kees: ah, great; in theory you are chairing today
<kees> pitti: yeah, we'll see if we have enough people :)
<kees> infinity: you around for meeting?
<cjwatson> ah, good, that's gdcm/hdf5/etc. migrated
<cjwatson> gets it out of the way of imagemagick etc. once Mirv's done
 * cjwatson EODs
<hallyn> infinity: mwhudson:  ok, bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897 , i'm going to push that debdiff (in comment #10) to vivid?  any objections / new developments i've missed here?
<ubottu> Ubuntu bug 1389897 in qemu (Ubuntu) "no way to install "enough qemu for kvm" in a cross platform way" [Undecided,Confirmed]
<mwhudson> hallyn: +1 from me
<mwhudson> hallyn: i haven't built tested it on !amd664
<mwhudson> wow good typing there michael
<mdeslaur> hallyn: please don't SRU qemu yet, I have security updates that are building
<mdeslaur> (in stable releases)
<hallyn> mdeslaur: no, i was only going to push to vivid.
<hallyn> mdeslaur: do you have fixes there?
<hallyn> if so i'll happily wait
<mdeslaur> hallyn: I'll have fixes, but not right now, so go ahead
<hallyn> i'm only working on srus for libvirt
<hallyn> ok, thx
<hallyn> mdeslaur: btw, please do shout at me whe you do push to vivid, as i want to be sure to get everything into the debian git tree before i accidentally drop hcanges at next update/merge
<hallyn> i do intend to merge next week into vivid
<mdeslaur> hallyn: ok, sure
<hallyn> (do it with rharper as a training execise)
<hallyn> thanks
<hallyn> mwhudson: but wait, i thought you'd tested it on ppc64el?
<hallyn> time for me to find a porter box i guess :)
<hallyn> or maybe i can nag smoser
<mwhudson> hallyn: infinity did some ppc testing of the kvm wrapper bits
<mwhudson> no package building afaik
<hallyn> ok, thx, trying on the porter
<smoser> hallyn, whats up?
<smoser> i can get you a ppc64el system if you need.
<hallyn> smoser: i'm trying the ppc64le porter box right now.  seems not too bad
<smoser> ok.
<hallyn> smoser: though it's taking forever,  if you wanted to grab the vivid qemu source and add the debdiff at http://people.canonical.com/~serge/qemu-8.debdiff and see if that builds there, that would rock
 * hallyn will be afk for a bit, but bbl
<hallyn> well build is *almost* done here.  looking good
#ubuntu-devel 2014-11-12
<infinity> hallyn: No objections from me, except that you gave mwhudson all the credit. ;)
<smoser> pitti, i'd appreciate your thoughts on bug https://bugs.launchpad.net/maas/+bug/1391354
<ubottu> Ubuntu bug 1391354 in MAAS "Failure to boot ephemeral image for Utopic Fast Installer deployment" [Undecided,Incomplete]
<hallyn> infinity: d'oh, i thought it was purely his.  that won't fly.  who exaclty is Ben?
<infinity> hallyn: Ben Collins.
<hallyn> thx
<infinity> hallyn: I was mostly kidding, I don't think Ben and I care about the credit, we have more than enough.
<infinity> hallyn: But if you're trying to be accurate, go for it. :)
<infinity> Okay, seriously brain, WTF?  Why did you just start humming 'Total Eclipse of the Heart'?
<hallyn> infinity: damn you
<hallyn> were i only too young to know that song
<infinity> hallyn: I've already moved on from humming it to singing it.  Send help.  I'm scared.
<hallyn> maybe tych0 can help with a meshugga link
<hallyn> anyway, package built fine and looks good on th eporter box
<infinity> \o/
<hallyn> so what the heck, pushing.  thanks again
<hallyn> (but no thanks for the crap now in my head)
<tych0> https://www.youtube.com/watch?v=DHdFTxu5M38
<tych0> at your service
<infinity> We'll let that bake in vivid for a short while and see if anyone whines about it being crap, then I'd like to SRU that changeset back to T and U.
<infinity> hallyn: I'd also like the qemu-slof dep in a trusty SRU, but that depends on me first getting a newer SLOF in -updates and promoting it to main.
<infinity> hallyn: And actually, forget I mentioned that, cause it should also go hand-in-hand with getting IBM to backport some LE fixes to that qemu version, which hasn't happened yet.
<hallyn> well at least i got the libvirt bit needed to giver permission to read slof into t,u sru
<hallyn> ah
<hallyn> tych0: thanks.  i'm on a hotspot.  trying to decide how precious this is to me.
<hallyn> pretty precious...
<infinity> I have to be in just the right mood for metal this metal.
<infinity> I might settle for a middleground of Soundgargen's Badmotorfinger as a palate cleanser.
 * tych0 sets mood to awesome
<tych0> the mood is always right for the best band in the world
<infinity> tych0: I agree, but seems odd, given that no one mentioned the Tea Party yet.
<hallyn> this conversation is starting to soar over my head
<tych0> or into the political gutter (:
 * tych0 ducks
<infinity> tych0: Wrong Tea Party. ;)
<tych0> i figured, but the joke was just right there
<infinity> tych0: It sure was.
<dobey> mhall119: it's the same spammer on -discuss again. how many times do you need to ban him?
<slangasek> well, mikeeusa is habitually immune to social pressure, so.
<mhall119> dobey: once for every email address he has it seems
<Mirv> pitti: is there a way for normal people to re-run autopkgtest? there's one amd64 autopkgtest that would probably like a rerun: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<infinity> pitti: Is there a way to specify that a DEP-8 test should only be triggered for rdeps, not for the package itself?
<infinity> pitti: It makes about 0 sense for glibc's rebuild test to run immediately after I just proved glibc can build from source by uploading it.
<infinity> pitti: Err, for deps, not rdeps.  But you know what I mean.
<Mirv> now it got re-run and passed
<Mirv> oh, not, it was for another package
<Unit193> pitti: Good morning.
<pitti> Good morning
<pitti> Mirv: yes, it's actually quite simple: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test shows how we do this in CI, and /usr/share/doc/autopkgtest/README.running-tests.html shows all scenarios
<pitti> Mirv: apparently someone already re-ran, or it fixed itself
<pitti> infinity: not at the moment, I'm afraid
<pitti> infinity: we might teach britney about such exceptions of course (glibc, gcc, and  binutils would be the only ones, I think)
<Mirv> pitti: I mean, re-run it on jenkins? I've done bookmarks on how to reproduce locally if needed.
<Mirv> pitti: it seems it run again for glibc, and tested the new qtbase at the same time so both were marked as Passed
<pitti> Mirv: you should be able to log in at http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/ and re-run them
<Mirv> pitti: right, I think I can. so they always run against whole -proposed or something, there doesn't need to be a parameter "run package xyz tests for getting it pass for package zyx migration?"
<pitti> Mirv: right, they need to succeed in -proposed, nothing to parameterize
<Mirv> then that's easy. I'll make a note. thanks!
<pitti> and meh, our testbeds are totally overloaded
<pitti> smoser, infinity: wolfe-09 is AWOL; reboot, s'il vous plaÃ®t ?
<pitti> smoser, infinity: wolfe-07 too
<smoser> pitti, i will bounce.
<smoser> this is possibly outcome of over commit there.
<pitti> smoser: wolfe-06 is really slow; is that maybe a problem on the host (and thus that needs reboot), or did the VMs crash independently?
<pitti> or overcommitting?
<pitti> ah
<pitti> smoser: so if you dial them down to 4 GB RAM, might that help?
<smoser> maybe
<RAOF> Oh, is this why my CI is going really slowly? :)
<Noskcaj> Can someone please retry din on all arches? It needed a newer version of libircclient (which we now have)
<pitti> RAOF: this is ppc64el only; x86 CI is really slowly as our 4 static testbeds are aching under the doubled number of tests since utopic (and they were aching already there..)
<pitti> Noskcaj: yeah, will do
 * RAOF thought everything was on ScalingStack now. Or is that just the buildds?
<Noskcaj> ty
<pitti> RAOF: just the buildds; still working on moving autopkgtests to Bootstack
<smoser> pitti, wolfe-07 and wolfe-09 rebooted. console logs
<smoser> wolfe-07: http://paste.ubuntu.com/8957820/
<smoser> wolfe-09: http://paste.ubuntu.com/8957823/
<pitti> smoser: "Unable to handle kernel paging request for data" -- that does sound related to overcommitting?
<smoser> i dont know. itspossible i'm just doing something stupid on the host.
<smoser> pitti, i'm really sorry, but i have to fall asleep.
<pitti> smoser: no worries, thanks
<Mirv> hey, I'd need help from core-dev since I don't have upload rights to the Qt's "-gles" packages.
<pitti> smoser: I'll ask infinity once he comes back, the others are really slow and failing too
<smoser> pitti, https://bugs.launchpad.net/maas/+bug/1391354 . if you have a right way  to solve that, i'd appreciate it.
<ubottu> Ubuntu bug 1391354 in MAAS "Failure to boot ephemeral image for Utopic Fast Installer deployment" [Undecided,Incomplete]
<pitti> smoser: yep, will look at that and comment on the bug
<Mirv> apt-get source qtlocation-opensource-src-gles , edit debian/control's line 61 to be << 5.3.2-0~ instead of 5.3.2-2~
<smoser> see the bug referenced there for mroe contex.t
<smoser> good night all.
<Mirv> I was able to decipher http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt and realized there's a wrong Breaks
<Mirv> debdiff http://pastebin.ubuntu.com/8958003/
<Mirv> oh... unping, it's in universe unlike the normal variant!
<Mirv> sorry for the noise
<pitti> Mirv: confused -- that debdiff wouldn't do anything AFAICS
<pitti>  qtdeclarative5-qtlocation-plugin-gles | 5.3.2-0ubuntu2 | vivid-proposed/universe | all
 * Mirv gets more coffee
<pitti> oh, ok, the new version is in -proposed
<Mirv> pitti: it's blocking proposed migration since the new transitional package cannot be installed since the qml module's Breaks has too high version
<pitti> Mirv: right; and you are saying that you can just upload it yourself?
<Mirv> pitti: yes, I just did since I'm MOTU nowadays.
 * pitti yays at jenkins just breaking a gazillion tests with some java exception
<pitti> die, jenkins, die!
<infinity> smoser: Err, are you overcommitting RAM, or just CPU?
<infinity> smoser: CPU overcommit works quite well, RAM overcommit will lead to nothing but pain.
<pitti> hey infinity  -- btw, please hold on with rebooting wolfes; that causes tons of x86 jobs to fail with a jenkins error due to the braindead way jenkins handles its jobs
<pitti> and the x86 ones are stalled enough without me having to retry a gazillion jobs :/
<infinity> pitti: I hadn't intended to reboot anything.
<infinity> pitti: I'm not really here.
<pitti> infinity: right, but I asked for that above
<pitti> infinity: ah, I must not be fully awake yet then, talking to an illusion :)
<Noskcaj> I don't have the internet quality to test built, but we can probably sync jocaml
<pitti> smoser: I responded to the bug
<ari-tczew> seb128: I've prepared a merge of gimp, it means I stole your merge. Hope you're not angry :-)
<seb128> ari-tczew, no worry, thanks for doing it
<Noskcaj> elkcode should build after a retry
<Noskcaj> seb128, What's required for gtk 3.14 to land?
<seb128> Noskcaj, work
<Noskcaj> Anything i can help with?
<seb128> Noskcaj, http://pad.ubuntu.com/gtk-update-v
<seb128> Noskcaj, feel free to work on some of the bugs
<seb128> bugs/issues
<Noskcaj> ok. I'll see if there's anything i can do
<seb128> thanks
<seb128> if you work on something please note it down, or let #ubuntu-desktop know at least, to not duplicate work
<didrocks> Riddell: hey, kind reminder about http://summit.ubuntu.com/uos-1411/meeting/22332/update-to-bluez-5/ today at 3PM UTC, some KDE input will be appreciated
<didrocks> cyphermox: as well ^
<Noskcaj> seb128, What version of gnome-disk-utility was the issue found?
<seb128> Noskcaj, not sure, I'm not the one who wrote that one down, the one in vivid I think
<Noskcaj> It sounds like upstream fixed the issue in the latest point release, so i was hoping that it was an older version and it wasn't an issue
<seb128> could be, check with Laney when he gets online, I think he's the one who wrote that one down
<Noskcaj> ok
<darkxst> seb128, inspector requires libgtk-3-dev to be installed for the keybindings to work
<seb128> I think that's a larsu's item, maybe say that on #ubuntu-desktop rather?
<Laney> Noskcaj: seb128: yeppers, that is fixed in 3.12
<Laney> DELETE!
<seb128> :-)
<Mirv> Qt 5.3.2 has migrated now to release pocket except for one small package which requires Ubuntu specific change (transitional package until 16.04 LTS...)
<cjwatson> RAOF: gnome-do's failing to build; it seems to be looking for dbus-sharp.dll in the wrong directory for some reason (/usr/lib/mono rather than /usr/lib/cli).  Do you know what's up here?
<Mirv> qtgraphicaleffects migrated now too
<highvoltage> F/win 34
<LocutusOfBorg1> cjwatson, you rock man :)
<LocutusOfBorg1> two or three transitions in a row :D
<ebel> packages.ubuntu.com isn't working well for me. Not showing me utopic packages, even when I directly access it http://packages.ubuntu.com/search?suite=utopic&keywords=postgresql-9.4 ?
<ebel> google cache is showing previews which don't match actual page, e.g. http://packages.ubuntu.com/utopic/nodejs
<cjwatson> doko: Is it intentional that "java -client" no longer works on ppc64el?
<cjwatson> doko: (causes java-gnome to FTBFS)
<mardy> tedg: hi! Does upstart (or libubuntu-app-launch) check that the APP_URIS are actually valid URIs, or can I pass any parameter there?
<tedg> mardy, There's light checking, which you could probably easily trick. But I'd recommend avoiding that. What are you trying to do?
<mardy> tedg: I need to pass a simple string (with no spaces) and then the address of a unix socket; I can easily prepend some scheme:// to them, if needed
<tedg> mardy, From where to where? For an application?
<tedg> mardy, Not sure how the launcher would know to pass those?
<mardy> tedg: ah, sorry, I didn't tell you the context: from a trusted helper to an untrusted helper; something like the pay service is doing
<mardy> tedg: one of the parameters is indeed the mir socket address
<pitti> infinity: glibc is a valid candidate now; *phew* (I overrode three regressions which are not due to glibc)
<caribou> slangasek: I still haven't found sponsoring for the libnss-ldap merge. SRU for all existing unbuildable pkgs are waiting for that (LP: #1387594)
<ubottu> Launchpad bug 1387594 in libnss-ldap (Ubuntu) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/1387594
<caribou> the merge bug is LP: #1389152
<ubottu> Launchpad bug 1389152 in libnss-ldap (Ubuntu) "please merge libnss-ldap 265-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1389152
<tedg> mardy, Ah, so we do far less checking in that case. We expect the pre-start helper to do the work there.
<infinity> pitti: Thanks for babysitting.
<pitti> the giant x86 queue is done, too
<pitti> mkdir: cannot create directory â/var/cache/autopkgtest/â: Read-only file system
<pitti> argh, seriously? /var/cache is r/o on touch?
<barry> pitti: hi.  would you have some time today to chat about running adt tests on the phone?
<pitti> rhuddie: so, I was fixing the first half of reboot support for tests on the phone
<pitti> rhuddie: but now I found that, and need to now ponder how I work around that :/
<pitti> barry: sure, what's up?
<rhuddie> pitti, ah, thanks for the update. so it's not as simple as it first seemed :)
<barry> pitti: i have several questions.  after discussing with qa, i want to turn this test plan into dep 8 tests: https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-image
<pitti> rhuddie: yeah, touch images breaking the file system in just about every way requires a lot of workarounds :/
<barry> pitti: i know how to write code to flex each of these test plans, but i have a few problems.  i can't even get the basic adt-run ... --- ssh -s adb to run tests
<barry> pitti: it just does some stuff then exits
<pitti> barry: which version are you using?
<mardy> tedg: cool, thanks
<pitti> barry: also, "some stuff" -> I'd need the full output log, preferrably with -d
<barry> % dpkg-query -W autopkgtest
<barry> autopkgtest	3.7git3
<barry>  
<pitti> barry: I usually start with trying to run the calculator tests, so perhaps start with that?
<barry> (i think adt-run doesn't have a --version)
<pitti> barry: adt-run -o /tmp/out --click com.ubuntu.calculator --- ssh -s adb -- -ps3kr1t
<pitti> barry: unless your password is 0000, then you can leave out the -p bit
<pitti> barry: if that fails, please pastebin /tmp/out/log
<barry> pitti: yep, i can generate that for you (the debug output).  another question, is adt-run over a _amd64.changes file supposed to work?  i can't get that to work either
<barry> pitti: let me try that
<pitti> barry: yes, but only on a r/w target (QEMU, schroot, etc.), not on a r/o phone for obvious reasons
<barry> pitti: yep sure.  okay, let me break each step down and give you output and we'll see if we can make this work (or fix my misunderstandings ;)
<pitti> barry: right; start with the calculator tests, and we'll work from there
 * barry nods
<pitti> barry: the initial phone setup always give most of the worries/variability
<rhuddie> pitti, for bootspeed testing I was using one of the cloud images from adt-buildvm-ubuntu-cloud, but that doesn't have a UI, so I'm missing various log files expected by the tests
<rhuddie> pitti, so I'm wondering how I can get adt-run to work with a standard ubuntu qemu image?
<pitti> rhuddie: do an install into a VM, then copy /usr/share/autopkgtest/adt-setup-vm into that VM, run it (with sudo)
<pitti> rhuddie: after that the VM should be prepared
<pitti> rhuddie: (disclaimer: I haven't tried that myself yet)
<barry> pitti: calculator click tests ran.  they failed but they ran.  let me see if i can reproduce my problem from yesterday
<rhuddie> pitti, ooh, thanks, I'll give that a go :)
<pitti> rhuddie: but looking at the script I see nothing that should fail
<pitti> rhuddie: that script is supposed to be the common "turn something into an adt capable image" script, for vmdebootstrap, cloud-init based images, nova boot, etc.
<arges> tych0: hey for bug 1384751 why did you make the version ubuntu3.14.10.1 instead of ubuntu3.1?
<ubottu> bug 1384751 in lxc (Ubuntu Utopic) "checkpoint restore fails with /usr/lib/x86_64-linux-gnu/lxc/lxc-restore-net: not found" [High,Triaged] https://launchpad.net/bugs/1384751
<pitti> barry: I have one or two failures as well, but some 30 successes; or do yo mean they all failed?
<barry> pitti: no, just a few failed
<pitti> barry: you shoudl see some numbers being auto-typed in and the UI moving, not just calculator stopping and starting all the time
<tych0> arges: probably because i don't know anything about packaging :)
<pitti> barry: ok good, that's expected
<tych0> arges: should i update it?
<tych0> arges: or, what's the best way to proceed
<arges> tych0: i mean it _really_ doesn't matter, but i'd probably use ubuntu3.1
<tych0> arges: oh, actually, perhaps hallyn can elaborate?
<tych0> arges: i'm happy to change it, though
<arges> yea if hallyn's ok with that version that's fine too. just wondering
<barry> pitti: here is my ..._amd64.changes file.  would you expect this to work: adt-run system-image_3.0-0ubuntu1_amd64.changes --- qemu adt-vivid-i386-cloud.img
<barry> pitti: http://paste.ubuntu.com/8966156/
<pitti> barry: no, because you didn't include teh source there
<mitya57> Does anybody know why texlive-extra can't migrate? update_excuses tells it's a valid candidate.
<pitti> barry: a Debian .changes has both the .dsc and the .debs in the .changes, thus it includes all information
<pitti> barry: like that you additionally need to specify the .dsc (or the source tree) after the .changes
<pitti> mitya57: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt says it makes texlive-full uninstallable
<barry> pitti: okay, that makes sense.  i'm not sure why sbuild isn't producing rith right .changes file, but okay
<pitti> mitya57: at that point you need a chroot or chdist with -proposed and see what's broken if you try to install them both
<mitya57> Oh, one more page to look at. Thanks pitti!
<pitti> barry: $build_source = 0 in ~/.sbuildrc?
<pitti> barry: I have that, as for ubuntu builds it's generally what I want
<pitti> barry: so, adt-run foo.changes foo.dsc
<pitti> barry: which is equivalent to adt-run foo1.deb foo2.deb ... foo.dsc
<barry> pitti: nope, but i'll bet that's the default
<pitti> barry: i. e. it just expands all the .debs and the .dscs in the .chagnes and pretends you would have specified them individually
<barry> pitti: so no different from say: adt-run -B *.deb foo.dsc
<pitti> barry: correct; just more convenient to say adt-run foo.changes to test a debian upload
<pitti> barry: right, and -B
<barry>        BUILD_SOURCE
<barry>               BOOL type.  By default, do not build a source  package  (binary
<barry>               only  build).   Set to 1 to force creation of a source package,
<barry>               but note that this is inappropriate for binary NMUs, where  the
<barry>               option will always be disabled.
<barry>  
<pitti> barry: ah ;)
<barry>               Default:
<barry>  
<barry>               $build_source = 0;
<barry>  
<barry> pitti: :)  okay, the world makes sense again
<barry> pitti: thanks.  let me run with this for a bit and i'll ping you again if i get stuck
<barry> pitti: i will definitely have questions about adt-run and device reboots
<pitti> barry: yeah, that's what I'm currently working on; reboot works fine for qemu, but touch makes that a little harder
<pitti> (testing a fix now)
<pitti> or, rather, "workaround"
<barry> pitti: ack, nice
<hallyn> tych0: arges: this is about the lxc version for sru?
<tych0> hallyn: yeah
<arges> hallyn: yup
 * hallyn waits on a slow rmadison...
<hallyn> come on ...
<arges> hallyn: 'rmadison -a source lxc' is a bit faster
<hallyn> ah
<hallyn> ok, so yeah ubuntu3.1 sould be fine (though i don't knwo whwat ubuntu-rtm/14.09 pocket is),
<arges> hallyn: its for the phone
<hallyn> the 14.10.1 is required if there are more than 1 older release with the same version #
<hallyn> arges: yes, but will it need a separate update, or will it be updated from the utopic pocket?
<hallyn> if the former, then we do need ubuntu3.14.10.1 in utopic so rtm can uplaod something
<hallyn> i guess this issue has died down since we have shortened the non-lts life cycle
<hallyn> interesting
<arges> hallyn: i'm not sure, but i generally haven't worried about it
<hallyn> arges: i've definately seen it be a problem.  but not in awhile
<hallyn> arges: do you wnat to chang eit to ubuntu3.1 inline?
<hallyn> (dunno if you have that power :)
<arges> hallyn: yea 3.1 would make the most sense. so reupload it and I'll accept the new one
<hallyn> not sure i still have that
<arges> hallyn:  i don't. you'll have to re-up or tych0 will
<tych0> arges: just the debdiff with s/14.10.1/.1 ?
<hallyn> i can't re-up.  i don't have it.
<arges> tych0: yup
<tych0> arges: ok, will do in a sec
<hallyn> arges: are you sponsoring his directly then?
<arges> hallyn: its easier if someone else sponsors so I can do my SRU magic
<arges> otherwise we'll need another SRU team member to do the approval
<tych0> arges: hallyn: hmm, i'm confused
<tych0> the debdiff doesn't actually have "14.10" in it anywhere
<arges> tych0: yea whomever sponsored it must have changed it
<hallyn> tych0: pastebin the debdiff?
<hallyn> or, people.canonical.com it :)
<infinity> arges: That formality is a bit silly.  If you review someone else's upload and it's all good except for a spelling mistake or bad version or something, it's entirely reasonable to sponsor a fixed upload, triple check the diff between previous and current to make sure all you changed is the one thing, and accept it.
<tych0> hallyn: http://files.tycho.ws/tmp/utopic.patch
<infinity> arges: In general, I agree that you shouldn't accept your own uploads, but the rules don't exist for the sake of rules, they exist to stop you backdooring the process.
<arges> infinity: gotcha.
<arges> tych0: hallyn i'll sponsor it
<hallyn> arges: but not as is
<arges> hallyn: yea i'll fix it
<hallyn> ok :)  thanks
<pitti> rhuddie: ok, I'm over this, now hitting the next problem :)
<tych0> arges: gracias
<rhuddie> pitti, thank you! adt-setup-vm did the job  nicely
<pitti> rhuddie: great
<mitya57> Can some archive admin please look at bug 1389841 and bug 1389843? Because of that, osm-gps-map is stuck in -proposed and thus the version in vivid is less than in trusty-updates.
<ubottu> bug 1389841 in creepy (Ubuntu) "Remove creepy from vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1389841
<ubottu> bug 1389843 in gpxviewer (Ubuntu) "Remove gpxviewer from vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1389843
<mitya57> (also, that trusty SRU should not have been sponsored / migrated to updates without the equivalent utopic/vivid uploads)
<barry> pitti: question: is there anything in d/t/control that can be used to limit certain dep 8 tests to only running on a device, and others to *not* run on a physical device?
<pitti> barry: not in d/t/c, as it's whoever runs adt-run who decides where to run it
<pitti> barry: however, you tests can of course detect what kind of environment they are running in, and skip themselves if they find an inappropriate one
<pitti> barry: aside from that there are the "isolation-machine" and "isolation-container" restrictions which tests can declare to avoid e. g. getting run in a schroot
<barry> pitti: ack, that's the way i'll probably do it.  some of the tests will require flashing the device, and it only makes sense to run some of the tests on a physical device
<barry> (e.g. reboot, and then post-reboot verification)
<pitti> barry: in the future we'll have a more fine-grained way of saying "we want these tests to run on this set of testbeds", but this will only be advisory
 * barry nods
<pitti> barry: eek
<barry> pitti: yeah.  that makes it more fun
<pitti> barry: right, then something like checking system-image-cli and if that fails, skip the test (i. e. print a message and exit 0) seems fine
<pitti> barry: I'm sure this will fail in all sorts of interesting ways :)
<barry> pitti: indeed :)
<pitti> ogra_: oh, could it be that "SetProperty ssh true" is not persistant across reboots?
<pitti> rhuddie: ^ (next reboot+touch error fixed, running into that now :)
<ogra_> pitti, it definitely is persistent
<pitti> ogra_: hm, doesn't seem to here, but I'll check more closely
<pitti> ogra_: ah, I guess the bit that doesn't survive is the adb forward
<ogra_> ah, yeah
<pitti> ogra_: ah yes, that was it
 * pitti ponders how to fix that
<ogra_> pitti, you could dump somethin into dbus-property-service
<pitti> ogra_: nah, I need to call adb forward again, I just need to remember somehow to which port I forward
<ogra_> ah, k
<pitti> rhuddie: ok, that's something for tomorrow then; I have a meeting now, and then EOD
<pitti> rhuddie: but at least I have a successful reboot test on the phone now (just need to turn my hack for ^ into a proper solution)
<rhuddie> pitti, good progress, no less, thank you :)
<slangasek> caribou: I don't have time to review this merge at the moment, but a first glance shows that an awful lot of the Ubuntu delta has been dropped with no explanation in the changelog.  I don't think this is sponsorable as-is
<caribou> slangasek: most probably because the ubuntu specific is now in the upstream (i.e. debian) patches
<caribou> slangasek: I thought that it did not require a specific mention as it was now part of the upstream debian package but I can add specific details
<slangasek> caribou: no, there are changes dropped on the floor here, and I want to know why :)
<caribou> slangasek: and I was not expecting *youÃ¹
<caribou> oups, you to do the merge
<caribou> infinity had done a first pass but he's off & I don't want to bother him with that
<slangasek> ok, then it's perhaps best left until he comes back
<caribou> slangasek: as long as nobody rebuild the existing libnss-ldap package
<caribou> slangasek: I sent him a detailed email with what I had done in the merge. So you're right, better to wait until he's back
<caribou> slangasek: just checked; all changes are either kept or now in upstream patches. I'll adapt the changelog
<caribou> slangasek: I'll see with infinity when he's back
<slangasek> caribou: well, so far I've identified one change that was dropped from the delta: the build-dependency on po-debconf has been reintroduced.  But yes, better changelog explaining why things like debian/patches/fix-ethers-truncation.patch have been dropped would be useful
<smoser> pitti, i updated bug 1391354.
<ubottu> bug 1391354 in MAAS "Failure to boot ephemeral image for Utopic Fast Installer deployment" [Undecided,Incomplete] https://launchpad.net/bugs/1391354
<smoser> oh. and you responded already
<smoser> :)
<caribou> slangasek: will do; fix-ethers-truncation.patch is now fixed upstream
<ChrisTownsend> hallyn: stgraber:  Hey Guys!  I'm getting an error when using a Vivid LXC on a Trusty host:
<ChrisTownsend> ** (process:851): WARNING **: Unable to get PID list from cgroup manager: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: invalid request
<ChrisTownsend> Works fine with a Utopic host.
<ChrisTownsend> Just wondering if either of you are familiar with this and what may need to be done to support this in Trusty?
<stgraber> ChrisTownsend: what's giving you that error? some LXC command, a python3-lxc script, ... ?
<ChrisTownsend> stgraber: It's when I try to start an app in the Unity 8 LXC, so it might be u-a-l.
<ChrisTownsend> stgraber: A recent change to u-a-l uses GetTaksRecursive.  Could that possibly have any bearing on this?
<stgraber> quite likely, yeah
<ChrisTownsend> stgraber: So GetTasksRecursive is not supported in Trusty?
<stgraber> correct, you need cgmanager 0.32 for that
<ChrisTownsend> stgraber: Dang, oh well, I ended up breaking my own stuff.  Ok, thanks!
<hallyn> but lxc is supposed to detect that
<stgraber> hallyn: yeah, it's not LXC, it's his code ;)
<hallyn> and only call the gettaskrecursive if it is supported
<hallyn> oh!  ok :)
<stgraber> LXC indeed does check the API version and has a fallback :)
<ChrisTownsend> Yeah, u-a-l explicitely call GetTasksRecursive.  Should probably put a fallback in there as well.
<ChrisTownsend> hallyn: stgraber: I suppose there are no plans to add support in Trusty for GetTasksRecursive, right?  More of a feature I suppose.
<hallyn> yup
<hallyn> well, i've considered trying,
<stgraber> ChrisTownsend: it'd indeed be a feature update to a stable release and we usually try to stay away from that
<hallyn> this could be a special case it's not something that will continue to be developed - it just got cut off during initial development by trusty release
<hallyn> so if we're going to continue this with partial support for 5 years, it may be worthwhile pushing it so we can simplify other code (like lxc)
<stgraber> if absolutely necessary and if we can provide very good test results showing there wouldn't be any regression, it may be negotiable with the SRU team
<hallyn> but it's not something we have time for right now :)
<ChrisTownsend> hallyn: stgraber:  Well, we need to check PIDs recursively for legacy X app support in Unity 8 and we want to support development of Unity 8 for Trusty users, so *something* needs to be worked out.  I'll see if I can get u-a-l to work properly for this.
<ChrisTownsend> Too many dang variables when trying to develop for the latest and greatest but still worry about Trusty users.
<stgraber> ChrisTownsend: ListChildren() and GetTasks() both existed in trusty I believe
<ChrisTownsend> stgraber: GetTasks does, so maybe using a combo of both I can accomplish the same thing.
<ChrisTownsend> stgraber: hallyn:  Thanks guys!
<stgraber> not ideal obviously as you'll have to do a ton of calls to get the same as GetTasksRecursive but still, doable
<ChrisTownsend> stgraber: It will be a fallback only if GetTasksRecursive fails and hopefully tedg won't frown too much on it:)
<stgraber> ChrisTownsend: instead of calling GetTasksRecursive and failing, please check api_version instead :)
<ChrisTownsend> stgraber: Even better!
<tedg> stgraber, I'd rather fail, as that means in the standard case we have two calls.
<ChrisTownsend> tedg: Well, whatever you want, sir!  I just need *something* to work as Trusty users are dead in the water right now.
<stgraber> is that a longstanding process? because if so, querying api_version at startup should be reasonable
<ChrisTownsend> And we publicized the unity8-lxc package just today at UOS.
<tedg> stgraber, We make a connection each time, last time we connected to a private bus provided by nih-dbus for a long time bad things happened.
<stgraber> tedg: sure, but you can still cache the cgmanager api_version, it's not going to change :)
<tedg> stgraber, I believe I just saw a demo of a container frozen and moved while playing doom ;-)
<hallyn> ChrisTownsend: if you really need it, that raises priority, and we can pursue sru :)
<hallyn> tedg: haha, yes.  so it could change, indeed
<ChrisTownsend> hallyn: It will certainly make life easier, but snails move faster than the SRU process, so I'm not sure what the best path is right now.  Wait on SRU or hack up u-a-l???
<ChrisTownsend> hallyn: Currently, Trusty users using the latest Ubuntu Next desktop image cannot open apps, so it's useless.
<ChrisTownsend> hallyn: We do have a PPA for the unity8-lxc stuff, so we could always upload a version of lxc that supports GetTasksRecursive and when the SRU hits the archive, it will supersede the PPA.
<ChrisTownsend> hallyn: How long would it take to backport that support after we have a go ahead from the SRU team that the change is OK?
<ChrisTownsend> hallyn: And how does my request stack up as a priority for the other work you guys are doing?
<mwhudson> hallyn: woo for qemu updates
<hallyn> ChrisTownsend: well right now i basically think it's something we could spend some time doing next week.  depending on how many high-level mtgs we get roped into
<hallyn> ChrisTownsend: I think the best would be to take the 0.33 version verbatim and push it into trusty.  no backporting, bc that will only risk more regressions
<hallyn> but, i expect a long SRU team fight
<ChrisTownsend> hallyn: Ok, sounds like the coding part is pretty straight forward.  It's just getting it approved that may be the blocker.
<ChrisTownsend> hallyn: I'd like to get an OK before moving forward.
<barry> pitti: i don't suppose you're still around?
<kgunn> mhall119: hey, i know it's last minute is there any way to move the unity8 session to 1pm my time tomorrow (i believe that's one hour later, 19:00 utc) ?
<kgunn> mhall119: nvmd, i'll make it work
<RAOF> cjwatson: Bug isn't in gnome-do, it's in libdbus2.0-cil-dev; the pkg-config file points to nonexistent files in /usr/lib/mono.
#ubuntu-devel 2014-11-13
<RAOF> doko_: Re https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493
<ubottu> Launchpad bug 1389493 in openjdk-7 (Ubuntu) "Package dropped pulse-java.jar, breaking some development environments" [High,Confirmed]
<RAOF> doko_: As far as I can tell it seems to be a largely cosmetic issue, but a sufficiently annoying one that we should resolve it.
<doko> RAOF, I'm not sure how. just adding the old name as a symlink doesn't work either
<RAOF> doko: Urgh.
<pitti> Good mornin
<ari-tczew> hello pitti
<Noskcaj> Does seahorse-nautilus really need to depend on seahorse-daemon? if not, we can sync
<Laibsch> now that Debian is frozen will Ubuntu default to syncing from experimental or should I file appropriate bugs for this to happen for the packages that I maintain?
<LocutusOfBorg1> +1 for Laibsch question, I hope the latter
<mitya57> No, we will not sync anything from rc-buggy (aka experimental) automatically.
<mitya57> Please use requestsync from ubuntu-dev-tools to request syncs.
<LocutusOfBorg1> happy to hear that, I hope you will consider sync from maintainer requests :)
<LocutusOfBorg1> wonderful thanks
<pitti> yes, manually requested syncs are no problem, we just don't want to auto-import experimental stuff without checking
<LocutusOfBorg1> yes, seems legit, I would like to avoid that too :)
<Laibsch> bug 1392236 it is
<ubottu> bug 1392236 in scanbd (Ubuntu) "please my packages from experimental" [Wishlist,New] https://launchpad.net/bugs/1392236
<Riddell> who can say why plasma-desktop isn't transitioning from proposed?
<Riddell> I can see kwrited isn't happy about me removing the kwrited-data package which I'm confused about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<Riddell> everything else should be ok
<doko> RAOF, hmm, would it help to place an empty pulse-java.jar there?
<cjwatson> Laibsch: We don't have a mechanism to sync all your packages from experimental; unless you fancy doing some hacking on auto-sync I don't expect to have one in the near future.  Please just file explicit sync requests as needed for now
<cjwatson> That is, per-upload
<cjwatson> Easiest is if you get PPU rights or better for your packages, and then you can run syncpackage yourself :)
<xnox> Laibsch: there is tool to do so in standard way to request syncs with the "requestsync" tool available from ubuntu-dev-tools in both ubuntu & debian.
<cjwatson> xnox: He was already pointed at that
<cjwatson> I just wanted to make it clear that the request in the text of bug 1392236 is not something that we actually have the technology put together to fulfil right now.
<ubottu> bug 1392236 in scanbd (Ubuntu) "please sync my packages from experimental" [Wishlist,New] https://launchpad.net/bugs/1392236
<Laibsch> cjwatson: I'd love to get that, but my request for @ubuntu membership was rejected in 2010 because I was contributing too much and had been doing so for too long a time (I kid you not!)
<Laibsch> after that experience I  said to myself "WTF" and rolled over and simply ignored the nonsense process and never retried
<Laibsch> it is quite a bit of work and I only needed to waste my time on an application once
<Laibsch> I have pretty high clearance on bug triage in LP and I am Debian DM but apparently I need to get that @ubuntu membership for what you are suggesting and frankly, after that experience in 2010  I cannot be  bothered to waste my time on the application process once again
<cjwatson> Laibsch: OK, just wanted to let you know about the parameters that are available for syncing
<cjwatson> Laibsch: BTW it's not true that membership is required before PPU or other similar upload access
<cjwatson> Laibsch: getting upload access *grants* membership as part of it
<Laibsch> really?
<Laibsch> Ubuntu processes evolve fast and have gotten complicated
<cjwatson> Laibsch: this has been the case as long as I can remember
<Laibsch> where is the doc describing the process?
<cjwatson> https://wiki.ubuntu.com/UbuntuDevelopers
<cjwatson> which links to https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<cjwatson> I would generally say that developers should be taking this route rather than going through the general Ubuntu membership thing first
<cjwatson> and again, that's pretty much always been the case - sorry if you were misadvised before
<Laibsch> "Joining the Per-package Uploaders Check out the general requirements for Ubuntu Membership. "
<cjwatson> yes, that means you need to meet the requirements
<Laibsch> it seems to be a requirement to me
<cjwatson> it doesn't mean you need to separately gain membership first
<Laibsch> but I have to go through the nonsense one more time?  seriously, how many times would you beg someone for a key when he told you you are TOO skilled and trustworthy?
<cjwatson> you don't have to go to the people who do general membership
<Laibsch> OK
<Laibsch> that might help
<Laibsch> ;-)
<cjwatson> what this means is that the DMB will check for sustained and significant contributions as part of their process
<Laibsch> I remember I had to wake up at 3 in the morning and sit around for two hours twiddling thumbs
<Laibsch> to receive a rejection because I do too much
<Laibsch> I am still thoroughly pissed off
<Laibsch> yes, sustained and significant
<cjwatson> so they check the same requirements, but you don't have to go through two committees or whatever
<Laibsch> in my case too sustained (since 2005) and apparently too significant
<Laibsch> :-/
<cjwatson> being granted any kind of upload access implicitly grants membership
<cjwatson> (technically: because ~ubuntu-dev is a member of ~ubuntumembers)
<cjwatson> I'm sorry you had a bad experience.  I can't do anything about that, but I can suggest a more appropriate avenue that might yield better results
<Laibsch> OK
<Laibsch> that is appreciated
<Laibsch> this really should not happen, I hope it never happened again, but I cannot be sure
<Laibsch> I will keep my application efforts to a minimum this time, if I receive another rejection this time because "I did not proof my case" then that will be it for me.  I only jump through so many hoops to be admitted as a volunteer
<cjwatson> I left the community council in 2006, so I haven't been directly involved with the non-developer membership stuff since then ...
<xnox> Laibsch: yeah, developer membership board focuses on checking / verifying sufficient technical skills and knoweledge of release process (to make sure one syncs/uploads the right things at the right time). Looking over your profile, it looks to me like you have sufficient technical skill to apply for PPU (per package uploader).
<xnox> for the packages that you are the mainter off in Debian already.
<xnox> and then you will be able to sync them yourself into ubuntu.
<xnox> ps. I sit on the Ubuntu Developer Membership Board that grants such rights
<xnox> Laibsch: i have never been involved in the Community governance, I gained my ubuntu membership via Developer Membership board but becoming ubuntu contributing developer first, and later a core dev.
<xnox> well, cjwatson chaired the meeting / voted to approve me :-)
<Laibsch> I'm sure that must help
<xnox> Laibsch: nah, he was skeptical, but fair =))))))
<xnox> Laibsch: if you make application wiki page, and email it in, we can review you on the 1st of December 19:00 UTC as per https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
<Laibsch> I hope I won't have to be present this time?
<xnox> (one needs to apply at least 2 weeks in advance of the meeting)
<Laibsch> that's again middle of the night
<Laibsch> the times are not good for Asia-based people
<Laibsch> like I said, my application effort will be minimal, including wiki page (I will create a very simple one)
<Laibsch> 19:00 UTC is not possible for me to attend
<Laibsch> that's again exactly 3 AM
<Laibsch> sorry, I love Ubuntu, but not that much
<xnox> Laibsch: those are generally irc interractive meeting.
<Laibsch> not after that experience
<xnox> Laibsch: you can email, and request for an email application.
<Laibsch> good
<Laibsch> I wonder where my old wiki page went?
<xnox> the meeting on the 15th will be at 15:00 UTC
<Laibsch> I'd like not having to redo it
<xnox> Laibsch: if that's any better for interractive application.
<cjwatson> If you happen to know the URL, try appending ?action=info to it
<Laibsch> here it is: https://wiki.ubuntu.com/RolfLeggewie
<Laibsch> found it
<Laibsch> deeply buried in google ;)
<ogra_> does anyone have an idea why the fix for debian bug 169922 does not seem to be in ubuntu ?
<ubottu> Debian bug 169922 in mount "umount doesn't remount fs read-only if force option is also used" [Normal,Open] http://bugs.debian.org/169922
 * ogra_ tries to make adb on the phone actually force a readonly re-mount before killing the system on "adb reboot" ... seems "umount -f -r -a" does not work (nor does it work with a single mountpoint)
<ogra_> according to that but this should work since 2004
<ogra_> s/but/bug/
<pitti> ogra_: I regularly do "mount -o remount,ro /", and that works fine
<pitti> (as both dual-boot and the emulator are r/w by default, annoyingly)
<ogra_> pitti, / is ro anyway ...
<ogra_> pitti, http://paste.ubuntu.com/8986920/
<ogra_> or
<ogra_> root@ubuntu-phablet:~# umount -f -r /userdata
<ogra_> umount: /userdata: target is busy
<pitti> ah, busy
<ogra_> right
<ogra_> the bug above suggests this should work though
<ogra_> even when busy
<pitti> well, if there are processes still having open files on that (for write mode), how is it supposed to work?
<ogra_> (and indeed it is busy)
<pitti> you'd break all the running processes
<ogra_> thats fine, we call reboot anyway (dircet kernel call)
<pitti> (but I guess that's intended)
<ogra_> *direct
<ogra_> i dont care about the state of the processes, but i do care about the integrity of the fs
<ogra_> we see a lot of file corruption on the phone ... one of the reasons is "adb reboot" ...
<ogra_> the logical option would indeed be to make it call /sbin/reboot ... but that takes long ...  i would like ot keep the convenience of speedy reboots in adb
<pitti> ogra_: so perhaps as a first mitigation sync; reboot -f?
<pitti> (but yeah, forcibly unmounting/ro mounting would of course be betteR)
<ogra_> the code already calls sync ... doe reboot -f gain me anything over the direct kernel reboot call ?
<ogra_> *does
<pitti> ogra_: no, reboot -f is pretty much that -- don't go through init, just reboot the kernel; that's what I meant
<ogra_> yeah, well, that is what happens already
<pitti> ogra_: hm, sysrq+u does forced r/o, I wonder if one can trigger that by some other means
<ogra_> with the init layer ripped out inbetween
<pitti>       MNT_FORCE (since Linux 2.1.116)
<pitti>               Force unmount even if busy.  This can cause data loss.  (Only for NFS mounts.)
<pitti> hmm
<pitti> umount(8) also only talks about NFS
<ogra_> well, the bug seems to actually use a real device
<pitti> ogra_: ooh!
<pitti> https://www.kernel.org/doc/Documentation/sysrq.txt
<pitti> ogra_: echo u > /proc/sysrq-trigger
<ogra_> hah !
 * ogra_ hugs pitti
<pitti> (well, open() and fputc('u') in C, of course)
<pitti> ogra_: at least sysrq+u seems to work fairly reliably for me to reboot my machine after a crash and save the fs
<ogra_> root@ubuntu-phablet:~# echo u > /proc/sysrq-trigger
<ogra_> root@ubuntu-phablet:~# touch /userdata/foo
<ogra_> touch: cannot touch â/userdata/fooâ: Read-only file system
<ogra_> \o/
<pitti> touchÃ©
<ogra_> lovely
<pitti> ogra_: so, write 'u', sleep(0.5), reboot()?
<pitti> or maybe even just (1); the whole reboot takes long enough that an extra .5 s for your data safety probably doesn't matter
<ogra_> well, adbalready has:
<ogra_> 188         execl("/system/bin/vdc", "/system/bin/vdc", "volume", "unmount",
<ogra_> 189                 getenv("EXTERNAL_STORAGE"), "force", NULL);
<ogra_> which it calls right before rebooting
<ogra_> i guess i can just replace these two lines
<pitti> so you are saying that this doesn't work, or it doesn't apply to our internal storage, or we need to do it for other mounts?
<ogra_> we dont use /system stuff in ubuntu indeed :)
<ogra_> nor do we use vdc ...
<ogra_> that code is a no-op currently
<pitti> aah
<ogra_> but in adbd it is executed right before the reboot call to the kernel
<pitti> ogra_: so yeah, sounds good
<pitti> I'd still give it a second to actually sync and remount
<ogra_> so for our usecase just writing to proc instead sounds good
<ogra_> yeah, i can add a sleep
<ogra_> that will still be miles better than using upstarts reboot though :)
<pitti> right, I didn't even realize that adb reboot didn't use the "proper" reboot
<pitti> it takes long enough, after all (some 5 s here)
<pitti> and I use it all the time
<ogra_> pitti, hah, i gues you never used a normal reboot then ... thats more in the area of 20s
<pitti> ogra_: well, I did (long-press power button)
<pitti> but I didn't really pay enough attention to wonder about the time difference
<pitti> ogra_: but these days most of what I do with the phone is to test/fix adt-run :)
<ogra_> it is quite significant ... i always prefer adb reboot
<ogra_> if i do work on the phone at least
<pitti> ogra_: so, thanks for fixing that!
<ogra_> well, thanks for getting me on the righ track !!
<ogra_> (i wouldnt have thought about sysreq ever)
<pitti> smoser: ok, SRU for bug 1391354 uploaded (it's fine in vivid)
<ubottu> bug 1391354 in systemd (Ubuntu Utopic) "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,In progress] https://launchpad.net/bugs/1391354
<mterry> wgrant, heyo -- I have a bzrlib script that I would ideally like to run even faster -- it's intent is to delete invalid tags.  http://paste.ubuntu.com/8987882/  Is there a cleverer way to do this?  (Or can you point me at someone else that would know?)
<Laibsch> cjwatson, xnox: what about the possibility not to have to attend the IRC meeting?  one of you mentioned a mail interview process?!
<xnox> Laibsch: yeah, in the application submission email you should state that you cannot attend either irc meeting times and wich to be processed via email.
<wgrant> mterry: I don't know bzrlib well at all, but I'd look for a bulk revision-id lookup method.
<Laibsch> well, I might be able to attend but I don't want another night session.  Even 1500 UTC is 23:00 here or even 00:00 if I am in Tokyo at the time and if it takes two hours like it did last time then I don't want that
<xnox> mterry: well that script is fast if the branch you point it at is local, rather than remote.
<xnox> mterry: so i'd clone it to a temp location first, find all tags to delete, and then delete them from target.
<xnox> it's equivalent of $ bzr tags | grep ? | cut -d\  -f1 | xargs -L1 bzr tag --delete
<mterry> xnox, yeah that might be the best solution, I was hoping to do a nice bzrlib thing
<mterry> xnox, but shell always wins  :)
<Saviq> mterry, check out http://people.canonical.com/~mwh/bzrlibapi/bzrlib.repository.Repository.html#all_revision_ids
<Saviq> xnox, that was the first thing we were doing, and it was _slow_ ;)
<mterry> Saviq, oh really?
<mterry> Saviq, just two bzr requests, I would expect it to be better
<Saviq> mterry, one request per tag, no?
<Saviq> mterry, `bzr tag --delete` does not seem to allow multiple tags (at least per man)
<Laibsch> xnox: I basically left my old application page from 2010 as is and only added a paragraph to the top explaining why I did so.  https://wiki.ubuntu.com/RolfLeggewie What are the next steps? Send e-mail to devel-permissions@lists.ubuntu.com and request for becoming a PPU dev?
<caribou_> when merging a package from Debian closes outstanding Ubuntu bugs, should those be listed in the changelog ?
<Laibsch> caribou_: You can add "LP: #123" in the changelog
<ubottu> Launchpad bug 123 in Launchpad itself "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123
<Laibsch> similar to "Closes: #123"
<caribou_> Laibsch: yeah, that's what I meant
<caribou_> Laibsch: I know that, I just want to know if this is part of a normal merge activity
<Laibsch> closes is for the Debian BTS, LP: for Launchpad
<Laibsch> oh, you are wondering if you need to leave the changelog intact?
<Laibsch> I'm not sure I understand the question
<Saviq> mterry, yeah, looks like pulling all_revision_ids() and matching to tags would be faster
<caribou_> Laibsch: when updating the changelog during a merge to the development version and the merge brings in patch from debian that fix existing bugs,should the changelog flag those bugs with (LP: #{bugno})
<xnox> caribou_: add lp: #N reference in the debian/changelog, upload to debian, the rest will happen.
<caribou> I would say I should, just need confirmation
<xnox> caribou: you can add lp:#N references, if you can, during merge/before uploads.
<caribou> xnox: "upload to debian" I suppose upload to ubuntu
<Laibsch> xnox: I believe he wants to know if he should fiddle with the changelog when the debian maintainer forgot to flag the LP bug
<xnox> caribou: otherwise you will need to close bugs yourself.
<xnox> caribou: don't modify other entries, just your own.
<caribou> Laibsch: nope, I'm merging a package from debian into Ubuntu Vivid
<caribou> xnox: indeed
<xnox> caribou: e.g. "* merge from debian, remaining changes:
<xnox>  * foo bar
<caribou> xnox: I meant in the section I'm adding following the merge
<xnox>  * Changes in debian fix LP: #1, LP: #2
<caribou> xnox: ok, that's what I wanted confirmed
<xnox> caribou: yeah.
<Laibsch> xnox: I basically left my old application page from 2010 as is and only added a paragraph to the top explaining why I did so.  https://wiki.ubuntu.com/RolfLeggewie What are the next steps? Send e-mail to devel-permissions@lists.ubuntu.com and request for becoming a PPU dev?
<Saviq> mterry, you there? connection issues it seems?
<Saviq> mterry, if you didn't get it, there's a branch.repository.all_revision_ids()
<Saviq> that can be matched against tags
<mterry> Saviq, yeah I found that, am working on revision (got sidetracked by a wizard issue)
<mterry> Saviq, thanks
<Saviq> mterry, no pressure, just wasn't sure you got the msg
<mterry> Saviq, I hadn't
<mterry> Saviq, I am having dumb irc problems indeed  :(
<mterry> Saviq, tell me if this is faster: http://paste.ubuntu.com/8988295/
<mterry> still seems slightly slow to me, but I think that's just my connection today
<mterry> locally is very fast
<Saviq> mterry, http://pastebin.ubuntu.com/8988345/
<Saviq> it's very slightly slower than the original one with hardcoded list
<Saviq> mterry, so it's great
<mterry> Saviq, heh
<mterry> Saviq, well once we feel comfortable with this, please replace your copy of the script in chinstrap
<Saviq> mterry, yup I will
<Saviq> mterry, I'll just add some logging and display for when you can't write to the branch
<Saviq> mhall119, hmm... how is it that sessions that were supposed to start at 1400 UTC are already finishedÂ¿?
<infinity> Saviq: Because it's 15:24?
<infinity> Saviq: 'date --utc' is your friend. :)
<Saviq> infinity, d'oh, I'm +1 now, not +2 ;)
<Saviq> damn DST
<Laibsch1> I had in the past always been able to simply swap out my HD, put it into a different computer and boot my old system from it.  This seems no longer to be the case.  what do I need to now?
<mhall119> Saviq: lol
<Laibsch> oops, wrong channel
<pitti> doko: FYI, regresssion in https://jenkins.qa.ubuntu.com/job/vivid-adt-python3.4/7/; (test.test_pyexpat.HandlerExceptionTest)
<pitti> it was auto-synced, so no mail notification to you specifically
<doko> pitti, succeeds on the buildd, and currently I can't see anything network specific
<pitti> doko: no, indeed; test.test_pyexpat.HandlerExceptionTest doesn't sound network specific at all, neither does "RuntimeError: a"
<pitti> smoser, infinity: btw, now would be a good time to reboot the wolfe host, or the remaining VMs (I suppose if I just reboot them from "within", they won't get teh changed qemu RAM config)
 * pitti slips in a quick dist-upgrade
<smoser> pitti, you rock.
<smoser> thank you.
<smoser> oh. i meant thank you for the help on that iscsi issue.
<smoser> pitti, i'm sorry, wrt wolfe, what do you need ?
#ubuntu-devel 2014-11-14
<pitti> Good morning
<pitti> smoser: infinity reconfigured the VMs to use 4 GB of RAM, to avoid over-committing (that wreaked havoc, as VMs encountered kernel paging errors)
<pitti> smoser: three VM qemus still need to be restarted; it's not urgent any more as the total RAM is now sufficient, but I understood he wanted to do it at some point
<pitti> smoser: we couldn't do it on Tuesday with a build queue of 500 items or so (glibc + qt), but now things are quiet
<doko> jamespage, maven main alarm
<LocutusOfBorg1> pitti, simple question: will vivid have systemd by default? I don't see online anything related ATM
<seb128> LocutusOfBorg1, http://summit.ubuntu.com/uos-1411/meeting/22401/systemd-transition/
<seb128> UOS session today
<LocutusOfBorg1> wow thanks!
<LocutusOfBorg1> seb128, quick question
<LocutusOfBorg1> vivid universe package universe/net/boinc-client requires systemd migration (sysv=True, upstart=False, systemd=False)
<LocutusOfBorg1> if you sync it from experimental you fix the issue :)
<seb128> LocutusOfBorg1, depending strictly on systemd before it's default seems buggy
<seb128> or do you mean the experimental version resolves that?
<seb128> what's the question exactly? ;-)
<LocutusOfBorg1> yep, I added the service file in the experimental upload
<LocutusOfBorg1> I was lookit at the blueprint link See: http://people.canonical.com/~jhunt/systemd/packages-to-convert/ (updated daily).
<LocutusOfBorg1> since I do not want to spare anybody's time I already did the file and uploaded on experimental
<seb128> LocutusOfBorg1, why not unstable?
<LocutusOfBorg1> freeze :/
<seb128> isn't 'make it work with the default init system' a value reason to get a freeze exception?
<LocutusOfBorg1> don't know :)
<LocutusOfBorg1> asking now on release channel
<seb128> thanks
<LocutusOfBorg1> <jcristau> it very much isn't.
<seb128> k
<LocutusOfBorg1> I can upload anyway, and revert if an RC steps up
<LocutusOfBorg1> it is not a major release
<pitti> LocutusOfBorg1: right, aiming for it, but it depends on getting more hands on porting upstart-only packages (still ~ 200 to go )
<LocutusOfBorg1> pitti, I understand, systemd handles the systemV scripts, but not the upstart ones?
<LocutusOfBorg1> what about patching systemd then? :)
<pitti> LocutusOfBorg1: to do what? :-)
<LocutusOfBorg1> to avoid porting creating 200 service files prior to vivid release :)
<LocutusOfBorg1> it will give us a "smoother" transition
<LocutusOfBorg1> but maybe most of that 200 packages just needs to be sync'd over from debian I guess
<pitti> LocutusOfBorg1: well, there was an alternative proposal to run upstart alongside systemd
<pitti> but nobody looked at that
<LocutusOfBorg1> I guess you will avoid that ;)
<pitti> LocutusOfBorg1: nope; those 200 are mostly the ones where we have heavy ubuntu development/deltas; mostly in the cloud/server/touch space
<LocutusOfBorg1> oh... ok
<pitti> LocutusOfBorg1: conceptually upstart and systemd are so far apart that it's pretty much impossible to "just run" upstart jobs by systemd
<LocutusOfBorg1> anyway creating a .service file is something easy for a person with enough knowledge I guess, I never saw a service file more than 20 lines
<LocutusOfBorg1> long
<pitti> right, every individual one isn't hard, it's just cumulatively hard due to sheer number
<LocutusOfBorg1> anyway, I guess you know what to do, who am I? :)
<LocutusOfBorg1> yes of course, 200 is an high number
<LocutusOfBorg1> I guess I'll try to help a little bit, but I'm really not a systemd person (at least not now)
<pitti> so if you want to help out with submitting missing systemd units (or even just init.d scripts), that'd be greatly appreciated
<LocutusOfBorg1> you mean vivid/main packages right? I see 191 left
<LocutusOfBorg1> grub-common seems a false-positive, hostname might just need a sync/revert, ifupdown needs a little merge?
<LocutusOfBorg1> oh... many of them seems to be sysv=True, so grep "sysv=False" |wc -l returns just 106 entries
<LocutusOfBorg1> I hope I'm on the right list http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-13.txt
<pitti> right
<pitti> jodh_: ^ I think we should really start with that -- if a package has an init.d script, it's fine for now
<pitti> then it doesn't block the switch and thus shoudln't be part of the transition
<LocutusOfBorg1> yep, 106 seems a better number :)
<LocutusOfBorg1> and of the 106 many are still false positive, like "upstart*"
<LocutusOfBorg1> or "systemd*"
<LocutusOfBorg1> I guess you need to start with sysv=False && systemd=False
<LocutusOfBorg1> grep "sysv=False" |grep "systemd=False" |wc -l
<LocutusOfBorg1> 91
<LocutusOfBorg1> even better
<LocutusOfBorg1> Laney, how do you feel about this patch for the transparency problem of gnome.-terminal? https://bug695371.bugzilla-attachments.gnome.org/attachment.cgi?id=274727
<LocutusOfBorg1> bug 1292282
<ubottu> bug 1292282 in gnome-terminal (Ubuntu) "background transparency is not working on gnome terminal" [Low,Confirmed] https://launchpad.net/bugs/1292282
<Laney> LocutusOfBorg1: what transparency problem?
<Laney> -> #ubuntu-desktop maybe
<LocutusOfBorg1> well yes
<cjwatson> LocutusOfBorg1: grub-common isn't entirely a false positive, I just haven't yet worked out how to do that "run as late as possible to approximate the system being fully booted" thing in systemd
<cjwatson> It's not urgent though, as the sysv file should do the job for the time being
<LocutusOfBorg1> cjwatson, I meant "also a debian issue" :)
<cjwatson> Sure
<cjwatson> bdmurray,ev,pitti: ubuntu-rtm has Contents now, would be good to confirm that retraces can now work
<pitti> cjwatson: hooray, thanks!
<pitti> barry: FYI, autopkgtest 3.8 is now in vivid, that also contains the funny apt fix
<jamespage> doko, ack
<jamespage> doko, not much time today but will look as soon as I can
<barry> pitti: awesome, thanks
<smoser> pitti, stgraber i've rebooted host on wolfe
<smoser> and restarted your instances there.
<pitti> smoser: ack, thanks
<stgraber> smoser: thanks
<stgraber> smoser: is it just my imagination or did we get a memory downgrade in those VMs?
<pitti> might be that infinity reconfigured your's as well
<pitti> the intention (from my POV) was to just reduce mem from 8 to 4 GB for wolfe-02 to -09 (the autopkgtest ones)
<stgraber> yeah, looks like we got downgraded from 8GB to 4GB, which may be a slight problem for us since we run all our builds in tmpfs as I/Os were horribly slow on there (10min on tmpfs vs 1h30 on disk last time I tested)
<pitti> stgraber: I think the wolfe host now has enough RAM left to run your's with 8
<pitti> rebooting the autopkgtset ones free'ed 12 GB, and we were under the "64 GB total" line before
<infinity> stgraber: What are you building that has such awful I/O characteristics?
<stgraber> infinity: tons of debootstraps
<infinity> stgraber: In theory, wolfe should be no different than denneed, fisher, and postal, and they perform quite well.
<stgraber> usually 3-4 of those in parallel
<infinity> stgraber: Ask smoser to start your guests with cache=unsafe
<infinity> stgraber: Then watch 'em fly.
<stgraber> infinity: yeah, cache=unsafe on the data volume would probably help quite a bit
<pitti> infinity: do they all need to have the same size?
<pitti> infinity: because we certainly do have the RAM now
<infinity> pitti: No, they don't have to be.  He can certainly have bigger ones.
<infinity> pitti: But "I like building in tmpfs" is also a lousy reason to eat all the RAM. ;)
<pitti> well, who doesn't :)
<infinity> Exactly.
 * pitti builds nowhere else at home
<pitti> also, if we can get the same cache=unsafe hack on "my" wolfes, I wouldn't complain loudly either (and it might even be easier as all VMs use the same config)
<stgraber> infinity: well, my concern was that our testsuite and image building scripts do a ton of IOPs so tmpfs obviously make things faster for us and also means we don't hammer the disks for everyone else on the box
<stgraber> but cache=unsafe may very well do that too just at a different layer :)
<pitti> can you just swap the stickers on the motherboard, so that we have 1 TB RAM and 64 GB disk? should be enough to fit the VM images :)
<pitti> (TGIF!)
<infinity> As long as no one cares about losing the occasional syslog or whatever, cache=unsafe isn't really all that unsafe on a VM where the base system doesn't change much.
<pitti> for my VMs, I don't care at all; if they break, I run my magic script to set up a fresh one
<infinity> (Okay, it's horribly unsafe, but if you don't like your data...)
 * pitti likes "fast" better than "safe" in this case
<stgraber> infinity: well, that's why we've got two disks on those VMs right? I sure don't want to loose data on the main volume, but the data volume I don't care about
<stgraber> so setting cache=unsafe for /dev/vdb would be perfectly fine
<infinity> stgraber: Do you have a host I can kill and restart to test this?
<infinity> s/host/guest/
<infinity> stgraber: I hacked up smoser's guest-start script to start the ephemeral image with cache=unsafe, want to test that I did it right. :P
<caribou> arges: here are the debs : http://people.canonical.com/~lbouchard/makedumpfile-1.5.7-3/
<infinity> pitti: Or if you have one I can kill.
<infinity> pitti: (And are you using the same root/data split?)
<infinity> Looks like you probably are.
<pitti> infinity: kill 07 or 08 (or both)
<pitti> infinity: yes, I mount /dev/sdb1 as /data
<pitti> which has the containers and logs
<pitti> but as I said, nothing on these machines is precious
<stgraber> infinity: you can kill 01. Just make sure that only sdb is affected, sda pretty much never changes and is a pain to setup so I'd like that one to be properly saved to disk :)
<infinity> That looks like it worked (for wolfe-08)
<infinity> stgraber: Want to halt 01 for me, or shall I just kill it?
<infinity> pitti: Check wolfe-08 seems happy, that's the one I twiddled.
<stgraber> infinity: shutting down now
<pitti> infinity: yep, already at it
<infinity> If this hack makes you guys happy, it's a simple diff to scott's guest-start that just applies cache=unsafe to all eph* images.
<infinity> stgraber: 01 should be back.
<infinity> smoser: http://paste.ubuntu.com/9007931/
<infinity> smoser: That's what I applied to wolfe.
<infinity> stgraber: If that's not responsive enough for you, we can give you more RAM too, but I suspect that should be pretty decent.
<pitti> infinity: doesn't really feel faster to me (doing another lxc-create), but at least it seems to work
<infinity> Well, I suppose it's also possible cache=unsafe is a noop for non-virtio...
<infinity> I have no idea.
<pitti> eek, this isn't virtio?
<infinity> qemu and I, we're not best buddies.
<infinity> pitti: No.  virtio is buggy as heck on !x86.
<infinity> pitti: This is ibm-vscsi, which is pretty performant, in my testing.
<stgraber> root@wolfe-01:/var/lib/lxc# dd if=/dev/zero of=blah.img conv=fsync bs=4M count=1000
<stgraber> 1000+0 records in
<infinity> But a bunch of VMs all contending for the same disk will hurt any I/O subsystem.
<stgraber> 1000+0 records out
<stgraber> now to test with a real load
<stgraber> 4194304000 bytes (4.2 GB) copied, 3.09727 s, 1.4 GB/s
<infinity> stgraber: Well, the real test is if unsafe is doing as advertised, and not passing syncs down to the host.
<infinity> stgraber: Since that's the slow down for debootstrap/dpkg.
<stgraber> infinity: still get 1.5GB/s with conv=sync so it looks like it's ignoring syncs as expected
<stgraber> the fs is also mounted with data=writeback for good measure too :)
<pitti> I'm running lxc-create under eatmydata, add force-unsafe-io to dpkg, but it still sucks :/ (there is a looong time during debootstrap when eatmydata isn't active)
<stgraber> pitti: you could use the download template, that'd at least make that part faster
<pitti> stgraber: I tried that a while ago, and there was some reason why it wasn't practical, but I forgot; probably firewalled or so
<stgraber> root@wolfe-01:/var/lib/lxc# grep proxy /etc/environment
<stgraber> http_proxy=http://squid.internal:3128
<stgraber> https_proxy=http://squid.internal:3128
<stgraber> then it works fine
<stgraber> it may also have been that back then there were no ppc64el images
<pitti> ah
<pitti> stgraber: or that
<pitti> hm, jenkins-slave fails to start now, WTH
<stgraber> infinity: test build was about as fast as on tmpfs, so I'm fine with sticking to that
<infinity> stgraber: \o/
<infinity> stgraber: Did you have two guests that needed this treatment, or just that one?
<stgraber> I just have the one
<infinity> Kay, cool.
 * infinity logs out of wolfe and wanders off.
<stgraber> 16min vs 14min and since that's still about 4x as faster than our armhf builder, we're good :)
<stgraber> with the previous I/O performances I was getting on wolfe, it was slower than my armhf devboard (which arguably does SATA-3 and uses a SSD) which seemed a bit ridiculous :)
<infinity> stgraber: Yeah, I imagine that was just insane I/O contention with every guest on there syncing like crazy.
<infinity> stgraber: Since the machine has 9 guests, all of whom pretty much just run dpkg a whole lot.
<infinity> stgraber: And qemu/kvm performs very poorly in that scenario with default settings.
<stgraber> clearly
<infinity> stgraber: The only thing to watch out for with cache=unsafe is that it really is very unsafe.  A poorly-timed crash could mean that filesystem needs reformatting on reboot.
<stgraber> which is fine because that's what I do at every reboot anyway :)
<infinity> Handy.
<stgraber> I never want crap sticking around in /var/lib/lxc
<dpm> willcooke, slangasek, shadeslayer, who is doing the developer track summary?
<dpm> i.e. the presentation at the end
<willcooke> I guess me
<dpm> cool, thanks willcooke
<dpm> gaughen, and I guess you're presenting the summary for the cloud track?
<gaughen> dpm, well actually I have a conflict. trying to see if i can re-arrange it.
<gaughen> it's with a partner
<dpm> gaughen, thanks. Otherwise, perhaps another cloud track lead can do it? Just let us know
<pitti> jodh_: ah, thanks for updating the systemd conversion lists!
<jodh_> pitti: np - scripts are here fwiw: http://people.canonical.com/~jhunt/systemd/scripts/
<pitti> wgrant: can we move the langpack schedule to produce RTM langpack exports on Tuesday evening or Wednesday early morning?
<pitti> ogra_: ^ so when exactly do you want the new packs in RTM? then we can calculate back from that
<pitti> about 1.5 h to prepare the sources, upload them, have them build, and propagate through -proposed, and about 6 hours for the export, plus two hours safety margin
<ogra_> pitti, as per https://wiki.ubuntu.com/LandingTeam/MilestoneSchedule we are freezing wed. morning (EU time) now ...
<pitti> ogra_: does the freeze include the langpacks, or you want to freeze, then export/upload langpacks, to catch the last string changes before freeze?
<ogra_> pitti, well, we freeze to be able to do image rebuilds for single fixes ... would eb good if everything langpack realted would be in place when the freeze starts so it doesnt taint tested images that get re-rolled
<pitti> sure
<pitti> wgrant: so could we kick off RTM exports around Tue 21:00 UTC? then I'd build packs around Wed 05:00 UTC, and we would be ready to build images around 07:00 UTC
<pitti> ogra_: ^ does that fit?
<ogra_> that sounds good, yeah
<pitti> ack; I'll adjust the cronjobs as soon as I get wgrant's ok
<jodh_> pitti, slangasek: just fixed and re-run http://people.canonical.com/~jhunt/systemd/scripts/ - outstanding main packages to convert figure is now 77.
<slangasek> jodh_: neato, thanks
<pitti> wgrant: if that collides with some other exports, I'm happy to move the other stuff around too
<pitti> jodh_: yay; can you fix it some more? :-)
<slangasek> jodh_: btw, do we know if any of these are packages that just require no-change rebuilds with current debhelper?
<pitti> jodh_: ah, and there's things like "upstart" and "mountall" which don't need conversion
<slangasek> you mean I don't get to write a mountall systemd unit?
<pitti> jodh_: could this grow a "known false positive" blacklist?
<jodh_> slangasek: no - it's a very crude script atm :)
<jodh_> slangasek: ... like it even shows that upstart and upstart-bin needs conversion so atleast a few false-positives there :)
<slangasek> sure
<pitti> or ureadahead
<slangasek> jodh_: oh, and there's no separation of user session jobs vs. system jobs
<pitti> or hostname
<slangasek> (indicator-*)
<jodh_> pitti: yes, it need to.
<jodh_> slangasek: right. still some whittling to do.
<slangasek> jodh_: thanks for making this script!  Let us tell you everything that's wrong with it
<pitti> oh right, all the indicator bits are session upstart
<slangasek> ;)
<jodh_> slangasek: yeah, I should be asking you for patches :)
<pitti> which is kind of fair, as we need to vet them for signals
<pitti> jodh_: is that based on xnox's scripts? ISTR that they spat out quite a bit more
 * pitti waves good night
<pitti> /qui/quit
<pitti> ok, let's try that again :)
<jodh_> pitti: no - it's a rewrite in python that uses a local mirror for speed. It's now here: https://code.launchpad.net/~ubuntu-foundations-team/+junk/migration-to-systemd
<dannf> i'm looking at a vnc4 upload, rebasing on debian to pull in arm64 support. i noticed that, though it has been rebased since, it is retaining some old ubuntu changelog (<= hardy): http://paste.ubuntu.com/9014774/
<dannf> should i follow suit and keep the recent ubuntu entries, or just add a Merge, Remaining changes: entry to the top?
#ubuntu-devel 2014-11-15
<Logan_> dannf: when you merge from Debian, you should be retaining all the other changelog entries that were specific to Ubuntu
<Logan_> how are you performing this merge?
<dannf> Logan_: ack. i'm taking a debdiff between the debian/ubuntu versions and rebasing it on top of the newer debian version
<Logan_> ah, have you tried using bzr or grab-merge to merge packages?
<dannf> Logan_: i've used bzr in the past, when an existing non-udd branch is there, i haven't used grab-merge before
 * dannf hadn't read https://wiki.ubuntu.com/UbuntuDevelopment/Merging yet - looks like it's covered there, will take a look when i get back at it
<dannf> thx - just needed to know what to google for apparently :)
<Logan_> dannf: you got it :)
<Logan_> tjaalton: can we sync freeipa from unstable?
<ScottK> pitti: You appear to be TIL for lvm2.  It would be nice to get it merged from Debian since I see at least one package depwaiting for the newer version.
<wgrant> sa
<wgrant> bah
<wgrant> pitti: I'll work out how to fit that into the schedule on Monday.
<tjaalton> Logan_: no
<tjaalton> Logan_: it needs some work because we don't use systemd yet
<tjaalton> and I haven't had time to test it
<Logan_> tjaalton: kk
<tjaalton> thanks for asking btw ;)
<brainwash> xnox: hey, I remember that you did some debugging on bug 1375893
<ubottu> bug 1375893 in ubiquity (Ubuntu) "Black background to Try/Install Dialogue" [High,Confirmed] https://launchpad.net/bugs/1375893
<brainwash> but you did not add a comment to the report
<brainwash> so, we still do not know what's exactly broken. one workaround for this problem is to use feh (like mentioned by bluesabre in the comments)
<bluesabre> brainwash: we know what is broken... xfdesktop dies for some reason
<brainwash> bluesabre: ok, the report does not reflect the current bug status/progress
<bluesabre> I'll add a comment, though we are no closer to fixing it
<brainwash> bluesabre: wouldn't it be easier to use a simple app like feh to do the job?
<brainwash> there is no need to load the "bloated" xfdesktop I think
<bluesabre> yeah, it'd be easier, but it would be better to fix xfdesktop
<brainwash> true, the crash needs to be fixed
<bluesabre> will try to get to the bottom of it this cycle
#ubuntu-devel 2014-11-16
<Laibsch> cjwatson, xnox: I guess you've seen my application for PPU?  I haven't heard a thing about it since.  Is everything on track?
<hjd> wgrant: Hi :) I see you're listed as the contact person of http://qa.ubuntuwire.com/multidistrotools/. Are there any plans to update that to compare Sid and Vivid?
<ihusa> hello everyone, in order not to ask to ask, just asking for help on how to estimate my project's development cost and time..I have written down all that needs to be done.
<bdmurray> doko: have you had a chance to look at bug 1363785 yet?
<ubottu> bug 1363785 in icedtea-web (Ubuntu Utopic) "package icedtea-netx:amd64 1.5.1-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [High,Triaged] https://launchpad.net/bugs/1363785
#ubuntu-devel 2015-11-09
<dupingping> hi, developers, please look here, https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1514288
<ubottu> Launchpad bug 1514288 in gnome-terminal (Ubuntu) "Japanese Character Encoding Bug" [Undecided,New]
<dholbach> good morning
<Odd_Bloke> infinity: I now have access to 1SS, so I'm ready for you to give me somewhere to play with powerpc cloud images. :)
<dupingping> https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1514288
<ubottu> Launchpad bug 1514288 in gnome-terminal (Ubuntu) "Japanese Character Encoding Bug" [Undecided,New]
<LocutusOfBorg1> mdeslaur, how do you feel about a sync of tar?
<LocutusOfBorg1> after dinstall of course
<alex__> hello what is the right irc channel to ask about building unity?
<brendand> alex__, here is fine
<brendand> alex__, but ask your question in as much detail as possible rather than asking to ask
<brendand> alex__, like 'i get this <pastebin> failure when building unity from lp:unity on <distro>'
<alex__> ok thanks. I have to build some parts of unity because we in gnustep are working to integrate gnustep apps as better as we can. So with this command "make panel"  the panel got compilet but at launch time I got
<alex__> ERROR 2015-11-09 12:15:44 nux.gltexture.resource.manager GLTextureResourceManager.cpp:54 Invalid target, impossible to generate a new texture. Impossible to generate a pixbuf: Failed to open file '/home/alex/test_unity/share/unity/icons/dash_noise.png': File o directory not found and similar errors
<alex__> also, how to install compiled stuff in a customized directory? following the HACKING file seems to not work
<alex__> -- Up-to-date: /home/alex/test_unity/share/locale/de/LC_MESSAGES/unity.mo
<alex__> -- Installing: /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml
<alex__> CMake Error at cmake_install.cmake:168 (file):
<alex__>   file INSTALL cannot copy file
<alex__>   "/home/alex/Scaricati/unity-7.3.3/com.canonical.Unity.gschema.xml" to
<alex__>   "/usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml".
<alex__> The distro is Uubntu 15.10 and I'm using the released source code of unity 7.3.3, the tarball on launchpad
<brendand> alex__, you did 'mkdir build; cd build; CMAKE -DCMAKE_INSTALL_PREFIX=~/staging ../'?
<alex__> yes, but insread of staging I used test_unity
<brendand> bleurgh, and cmake should be lowercase
<alex__> and yes I used a lowercase cmake command
<brendand> alex__, what gave you the error? make or cmake?
<brendand> alex__, did you do apt-get build-dep unity?
<alex__> yes to build-dep, I don't have error while buidling panel, but running it. The build has success
<alex__> brendand, this is the command I run cmake -DCMAKE_INSTALL_PREFIX=~/test_unity ../
<alex__> then, make -j8 has success
<alex__> make -j8 panel sorry
<alex__> brendand, just rebuilt
<alex__> Linking CXX static library libunity-shared-standalone.a
<alex__> [100%] Built target unity-shared-standalone
<alex__> Linking CXX static library libpanel-lib.a
<alex__> [100%] Built target panel-lib
<alex__> Linking CXX static library libunity-shared-bamf.a
<alex__> [100%] Built target unity-shared-bamf
<alex__> Scanning dependencies of target panel
<alex__> [100%] Building CXX object panel/CMakeFiles/panel.dir/StandalonePanel.cpp.o
<alex__> Linking CXX executable panel
<alex__> [100%] Built target panel
<alex__> no errors, but if I try to run it... I got the previous errors
<brendand> alex__, i would doubt that building part of it will work
<brendand> alex__, you would have to build it all, then make panel would work to rebuild just the panel bits if that's all you changed
<alex__> brendand, ah ok, so it works in this way, understoo. I go to rebuild all
<sladen> directhex: ta
<directhex> hm?
<alex__> brendand, ok Ibuilt every think and succesfully. Now I want to install everything in my customized directory
<brendand> alex_ - make install should work?
<mdeslaur> LocutusOfBorg1: how do I feel about a sync that would revert the ftbfs fix? Is that what you're asking me?
<nikow> .win 21
<nikow> woops, sorry
<Slex1> seems I lost the xchat window. I should not use anymore xchat. I was alex__
<alex__> brendand, I hope
<alex__> brendand, it fails here:
<alex__> CMake Error at cmake_install.cmake:168 (file):
<alex__>   file INSTALL cannot copy file
<alex__>   "/home/alex/Scaricati/unity-7.3.3/com.canonical.Unity.gschema.xml" to
<alex__>   "/usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml".
<alex__> I think the reason is that it wants root permission. Why it don't install that .xm file in my custom dir?
<alex__> xml*
<directhex> sladen: don't thank me yet, i have Plans(tm) for OpenBVE. evil plans
<Slex1> time to go, woth both account Slex and alex__ see you soon and thanks dor the help
<mdeslaur> LocutusOfBorg1: oh! I see the -2.1 version now. Sure, sync it.
<LocutusOfBorg1> exactly mdeslaur :)
<mdeslaur> LocutusOfBorg1: I need to wait until I've had more coffee before responding to people in the morning :P
<LocutusOfBorg1> me too :)
<utlemming> pitti: did the behavior of "nofail" in /etc/fstab change with 15.10?
<utlemming> pitti: I'm seeing an issue where "nofail" file systems that fail to mount on boot is resulting in a system going into emergency mode instead of continuing to boot. On 15.04 the option results in the system continuing to boot.
<mbiebl> utlemming: can you pastebin the output of systemctl status foo.mount and systemctl show foo.mount
<utlemming> mbiebl: sure
<utlemming> mbiebl: http://paste.ubuntu.com/13209036/
<mbiebl> utlemming: hm, that's not what I asked for
<mbiebl> can you run systemctl status and show for the failed mnt.mount unit?
<utlemming> mbiebl: oh, sorry...let me see if I can get to a system. This a remote headless system in the cloud.
<mbiebl> utlemming: oh, and sharing your /etc/fstab would help as well
<utlemming> mbiebl: http://paste.ubuntu.com/13209069/
<mbiebl> utlemming: ah
<mbiebl> nobootwait != nofail
<mbiebl> I think that Ubuntu specific fallback has been removed
<utlemming> mbiebl: oh, really? you wouldn't happen to have the bug/commit where that change happened?
<mbiebl> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=8fbf6c7e671c663190eae8a63b158e686c3d41fa
<mbiebl> utlemming: so either the migration code is buggy or you added the fstab entry using nobootwait *after* the upgrade
<utlemming> mbiebl: the nobootwait was added by cloud-init at first boot. Then the system snapshoted and launched as a new instance.
<utlemming> mbiebl: no upgrade, wily native
<utlemming> mbiebl: it works just fine with 15.04
<nemo> So, I ran into a very confusing launchpad issue when trying to figure out the vmware-view smartcard authentication using vmware-view-open-client 4.5 package
<nemo> https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770
<ubottu> Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,New]
<nemo> it was filed almost 2 years ago, and suggested a rather convoluted fix
<mbiebl> utlemming: please file a bug against cloud-init!
<utlemming> mbiebl: ack...should it be using nofail then?
<nemo> both (a) and (b) seem to boil down to "custom build of OpenSC"
<mbiebl> utlemming: yeah
<utlemming> mbiebl: thanks, will do
<nemo> anyway. looks like vmware view open client is broken in ubuntu packaging - at least for smartcard auth, which is an increasingly common use-case (and non-optional here)
<nemo> gonna try that custom opensc build, but was hoping maybe there was some magic PPA or something âº
<pgquiles> does ubuntu/canonical provide any facility to store specialized ubuntu flavors?
<pgquiles> translated into something meaningful: I've created an ISO of Wily with better support for Bay Trail-based computers and I cannot host 1.2 GB on my server without my ISP killing me
<pgquiles> (new drivers, kernel 4.3 with a few patches, etc)
<jpds> Is there a reason you can't use the hardware enablement stack?
<jpds> pgquiles: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<pgquiles> jpds: multiple reasons: current ubuntu images won't boot on bay trail, so it's a bad start. Also my kernel includes a couple of patches of my own to get the nvram from uefi on broadcom network/bluetooth devices and to fix the clocksource. For the rest, the new drivers are packaged in my PPA.
<pgquiles> none of that is available from the LTS Enablement Stack, which is great otherwise
<cyphermox> pgquiles: I think if booting on bay trail is the only requirement (for example, there aren't different packages you need for this and that aside from bay trail support), then you should ask on ubuntu-devel for an image that has the right kernel and bootloader bits. I'm not sure yet how we'd do to support that though
<cyphermox> what changes are you making to the stock image?
<pgquiles> cyphermox: speaking off the top of my head 32-bit efi loader, kernel 4.3 on wily with a couple of patches for better clock resolution and downloading the nvram in brcmfmac (instead of providing it as a device-specific .txt file), qf9700 driver, rtl8723bs drivers (wifi and bluetooth) and probably something else
<cyphermox> right, so bootloader and kernel
<pgquiles> the 32-bit efi is lp #1341944 and  lp #1025555
<ubottu> Launchpad bug 1341944 in grub2 (Ubuntu) "32-Bit UEFI bootloader support needed" [High,Triaged] https://launchpad.net/bugs/1341944
<ubottu> Launchpad bug 1025555 in Ubuntu CD Images "Ubuntu i386 images (install media) cannot boot in UEFI mode" [Undecided,Won't fix] https://launchpad.net/bugs/1025555
<pgquiles> the drivers are dkms-enabled packages, actually. Problem is if you don't have a network connection (which is what these drivers provide), you cannot install them from a PPA :-|
<pgquiles> cyphermox: oh, also new linux-firmware snapshot from kernel.org and new broadcom-sta proprietary driver (wl.ko)
<cyphermox> pgquiles: I can't really comment on kernel specifics, since I'm not really involved in doing kernel work
<pgquiles> cyphermox: I see. My question was more about hosting the ISO somewhere "decent" instead of using mega or alike.
<cyphermox> sure, but to do that we need to have the right things in the archive already.
<pgquiles> cyphermox: what do you mean? I'm not talking about an official ISO :-?
<smoser> pitti, are you around ?
<smoser> wonder if anyone else can help. i'm looking at open-iscsi and initramfs.
<smoser> in ubuntu, we have for quite some time had https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/728088
<ubottu> Launchpad bug 728088 in open-iscsi (Ubuntu Oneiric) "iscsi root with or without auth fails to boot" [High,Fix released]
<smoser> basically something that stops the network device upon which the iscsi root is attached from getting bounced.
<smoser> but debian doesn't seem to have anything like that.
<smoser> and i'm wondering how that is possible
<josepht> smoser: afaik there's an issue with open-iscsi and systemd
<smoser> in ubuntu ? or in debian
<smoser> also, it looks (this is my first look at it) that there might be a systemd-initramfs path in debian
<josepht> smoser: I was looking at bug 1465196, but haven't made much progress yet
<ubottu> bug 1465196 in open-iscsi (Ubuntu) "open-iscsi init script creates dependency cycle with NetworkManager" [Medium,Triaged] https://launchpad.net/bugs/1465196
<smoser> that must be dracut (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787553)
<ubottu> Debian bug 787553 in systemd "fails to boot with a dracut generated initramfs" [Grave,Fixed]
<smoser> is debian moving away from initramfs-tools and towards dracut ?
<smoser> hm... wondering outloud.
<smoser> should /etc/udev/rules.d/70-persistent-net.rules be in the initramfs ? if ip= is used, and network devicews are kept up (iscsi root) it would seem maybe it should
#ubuntu-devel 2015-11-10
<pitti> utlemming: systemd.postinst translates these old upstart specific options (nobootwait and optional) to the standard "nofail"; please don't use these in new code
<pitti> smoser: /etc/udev/rules.d/70-persistent-net.rules shold be in the initramfs, yes; is it not?
<pitti> Good morning
<Unit193> Howdy, pitti.  Any way you can fix policykit/dbus/systemd such that restarting dbus (or whatever happened) doesn't require a hard reset?
<pitti> Unit193: restarting dbus has never been supported
<pitti> Unit193: everything that connects to it will die, like half of your desktop
<pitti> not related to polkit or dbus, for these in particular restaritng dbus is fine
<Unit193> pitti: I understand this, but something seems to have reset or restarted dbus and the only thing I could do was  reboot -f  to restart it.  Vivid even handled it better than that.
<Unit193> I know lightdm and NM die, that's fine.  systemctl failing on every command is not good, though.
<pitti> Unit193: run systemctl as root
<Unit193> Did.
<pitti> hm, systmed has its own private dbus server, it shold talk to that when dbus is down or not installed; but that might be different if it was restarted
<Unit193> (As in, sudo -i  and sudo systemctl fooo, nothing worked.  As I said, reboot -f was the only thing.)
<pitti> so that might need a systemclt daemon-reexec
<Unit193> I did that.
<pitti> Unit193: ok, that's news to me
<Unit193> pitti: So open to debugging/fixing? :)
<pitti> yes, I guess so :)
<Unit193> Thank you very much!
<pitti> stgraber: once I have an lxd image cached locally, can I do "lxc launch ubuntu/wily/amd64 w1" somehow? (that doesn't work); i. e. like "images:ubuntu/wily/amd64", but using the already cached local copy
<hallyn> pitti: you can add aliases to teh already-downloaded images, yes.  'lxc image list', then 'lxc image alias create x1 <some-sha1>'
<hallyn> then you can just lxc launch x1 c1
<hallyn> pitti: wasn't following previous conv;  you might also be better off using lxd-images.
<pitti> hallyn: ah, is that what's done on https://images.linuxcontainers.org:8443 ?
<pitti> hallyn: I mean, I find it convenient to do this name-based lookup with distro/release/arch instead of having to look up and use UUIDs
<pitti> stgraber, hallyn: lxc/lxd is really nice, many thanks for that!
<hallyn> pitti: right, you're really meant to do 'lxd-images download ubuntu --alias wily wily amd64'
<pitti> it even works for rebooting xenial containers :) (curiously)
<hallyn> orly
<pitti> and the remote feature is nice, we could set up armhf testing in scalingstack with that
<hallyn> the reason i've not been helpful with the reboot problem actualy is that most ofthe time right now if i type 'reboot' nothing happens.  i need to set up a good test vm.  (that and i'm really hoping to finish cgroup namespaces)
<pitti> I guess it's time to add an lxd autopkgtest virt backend :)
<hallyn> that should shake out some interesting bugs
<pitti> hallyn: uh, reboot is broken for you?
<hallyn> yeah, just hangs
<pitti> stgraber: do you plan to add xenial lxd images soon? now that there's no debootstrap any more, we'd need these from pretty much day 1
<stgraber> pitti: lxd-images pulls from cloud images' release stream so we'd need CPC to publish something in that stream (or you can force with --stream daily)
<stgraber> pitti: as for old school images on images.linuxcontainers.org, Jenkins is configured but is failing to produce them due to debootstrap in trusty not knowing about xenial, that should be fixed very soon as there's an SRU in -proposed right now
<pitti> stgraber: oh, interesting; so that'll hopefully be quicker again next cycle when the new-style cloud images have settled down
<pitti> stgraber: SRU of distro-info-data you mean? thanks for the heads-up
<stgraber> yeah, we're trying to standardize on the same images for all cloudy products :)
<pitti> until then this could be emulated by creating a wily container, dist-upgrading it, and importing it as image, right?
<pitti> (pretty much what I do with cloud images too)
<stgraber> pitti: nope, debootstrap itself, for the symlink
<pitti> ah
<stgraber> pitti: yep, that's how I've been dealing with xenial so far, take wily and upgrade :)
<stgraber> actually, let me release it, it's at 6 days now, that's long enough :)
<stgraber> done
<stgraber> and now off to bed :)
<pitti> stgraber: bonne nuit !
<alexlist> wgrant: Is linking against e.g. libboost-program-options1.58 but disabling the CXX 11 ABI something that should work?
<alexlist> wgrant: e.g., on 15.10,  g++ -o main main.cc -lboost_program_options  -D_GLIBCXX_USE_CXX11_ABI=0
<alexlist> Actually that is a question for a larger audience...
<alexlist> https://bugs.launchpad.net/ubuntu/+source/boost1.58/+bug/1514717
<ubottu> Launchpad bug 1514717 in boost1.58 (Ubuntu) "linker error when disabling CXX11_ABI" [Undecided,New]
<wgrant> alexlist: wily's libraries are built with the C++11 ABI; you're not going to have much luck linking objects for another ABI against them.
<alexlist> wgrant: thx, that's what I feared. So essentially if you depend on a closed source 3rdparty library you are in trouble...
<wgrant> Right, proprietary C++ libraries are a bad idea, as the ABI tends to break every few years.
<wgrant> Though GCC is a lot better than MSVC on that front, I suppose.
<dholbach> good morning
<pgquiles_> alexlist: workaround: distribute your own boost and use $ORIGIN in the application
<pitti> mvo: meh, bug 1510060 wasn't magically fixed after all :(
<ubottu> bug 1510060 in apt-clone (Ubuntu) "test regression: TestCloneUpgrade.test_clone_upgrade_synthetic" [High,Triaged] https://launchpad.net/bugs/1510060
<mvo> pitti: its back? meh :(
<seb128> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
 * dholbach hugs seb128
<dholbach> go go go!
<davmor2> dholbach: okay we get it you like golang but seriously you don't need to should about it ;)
<dholbach> shout? :)
<davmor2> dholbach: yeah shout aswell
 * seb128 hugs dholbach back
<mdeslaur> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur, seb128
<seb128> mdeslaur, do you start in a particular order? just to not conflict
<seb128> mdeslaur, hey btw ;-)
<mdeslaur> seb128: nah, no particular order...you?
<seb128> mdeslaur, I was starting from the most recents
<seb128> but I did skip over a few ones and started in the yellow section now
<mdeslaur> seb128: I'll take cups
<seb128> mdeslaur, seems like security related, have fun ;-)
<seb128> mdeslaur, feel to take the dovecot/apparmor one as well
<mdeslaur> ok
<seb128> slangasek, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/sbsigntool/+bug/1511108 ?
<ubottu> Launchpad bug 1511108 in sbsigntool (Ubuntu) "Handle odd buffer lengths in checksum" [Medium,New]
<seb128> jibel, hey, could you get (or do you know who could) https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298 merged?
<matsubara> rbasak, ^
<jibel> seb128, sure, let me find someone
<seb128> jibel, thanks
<seb128> jibel, it's in the sponsoring queue (I guess since Laney's changes) so would be good to get merged
<jibel> seb128, actually matsubara or rbasak can do it, it's a server branch
<seb128> j
<seb128> matsubara, rbasak, ^
<seb128> jibel, thanks
<matsubara> seb128, I don't have permission, that's why I pinged rbasak. He's the one who usually merge in my changes
<seb128> matsubara, k
<mdeslaur> seb128: I'll take the xscreensaver merge
<rbasak> matsubara: otp, please ping again if I forget.
<dgadomski> hey pitti, could you please take a look at debdiffs for bug 1337873
<ubottu> bug 1337873 in ifupdown (Ubuntu) "Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition" [Medium,In progress] https://launchpad.net/bugs/1337873
<elijah> https://insights.ubuntu.com/2013/02/15/developers-get-the-full-support-they-need/ says there is an #ubuntu-phone but when I try to join it says I need an invitation.
<elijah> Anyone know when this will be open?
<Laney> Is it meant to be #ubuntu-touch?
<Laney> dpm: ^?
<brendand> elijah, that's quite an old blog post, #ubuntu-touch exists
<dpm> I thought someone had set up a redirect a long time ago
<dpm> popey, ? ^^
<Laney> presumably the blog post could be edited anyway
<dpm> let's see who else gets pinged in the chain :-)
<elijah> Okay, so #ubuntu-touch is the official channel?
<brendand> elijah, but if you're an app developer there is a full channel just for you - #ubuntu-app-devel
<popey> yes
<popey> will get the redirect fixed
<brendand> popey, but ubuntu-app-devel is more appropriate for application developers
<brendand> popey, as i'm sure you'd agree
<popey> (I know)
<elijah> #ubuntu-touch has a much larger user list
<elijah> I am in both though
<elijah> I am getting ready to ditch Android, just trying to get started
<elijah> Will ubuntu-touch and ubuntu-app-devel eventually become one channel?
<elijah> I thought we are moving towards unified apps
<slangasek> seb128: yep, it's in my queue
<seb128> slangasek, thanks
<pitti> dgadomski: you are already reviewing this with Guus, no? I'm not familiar with the ifupdown code and this is rather intrusive
<pitti> dgadomski: i. e. could we get this reviewed and landed in sid and xenial for a bit before we backport? this has a really high regression potential
<dgadomski> pitti: sure, this is a backport of Guus change already present in debian git repo
<pitti> dgadomski: ah, it is? godo
<dgadomski> pitti: although I think it has not been released yet
<pitti> dgadomski: right, the bug is still open
<dgadomski> pitti: it has already been tested in several different environments so it is known to at least fix this bug, releasing to xenial may help us make sure about regressions
<pitti> dgadomski: right, so I'm fine with the xenial upload, but I'd give the SRUs some time
<dgadomski> pitti: agreed, I'll keep testing it in xenial
<seb128> sil2100, hey, what's the status of https://code.launchpad.net/~sil2100/livecd-rootfs/fix-apt-lists-rm-hook/+merge/273117 ? could you get ogra or somebody who usually upload those changes to review?
<seb128> ogra_, https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new-and-old/+merge/274875 is in the sponsoring queue, is that something you are still reviewing for mvo?
<ogra_> seb128, i'll sing it off once it is ready (requores a lot of other architectural changes first)
<ogra_> i thought the apt list removal landed ages ago ... will pull it inot the next livecd-rootfs upload
<seb128> ogra_, thanks, the removal landed it seems but that's a follow up to fix small issues
<ogra_> ah
<smoser> pitti, yeah. even on my physical system, it doesn't show up. http://paste.ubuntu.com/13216207/
<smoser> pitti, do you have it in  yours ?
<davmor2> hey pitti did you get home in the end or are you working from ausitn?
<Unit193> mdeslaur: Thanks!
<mdeslaur> Unit193: yw!
<mvo> ogra_: fwiw, we could land it now it is fully backward compatible, but I don't mind either way
<pitti> smoser: I'm back home, the third flight worked after all :)
<pitti> smoser: what is "it" in "it does not show up"?
<smoser> pitti, persistent networking
<smoser> per
<smoser> <pitti>  smoser: /etc/udev/rules.d/70-persistent-net.rules shold be in the initramfs, yes; is it not?
<seb128> jibel, and do you know who would be right to review https://code.launchpad.net/~psivaa/ubuntu-test-cases/remove-ceph-lxc-floodlight/+merge/240144 ?
<seb128> https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620 as well
<psivaa> seb128: the latter should be rejected. I'll do that
<seb128> psivaa, thanks
<pitti> smoser: could you please add set -x to /usr/share/initramfs-tools/hooks/udev and do "sudo update-initramfs -u"?
<sil2100> seb128: ok, I'll try getting someone to review that ASAP
<pitti> smoser: when I touch /etc/udev/rules.d/70-persistent-net.rules and update, my initrd gets it
<seb128> sil2100, thanks
<smoser> pitti, sure.
<smoser> pitti, looking at /usr/share/initramfs-tools/hooks/udev
<smoser> its based on NEED_PERSISTENT_NET
<psivaa> seb128: sil2100: https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620 could also be reviewed please. I was talking with a bad memory when I said that should be rejected
<pitti> smoser: oh sorry, which release is that?
<smoser> i dont know why you'd get it, though.  either you must have configured it, or 'root_over_the_network' would be true for your system (which would seem odd)
<pitti> smoser: this is gone from wily
<smoser> why?
<pitti> smoser: >= wily just copies everything in /etc/udev/rules.d/ into the initramfs (which doesn't have a counterpart in /lib/udev/rules.d/, i. e. all custom rules)
<pitti> because we can't know which bits apply to the initrd
<pitti> smoser: I mean the specific check is gone from wily
<jibel> seb128, both are for the server team
<seb128> jibel, k, the merges mention daily iso testing so I was unsure if that was a QA thing
<seb128> who is in the server team that could be pinged about those? ;-)
<jibel> seb128, yes but the server team manages its own tests
<jibel> seb128, matsubara or rbasak
<seb128> jamespage, ^ you own lp:ubuntu-test-cases/server it seems, can you get those reviewed?
<seb128> rbasak, matsubara, ^
<seb128> they are sitting there for around a year
<seb128> we should get them out of the sponsoring queue if we can :-)
<seb128> jibel, thanks
<smoser> pitti, i'm looking at wily system up to date.
<smoser> it most definitely includes /etc/udev/rules.d/70-persistent-net.rules based on NEED_PERSISTENT_NET
<smoser> maybe you meant 'I mean the specific check is gone from XENIAL'
<smoser> ?
<smoser> am i missing something?
<pitti> smoser: no, I meant http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=022e24e5b3 which is in wily
<pitti> smoser: in my wily VM I don't see anything "NEED*" in /usr/share/initramfs-tools/hooks/udev ?
<pitti> smoser: indeed in older releases there was a check like that, as apparently someone thought back then that we don't need the interface names in initrd yet (i. e. without taking the iscsi use case into account)
<smoser>  grep NEED /usr/share/initramfs-tools/hooks/udev
<smoser> if [ -z "$NEED_PERSISTENT_NET" ] && root_over_the_network; then
<smoser>   NEED_PERSISTENT_NET='yes'
<smoser> case "$NEED_PERSISTENT_NET" in
<smoser> $ dpkg -S /usr/share/initramfs-tools/hooks/udev
<smoser> udev: /usr/share/initramfs-tools/hooks/udev
<smoser> $ dpkg-query --show udev
<smoser> udev    219-7ubuntu6
<pitti> well, that's not wily :)
<smoser> $%&*#
<smoser> smoser stop being an idiot
<smoser> i swear that system was wily a minute ago :)
<pitti> smoser: so yes, in vivid this was still the case
<smoser> thank you
<pitti> smoser: is that important for an SRU?
<smoser> maybe i would need this for trusty.
<pitti> in principle it should apply, but I had thought the existing NEED checks should apply to iscei
<smoser> but not tat the moment.
<smoser> the path would be to support iscsi root and ibft
<smoser> https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1513254
<ubottu> Launchpad bug 1513254 in open-iscsi (Debian) "iscsi_auto flag should use --fwparam_network in addition to -b" [Unknown,Confirmed]
<smoser> is where this came up, was just looking at the path that would include ibft for iscsi
<seb128> mdeslaur, unsure it's still worth doing SRUs to vivid for non critical issues
<seb128> mdeslaur, btw when do you set mps to merged? to you actually push to the udd vcs?
<mdeslaur> seb128: yeah, didn't think it was worth it either, but sru team can decide
<mdeslaur> seb128: when I upload the package
<mdeslaur> I don't actually udd merge it
<seb128> mdeslaur, k, you put https://code.launchpad.net/~e7appew/ubuntu/vivid/deluge/fix-set-trackers-cherry-picked/+merge/271221 to approved and not mergd though?
<mdeslaur> seb128: hrm, what do you usually do?
 * mdeslaur has no idea what to set that to
<seb128> mdeslaur, I set it to merged when I upload to get it out of the queue summary
<seb128> but I'm not sure it's right either ;-)
<mdeslaur> ok, I'll set it to merged too
<seb128> just avoiding having items staying on the queue
<mdeslaur> I thought approved got it out of the queue, but merge works for me too :P
<seb128> for the same reason I also unsubscribe ubuntu-sponsors from SRU bugs because it takes a while to get them to fix released
<seb128> ok, maybe it does
<seb128> but then they stay in that state
<seb128> merged is done ;-)
<mdeslaur> sounds good, merged from now on
<seb128> thanks
<seb128> xnox, you asked details on https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1472314 and got a reply and the submitter pinged since, you might want to have another look? ;-)
<ubottu> Launchpad bug 1472314 in cmake (Ubuntu) "Fix subsequent cmake runs when using multi-arch" [Medium,New]
<xnox> seb128: i do not currently have internet at home. so i cannot do any ubuntu stuff at the moment.
<seb128> xnox, no worry, enjoy the quiet time without internet disturbances ;-)
<mdeslaur> I wish I didn't have internet :)
<seb128> cyphermox, hey, do you plan to deal with an eventual trusty SRU for https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1459872 ?
<ubottu> Launchpad bug 1459872 in grub2 (Ubuntu Vivid) "using progress mod w/ net files crashes" [Medium,New]
<seb128> mdeslaur, yeah, who needs a job anyway :p
<cyphermox> seb128: yes, that's the plan
<seb128> cyphermox, no need of keeping it in the sponsoring queue then?
<cyphermox> ah, no. sorry, I didn't notice it was
<seb128> cyphermox, thanks
<seb128> cyphermox, same for https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/277903 ,
<ubottu> Launchpad bug 277903 in syslinux (Ubuntu) "Missing Operating System [message at boot]" [Medium,In progress]
<seb128> it's assigned to you
<cyphermox> yes
<seb128> thanks ;-)
<seb128> Sarvatt, do we still care about vivid for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1506107 ?
<ubottu> Launchpad bug 1506107 in xserver-xorg-video-intel (Ubuntu Vivid) "Bad webcam video rendering when using XV acceleration on Skylake gpus." [Medium,In progress]
<Sarvatt> seb128: trusty's lts-vivid at least
<Sarvatt> that's whats shipping on OEM machines till 16.04
<mdeslaur> seb128: did you forget to actually unsubscribe sponsors here? 1506536
<mdeslaur> bug 1506536
<ubottu> bug 1506536 in pylint (Ubuntu) "FTBFS because of python3.5" [High,Incomplete] https://launchpad.net/bugs/1506536
<seb128> mdeslaur, seems I did!
<seb128> Sarvatt, is tjaalton or robert_ancell going to sponsor that SRU for you?
<Sarvatt> seb128: tseliot just said he would
<seb128> great
<seb128> tseliot, Sarvatt, thanks
<tseliot> yw
<seb128> smoser, pitti, mvo, there is an update patch on https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674 since you reviewed the previous version and had comment could you maybe have another look to the updated one?
<ubottu> Launchpad bug 525674 in update-notifier (Ubuntu) "apt-check hangs, preventing login via SSH" [Medium,Confirmed]
<smoser> seb128, done.
<smoser> please sponsor that for xenial
<seb128> smoser, thanks
 * smoser says thank you.  cpaelzer best.fix.ever!
<seb128> mvo, ^ maybe you merge that back in update-notifier's vcs? ;-)
<seb128> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<seb128> dholbach, do you know if it was discussed listed the newest sponsoring entries first on the page?
<mdeslaur> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> seb128, no... maybe Laney knows?
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back
<seb128> @pilot out
<seb128> oh, I just did that :p
<seb128> dholbach, my rational would be that the top of the page is always year old difficult items that probably most people skips over
<seb128> but some new comers might also try to get to one, find it difficult, go the next one, same and then give up
<seb128> I think it would be less discouraging to have the newest ones first
<dholbach> you can sort it the other way if you click on the title
<dholbach> but I'm happy either way
<seb128> lol
<seb128> I know that, I also sort it first thing
<seb128> well, I just wanted to mention it, I've no strong opinion
<seb128> and I do try to tackle some ancient ones ;-)
<Laney> no
<Laney> not discussed
<Laney> I think it's bad we have ancient stuff there
<seb128> yeah, it is
<seb128> but sorting them first obviously doesn't resolve the issue
<seb128> it just means people who know what they are doing skip over those and others might think things are just impossible to review
<mterry> seb128, mdeslaur: stop piloting so hard, you make the rest of us look bad  :)
<seb128> lol
<mdeslaur> slackers :)
<seb128> mterry, there are some easy items left, help yourself ;-)
<seb128> like the 2 most recent ones
<pitti> seb128: bon travail sur le "sponsoring queue" !
<seb128> pitti, merci !
<seb128> mdeslaur, you could have handled https://bugs.launchpad.net/ubuntu/+source/electrum/+bug/1481033 since it's a security one :-)
<ubottu> Launchpad bug 1481033 in electrum (Ubuntu Trusty) "Please remove electrum from the archive" [Medium,Triaged]
<seb128> replacing it with a dummy binary
<mdeslaur> I've been the bad guy twice now for doing that, first sun-java, then owncloud
<mdeslaur> I'll get someone else get the death threats this time :)
<mdeslaur> s/get/let/
<Chipaca> xnox: o/
<Chipaca> xnox: any news on bug 1025555? (cjwatson mentions you need to follow up something with intel?)
<ubottu> bug 1025555 in Ubuntu CD Images "Ubuntu i386 images (install media) cannot boot in UEFI mode" [Undecided,Won't fix] https://launchpad.net/bugs/1025555
<xnox> hm.
<xnox> yes and no.
<xnox> in a meeting now.
<Chipaca> xnox: i'd assumed i was going to get an async answer; no hurry :)
<seb128> cyphermox, did you say you would handle the https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095 modemmanager/n-m uploads for trusty as well?
<ubottu> Launchpad bug 1441095 in network-manager (Ubuntu Trusty) "novatel: improve probing for Dell branded modems" [High,In progress]
<cyphermox> I'll do all these sponsorings this PM
<roadmr> heya folks. I'd like the checkbox package to stop building all its binaries altogether. Is it OK for the ubuntu branch to contain just the debian directory which will build the required transitional packages?
<pitti> infinity, kees, stgraber, slangasek, mdeslaur: TB meeting
<seb128> xnox, in https://launchpad.net/ubuntu/+source/samba/2:4.1.11+dfsg-1ubuntu1 you did
<seb128> -		reload nmbd 2>/dev/null
<seb128> +		service nmbd reload 2>/dev/null
<seb128> but that seems buggy (https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1385868)
<ubottu> Launchpad bug 1385868 in samba (Ubuntu) "Samba logrotate script uses invalid argument to /etc/init.d/nmdb" [Medium,Confirmed]
<seb128> debian uses
<seb128> 		[ ! -f /var/run/samba/nmbd.pid ] || kill -HUP `cat /var/run/samba/nmbd.pid`
<seb128> should we go back to that
<slangasek> yes we should
<slangasek> :)
<seb128> or is there a better version of that line?
<slangasek> no there's not
<seb128> slangasek, thanks
<slangasek> not one that is boot-system-agnostic
<seb128> unsure why we changed it in the first place
<seb128> k
<seb128> I guess because we were upstart centric
<ogra_> could someone bump the score of https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/8284490 ? (sits there saying "15 min" since over 1h
<ogra_> )
<cjwatson> ogra_: done
<ogra_> thanks
<cjwatson> unusually long armhf queue
<ogra_> do we know why livecd-rootfs is arch any ?
<ogra_> i guess i asked that before
<cjwatson> changelog does
 * ogra_ reads
<ogra_> ah, android :/
<hallyn> xnox: any time this week to pick up the shadow pkg? :)
<gAtheos> Hey, I am a computer science student and I am looking to contribute to development of Ubuntu in some way, does anyone have any advice or some direction for where I could go or what I could do?
<TJ-> gAtheos: see https://wiki.ubuntu.com/ContributeToUbuntu#Maintaining_Ubuntu
<slangasek> pitti: http://autopkgtest.ubuntu.com/packages/c/cantor/xenial/armhf/ - I guess it's going to be a bit more difficult now to reproduce these tests exactly given the new pinning handling, and the test output doesn't say *what* packages are uninstallable; any advice on debugging?
<cyphermox> gAtheos: the easiest way to start is probably to pick some software that you're interested in and see if you can triage or fix bugs, etc. starting with something you know and use helps.
<slangasek> pitti: and ppc64el gets timeout connecting to systemd :/ http://autopkgtest.ubuntu.com/packages/c/cantor/xenial/ppc64el/
<slangasek> Laney: how does mathgl 2.3.3-3build2 count as a rebuild if you're changing debian/control...?
<slangasek> Laney: the gsl transition has gotten wedged in with the ocaml and giflib transitions fwiw
<slangasek> also mathgl apparently needs porting to the new gsl
<gAtheos> cyphermox: That is what I am trying to do. I found a bitesize bug in RhythmBox and have been following the instructions found here: http://goo.gl/V3zA6j and I have just been having a lot of trouble. I have no doubt I will be able to contribute once I get started, but I have no experience doing this and the examples and walkthroughs seem lacking
<cyphermox> gAtheos: yes, it's a bit outdated. You probably should just grab the code using 'pull-lp-source rhythmbox' to start hacking on it rather than creating a repo.
<gAtheos> cyphermox: I'll have to try that once I get home
<sil2100> cyphermox: hey! Another no-change rebuild - this one would be a 'just in case' rebuild, as the package fails to install for other reasons right now: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.6/+bug/1515031
<ubottu> Launchpad bug 1515031 in llvm-toolchain-3.6 (Ubuntu) "Release no-change rebuild for ocaml transition" [Undecided,New]
<sil2100> cyphermox: still, the packages depend on ocaml so I would feel better if this gets released anyway
#ubuntu-devel 2015-11-11
<alexlist> pgquiles_: thats what we end up doing until the upstream 3rd pty software vendor comes up with a version compiled with gcc 5.2 ...
<pgquiles_> alexlist: then move your application to C++11 ABI too :-)
<psusi> does anyone have experience with IP multicast?  I'm trying to figure out what is wrong with mediatomb... it currently has its .service file run route add -n 239.0.0.0 netmask 255.0.0.0 eth0, and ifconfig eth0 allmulti... but shouldn't these be entirely unneeded if it were programmed right?
<psusi> that is to say, shouldn't it be using the sockets api to subscribe to the multicast group and send packets to the right interfaces, without the startup script running these commands?
<hallyn> pitti: mbiebl: is there a way (rm some stampfile) to get just the fakeroot debian/rules binary part of a systemd package build to be re-done?  (I changed one file, want just that rebuilt)
<pitti> Good morning
<pitti> hallyn: it heavily depends on the packaging, but try debuild/dpkg-buildpackge with -nc ?
<hallyn> pitti: was specifically asking about sytemd :)  but will try that next time, thx
<hallyn> good night :)
 * hallyn out
<pitti> hallyn: I suggest building with CFLAGS="-O0 -g", it's muuuch faster
<pitti> hallyn: good night!
<pitti> slangasek: cantor> ah, so that's a case where test-simulated-installing the individual debs from -proposed works, but several of them as a whole; I'll have a closer look at that, and either robustify our fallback to un-pinned, or maybe infinity's suggestion works even better
<pitti> slangasek: curious that it did find that "uninstallable with partial -proposed" on i386/amd64
<pitti> slangasek: It can be reproduced locally rather easily, I just need to do an autopkgtest release; doing that now
<pitti> slangasek: err, "soon" -- after looking at the trigger prio thing
<pitti> (giving this some field testing is the reason why I didn't release it yet)
<slangasek> pitti: "trigger prio thing"?
<pitti> slangasek: sorry, I meant changing the apt pinning the way Adam suggested
<slangasek> pitti: but ok, thanks for the clarification on cantor
<slangasek> ah right on
<pitti> I actually thought I tried with higher prios already, but maybe not high enough
<slangasek> I think the threshold is 500
<slangasek> and I guess I read the manpage wrong
<pitti> yeah, I remembered right -- merely bumping 100 to 800 for -proposed still doesn't fix my test case
<slangasek> pitti: ok you and infinity get to scratch your heads together then :)
<pitti> but I'll try this on cantor and lxd, if it makes things any better
<pitti> slangasek: and in any case I have cantor and lxd (and possibly others) to at least fix the regressing tests :)
<slangasek> right ;)
<slangasek> meanwhile I'm overriding for octave so we can make progress on the transition
<pitti> slangasek: that won't actually propagate yet as it seems, so I can still look at it while it's in proposed, yes
<pitti> slangasek, stgraber: ooh, I know what's wrong -- we still dist-upgrade the whole testbed to -proposed (things like sqlite or kernel, which are in the default install), which then conflicts with the apt pinning that we set up
<pitti> (unrelated to that apt pinning not working in every case, but explaining the test regressions)
<pitti> in fact, in the new regime we don't actually *want* to upgrade the whole testbed, I think
<pitti> only the packages we are testing
<pitti> it gives us better coverage for testing low-level packages, but it's incompatible with that new pinning isolation approach
<dkessel> good morning
<dholbach> good morning
<ginggs_> Logan, doko: can i go ahead and sync openblas? you had a "build everywhere" patch and now the new version builds on all the ubuntu archs https://buildd.debian.org/status/package.php?p=openblas&suite=unstable
<pitti> slangasek: removed your hint again, octave is green again (and it's stuck on the graphicsmagick transition)
<mapreri> can somebody help me make some sense of these failures?  https://launchpad.net/ubuntu/+source/sigil/0.9.0+dfsg-1
<pitti> infinity, Laney: FYI, I documented the improved tmpfail handling and also added the SIGHUP vs. SIGTERM bits to https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration
<decci> Hello Developers
<decci> I am trying to build multiple .deb packages. One .DEB package worked fine but while I am trying to use the same rule file for multiple packages it throws dh_builddeb: -P was specified, but multiple packages would be acted on
<cjwatson> decci: this will probably be easier to debug if you pastebin your rules file
<decci> cjwatson: Sure
<decci> cjwatson: http://pastebin.com/CKx62rB4
<decci> cjwatson: While I tried creating .DEB with 1 package entry in control file, it worked. But while I added two more package entries into control file, it complained
<decci> dh_builddeb: -P was specified, but multiple packages would be acted on
<cjwatson> decci: ok, that has a number of flaws
<decci> cjwatson: like?
<cjwatson> you shouldn't be calling so many dh_* commands in override_dh_install, to start with - that should only be modifying the behaviour of dh_install
<cjwatson> and you probably have no real need to pass --tmpdir to dh_builddeb
<decci> cjwatson: I skipped dh $@ --with autotools-dev --with autoreconf --parallel --builddirectory=_build
<cjwatson> you would be better off installing files to the right place rather than overriding tmpdir
<decci> cjwatson: What is the right way?
<cjwatson> which probably simply means setting buildroot = debian/dang (assuming that that's your package name)
<decci> cjwatson: I usually do is dh_make >> !cmake >> debian/rules build >> debian/rules binary
<cjwatson> but it depends on what delta.mk does
<decci> cjwatson: It just has variables for lib, opt and etc placement
<cjwatson> decci: debian/rules should be the entry point and should take care of calling cmake or whatever
<decci> cjwatson: Few queries I have
<xnox> hallyn: i has no internets at home yet =)
<xnox> hallyn: when i haz internets i'll be happy to do things.
<decci> cjwatson: Say I have precompiled source code
<decci> cjwatson: I went to source directory
<cjwatson> precompiled source code makes no difference, if that's the case you just have debian/rules not do the build pass, it usually actually simplifies things
<decci> cjwatson: Ran dh_make -f ../delta.tar.gz -p delta_6.2.0
<decci> cjwatson: okay
<decci> cjwatson: Then ran cmake command with cmake -DDO_STAGING=FALSE -G 'Unix Makefiles' -DCMAKE_INSTALL_PREFIX=/tmp/INST/620/64 -DCMAKE_BUILD_TYPE=Release -DBUILD_ARCH=m64 -DRELEASE_MAJOR=6 -DRELEASE_MINOR=2  -DRELEASE_MICRO=0 -DSIGN_JARS=FALSE -DOBFUSCATE_JARS=FALSE -DTKT_NO=1234 -DREV_NO=1234 .
<decci> cjwatson: then debian/rules build
<cjwatson> ok, seriously, don't
<cjwatson> debian/rules should be the thing that calls cmake
<decci> cjwatson: :(
<cjwatson> (possibly via helpers)
<cjwatson> and for sensibly-laid-out cmake packages, dh will do most of the hard work for you
<decci> cjwatson: you mean I can skip cmake..but DCMAKE_INSTALL_PREFIX refers to /tmp/INST/620/64
<cjwatson> dh will set a more sensible CMAKE_INSTALL_PREFIX
<decci> cjwatson: where my required directories and files are stored to be picked up
<cjwatson> /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm:  -DCMAKE_INSTALL_PREFIX=/usr
<cjwatson> but you can override that in override_dh_auto_build if you need to
<cjwatson> /tmp/INST/620/64 is a seriously weird place for files to end up in the built package
<decci> cjwatson::(
<decci> cjwatson: Looks like I have been doing things wrongly
<decci> cjwatson: though I was able to create a single package
<decci> cjwatson: Any reference which can help me with example how to proceed when one has precompiled source and cmake ready
<cjwatson> decci: so, my starting point for what you're describing would be something roughly like http://paste.ubuntu.com/13226226/
<decci> cjwatson: let me go through
<cjwatson> you can add more stuff to the dh_auto_build line if you need to, to pass other cmake options
<cjwatson> and I might have got some of the paths a bit wrong because I don't know all the detials
<cjwatson> *details
<decci> cjwatson: So dont we need dh_install, dh_builddeb
<cjwatson> decci: dh will call those automatically
<cjwatson> that's its purpose
<decci> cjwatson: not even dh_install
<cjwatson> dh calls that
<decci> cjwatson: okay
<cjwatson> see "man dh"
<cjwatson> the point of these override rules is that you can have a rules file that says "just do the sensible thing" and then override it for the bits where you need non-default behaviour
<decci> cjwatson: and where shall I put my directory which I want to install like /opt /etc
<cjwatson> debian/<package-name>.dirs
<cjwatson> debian/dang in my example should be replaced with debian/<package-name> where <package-name> is the binary package you want to install that stuff into
<cjwatson> oh, in fact my example probably wants to be http://paste.ubuntu.com/13226240/ so that you can still use debian/*.install files
<cjwatson> (i.e. override_dh_install changed to be "dh_install + more stuff" rather than just the custom stuff)
<cjwatson> decci: ^-
<decci> cjwatson: Do I need to simply dump all my diretory udner debian/<package-name>.dirs
<decci> cjwatson: What about buildroot?
<decci> cjwatson: Let me try following your rules file and see if that works
<cjwatson> I would strongly recommend reading the debhelper docs - the .dirs file is documented in "man dh_installdirs"
<cjwatson> for buildroot, well, that depends what that actually does
<cjwatson> but normally, the way this works when you have multiple binaries is that you install your stuff to debian/tmp (or more usually let debhelper sort that out for you) and then you have .install files that select which bits of the upstream-installed tree to put into which binaries
<cjwatson> you should make sure that it's actually worth multiple binary packages, since it's somewhat inevitably more work to keep track of what goes where
<decci> cjwatson: I am trying that now..rules file ready..just need to dump .dir
<decci> cjwatson: 2 min
<decci> cjwatson: but normally, the way this works when you have multiple binaries is that you install your stuff to debian/tmp (or more usually let debhelper sort that out for you) and then you have .install files that select which bits of the upstream-installed tree to put into which binaries
<decci> cjwatson: The above recommendation is what I tried too..let me show what I actually did..
<ara> cjwatson, tjaalton: hello! This bug has been verified for some days in trusty-proposed and it is quite critical to have it in updates, can any of you review it, please?
<ara> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1480217
<ubottu> Launchpad bug 1480217 in nautilus (Ubuntu Trusty) "Nautilus background handling screwed when changing scaling factor." [High,Fix committed]
<ara> or pitti ^
<ara> :)
<pitti> ara: it's been 5 days, and we normally require 7
<ara> pitti, ah, great, good to know :)
<pitti> ara: as an explanation why it hasn't been moved yet
<pitti> ara: if that's super-urgent, we can expedite of course
<ara> this one is a bit urgent, yes, but it is good to know the 7-day rule
<tjaalton> and works around a crasher in the intel X driver, giving more time to bisect it..
<rbasak> Is there a known bug in lintian in Wily? I'm getting a false positive on postinst-must-call-ldconfig but can't reproduce with lintian on sid.
 * rbasak ignores the error
<decci> cjwatson: http://paste.ubuntu.com/13226314/
<pitti> ara: released
<ara> pitti, fantastic, thanks a lot
<decci> cjwatson: I tried specifying .install file where I have added entries for files..but where shall I actually add those directories to ..will debian/tmp the right directory to put?
<decci> cjwatson: Does the pastebin looks good
<doko> ginggs_, sure
<decci> cjwatson: tried running it lets see how it goes
<cjwatson> decci: so, "delta-dang" is not one of the package names you've listed in debian/control, so that won't work
<cjwatson> decci: nor will the "Depends: delta-dang (>= blah)" in a couple of places in debian/control
<cjwatson> decci: also, debian/dang in debian/rules should be replaced with debian/delta-eng or debian/delta-dang-snmp or debian/delta-dang-dev or something, depending on which package you want those ld.so.conf.d files to go in
<decci> cjwatson: That I am going to correct..just an example ...
<decci> cjwatson: One thing to ask - how will debian/rules binary know to pick up all directory under debian/tmp
<decci> cjwatson: is what buildroot enough to help it
<cjwatson> decci: dh_install will expect to be able to copy those files from under debian/tmp; normally you shouldn't need to hardcode that though, because dh_auto_install will run "make install DESTDIR=$(pwd)/debian/tmp" or equivalent for you
<cjwatson> any vaguely well-written upstream build system should honour that
<decci> cjwatson: Great info
<cjwatson> decci: buildroot is entirely your stuff, debhelper doesn't know or care about it
<decci> cjwatson: What about Depends section in control file, say for a package if I mention Depends: (foo1), (foo2) and that is not current built..will the .DEB packaging proceed
<cjwatson> in general most variables that you set in debian/rules are up to you, unless specifically documented otherwise
<cjwatson> decci: an unsatisfiable Depends won't prevent the build from completing, but you might end up with a .deb you can't install
<decci> cjwatson: So it means if I install it on ubuntu machine, it will throw error saying it is dependend upon foo2 wwhich has to be installed
<decci> cjwatson: correct
<cjwatson> decci: right
<decci> cjwatson: So it is suggested to install the foo2 first and then install this package
<decci> cjwatson: got your point
<cjwatson> well, most people will use apt which handles that automatically, but yes, if you install with dpkg -i then you have to deal with that yourself
<decci> cjwatson: it was great info..I am going to start from fresh with correct pkg name which u suggest and see if that helps
<cjwatson> this is entirely necessary behaviour of course, since you're typically depending on all sorts of things that aren't part of your source package
<decci> cjwatson: I wonder if there would be more easy way..I loved checkinstall but it lacks rules part right
<decci> cjwatson: debreate is GUI based but quite slow
<cjwatson> decci: well, I'm the wrong person to ask about that
<decci> cjwatson:I understand...an official way is debian doc
<ginggs_> thanks doko
<decci> cjwatson: One question - delta-dang.install under http://paste.ubuntu.com/13226314/...does it install those directory
<decci> cjwatson: sbin doesnt occur under opt/dang/dang
<decci> cjwatson: so wonder what this file actually does
<cjwatson> decci: if it doesn't occur there, why did you write the file that way?
<cjwatson> decci: "man dh_install" explains what *.install files do
<cjwatson> please do read it
<decci> cjwatson: Look in my rules I specify mkdir, touch and mv to copy , create files..here and there which is required..so I wanted to understand what actually entries under .install doing
<decci> cjwatson: ok will read it
<cjwatson> decci: you can always do things by hand, but where possible it's more robust, simpler, and clearer to use declarative forms rather than big piles of shell
<decci> cjwatson: The rules went fine.During dh_install part , http://paste.ubuntu.com/13226669/
<cjwatson> decci: you should only be putting something in *.install if the upstream build system installs it
<cjwatson> otherwise, I don't have enough context of this build system to advise
<decci> cjwatson: Do I need .dir directory which u suggested to dump all the directories to
<decci> cjwatson: I was mistakenly dumping everything under /tmp...i think debian/tmp is being created while rule is run
<decci> cjwatson: So I would need .dir directory too
<decci> cjwatson: correct?
<cjwatson> the purpose of debian/*.dirs (which is "dirs", not "dir", and is a file, not a directory) is to declare that you need a bunch of mkdir commands run by dh_installdirs; nothing else
<cjwatson> installing to /tmp is a serious mistake, fix that first
<cjwatson> the upstream build system ought to be installing to where DESTDIR says, and creating directories as needed
<decci> cjwatson: Can you help me with an example..little confusing
<decci> cjwatson: you can take http://paste.ubuntu.com/13226669/ as an example
<cjwatson> not at the moment, I'm sorry, run out of time for this
<decci> cjwatson: Just need to udnerstand dh_install
<pgquiles_> decci: you may need to run dh_instal with --sourcedir=debian/tmp/
<pgquiles_> and that's assuming you are actually installing to debian/tmp, by default .dirs creates directores under debian/packagename
<cjwatson> or 'echo 9 >debian/compat' so that it uses more modern behaviour by default
<cjwatson> (assuming that's currently missing or set to something less than 7)
<decci> ok
<decci> cjwatson: compat is set to 7
<decci> pgquiles_: but debian/tmp is something which is being created as it is buildroot.
<decci> cjwatson: where do I need to dump the directories which I want to push to debian/tmp
<decci> pgquiles_: where do I need to dump the directories which I want to push to debian/tmp
<hallyn> xnox: is that scheduled soon or are you like waiting for fiber to be laid down in february or something? :)
<xnox> hallyn: i'm awaiting for a fibre modem to arrive.
<xnox> hallyn: the fibre is in place.
<cyphermox> good morning!
<roadmr> hey folks! I need to make the checkbox source package produce only dummiy binaries for upgrading purposes. Is it ok if the source package contains only a debian directory?
<Laney> roadmr: you could also make the new package provide the old binaries
<cjwatson> yeah, the latter approach would be more usual, although the former is OK
<roadmr> oh good idea... let me ask the new package folks
<hallyn> xnox: swanky :)  for me, high bw is reserved for my servers, sadly
<pitti> sitter: ah, I see some kde tests got fixed for the "command line option â-std=c++11â is valid for C++/ObjC++ but not for C
<pitti> " thingy
<pitti> sil2100: AFAICS, kcoreaddons, kio, and kde-runtime are still left
<pitti> err, sitter ^
<pitti> greyback, sil2100: FYI, seems qtmir FTBFS on armhf now: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/q/qtmir/20151111_122235@/log.gz
<sitter> yofel: ^
<sil2100> pitti: you pinging me again!
<sil2100> ;p
<greyback> CLOCK_MONOTONIC undeclared??
<pitti> greyback: yeah, that's what the log says; not sure, might be a change/regression in new kernel?
<yofel> pitti: I fixed all of that as far as I know, but as 35 of my uploads were rejected, I first need to develop a way to keep the kubuntu packageset in sync with reality. Then I'll upload the rest.
<yofel> (regarding kde tests)
<pitti> yofel: oh cool, thank you!
<greyback> pitti: that's coming in via lttng headers that qtmir includes. Looking to see where that symbol might have gone
<pitti> doko: the python{2.7,3.4,3.5} regressions actually do look related to the new openssl: http://paste.ubuntu.com/13227864/
<pitti> doko: does that magic "options" number need to be adjusted for the new openssl, or is that actually a bug in openssl?
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openssl
<pitti> yofel: FYI, kwin (https://launchpad.net/ubuntu/+source/kwin/4:5.4.2-0ubuntu2) FTBFS on symbols mismatches
<roaksoax_> pitti: so, I'm running into an issue where the tests seems to be failing, even though all the tests have run successfully. Anychance you can take a look? http://paste.ubuntu.com/13227887/
<roaksoax_> my guess is that it is: adt-run: DBG: / tests-tree rmtree /var/lib/jenkins/workspace/maas-trusty-trunk-manual/results/tests-tree
<roaksoax_> Build step 'Execute shell' marked build as failure
<pitti> roaksoax_: what prints that ^, a Jenkins job?
<mdeslaur> pitti, doko: python tests need to be fixed to match how I've disabled sslv3
<yofel> pitti: I know, I'll patch that later today (there was some upstream discussion involved)
<pitti> mdeslaur: ah, that's the missing 0x2000000?
<mdeslaur> pitti: yeah...it's making some assumptions there....there also seems to be sslv3 tests later on too which probably will fail
<mdeslaur> pitti, doko: I'll fix them
<pitti> mdeslaur: thanks for the heads-up; does that apply to Debian's openssl too?
<pitti> doko usually keeps the python* in sync
<pitti> or perhaps the test should just be loosened
<mdeslaur> debian broke abi with their change, so a lot of things will be breaking there
<pitti> so at worst, "options in [2164261887, 2197816319]"
<mdeslaur> yeah, I'll try and make it work both ways
<dholbach> can somebody moderate my mail to u-d-a?
<cjwatson> dholbach: done
<dholbach> thanks cjwatson
<mapreri> the sigil builds on xenial are failing due to apt failures that don't make sense to me, can some of you take a look at them? (they are all the same) https://launchpadlibrarian.net/225723080/buildlog_ubuntu-xenial-amd64.sigil_0.9.0%2Bdfsg-1_BUILDING.txt.gz
<Laney> mapreri: Looks like libjs-jquery-scrollto isn't installable because we don't have jquery >= 1.8
<cjwatson>  libjs-jquery-scrollto : Depends: libjs-jquery (>= 1.8) but 1.7.2+dfsg-3ubuntu2 is to be installed
<cjwatson> bah, too slow
<mapreri> oh, right :\
<mapreri> Laney: cjwatson: but shouldn't LP figure this out *before* trying to build it?
<mapreri> and put the package in depwait
<mapreri> and also, xenial/release contains an installable version of libjs-jquery-scrollto that does not need libjs-jquery (>= 1.8), why not trying that
<cjwatson> mapreri: the problem is that that depwait could be resolved in multiple different ways
<cjwatson> mapreri: it wouldn't be accurate to set a depwait on libjs-jquery (>= 1.8), because libjs-jquery-scrollto might stop depending on it
<cjwatson> mapreri: and beyond that this gets combinatorial-explody
<mapreri> (it won't)
<cjwatson> yeah but LP doesn't know that
<cjwatson> mapreri: so we don't set depwaits more than one level down
<cjwatson> to avoid the situation where there's an outdated depwait that will never clear by itself
<mapreri> cjwatson: any reason why apt can't figure out to use an outdated version of libjs-jquery-scrollto which is installable?
<cjwatson> no idea
<cjwatson> possibly just trying to avoid having to do exponential backtracking
<mapreri> ok
<mapreri> i'll just ignore it, hopefully somebody will merge a newer version of jquery and everything will fix by itself
<greyback> pitti: https://code.launchpad.net/~gerboland/qtmir/xenial-armhf-fix/+merge/277282 fixes that qtmir issue here. How to land? Make a silo?
<elbrus> pitti: my latest upload of dbconfig-common fails to pass the autopkgtests on armhf only, everytime for another reason which all look unrelated to dbconfig-commoon... what is the best way forward?
<elbrus> http://autopkgtest.ubuntu.com/packages/d/dbconfig-common/xenial/armhf/
<slangasek> pitti: it appears britney is waiting for a test result from libpdl-stats-perl on amd64 triggered by gsl/2.0+dfsg-1ubuntu1, but the request looks like it was lost because there was another libpdl-stats-perl test running at the same time with a different trigger
<slangasek> pitti: (manually triggered now)
<ponycorn> Hey guys, are there any plans to update the gpg iso signing keys? To my knowledge, 1024 bit DSA keys are not considered safe anymore?
<mdeslaur> ponycorn: bug 1363482
<ubottu> bug 1363482 in ubuntu-keyring (Ubuntu) "ubuntu-keyring includes 1024D keys" [High,Confirmed] https://launchpad.net/bugs/1363482
<cjwatson> (answered on #ubuntu-release, too)
<ponycorn> Awesome, thank you mdeslaur and ubottu, and sorry for posting this in multiple channels
<robert_ancell> slangasek, infinity, could someone have a look at the lightdm 1.14.3 SRU for vivid? It's got a feature that's important for the phone.
<mbiebl> hallyn: not sure if your question was answered, but I think this is standard dh7 behaviour
<mbiebl> I assume dh keeps stamp files in debian/, but I actually dunno if you can remove one of those to trigger a new make run
<mbiebl> what you can do, to speed up the build, is to not run the test-suite and skip the udeb build
<mbiebl> export DEB_BUILD_OPTIONS="nocheck noudeb"
<pitti> elbrus: indeed; it either fails with "hostname: Temporary failure in name resolution
<pitti> elbrus: or
<pitti> ERROR: encoding "UTF8" does not match locale "en_US" DETAIL: The chosen LC_CTYPE
<pitti> elbrus: ^ not sure if that's intended and part of the test case?
<pitti> elbrus: anyway, I'll have closer look tomorrow morning and reproduce; I might just set it to "always failed" (then it'll promote), but at least figure out some details
<pitti> slangasek: libpdl-stats-perl> hm, we shouldn't "lose" results, and britney also tracks them by-trigger; looking at log files
<pitti> slangasek: I see two runs for ADT_TEST_TRIGGERS=gsl/2.0+dfsg-1ubuntu1 now -- if you manually triggered once, the other was from britney itself?
<pitti> slangasek: could it just have been busy queues?
<pitti> capacity and cloud breakage is continuing problem..
<pitti> slangasek: actually there's three results
<pitti> 2015-11-11 20:09:45, 2015-11-11 19:34:21, and 2015-11-11 19:27:48
<pitti> slangasek: so at least the latter was finished before your manual one
<leezer3> Looking for a little help here; I appear to have taken over development of an abandoned game, which is available in the Ubuntu repositories, but has a couple of critical bugs, which means it no longer works full-stop for most users.
<leezer3> I'm rather unclear as to what/ who I should be talking to to get a patch into the repositories; I've tried mailing the package maintainer, who appears to be MIA, and I've discovered the patch pilot page on the wiki, which has kinda sent me here :)
<leezer3> my source is on Github at the minute, and the version that the repos have was behind what I started modifying, so there's a lot of code differences.
<leezer3> I don't claim my source is ready for primetime, but I'm looking for help on the process so that when it is, this can be sorted out :)
<slangasek> pitti: oh.  yes it could have been busy queues; the fact that scheduled tests don't show up on autopkgtest.u.c is rather inconvenient...
#ubuntu-devel 2015-11-12
<dupingping> https://answers.launchpad.net/ubuntu/+source/gvfs/+question/274076
<dupingping> please help me.
<dholbach> good morning
<pitti> slangasek: yeah, I know; It's ridiculously hard to inspect AMQP queues, much harder than e. g. doing the live logtailing :/
<pitti> slangasek: however, we could publish britney's pending.txt somewhere, which would already be a start
<pitti> Laney: wow, now that we get mailed about the cloud errors/worker failures it's quite dazzling how many there are..
<seb128> doko, hey, "libllvm3.7: Add Conflicts/Replaces to libllvm3.7v4 (anticipated backport)." ... what do you mean "anticipated backport"? could that go to Debian as well?
<seb128> doko, bug #1501300 ... seems like llvm-toolchain-3.4 was built with gcc-4.9 in wily due to an issue with the debian/rules gcc version regexp, do you think fixing that/building with gcc5 is the sort of change that is fine for a SRU?
<ubottu> bug 1501300 in llvm-toolchain-3.4 (Ubuntu) "Wily (15.10) this package got not compiled with __cxx11 support" [Medium,Fix released] https://launchpad.net/bugs/1501300
<seb128> same for bug #1511128
<ubottu> bug 1511128 in llvm-toolchain-3.7 (Ubuntu) "Package compiled on wrong compiler for wily" [Medium,Confirmed] https://launchpad.net/bugs/1511128
<Laney> pitti: yeah... what's up with the ssh timeout ones? just the instances failing to come up properly?
<pitti> Laney: seems they all come from vivid systemd's fsck test
<pitti> Laney: it timed out, it got handed to another worker, and then killed that as well
<pitti> Laney: I guess the possibility of chain-killing workers is now a consequence of not giving up on tmpfails
<pitti> but I'd rather have it this way, this happens much less (systemd/vivid/ppc64el is the only known case to me)
<pitti> Laney: the others were quota ceiling again
<pitti> Laney: wrt. http://autopkgtest.ubuntu.com/status/alerts/ -- I retried mpfit (RT to delete the two undeletable nova instances got processed and done)
<pitti> Laney: systemd/network-manager are these chain-killers, to be investigated
<pitti> Laney: apw and I found the reason for the linux/ppc64el test dep uninstallability, but there's still a bug somewhere in my code because it re-tries twice and then fails on the already removed apt pin file
<pitti> so TL;DR: I'm on them, please don't retry those
<Laney> okay, thanks for being on top of them!
<pitti> Laney: I'm now looking into converting these pesky "Temporary failure resolving 'ftpmaster.internal'
<pitti> Laney: ... to tmpfail, so that they will auto-retry
<pitti> instead of having to be retried manually
<Laney> is that fatal or can adt itself be retried?
<Laney> i.e. do you have to kill the instance when that happens?
<pitti> Laney: you mean apt?
<Laney> well I presume it makes adt-run fail
<pitti> we already retry apt-get update
<Laney> can you try it again?
<pitti> we might try to re-run apt-get install too
<pitti> Laney: if adt-run exits with a failure, the container is gone, so we have to start over, yes
<pitti> (but I don't see that as a big problem)
<pitti> retrying apt-get install itself is a bit more elegant, though
<pitti> in both cases I simultaneously need to capture apt's output to check for the error message but also have it go to stdout/err for the log
<pitti> so I might just as well do it locally in the apt-get call
<pitti> apt-get --quiet update || (sleep 15; apt-get update)) 2>&1
<pitti> we already do that trick for update, which commonly fail with hash sum mismatches
<pitti> hm, but if the outages last longer than a few seconds, then the test can't do much about it by itself
<pitti> mvo: apt-get always exits with 100 on errors? is there a way to tell apart errors on downloading/fetching stuff from uninstallability or postinst errors?
<pitti> mvo: apart from checking the output, I mean
<pitti> mvo: or maybe some extra "side channel" where it outputs such errors in addition, so that I can leave normal stdout/stderr in place?
<pitti> mvo: like dpkg's --status-fd
 * pitti discovers README.progress-reporting in the source and APT::Status-Fd
<pitti> err, the status-fd messages are translated
<apw> heh just what you need
<pitti> -o APT::Status-Fd=2 works
<pitti> but this doesn't, /tmp/out is empty; sudo apt-get install -o APT::Status-Fd=2 pmount 3>/tmp/out
<pitti> err, APT::Status-Fd=3 of course
<pitti> apparently my redirection fu isn't strong enough
<apw> pitti, some LANG=C foo tooo to make sure its parable
<apw> *parsable
<pitti> oh, sudo, hang on
<pitti> yep, works without sudo and in a root shell, sorry for the noise; so indeed weak redir fu :)
<pitti> mvo: so, found it, unping
<pitti> so I think if the file contains ^dlstatus: but does not contain ^pmstatus:, I can assume downlaod failed and it's worth trying again
<pitti> with sleeping 10 s in between, and give up with tmpfail after the third failure
<ara> hello all,
<ara> I have a general question about contributing to Ubuntu through bzr branches
<mvo> pitti: hi, what exactly is the problem you need to solve? I guess I can look into giving you different exit codes for certain failures
<ara> Currently, there is no xenial branch for partman efi: https://code.launchpad.net/ubuntu/+source/partman-efi
<ara> can we expect that branch to exist at some point? how/when that happens?
<pitti> mvo: we have a lot of failures like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/x/xen-tools/20151111_234936@/log.gz
<pitti> mvo: so if a package fails to install due to postinst bugs, bad dependencies etc., I want the test to fail
<pitti> mvo: but if it fails to download, or these DNS errors, I want to retry or make it a temporary testbed failure insted of a test failure
<pitti> mvo: but APT::Status-Fd=3 actually works well enough
 * pitti checks if that's available in precise
<mvo> pitti: ok, so a different exit code for download failures? that sounds not too terrible, let me check
<pitti> mvo: well, I need something that works on all releases; so it might be nice for the future as these retry loops become much simpler
<mvo> pitti: aha, ok. if status-fd is good enough, sure. it should be in precise, its availalbe since a long time (~2007ish I would say)
<pitti> yep, works in precise
<pitti> so, that's good, thanks!
<mvo> yw
<pitti> mvo: so I guess I'll use "apt-get install -o APT::Status-Fd=3 ... 3>&2 2>&1" and capture stderr
<caribou> hmm, looks like my upgrade to Xenial was not a success : lost sound, external display, USB keyboard & I don't get a prompt upon boot for my encryption password
<ara> hey dholbach, can I ask you a question related to contributing to Ubuntu through bzr branches?
<pitti> caribou: wow -- was it interrupted in the middle or so?
<pitti> caribou: the worst that I can say is that gedit now looks strange, so it's not generally broken for everyone
<dholbach> ara, sure
<caribou> pitti: no nothing to report
<ara> dholbach, Currently, there is no xenial branch for partman efi: https://code.launchpad.net/ubuntu/+source/partman-efi
<ara> can we expect that branch to exist at some point? how/when that happens?
<caribou> pitti: I'm going to reboot with  a clean syslog & I'll be back
<dholbach> ara, no idea - let me ask somebody
<dholbach> pitti, cjwatson (or anyone else): do you know why there's no xenial branch for https://code.launchpad.net/ubuntu/+source/partman-efi yet? (ara just asked.)
<pitti> I don't know, sorry; I don't know whether anybody still maintains the UDD branches in LP, but it seemed pretty dead to me
<pitti> to be blunt, they've been a mis-design right from the start, and a lot of imports tend to be behind; I thought there was a new plan to have something like dgit
<dholbach> pitti, so you'd recommend to just send a patch?
<pitti> dholbach: personally, yes (I know other sponsors actually like the UDD branches, so don't consider that a "project opinion")
<pitti> personally, a debdiff to a sponsoring bug is ten times faster and simpler than wrestling with the UDD patch maze
<dholbach> ok
<pitti> and no sponsor I know of dares to actually push these branches
<dholbach> ara, ^ does that help?
<ara> yes, it does
<ara> dholbach, the packaging guide still says that UDD is the way to go :)
<ara> dholbach, pitti: thanks!
<pitti> ara: the other option is to work on the Debian git, but we have a delta, so this mostly just makes sense for more convenient development if you want to use git diff, stashing, etc.
<pitti> and then attach the git format-patch to the bug
<dholbach> ara, I guess it needs a bit of a broader discussion - but yeah, I agree
<Laney> dholbach: have the candidates for CC written any kind of platform?
<Laney> I don't know how to choose between most of them tbh
<cjwatson> dholbach: right, more or less as pitti says.  We haven't brought them up yet, and conceivably, we might be close enough to being able to have dgit working that it might not be worth the effort.  And the auto-import branches have been so badly broken in so many ways for so long ...
<dholbach> some might have something up on their website, but as we were a bit late already, I didn't want to go through another round of "please write something and send a link back" before we announce
<dholbach> cjwatson, cool - thanks!
<cjwatson> ara: I have been complaining about that in the packaging guide for years :P
<ara> cjwatson, :)
<cjwatson> nothing ever happens because rah rah revision control (even if it's horribly broken)
<dholbach> ok... let's have a discussion about it and change it
<dholbach> I'm not sure if I'm seen as blocking this... because I'm happy for it to be changed
<caribou> pitti: systemd complains about some apparmor issue : http://paste.ubuntu.com/13237626/
<pitti> caribou: ah, I get that too
<pitti> sudo systemctl status apparmor -l
<pitti> Nov 12 08:34:00 donald apparmor[476]: AppArmor-Analysefehler f?r /etc/apparmor.d/usr.bin.webbrowser-app in /etc/apparmor.d/usr.bin.webbrowser-app in Zeile 26: >>/usr/share/apparmor/hardware/graphics.d<< konnte nicht ge?ffnet werden
<pitti> so apparently an error in webbrowser-app's apparmor profile
<pitti> but that should be moderately harmless
<pitti> why do I have webbrowser-app installed in the first place..
<seb128> pitti, we install it by default (should be cleaned out but we noticed that just before xenial and it was too late for such changes)
<pitti> seb128: s/xenial/wily/ I  suppose
<seb128> yes
<seb128> it's used by webapps but we don't install any by default so we don't need it on the iso
<caribou> pitti: I found my problem
<caribou> pitti: linux-image-extra for .18 is missing in the Xenial archive
<caribou> pitti: apw is looking into it
<pitti> caribou: oh indeed; I still have -16 installed
<caribou> pitti: I also had  .17 so going back to that one fixes my usb/sound/external display problem
<pitti> caribou: .17 is in -proposed still
<pitti> never ever (and I mean EVER) enable devel-proposed on a real machine
<pitti> devel-proposed by definition are all packages which are broken
<caribou> pitti: I don't have it enabled.
<caribou> pitti: apparently it is a miss from a CVE upload
<pitti> caribou: oh, wily now has a newer kernel than xenial? nice..
<caribou> pitti: no, xenial has linux-image-4.2.0.18-generic but it is missing linux-image-EXTRA-4.2.0.18-generic
<pitti> caribou: ok, so missing -extra does explain missing sound, graphics, and stuff
<caribou> pitti: yes
<caribou> pitti: thanks for diwic for nailing it down
<caribou> ok, rebooting to see if I get my password prompt
<diwic> yw
<pitti> hm, so wily-updates has 4.2.0-18.22, xenial has 4.2.0-16.19 , xenial-proposed has 4.2.0-17.21
<pitti> caribou: that explains why I didn't see that, as I dist-upgraded to xenial right away, before I got wily-updates bits
<pitti> diwic, caribou: thanks for tracking it down!
<caribou> pitti: well, that's the reason for running/upgrading to Xenial isn't it ?
<pitti> caribou: well, usually I'd expect the breakage to be in the devel series, not in the stable series
<pitti> in devel it would be "meh", but devel is fine
<pitti> it seems we completely screwed wily with that
<pitti> and that's in the "disaster" category
<pitti> caribou: or did I misunderstand this somehow? did you have -18 extras in wily, but it somehow got lost on the xenial update?
<pitti> linux-image-extra-4.2.0-18-generic | 4.2.0-18.22 | wily-security | amd64, i386, ppc64el
<pitti> ah no, *phew*
<pitti> caribou: so your -18 kernel got partially removed during the upgrade then?
<apw> pitti, the tl;dr was that the install of -18 was manual and not done completly, so all is understod and we're fine
<pitti> apw: ok, good
<apw> pitti, he wanted -18, but was on xenail where it did not exist
<caribou> pitti: no, dist-upgrade was complaining it couldn't find it in the archive so I went back to wily and manually installed _only_ the linux-image
<apw> pitti, and i've requested that be copied up to close this hole
<caribou> pitti: then dist-ugprade
<pitti> Laney, mvo: this works nicely: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=609c99
<pitti> Laney: and the .bomb() instead of .badpkg() will make it a tmpfail instead of a test fail, so hopefully these shoudl be gone
 * pitti runs a mass-retry to mop up the current failures
<pitti> I'm sure that we now find some tests which are genuinely broken but trigger this :)
<mvo> pitti: heh :)
<seb128> Laney, did you get a reply from dholbach earlier about the community council eventual programs? (didn't see you but there were cross discussions)
<Laney> seb128: "eventual programs"? nothing further no
<Laney> but I don't know what one of those is. :P
<seb128> sorry, I guess franglish
<Laney> platform is the thing I asked for
<seb128> you asked if candidates eventually had a platform
<Laney> don't think there is any central list of them
<seb128> k
<seb128> we use "programme" for "platform" in french
<Laney> ah
<seb128> I though "program" would work in this context in english
<seb128> sorry ;-)
<Laney> no worries
<seb128> like "having an agenda"
<cjwatson> It kind of works but wouldn't be the usual term
<seb128> I see
<dholbach> seb128, Laney: sorry - maybe I should have been clearer earlier.... we were a bit late with the election and I wanted to get it announced as opposed to mailing everyone again, asking for a platform to be written, pages updated, etc
<seb128> dholbach, no worry, but does it mean it's likely that some people will write something?
<seb128> or said differently is waiting likely to provide more details to make an informed choice?
<dholbach> seb128, I haven't pinged people yet, but I could do that - and send a mail with links to their wiki page in an update?
<seb128> dholbach, that would be nice
<dholbach> ok.......
<seb128> dholbach, don't feel like you have to do it, I was just asking in case because I don't know some of the candidates, but I opened their launchpad page which already gives some kind of idea
<dholbach> seb128, I would... but the wiki doesn't let me :-P
<seb128> heh
<Laney> doko: you here? can you take a look at phonon-backend-vlc maybe?
<Laney> (build failure, -fPIC stuff, I can't get it to build)
<jdstrand> pitti: the webbroswer-app bug is known. oSoMoN is working on it
<jdstrand> bug #1511439
<ubottu> bug 1511439 in webbrowser-app (Ubuntu) "webbrowser-app apparmor policy fails to load on desktop" [High,In progress] https://launchpad.net/bugs/1511439
<pitti> jdstrand: thanks
<jdstrand> pitti: do you need more for migration or is that enough?
<jdstrand> s/more/more info/
<pitti> jdstrand: oh, I was looking at that in the context of caribou's upgrade b0rkage, not proposed-migration
<jdstrand> pitti: ah. well, in either case, you can install apparmor-easyprof-ubuntu on the system or disable the profile with aa-disable
<jdstrand> and that should fix things. oSoMoN's fix will (obviously) also fix it, but it hasn't landed yet
<pitti> jdstrand: TBH I just purged webbrowser-app; seb128 said it's going away from the default install anyway, and I have no need for it
<jdstrand> pitti: heh, that is another option :)
<jdstrand> pitti: ok, looking at proposed migration, the regression has nothing to do with apparmor: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/systemd/20151112_015036@/log.gz
<jdstrand> FAIL: test_hotplug_dhcp_ip6 (__main__.TestNetworkd)
<pitti> jdstrand: no, that's a race condition in the networkd test, I'm aware of it
<jdstrand> AssertionError: nameserver 192.168.5.1 not found in /etc/resolv.conf
<jdstrand> ok
<pitti> (either in the test, or in the resolvconf integration, not sure yet)
<jdstrand> pitti: does that mean you'll handle the proposed migration for apparmor then?
<pitti> jdstrand: yes, will do
<jdstrand> pitti: thanks! :)
<oSoMoN> jdstrand, pitti: my fix for webbrowser-app is awaiting QA verification, will hopefully land soon
<pitti> doko: asking you because TIL: puppetmaster-passenger started to become uninstallable because it depends on the removed libapache2-mod-passenger; do you have any idea about that, or is that server team matter?
<pitti> ah, this was fixed in Debian
<pitti> so, merge o'clock
<pitti> doko: I can do the merge if you don't care, but would like to ask you first
<yofel> Laney: do you plan to merge lintian anytime soon?
<yofel> with debhelper updated all libraries in the kubuntu ci throw lintian errors about missing ldconfig calls. So if you don't plan to merge it soon I would give it a try.
<popey> Anyone else had apport just sit there chewing a cpu for _ages_ on xenial?
<popey>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
<popey>  5386 root      20   0  164460  82176   8768 R 100.0  0.5 124:53.76 apport
<popey> ahh, it's dealing with a caja crash, will poke flexiondotorg :)
<pitti> popey: is it actually writing a .crash file in /var/crash and is the crashed process still existing (in 'D' state)? or is it trapped in a post-crash loop?
<popey> nothing in /var/crash
<popey> was just sat there in a loop
<popey> alan     27679  0.0  0.3 1211948 62316 ?       Sl   Nov10   0:07 caja
<popey> thats the process it was dealing with
<pitti> popey: can you show me the tail of /var/log/apport.log? This caja process didn't even crash
<popey> -rw-r----- 1 root adm 0 Nov 11 07:39 /var/log/apport.log
<popey> :(
<popey> its a days old process, maybe an older apport log...
<ogra_> definitely a short tail
<pitti> popey: what's the full command line of that apport process?
<popey> root      5386 99.8  0.5 164740 85876 ?        R    12:29 125:47 /usr/bin/python3 /usr/share/apport/apport 27679 11 0 27679
<popey> http://paste.ubuntu.com/13238745/ is the previous apport log
<pitti> "another apport instance is already running, aborting", ah
<pitti> this makes no sense at all
<pitti> so caja crashed with SEGV (signal 11), the kernel called apport, but the process is still alive; it should go into 'D' and then die after core dumping
<pitti> popey: can you attach strace to apport for a bit and see what it's looping on?
<popey> I'd already killed it, sorry :(
 * pitti wonders if it's continuously reading some junk from the kernel as core dump data
<pitti> ok
<popey> It may happen again, I have seen this before
<popey> and if it does, I'll trace it
<Laney> yofel: I'll get to all my merges soon, been a bit busy shepherding some transitions
<yofel> Laney: ok, then I'll leave it to you as I would need a sponsor for it.
<yofel> thanks
<rbasak> tdaitx: how is the squid3 merge going?
<rbasak> tdaitx: no hurry, just checking it's not stuck.
<tdaitx> rbasak, hi there! well, it is stuck, but just because we didn't have time to work on it during the sprint =)
<rbasak> tdaitx: OK, no problem.
<doko> pitti, puppet is now demoted
<pitti> doko: i. e. does that translate to "I don't care, go ahead and merge", or something else? :-)
<rbasak> doko: I wasn't aware of any plan around puppet. Is that intended to be permanent?
<doko> pitti, the former ;p
<pitti> doko: ok :) I'll do that then to fix that again
<rbasak> doko: I wasn't aware of any plan around puppet. Is that intended to be permanent?
<smoser> doko, can you give some background on that ? i think that i've seen something around it, but dont remember the details.
<infinity> Whatever was pulling it into main must have stopped...
<rbasak> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.xenial/revision/2008
<infinity> Ahh.
<infinity> doko: Yeah, why was that done? :P
<infinity> doko: supported != shipped, so that has no effect on images.
<smoser> hey. i need to fix http://pad.lv/1515661
<ubottu> Launchpad bug 1515661 in cloud-initramfs-tools (Ubuntu Precise) "SRU:add cloud-initramfs-copymods to 12.04" [Medium,Confirmed]
<smoser> the easiest thing to do would be to take the trusty-updates version and get it to precise.
<smoser> trusty-updates is 0.25ubuntu1.14.04.1
<doko> rbasak, infinity: puppet was only needed by IS, and isn't anymore. I didn't get any reply from the server team that it is still needed.
<rbasak> doko: I wasn't aware that you asked. Where did you ask?
<rbasak> doko: I'd prefer us to make a considered decision on whether we want it in main rather than have it ripped out from under us.
<doko> rbasak, nothing is permanent until the release is done
<rbasak> doko: I wasn't aware that you asked. Where did you ask?
<doko> rbasak, by email
<rbasak> To whom?
<seb128> doko, hey, did you see my llvm/SRU question this morning?
<doko> seb128, yes, but I didn't look at it yet. the issue is that backported llvm 3.7 packages need a different library package name when built with GCC 4.9 or earlier
<seb128> doko, speaking of gcc, apparently the wily packages are built with 4.9 instead of 5 due to an issue with the debian/rules regexp issue, unsure if changing the gcc version is material for a SRU?
<tdaitx> slangasek, when configuring my system to work on a high dpi display I noticed that console-setup, console-setup-linux, and keyboard-configuration have upstart scripts, but only keyboard-configuration has a systemd service, thus the font I selected on console-setup is never applied on boot time (there are open bugs for that)
<tdaitx> is that the expected behavior or somtehing that needs fixing?
<doko> seb128, afaics, it's not yet used, so maybe nobody cares (and somebody should address the ftbfs on i386 and powerpc)
<seb128> doko, there is a bug reported so I guess some people care
<seb128> and ack on the build issues
<tdaitx> slangasek, apart from that, I find it a bit weird that keyboard-configuration init/systemd service is named console-setup and its initram hook also handles font and depends on stuff setup by setupcon (setupcon is from console-setup, which actually depends on keyboard-configuration, not the other way around)
<slangasek> Mirv: do you have any clues about this x86-only build failure in phonon-backend-vlc? it looks like something internal to cmake+qt5 rather than a bug in phonon-backend-vlc's code:
<slangasek> In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtGlobal:1:0,
<slangasek>                  from /Â«PKGBUILDDIRÂ»/obj-qt5/CMakeTmp/check_qt_visibility.cpp:1:
<slangasek> /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1052:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)."
<slangasek>  #  error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
<slangasek> tdaitx: console-setup/keyboard-configuration have a very long history, and it's possible the current state includes some historical reasons.  And if the configured console-setup font is not applied at boot, yes, that's a bug and quite possibly related to this
<slangasek> tdaitx: cyphermox would have some recent context about console-setup; pitti might know a thing or two about how systemd expects to set console fonts
<doko> slangasek, this popped up a lot during the last cycle. iirc, the "solution" was to remove -fPIE and add -fPIC.
<doko> sbeattie, ^^^
<slangasek> doko: well, but this package isn't passing -fPIE
<doko> but -fPIC?
<slangasek> doko: no - I mean that -fPIE is being passed but not by this package
<slangasek> maybe it comes from /usr/share/phonon4qt5/buildsystem/FindPhononInternal.cmake
<Odd_Bloke> Is there an email from gaughen_ sitting in the ubuntu-devel@ moderation queue?
<slangasek> there's a KDE4_ENABLE_FPIE
<Odd_Bloke> (And if so, who can unblock it?)
<slangasek> Odd_Bloke: I think cjwatson has moderation privs there; not sure who else might
<Laney> me, nothing there
<Laney> Odd_Bloke: ^
<gaughen_> Laney, sweet, thanks!
<nemo> FWIW, I finally solved the problem that I came by here to figure out:
<nemo> https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770/comments/1
<ubottu> Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed]
<nemo> all better
<nemo> 'course, IMO there's a couple of broken packages there, but whatev âº
<nemo> works for me! ð
<doko> $ simple-scan
<doko> simple-scan: error while loading shared libraries: libpackagekit-glib2.so.16: cannot open shared object file: No such file or directory
<doko> seb128, ^^^ can you reproduce this? or was this something part of wily-proposed which didn't go into the release?
<seb128> doko,
<seb128> $ dpkg -S libpackagekit-glib2.so.16
<seb128> libpackagekit-glib2-16:i386: /usr/lib/i386-linux-gnu/libpackagekit-glib2.so.16
<seb128> do you have that package?
<doko> $ dpkg -S libpackagekit-glib2.so.18
<doko> libpackagekit-glib2-16:amd64: /usr/lib/x86_64-linux-gnu/libpackagekit-glib2.so.18
<doko> libpackagekit-glib2-16:amd64: /usr/lib/x86_64-linux-gnu/libpackagekit-glib2.so.18.0.0
<doko> so, maybe left over from using -proposed during the GCC 5 transition
<seb128> doko, yes, that version of packagekit was in proposed only and breaking aptdaemon and never migrated/was removed
<doko> ahh, I remember ...
<seb128> but the binary should depends on the lib it uses
<slangasek> how does anyone debug cmake, ever?
<seb128> so looks like there is a bug
<Laney> slangasek: I just pinged mitya57 about this and he said he'd look, FYi
<Laney> I
<Laney> as a more qualified cmaker than me
<slangasek> Laney: alright; my question stands
<slangasek> this is untraceable spaghetti
<slangasek> check_cxx_compiler_flag(-fPIE HAVE_FPIE_SUPPORT)
<slangasek> so OBVIOUSLY that causes all tests to immediately start using that flag
<mitya57> I don't understand why this bug doesn't happen in Debian
<mitya57> In simple case one just needs to add something like set(CMAKE_CXX_FLAGS "-fPIC") and that will work. But looks like it's a bit more complicate here.
 * mitya57 is not a CMake expert unfortunately
<slangasek> I can't find anything in the cmake code that explains why -fPIE is being used
<slangasek> maybe you'll have better luck than me
<slangasek> mitya57: Debian version of libphonon4qt5-dev doesn't include the check for -fPIE
<mitya57> ah, I thought that warning was coming from Qt itself
<mitya57> Actually I believe adding actually set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}") to CMakeLists.txt will just work
<slangasek> maybe it's worth checking if this is fixed by a phonon merge from unstable
<cyphermox> tdaitx: what about console-setup/keyboard-configuration?
<slangasek> since there are (surprising) differences in the installed cmake rules, and Debian doesn't have this problem
<tdaitx> cyphermox, well, I set up a new font and keyboard layout for the new computer, but only the keyboard layout is being applied on boot... I'm investigating what I might be missing in my initramfs config, but anyway I noticed that console-setup, console-setup-linux, and keyboard-configuration have upstart scripts, while only keyboard-configuration has a systemd service, so the console font is not being set
 * Laney stares at gstreamer-vaapi
<Laney> ah right, probably just skew
<cyphermox> tdaitx: interesting. text-mode console font?
<tdaitx> cyphermox, yes
<cyphermox> as you expect this would be applied in initramfs, before systemd, no?
<cyphermox> which font, for fun? if I want to install it here?
<tdaitx> it should be
<tdaitx> CODESET="Lat15"
<tdaitx> FONTFACE="TerminusBold"
<tdaitx> FONTSIZE="16x32"
<tdaitx> cyphermox, ^
<cyphermox> yep, will apply this here on my temporary laptop, while the tech finishes changing the mobo
<tdaitx> cyphermox, you might want to use a smaller one =)
<tdaitx> in case you dont have a high dpi display
<seb128> tjaalton, is anyone looking at bug #1510970
<ubottu> bug 1510970 in xserver-xorg-video-intel (Ubuntu) "Intel driver crashes on Ubuntu 15.10" [Medium,Confirmed] https://launchpad.net/bugs/1510970
<seb128> seems lamont is able to reproduce easily
<lamont> well, easily is more one of "I do things, and it gets mad sometime with in about 10 minutes of normal work on my laptop"
<lamont> but yeah, it reproduces on an alarmingly easy basis
<cyphermox> tdaitx: I see so well that this is a great font size for me ;)
<cyphermox> yay, I gotz new variables now.
<tdaitx> cyphermox, sorry, my battery ran out
<tdaitx> cyphermox, heh, nice
<cyphermox> tdaitx: so, I agree, needs some systemd magic
<cyphermox> but it should also get applied before then in initramfs and it doesn't seem to be
<lamont> dbg package installed, laptop rebooting for a known-fresh start, let see how hard it falls over now
<tdaitx> cyphermox, indeed, I'm trying to figure out why
<cyphermox> it should be run setfont in init-top though
<bdmurray> hallyn: The T upload for bug 1511830 seems to be missing.
<ubottu> bug 1511830 in libvirt (Ubuntu Trusty) "apparmor denies VM startup when image is network mounted" [High,New] https://launchpad.net/bugs/1511830
<hallyn> bdmurray: correct
<hallyn> when i uploaded those on 11/04 i was still waiting for libvirt to clear t-proposed
<hallyn> in fact i still am
<Unit193> hallyn: Re: ubuntu-vm-builder.  Looked into vmdebootstrap?
<hallyn> Unit193: in what sense?  I encourage anyone rdep'ing on vmbuilder to switch over :)
<hallyn> i don't think it was around last time i tried to drop vmbuilder
<hallyn> (from the archive)
<hallyn> currently rdeps are sandbox-upgrader and auto-upgrade-tester
<Unit193> Aha, so yes.  Nice.
<hallyn> any chance you'd have time to work on proposed debdiffs to move those over? :-)
<slangasek> Laney, mitya57: well hey, it seems that this same failure causes phonon itself to FTBFS; so the problem lies deeper yet
<Laney> I'm sad that I don't get to do the last upload. :)
 * Laney has to go
<Unit193> hallyn: That's not actually directed at me is it?
<hallyn> <shrug>
<Unit193> (That is, never touched those, not a core dev.)
<lamont> seb128: so much for "trivial reproduction"
<lamont> once I get it to die, I'll update 1510970
<seb128> lamont, :-(
<seb128> thanks
<lamont> seb128: it did seem to always be around a popup window being created, fwiw
<seb128> write that on the bug when you get the bt
<seb128> then we can do some nagging upstream ;-)
<lamont> tbf, if -dbg makes it go away, ... :D
<seb128> I doubt it, -dbg doesn't change runtine
<seb128> runtime
<seb128> those are just files on the side that gdb uses
<lamont> yeah
 * lamont otp meeting
<hallyn> Unit193: s'ok, you can still post debdiffs :)
<lamont> seb128: tbf, when I installed -dbg, it upgraded the driver too
<lamont> I'm tempted do downrev and grab the matching -dbg
<seb128> lamont, it's likely that the update fixed it, dholbach had a similar issue and tjaalton said the new git snapshot in xenial included fixes for some similar issues
<seb128> we should still find the fix for that issue and SRU it
<seb128> so having a debug bt of the old version would be useful
<seb128> could help to find the corresponding upstream bug/commit
<lamont> sure
<lamont> reboot for cleanstart with old version
<tdaitx> cyphermox, ok, there is a mismatch between the console-setup (re)configure script and the initramfs hook+init-top
<tdaitx> cyphermox, for a start, the configure script setups the size as 16x32 and writes that to /etc/default/console-setup as FONTSIZE. AFAICS the font name is in the format 32x16
<tdaitx> setupcon does detect and handles that, inverting it to 32x16 before searching for the font file, then copies that file to /etc/console-setup
<tdaitx> the initramfs hook and init-top scripts for console-setup use the value from /etc/default/console-setup (16x32) so they wouldn't find the font
<tdaitx> and, second, the font is saved to /etc/console-setup as a .gz file, but the initramfs hook and script expect a .psf file not a .gz file
<tdaitx> cyphermox, also, /etc/default/console-setup has an example for using FONT='font1 font2', that works fine for /bin/setupcon but it does not work as expected for both console-setup initramfs hook and init-top script
<tdaitx> seems like console-setup needs some love
<tsimonq2> is there a channel in which to ask about the Launchpad API? #launchpad maybe?
<cjwatson> tsimonq2: #launchpad is fine
<tsimonq2> cjwatson: ok, thanks
<Noskcaj> When are the UDD branches expected to appear?
<cjwatson> Noskcaj: it is possible that they will not.  we're still deciding
<cjwatson> it is a fair bit of work to bring them up and it's not clear it's worth it given how badly broken they are in so many cases
<cjwatson> it depends somewhat on whether we can make progress with dgit in a reasonable time
<Unit193> What about something ala sources.d.net?  And dgit, hrm..
<Noskcaj> ok
<cjwatson> Unit193: I would love to do sources.d.n but it's not clear when :-)
<cjwatson> I think dgit is more urgent
<Unit193> cjwatson: ..And all those other things you need to fix first, as well as all those other things you'd like to do.  As of yet I've ignored dgit because I don't have upload perms, is there a testing ground for it?
<cjwatson> Unit193: not quite that far along yet, current state is https://code.launchpad.net/~cjwatson/launchpad/sourcefileurls-include-meta/+merge/276928
<Unit193> (I was referring to Debian's use in terms of ignoring it.)
<Unit193> Ah, cool
<cjwatson> then I need to test out the WIP patch I have to make dgit support Launchpad at all (it needs to query its API for a few things, mostly), and then we have two things to do roughly in parallel, which are (a) figure out how on earth to implement something akin to dgit-repos-server's push policy in turnip (the LP git backend), and (b) make lp:ubuntu/+source/<source> git repositories work, mainly hooking them up to upload permissions
<cjwatson> and then figure out and deploy a mass importers
<cjwatson> *importer
<cjwatson> it's not intractably complex but there's a reasonable amount to do
<tjaalton> seb128, lamont: oh right, apparently the new snapshot works better, so the fix should ne bisectable
<tjaalton> *be
<Mirv> slangasek: Laney mitya57: it should be patched to ban -fPIE like required with GCC5 (on x86, where Qt autodetecs and enables the -reduce-relocations option qtbase). something similar to what you did Laney here https://launchpad.net/ubuntu/+source/poppler/0.33.0-0ubuntu3
<slangasek> Mirv: do you know where this -fPIE is coming from in the first place?  This is somewhere deep in the build-dependencies; we shouldn't patch every leaf package that's getting bitten by wrong cmake checks
<Mirv> another example http://launchpadlibrarian.net/214075540/gnuplot5_5.0.1%2Bdfsg1-2build1_5.0.1%2Bdfsg1-2ubuntu1.diff.gz
<Mirv> slangasek: I'm not sure, those two examples were from hardening flags, +all includes -fPIE
<Mirv> most leaf packages, also CMake, have worked without changes
<Mirv> and in this example, which may be the last one that was done during wily, set -fPIE itself http://launchpadlibrarian.net/213155371/pay-service_2.0.0%2B15.10.20150727-0ubuntu1_2.0.0%2B15.10.20150730-0ubuntu1.diff.gz
<slangasek> it's not coming from either phonon or phonon-backend-vlc; both packages FTBFS but the -fPIE is coming from somewhere else
<Mirv> slangasek: phonon has  check_cxx_compiler_flag(-fPIE HAVE_FPIE_SUPPORT) and that would look to be there in the phonon-backend-vlc build log
<slangasek> Mirv: yes, there's a check for whether the compiler flag is supported; but that shouldn't cause it to be used automatically for all tests...
<Mirv> if it has it, it seems to set (KDE4_CXX_FPIE_FLAGS "-fPIE")
<Mirv> (reading FindPhononInternal.cmake)
<Mirv> but there's also KDE4_ENABLE_FPIE coming from somewhere
<davmor2> Mirv: what are you even doing online isn;t like 2am for you? ;)
<slangasek> Mirv: but doing set(KDE4_ENABLE_FPIE) in phonon-backend-vlc's CMakeLists.txt doesn't seem to do any good; and I can't find anything that's setting it, anywhere under /usr
<slangasek> there's basically *nothing* that says PIE, in the build tree or in the build-deps
<Mirv> davmor2: going to sleep :) not 2am, just early mornings
<elbrus> pitti: I missed that encoding error, let me think about that one (but it works on other archs, so I think it is not correct to fail on it.
<Mirv> slangasek: I need to go, but this sounds related https://git.reviewboard.kde.org/r/123874/diff/2#index_header
<Mirv> also in Debian http://anonscm.debian.org/cgit/pkg-kde/kde-req/phonon.git/commit/?id=7b0e6608211707c91b52833adc23f6d9295a6916
<Mirv> maybe this "small" commit too http://anonscm.debian.org/cgit/pkg-kde/kde-req/phonon.git/commit/?id=c78af618d090b3ee7fd9e124c25e1568b20fa9b3
<Noskcaj> Are we ok to sync gpgme1.0 from debian? the default install now carries pinentry-gnome3 and gnupg2
<slangasek> Mirv: aha!  strange that I didn't see that in the diff with Debian...
<rodrigc> is anyone here working on Python 3 ( https://wiki.ubuntu.com/Python/3 )?
<teward> when someone files a bug, is there a reason apport wouldn't work with the package hooks
<lamont> tjaalton: seb128: sadly, I left the laptop power supply at home this morning, so ... :(
#ubuntu-devel 2015-11-13
<pitti> teward: no, in general package hooks are being run
<pitti> teward: they might cause an exception of course, and then will be ignored
<pitti> mdeslaur: hm, you changed the pythons to rely on the new value of the -proposed openssl, not to work with either
<pitti> but no bump of dependencies, so they block each other in -proposed now
 * pitti re-runs the two proposed versions against each other
<darkxst> pitti, your piloting today? can you take a look at bug 1509946, i can't upload since its a new source package with the gdm3 rename
<ubottu> bug 1509946 in gdm (Ubuntu) "Update to 3.18.0" [Wishlist,Triaged] https://launchpad.net/bugs/1509946
<pitti> darkxst: oh, am I? indeed
<darkxst> pitti, that is what the calender says!
<pitti> darkxst: I'll have a look soon then
<darkxst> pitti, thanks
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<elbrus> pitti: do you now if the locale settings are different on the different autopkgtest machines for different archs?
<elbrus> we propably found an issue with locales, postgresql and dbconfig-common
<pitti> elbrus: autopkgtest always sets C.UTF-8 for the tests
<elbrus> LC_ALL I assume?
<pitti> elbrus: sorry, I didn't have time to look into the armhf failure yet, but still on my list
<pitti> elbrus: no, LANG=C.UTF-8 and it unsets all LC_*
<elbrus> doesn't look like regression.. this probably never works under the same circumstances
<pitti> and unsets $LANGUAGE too
<elbrus> where does the en_US come from then?
<elbrus> pitti: and "LC_CTYPE setting requires encoding "LATIN1""
 * elbrus doesn't know all the details of locales
<pitti> en_US> no idea right now; but I don't see LATIN1 anywhere in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_152940@/log.gz
<pitti> oh, that's the "hostname: Temporary failure in name resolution" bit
<elbrus> pitti: it was the next log that failed on locale, this one failed on hostname not found
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_084807@/log.gz
<pitti> right
<elbrus> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_084807@/log.gz
<elbrus> yes
<elbrus> pitti: I think postgresql is installed with the wrong locale, but why only on armhf? i.e. why doesn't this happen on all archs the same?
<elbrus> and yes, for utf-8 to work the locale should have been en_US.UTF-8
<elbrus> during INSTALL of postgresql, so out of control of dbconfig-common
<pitti> elbrus: the biggest difference between armhf and the other arches is that we run armhf tests in LXC containers, the others in full (QEMU) instances in the cloud
<pitti> so far I don't know where the en_US comes from, it's neither from dbconfig-common nor postgresql-common
<elbrus> indeed
<elbrus> pitti: do you think there is anything that I can do at this moment?
<pitti> currently running this locally with lxc
<elbrus> ack
<pitti> to see if it reproduces there
<pitti> (i. e. on amd64)
<elbrus> aha, to check if it is lxc thingy
<elbrus> my lxc's work fine
<pitti> first run failed becuse it interactively asked for some host name
<elbrus> (I did all my testing creating the autopkgtest in a lxc)
<pitti> now running with < /dev/null to quiesce that
<elbrus> but I didn't do anything specific to the locales
<elbrus> so I got the Debian default
<pitti> might that be some default value of "locales" on installation if you don't specify anything?
<elbrus> you mean in postgresql? it takes it from the system, yes (reading on internet)
<elbrus> specifically LC_CTYPE
<pitti> passes here
<pitti> so, this needs to be investigated on the armhf machiens
<elbrus> and LC_COLLATE
<pitti> ah, maybe debootstrap defaults to en_US; adt-run sets LANG=C.UTF-8 into the test env, but it doesn't change /etc/default/locale
<pitti> but then this should apply to amd64 containers too
<pitti> really, need to find some time to look into this
<elbrus> does it makes sense to mark armhf as failed_always then for now? This is a new autopkgtest that fails.
<pitti> I can't specifically mark armhf, but I can mark the test as broken for now
<elbrus> the previous one on willy was only one test, I now have three
<elbrus> ouch
 * elbrus wonders how many dbconfig-common based packages are actively setting the encoding (and thus may be buggy in this sense)
<pitti> elbrus: the production boxes have
<pitti> # cat adt-xenial/rootfs/etc/default/locale
<pitti> #  File generated by update-locale
<pitti> LANG=en_US.UTF-8
<pitti> elbrus: while my local container has LANG=de_DE.UTF-8; apparently it takes that from the environment you create the container in
<pitti> so if anything, it ought to work *worse* in  my local one..
<elbrus> yes, but it is utf-8
<pitti> but I don't see en_US anywhere; and that's latin1, and just ought to die, die, die
<elbrus> so that's fine.
<elbrus> also not on the system that created the lxc?
<pitti> no, that's en_US.UTF-8 too
<pitti> elbrus: we never supported/created non-UTF-8 locales in ubuntu (aside from C)
<pitti> so, where on earth does that come from
 * elbrus has to go for a while...
<LocutusOfBorg1> pitti, why llvm-3.7 doesn't migrate? the previous one didn't build on i386 and powerpc too
<seb128> LocutusOfBorg1, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<seb128> LocutusOfBorg1, I think it was in binNEW
<seb128> unsure when the binaries got NEWEd and if britney refreshed since
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#llvm-toolchain-3.7 in particular
<pitti> right, NEW is empty now, so perhaps someone just did that
<rbasak> So I'm working on merging monitoring-plugins, and the Debian maintainer would prefer to take patches and not have us maintain a delta in Ubuntu. But we need to drop a build dep in Ubuntu because it's in universe.
<rbasak> Am I right in thinking that there's no way to do this conditionally based on dpkg-vendor, since it's a build dep?
<LocutusOfBorg1> thanks
<Unit193> rbasak: Unless there's something new, correct.
<rbasak> Unit193: thanks.
<seb128> wooot pitti piloting
<seb128> there goes the remaining for the queue! ;-)
 * seb128 donne une accolade Ã  pitti
 * pitti te donne une accolade en retour
 * dholbach hugs pitti
 * pitti hugs dholback
<Unit193> dhugbach
<dholbach> :-)
<LocutusOfBorg1> wow, how many merges done in a few minutes
<seb128> pitti, unsure how much of the queue you are going to cover but you might want to look at bug #525674 you already reviewed/commented on it in a previous round
<ubottu> bug 525674 in update-notifier (Ubuntu) "apt-check hangs, preventing login via SSH" [Medium,Confirmed] https://launchpad.net/bugs/525674
<pitti> meh @ bug 1498370
<ubottu> bug 1498370 in neutron (Ubuntu Trusty) "[SRU] DHCP agent: interface unplug leads to exception" [Undecided,Incomplete] https://launchpad.net/bugs/1498370
<pitti> this is a sponsor's waste of time
<pitti> seb128: looking
<seb128> pitti, danke
<pitti> seb128: meh, u-n is currently FTBFS
<pitti> Err http://localhost:59762/canary-file.txt
<pitti>   403  Forbidden file type or location: http://localhost:59762/canary-file.txt
<pitti> E: Failed to fetch http://localhost:59762/canary-file.txt  403  Forbidden file type or location: http://localhost:59762/canary-file.txt
<pitti> what on earth should that be
<seb128> bah :-/
<Laney> mvooooooooooooooooo
<pitti> ah, it trips over my proxy setting in the shroot
<pitti> disabling it helps
<pitti> seb128: there goes the remaining for the queue> can't -- I dealt with some 15 items in the queue, but it grows so far
<pitti> fast
<pitti> I started with 48, it's still at 43..
<pitti> ok, and at least 4 just lag due to build/proposed-migration
<seb128> pitti, sorry, I added some :-/
<doko> somebody just unblocked the ocaml/giflib/whatever transition. ta!
<seb128> I do review +patches sometimes
<seb128> doko, beers go to Laney I think
<seb128> though I pressed some buttons so I wouldn't say no to a pint as well :p
<doko> seb128, next sprint or Debconf ;p
<seb128> deal :-)
<Laney> was a good team effort
<Laney> sil2100: slangasek: seb128: good work
<Laney> woah, you all start with s
<seb128> hehe
<seb128> indeed was a good team effort
<sil2100> \o/
 * sil2100 just got spammed with no-change rebuild migration e-mail
<mdeslaur> pitti: huh? It should work with either
<cjwatson> stgraber,hallyn_: did lxc break in xenial recently?  http://paste.ubuntu.com/13247579/
<cjwatson> (repeatable: I can't start any of my containers at the moment)
<cjwatson> upgraded to lxc 1.1.5-0ubuntu1 last night, I expect it relates to that
<pitti> wily and xenial containers start fine here, I don't have a trusty one at hand
<pitti> (same lxc version)
<pitti> oh, I do have trusty containers as user container, not system one; that works too
<cjwatson> same with precise containers
<cjwatson> I don't have any containers newer than trusty ;-)
<pitti> cjwatson: we clearly work on different things :)
<cjwatson> I've also just rebooted, that made no difference
<cjwatson> pitti: are you running a wily/xenial kernel?
<cjwatson> clone(child_stack=0x7ffde67d2280, flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = 6324
<cjwatson> certainly seems odd ...
<pitti> cjwatson: xenial du jour
<cjwatson> access("/proc/6324/ns", X_OK)           = 0
<cjwatson> open("/proc/6324/ns/mnt", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
<pitti> 4.2.0-17-generic
<cjwatson> ditto
<pitti> cjwatson: is your's a system or user container?
<pitti> I tried trusty/user (unpriv) and {wily,xenial}/system, not yet trusty/system
<cjwatson> system
<pitti> lxd also works, but that's more like user containers
<cjwatson> I'm sure I probably should migrate to user containers for a bunch of things, but haven't yet
 * pitti runs $ sudo lxc-create -n trusty1 -t download -- -d ubuntu -r trusty -a amd64
<pitti> boots fine
<cjwatson> pitti: same thing for me after "sudo lxc-create -n trusty-test -t ubuntu -- -r trusty"
<cjwatson> it doesn't really seem to be about the container contents though, given that strace fragment
<pitti> cjwatson: do you get an AA violation in dmesg?
<pitti> $ LANG= cat /proc/$$/ns/mnt
<pitti> cat: /proc/3924/ns/mnt: Invalid argument
<pitti> hm, that's a bit odd, but not EACCESS
<cjwatson> strace: http://paste.ubuntu.com/13247663/
<cjwatson> pitti: no
<pitti> 1961  access("/proc/1974/ns", X_OK)     = 0
<pitti> 1961  open("/proc/1974/ns/mnt", O_RDONLY|O_CLOEXEC) = 15
<pitti> 1961  open("/proc/1974/ns/pid", O_RDONLY|O_CLOEXEC) = 16
<pitti> 1961  open("/proc/1974/ns/uts", O_RDONLY|O_CLOEXEC) = 17
<pitti> 1961  open("/proc/1974/ns/ipc", O_RDONLY|O_CLOEXEC) = 18
<pitti> 1961  open("/proc/1974/ns/net", O_RDONLY|O_CLOEXEC) = 19
<pitti> here
<pitti> stgraber: please fix the strcmp(pw->pw_nam, "cjwatson")
<cjwatson> let's try downgrading lxc
<cjwatson> starts fine with lxc 1.1.4-0ubuntu3
 * cjwatson files https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1516037
<ubottu> Launchpad bug 1516037 in lxc (Ubuntu) "lxc-start fails with 1.1.5-0ubuntu1" [Undecided,New]
<hallyn_> cjwatson: very odd.  grabbing the 1.1.4-0ubuntu3 source to looka t debdiff...
<stgraber> hallyn_: hmm, why did preserve_ns kick in here
<stgraber> hallyn_: FYI, that's 1.1.4 to 1.1.5: http://paste.ubuntu.com/13248147/
<stgraber> 8cecbd386123dfcb291b96b23a38fb9d74d2ea3b preserve container namespace
<stgraber> 5b657f6bfee3d6b238a37ad2f3dcac37a224a333 start.c:preserve_ns: added pid parameter
<stgraber> hallyn_: those are the most likely candidate ^
<hallyn_> stgraber: wondering whether getpid() is returning invalid number
<stgraber> hallyn_: the thing is, I'm not seeing the getpid which returned 7170 in cjwatson's strace but 7170 is the pid of one of our sub-processes
<stgraber> hallyn_: what doesn't make sense is that my reading of the code is that getpid and preserve_ns are happening in the same process, so I don't understand why getpid would have happened in 7170 and then preserve_ns in 7160
<stgraber> hallyn_: not that any of this really explains everything, we're talking privileged container here, lxc-start is root, so permission denied shouldn't be possible...
<stgraber> hallyn_: getting no such file or directory would indicate an invalid pid but here the process does seem to exist
<stgraber> Anyway, I'm updating my laptop, will then reboot and see if I've got any luck at reproducing this. Also asked a few more question for cjwatson in the bug report.
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<stgraber> hallyn_: oh, nevermind that part, the failing preserve_ns is the second one, which uses handler->pid
<hallyn_> hm
<stgraber> hallyn_: at this point, I think we'd need to go dig in the kernel to figure out in what case can we get EACCES as root
<stgraber> hallyn_: because AFAICT, lxc_clone succeeds, we get a valid pid back, then we attempt to open ns/mnt and get EACCES, so the process does exist, we are root and we can't open ns/mnt
<hallyn_> stgraber: but pitti said itworked for him on xenial
<hallyn_> so it's even more weird, whatever's going on
<stgraber> hallyn_: yep, and so does it here :)
<stgraber> and in autopkgtest and in upstream jenkins
<stgraber> hallyn_: also what's odd is that it's the open that's failing. Usually we see errors at setns instead :)
 * hallyn_ thinks ptrace is involved somehow,
<hallyn_> yama
<stgraber> hallyn_: something else which doesn't make sense is that looking at the code, we call preserve_ns twice but the strace from cjwatson only shows the second
<stgraber> oh, no, nevermind, I'm blind
<stgraber> was grepping for /ns/ which didn't get me the first access with just /proc/7160/ns
<stgraber> hallyn_: and yeah, that's very much smells like a LSM messing with things but dmesg is clean...
<cjwatson> I can get a full dmesg if you need it, but the relevant bits were basically just witter about network interfaces coming up and down
<stgraber> If there was a denial, you'd have seen it. Unfortunately, LSMs don't have to log.
<stgraber> cjwatson: just to confirm it's not some apparmor weirdness, could you unload all profile (sudo /etc/init.d/apparmor teardown) and try again?
<cjwatson> just a minute while I stop containers
<stgraber> it sure looks like something wrong's going on in the kernel here but I have no idea why it's apparently only hitting your system :)
<cjwatson> stgraber: what's the restoration process after teardown?  reboot?
<stgraber> cjwatson: /etc/init.d/apparmor start will reload all the profiles but won't apply them to running processes, for that you'd need to restart the various services, or indeed, reboot
<cjwatson> stgraber: well, you're right, tearing down apparmor lets the container start
<stgraber> oh, that's interesting
<stgraber> cjwatson: can you try starting apparmor again and confirm that things fail again?
<stgraber> for lxc specifically, no reboot should be required, just start apparmor and start the container again
<hallyn_> any chance you customized your usr.bin.lxc-start profile at some point?
<cjwatson> stgraber: it still works
<hallyn_> !
<cjwatson> hallyn_: it is not impossible
<stgraber> well, I didn't expect that one :)
<cjwatson> /etc/apparmor.d/local/usr.bin.lxc-start has nothing
<hallyn_> do you have dpkg-backup copy of /etc/apparmor.d/abstractions/lxc/start-container by chance?
<cjwatson> http://paste.ubuntu.com/13248531/
<hallyn_> (which doesn't contain "ptrace,")
<cjwatson> no .dpkg-foo files for that
<stgraber> ok, let me grab the magic apparmor command that dumps things in a way we can diff
<stgraber> not that any of this really makes sense because if it's a subtile profile difference, starting apparmor would have caused the issue to re-appear
<stgraber> root@castiana:~# apparmor_parser -p /etc/apparmor.d/lxc-containers /etc/apparmor.d/usr.bin.lxc-start | md5sum
<stgraber> cd7c4c6466b21dc77bea45660674c933  -
<stgraber> that's on clean xenial (reproducible) ^
<cjwatson> 8e3943455937a5a09eccfa742d8c58c1  -
<stgraber> oh
<stgraber> can you dump the output somewhere?
<cjwatson> it won't have anything private, right?
<cjwatson> doesn't especially look like it
<stgraber> correct, it's just the expanded version of the lxc profile
<cjwatson> http://paste.ubuntu.com/13248559/
<stgraber> -/usr/bin/lxc-start flags=(attach_disconnected) {
<stgraber> +/usr/bin/lxc-start {
<stgraber> and some different ordering (not as reproducible as it looks, then), but the above could very well explain what you're seeing
 * stgraber applies same change as cjwatson's usr.bin.lxc-start and reboots
<stgraber> reminds me I need to talk to pitti about my laptop not shutting down properly (have to wait the 1m30 timeout for systemd to give up and force reboot)
<stgraber> lxc-start: start.c: preserve_ns: 156 Permission denied - failed to open '/proc/1937/ns/mnt'
<stgraber> cjwatson: bingo, that's the issue!
<stgraber> cjwatson: so restore your /etc/apparmor.d/usr.bin.lxc-start to what we ship in our package and you should be fine. (clean content is http://paste.ubuntu.com/13248615/)
<hallyn_> stgraber: i accept that that's what did it, but it doesn't really make sense.  /proc/pid/ns/mnt should not have been disconnected!
<hallyn_> unless apparmor treats all the ns fds as disconnected
<hallyn_> since the fs isn't mounted anywhere
<hallyn_> 'fs'
<hallyn_> jjohansen: ^ do you know whether that's the case?
<cjwatson> no idea how that happened - I might have modified that in the distant past
<stgraber> also, it's kinda annoying that "/etc/init.d/apparmor reload" no longer works in xenial, triggers some systemd thing which fails...
 * stgraber reboots again
<stgraber> the upside is, lxc in xenial actually works so I can get back to preparing my current upload and don't have to wait for us to bundle another bugfix in there :)
<stgraber> cjwatson: can you confirm that restoring the profile to its default value and rebooting (unless you find a way to avoid the systemd issue and call reload) fixes things for you?
<cjwatson> stgraber: confirmed, thanks
<stgraber> cjwatson: great, closing the bug then
<cjwatson> I removed the file and used dpkg -i --force-confmiss
<stgraber> ah yeah, that'd trigger our postinst which does a straight apparmor_parser call :)
<cjwatson> well, I rebooted too :)
<cjwatson> thanks for the debugging help, that was pretty opaque to me
<hallyn_> stgraber: well there is https://bugs.launchpad.net/bugs/1516008 but it's clearly a kernel (likely aa) regression (regarding xenial  lxc bugs :)
<ubottu> Launchpad bug 1516008 in lxc (Ubuntu) "lxc: adt testing against v4.3 kernel failing" [Undecided,New]
<stgraber> hallyn_: no, it's not
<stgraber> hallyn_: it's just the cloud-image stream being broken, has been for days
<stgraber> hallyn_: see, it's downloading xenial-server-cloudimg-amd64-lxd.tar.xz instead of xenial-server-cloudimg-amd64-root.tar.xz
<hallyn_> doh.  i looked for that in the report but missed that failure
<hallyn_> just saw the missing /etc/localtime or whatever
<stgraber> so it's an "expected" failure until Odd_Bloke, utlemming, gaughen, rcj ... fix the daily stream
<stgraber> apw: ^ FYI, I'll be closing your bug report against lxc as invalid, the problem is a broken simplestream which I've mentioned to the CPC team a week ago and hasn't been fixed yet
<stgraber> I'm just failing to understand why adding 20 lines of json is taking so long though
<apw> stgraber, or reassign it to simplestreams, and then i will whine at them instead ;)
<stgraber> apw: IIRC the CPC stuff is a private project, not sure how to re-assign to it.
<apw> isn't simpletreams a thing in the archive, its not quite right, but
<stgraber> apw: hopefully the highlight in here will be enough to get things moving, it's been breaking all our tests for a while now
<stgraber> apw: the client is, yeah, the server isn't
<Laney> cjwatson: I got an action item to ask you if ssh-askpass-gnome is still needed (it's seeded on desktop)
<cjwatson> Laney: I guess that depends on whether a system without it does something sensible when it needs to ask for a password
<cjwatson> I suppose it goes through the horrible seahorse agent nowadays?
<cjwatson> which e.g. doesn't support modern key formats
<cjwatson> so ... I don't think it's needed in the absolute default configuration, it just might be worth bearing in mind that users with not very unusual requirements might have needed to switch to openssh's agent and then it's needed.  but maybe that's not a strong enough reason to have a GTK2 thing in desktop
<Unit193> https://bugzilla.gnome.org/show_bug.cgi?id=754028 not bad progress though.
<ubottu> Gnome bug 754028 in Daemon "No support for ed25519 and ecdsa SSH keys" [Enhancement,New]
<Laney> Doesn't seem to be much on the g-k side
<Laney> anyway, thanks for info - got to go but I'll look at bit next week
<Laney> bye!
<cjwatson> Laney: I could probably port ssh-askpass-gnome to GTK3 without too much trouble if that would help
<chiluk> hey arges.. what would need to happen in order to get an upstream version of findutils into xenial?
<chiluk> basically the versino we have right now is cerca 2009
<Unit193> chiluk: There's one in experimental.
<arges> chiluk: maybe we need to sync that version cvhecking
<richmb> infinity: I was asking questions about the ubuntu core minimal rootfs in #snappy, orga referred me to you.  The Wiki page seems like it hasn't been updated in a while, but the releases have.  Is this going to be supported/updated in future releases?
<tdaitx> pitti, I just saw LP: #1497420, while unrelated, I have been unable to lxc-attach into a Xenial container from my Wily host... http://paste.ubuntu.com/13249491/
<ubottu> Launchpad bug 1497420 in lxcfs (Ubuntu) "systemd 226 (moving pid 1 into /init.scope cgroup) breaks lxc-attach" [High,Fix released] https://launchpad.net/bugs/1497420
<arges> chiluk: $ requestsync findutils
<arges> W: Target release missing - assuming xenial
<arges> E: The versions in Debian and Ubuntu are the same already (4.4.2-10). Aborting.
<tdaitx> pitti, attaching to precise, trusty, vivid, and wily containers works fine... besides it being a Xenial container the only difference is that it was created just now (the other containers have been around for a while)
<arges> chiluk: 4.5.x is still an alpha version, maybe that's why it hasn't hit sid
<infinity> richmb: Yeah, it continues to be updated.  As for "supported", there's not much to support.  It's a very minimal rootfs that pretty much does what it says on the tin.
<richmb> infinity: we like it because it was very easy to port to various arm targets.  But we just wanted to make sure that future ubuntu releases would still be available before we chose to use it on a bunch of our products.
<infinity> richmb: It's not going away any time soon.  It's also a handy and quick infrastructure test case. ;)
<chiluk> hmm thanks arges.
<chiluk> well that's really ugly.  arges Unit193  .. how did you determine that 4.5.x is still an alpha version?
<chiluk> or is it just debian alpha.
<Unit193> chiluk: I just mentioned it was in EXP, didn't look into it. :)
<chiluk> I'm looking at https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788
<ubottu> Launchpad bug 1347788 in findutils (Ubuntu) "find crashed when current working directory is not readable and -exec or -execdir used" [Low,Confirmed]
<chiluk> and it seems to have been resolved in upstream.
<chiluk> let me check version
<arges> i just found the source here: ftp://alpha.gnu.org/gnu/findutils
<arges> instead of at the normal ftp site
<chiluk> hmm that's odd.
<chiluk> well the fix we need for 1347788 is in 4.5.9
<chiluk> and a backport is proving as bad if not worse than the recent coreutils backport I pained through.
<richmb> infinity: How is ubuntu core related to ubuntu server and desktop.  Is it used to build them? or extracted from them?
<chiluk> richmb: extracted from them afaik
<infinity> Neither, really.
<infinity> It's a separate build that just has a minimal set of packages and (as you've no doubt discovered, if you use it) no installer or initial setup.
<mvo> infinity: https://launchpad.net/~mvo/+archive/ubuntu/apt-xenial will soon have some stuff, preparing the abi change merge
<Unit193> Speaking of which...
<infinity> mvo: ABI change?  Is that 1.1?
<infinity> mvo: If it's 1.1, you're my favourite mvo in the whole world.
<bdmurray> mvo: no phasing support?
<infinity> I'm still dubious of phasing in apt proper.
<infinity> I guess it would need to be an apt.conf tunable, defaulting to off, and we'd drop a conffile in.
<infinity> Or something.
<infinity> Definitely needs to be overridable.
<richmb> infinity: Any reason why Ubuntu core would not be a suitable long term base rootfs for a industrial product?
<infinity> richmb: IMO, it's fine for that use (and one of the reasons we produced it), though if you're swayed by the idea of transaction/image updates instead of apt-get, snappy's worth a look.
<infinity> richmb: Right tool for the job, etc.  I'm not in the business of forcing decisions on others, evaluate what you need and go nuts.
<richmb> infinity: we did like snappy, but had troubles porting it.
<infinity> richmb: Well, if snappy's attractive, but giving you issues, ogra's team are the people to talk to.  But I won't recommend against classic ubuntu-core either, it gets the job done, just differently.
<infinity> richmb: The key difference is just how you design your update strategy, since shipping 100k units of a network-connected product with no plan for how you're going to address, say, security issues or critical bugs, is generally unwise.  But that problem exists for both snappy and classic core, just that the solutions differ.
<infinity> richmb: On the flip side, if it's a more classic pure embedded sort of device with no contact with the outside world, updates become a think no one really cares about, and your flexibility for how you construct it goes up a bit.
<infinity> s/a think/a thing/
<richmb> infinity: we're more so in the embedded bucket.  non-internet connected product
<richmb> infinity: thanks a bunch.  I have a better feel for ubuntu core's future.  I'll ask about our snappy porting issues in  #snappy.
<infinity> richmb: Yeah, then update stories are slightly less interesting.  You still need a way to get "our product sucks, here's an update" fixes out to users, but you don't need to worry about 0-day root exploits or anything.
<infinity> Or, if you're confident in your QA, you don't even necessarily need the "we suck" updates.  Depends on your process, of course. :P
<richmb> we still want ability to update various os/kernel packages.  just for the sake of easier sharing code between new and old products.
<mvo> infinity: hm, hm, looks like the new apt does not like the ppa chroots https://launchpadlibrarian.net/226517672/buildlog_ubuntu-xenial-amd64.python-apt_1.1.0~alpha3ubuntu1~ppa1_BUILDING.txt.gz I will need to do some digging
<popey> pitti, got my apport / caja crash loop thing again, but I guess you're not around :)
<popey> Ooh! I think I know what it is, dropbox!
#ubuntu-devel 2015-11-14
<darkxst> Laney, can you run the packageset scripts to pick up new gdm3 source, when you have a chance
<LocutusOfBorg1> hi folks, can anybody please retry autopkgtest for pbuilder/xenial/armhf/ppc64el? they are preventing it from migration I think
<melodie> hi
<melodie> infinity I wanted to get in touch with you, because I just realized when I used a Live Trusty in a laptop having 3 GB ram that I got zram block devices : whereas with the initramfs hook it should not be started, unless there is 512MB ram available max. Do you want me to file a bug report?
<melodie> I am not at home right  now, but I have an internet connection, so if you read me later, we can get in touch again in the coming evenings or days
<darkxst> melodie, lubuntu enable zram though
<melodie> hi darkxst
<melodie> I have been a tester for zram-config, not so long ago when the script has been ported to systemd, so this is related
<melodie> the changes done have not been complete, there is a part of how the program is supposed to work, that is missing.
<melodie> this is why I want to ask infinity if he would want me to file a bug, or if he would rather work on the issue directly in the coming days.
<melodie> and if lubuntu enables zram since a pair of editions, this is because I made gilir aware of me doing so in my non official remixes. ;)
<darkxst> melodie, sounds like you should just file a bug ;)
<melodie> darkxst possibly
<darkxst> melodie, not possibly, just do it, that is why launchpad is there ;)
<melodie> I'm not at home right now
<melodie> I just noticed the issue yesterday when I did a new install and I don't want to forget to take care of it
<darkxst> melodie, you are on the internet, you can still file a bug
<melodie> if I reproduce it with a live and bring tech info
<melodie> I am in a public forum right now and discussion irl with people too
<melodie> bbl :)
<elbrus> pitti: did you change anything to the armhf autopkgtest lxc? dbconfig-common is now passing
<elbrus> pitti: to be honest, I currently believe that this situation SHOULD have been handled by dbconfig-common and postgresql correctly. Apparently the way to do this is to copy the template0 in postgresql and that is exaclty what dbconfig-common is (or should be) doing
<sebastic_> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<sebastic_> The Debian Security Team just released: [DSA 3208-2] freexl regression update, this regression affects trusty & vivid (LP: #1437087)
<ubottu> Launchpad bug 1437087 in freexl (Ubuntu) "Multiple vulnerabilities in freexl 1.0.0" [Undecided,Fix released] https://launchpad.net/bugs/1437087
<mdeslaur> sebastic: please file a new bug, so that's it's not "fix released", and subscribe ubuntu-security-sponsors to it
<sebastic> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/freexl/+bug/1516257
<ubottu> Error: launchpad bug 1516257 not found
#ubuntu-devel 2015-11-15
<tsimonq2> just curious, I have seen build servers for Ubuntu that build packages for the repos. Are those only Ubuntu servers that can do that, or can I contribute my free resources to do this on my server?
<slangasek> pitti: latest kernel autopkgtests show a failure because the testbed is being upgraded to -proposed before the pin preferences are set, pulling in a new libuuid1 from xenial-proposed; so when the package tests later try to install uuid-dev (transitive build-dep of apparmor), this fails
<jjohansen> hallyn: yes, because they are. nsfs use proc magic to have the symlink jump to the nsfs dentry/inode
<jjohansen> stgraber: the systemd thing is that systemd doesn't have a restart/reload. They do a stop and then start for it. But for apparmor stop tears down the loaded policy, and your attachments/mappings to tasks are lost
<jjohansen> we are going to have to do something different so that policy doesn't get removed like that
<jjohansen> back to nsfs, I have some ideas on how to deal with it, but haven't gotten to implementing them yet
<infinity> slangasek: Yeah, that's a known bug/misfeature that pitti's left in place to make sure the base system gets testing.  I think we should just introduce some autopkgtests for util-linux, etc, and fix the bug.
<slangasek> ah?  yes, I agree
<slangasek> it would be less of a problem in this case of util-linux wasn't hanging the ppc64el buildds
<slangasek> (because then util-linux would be migrate and linux tests would be fine)
<cjwatson> tsimonq2: Thanks for the offer, but to ensure proper security we only build packages on systems we run ourselves.
<cjwatson> tsimonq2: (We're also not particularly short of x86 builder capacity nowadays.)
<tsimonq2> cjwatson: Ok, I was just wondering as Debian has their buildd setuo
<tsimonq2> s/setuo/setup/
<hallyn> jjohansen: ok, thx.
<cjwatson> tsimonq2: Debian doesn't take buildd contributions from just anyone, either :)
<cjwatson> tsimonq2: Most Debian buildds these days are DSA-operated
<cjwatson> But they do have somewhat different constraints.
<hjd> Hi all. :) Someone who around who can rebuild packages which failed to build on Xenial? Looks like both s3fs-fuse and node-string-decoder failed due to random errors when attempting to download packages. (https://launchpadlibrarian.net/225417305/buildlog_ubuntu-xenial-amd64.s3fs-fuse_1.79%2Bgit90-g8f11507-1_BUILDING.txt.gz and
<hjd> https://launchpadlibrarian.net/225417304/buildlog_ubuntu-xenial-amd64.node-string-decoder_0.10.25-1_BUILDING.txt.gz)
<hjd> And it looks like libmath-bigint-gmp-perl and turbogears2-doc both attempted to build before all dependencies had been synced/built, so they might work better now as well. Thanks in advance :)
<ginggs_> hjd: i'll do it
<ginggs_> hjd: node-string-decoder failed again for a different reason
<ginggs_> hjd:  s3fs-fuse, libmath-bigint-gmp-perl and turbogears2-doc built ok
<hjd> ginggs_: Yes, looks like node-string-decoder has a real bug. Thanks again :)
<Unit193> barry: I don't suppose that bzr-fastimport thing is on your agenda anymore then?
#ubuntu-devel 2016-11-14
<pitti> Good morning
<pitti> rbasak: cheers! removed/promoted
<cpaelzer> good but somehow weird morning
<cpaelzer> I'm slowly getting to the point that I just miss something.
<cpaelzer> Could one of you try http://paste.ubuntu.com/23474596/ and tell me why it ends up with modifications to upstream files?
 * cpaelzer is waiting for a shameful "there it is" pointer to come in :-/
<sladen> cpaelzer: these all look like auto-generated files.
<cpaelzer> yes
<cpaelzer> but on all the packages I modified so far that never happened - so I wondered
<sladen> cpaelzer: eg. suse.in (from ./configure), .pc/* (from quilt), .git-commit-message (artifact of an in-progress commit).  The rest is cut off
<cpaelzer> what I wonder is if I'm supposed to undo those changes before an upload
<cpaelzer> I was able to make a clean debdiff by dropping .pc
<cpaelzer> but lintian still is mad at me on dput as the diff.gz contains changes outside of debian/
<cpaelzer> e.g. all the .po changes
<sladen> echo -e 'unapply-patches\nabort-on-upstream-changes\n' >> debian/source/local-options
<sladen> should help with automatically unapplying the quilt patches
<sladen> but I would check it out, manually change the debian/changelog.  Check it builds, and be done with it
<sladen> I can't see the diff, but I expect most of it will be timetstamps
<seb128> SRU team, could you review https://launchpad.net/ubuntu/xenial/+queue?queue_state=0&queue_text=snapd ? snapd updates made gnome-software not able to install snaps anymore and that new package is needed to fix it (it has already been SRUed to yakkety but the xenial uploads is sitting in the queue for a while)
<pitti> seb128: okay-ish, but it has a higher versino number than yakkety, so it should be reuploaded as ubuntu1.1~xenial
<pitti> (rejected with that reason)
<seb128> pitti, oh, doh, indeed, thanks for spotting that (and for the review)
<pitti> please poke me after reuploading
<seb128> k
<seb128> thanks!
<LocutusOfBorg> kees, hi, you around?
<LocutusOfBorg> jdstrand, also ^^ I have an apparmor specific question
<LocutusOfBorg> can I enforce some sort of global policy, where I forbid access to a specific file, no matter the process/application/user trying to open it?
<pitti> not with AppArmor, as a process must be in a profile for that
<LocutusOfBorg> I would like to secure my GPG private key with apparmor configuration
<pitti> this is what DAC is for -- restrict user/group to root:root and set appropriate permissions
<LocutusOfBorg> mmm ok, so there is no way to forbid root by looking at it
<pitti> not towards root, no -- root can also just pry it out of the raw block device, unless you use encryption
<pitti> but then it can ptrace a process that is allowed to access it
<pitti> I'm afraid you can't lock root out of files
<LocutusOfBorg> unless I patch the kernel, to forbid read syscall when the file matches a pattern, but I agree, for raw block device... there is no way
<pitti> LocutusOfBorg: it's a more useful exercise to block access to the key from other user processes, IMHO
<pitti> as these are the real danger
<pitti> e. g. firefox
<sladen> rbasak: Git double ++
<rbasak> Thanks :)
<juliank> Bah, the fixes I picked for fixing the locale stuff apt 1.2.16 should be correct, but they don't compile on travis because it's libstdc++6 is too old to have std::put_time (newer builds pull in a newer one by accident...). :(
<juliank> bdmurray: pitti: What remains to be done about the apt/1.2.15 xenial SRU? The autopkgtest of sbuild and autopkgtest fail, but that's not apt's fault - the failures also happen for other packages. It's been about 2 (silent) weeks since the upload, and I've been running this for about 1.5 months now without any issues on my server.
<juliank> ^ infinity (show a bit enthusiasm, you wanted the autoremove fix that's in there :D)
<juliank> Meanwhile I got the 1.2.16 patch queue to compile, but it fails the test suite on travis' franken-trusty-wily-stein :/
<pitti> juliank: right, sbuild fails due to removing procenv
<pitti> actually no, it's there
<pitti> and 100 is an apt error code
<pitti> so that should at least be investigated
<juliank> pitti: That also occurs with 1.2.10ubuntu1 in -updates as can be seen in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/sbuild/20160512_132544@/log.gz
<juliank> (which was triggered by dpkg/1.18.4ubuntu1.1
<juliank> With yakkety instead of zesty, of course
<juliank> (that was back in may)
<pitti> ah, ok; releasing then
<juliank> Alright, thx
<jdstrand> LocutusOfBorg: you theoretically can replace the unconfined template, but it gets crazy difficult to lock things down cause you'll define a profile that can access it, but unconfined can change_profile into that one, and then things spin out into full system policy, which is a lot of work
<jdstrand> s/template/profile/
<jdstrand> you can create a root strong policy fwiw, but your system also needs to run and access stuff and do things so there will be a process somewhere that has enough to access it. it is more fun to think about than to implement for a general purpose system
<jdstrand> there are also hardware devices that can be used to aid in this sort of thing. eg, https://www.yubico.com/support/knowledge-base/categories/articles/use-yubikey-openpgp/
<LocutusOfBorg> thanks jdstrand!
<cpaelzer> having an issue with a build on LP infrastructure I wonder what else I could do to become more similar - it fails on LP, but works on autopkgtest
<cpaelzer> whicih should both be cloudimg based right?
<cpaelzer> with LP having a modified one (I wonder how slightly or extensive that is)
<cpaelzer> I created a zesty instance on serverstack to be even closer, but there as well the issue doesn't trigger
<cpaelzer> if there are common "make it more similar to LP for debuggung" hints that you have please feel free to share
<cjwatson> cpaelzer: The usual thing is to take away network access other than to essential facilities like the archive.
<doko> zul: rejected python-vmware-nsxlib , again missing information in debian/copyright
<zul> doko: shoot thanks
<cjwatson> cpaelzer: The base image is basically only modified to install launchpad-buildd and friends.
<cjwatson> cpaelzer: You can look at lp:launchpad-buildd (especially sbuild-package and sbuildrc) to see how sbuild is run.
<cjwatson> cpaelzer: And you can get the chroot that the build is executed in by starting from https://api.launchpad.net/devel/ubuntu/zesty/amd64 etc.
<cjwatson> (or manage-chroot from lp:ubuntu-archive-tools)
<smoser> slangasek, how did you make the ascii art showing cloud-init services ?
<slangasek> smoser: by hand hnnngh :)
<smoser> bah
<smoser> well then, makes it harder for me to jsut change things and see how it changes therendering :)
<sarnold> did you use something like http://www.vim.org/scripts/script.php?script_id=40 or the similar emacs thingy? or by-hand by hand? :)
<smoser> sarnold, that looks neat
<sarnold> smoser: the docs are thick enough that I've never actually -used- it -- I thankfully don't have to draw diagrams often :)
<slangasek> sarnold: genuinely by hand ;)
<slangasek> smoser: there are tools for graphing systemd unit deps, but nothing text-y AFAIK and I'm not proficient
<slangasek> smoser: discussion with pitti suggests 'systemd-analyze dot "cloud*"' or 'systemd-analyze dot --order "cloud*"' might be the thing
<pitti> smoser: dot --order "cloud*" â http://people.canonical.com/~pitti/tmp/cloud-all.svg
<smoser> slangaseks' was prettier :)
<pitti> slangasek also draws graphs with 50% more love than graphviz :)
<slangasek> and I truncated the graph for legibility
<nacc> smoser: what do you think about the importer doing no-clean on error?
<nacc> smoser: i feel like that is a sane default, as i generally don't need to keep the repo around if it successfully imports, but if it fails, i need to debug :)
<smoser> nacc, that seems reasonable.  you dont have to give a dir, though right ?
<nacc> right, it just won't rm -rf the tmp dir
<nacc> smoser: --^
<smoser> so in that event if i run that 100 times in a loop (which i'm apt to do with the up arrow) i end up with a ton of wasted disk space.
<teward> what bug type is for when someone files a bug with `ubuntu-bug`?
<smoser> obviously solvable by passing --directory
<smoser> but it seems that you end up with lots of space taken if you're not aware
<nacc> smoser: it says pretty explicitly (when no-clean is used) that it's leaving a directory around
<nacc> smoser: and the path to the same
<nacc> smoser: again, the odds of anyone running the importer locally is very low :)
<smoser> nacc, to my knowledge 100% of users of it have used it locally
<nacc> smoser: yes, that's a limitation of the current deployment
<smoser> so... while you might have one plan, that isnt' reality at the moment at least
<nacc> smoser: yes, and almost *all* users run w/o --no-clean
<nacc> smoser: and don't hit errors
<nacc> smoser: and can't debug
<nacc> smoser: fine, i'll add another flag
<smoser> nacc, i dont really care. i dont think its bad.
 * tsimonq2 hunts for patch pilot
<tsimonq2> Seems Laney and henrix were scheduled for today? Hmmmmmmmmmmmmmm
<tsimonq2> bug 1641315
<ubottu> bug 1641315 in purpose (Ubuntu) "We need a new purpose! (Sync purpose 1.1-2 (universe) from Debian unstable (main))" [Undecided,New] https://launchpad.net/bugs/1641315
<tsimonq2> bug 1636655
<ubottu> bug 1636655 in ark (Ubuntu) "Ark no longer opens rar files in 16.10" [Undecided,In progress] https://launchpad.net/bugs/1636655
<tsimonq2> If a MOTU is willing to help me out, that would be awesome.
<tsimonq2> The first one is a simple Debian sync, should be flawless.
<tsimonq2> The second one fixes RAR support and needs to get in Zesty before we make an SRU, I assume.
<tsimonq2> We got a prod from upstream, and it's just that. An upstream commit. acheronuk tested it on Zesty and Yakkety from my test uploads to a PPA.
<tsimonq2> So I see no reason why that shouldn't be uploaded.
<tsimonq2> Any takers? ;)
<juliank> tsimonq2: That purpose thing seems a bit dubious. It mentions transitional packages for libkf5purposewidgets5, but there are none.
<tsimonq2> acheronuk: ^^^^^^^^^^^^^^^^^^^^^^^^^^
<juliank> All I see is libkf5purpose5 conflicting and replacing that
<juliank> Hmm, seems like it was dropped in packaging git recently, but apparently the history in that git repo (https://anonscm.debian.org/git/pkg-kde/frameworks/purpose.git) does not quite match the uploads
<tsimonq2> Kubuntu's packaging BTW, juliank: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/purpose
<tsimonq2> juliank: So is the problem in our package or Debian's?
<juliank> tsimonq2: I was just wondering where the package is in 1.1-2, but if nothing rdepends on it, that seems fine
<tsimonq2> On purpose or libkf5purposewidgets5?
<juliank> (Because it was there in the old package, so syncing it would remove it, so better nothing depends on it)
<juliank> The latter
<tsimonq2> Correct, it seems it's fine.
<juliank> tsimonq2: ack
<tsimonq2> juliank: Thanks for taking a look at this. ;)
<juliank> Bah, syncpackage "signed" that with my gmail
<juliank> Ah, probably because I changed the lp email
<juliank> tsimonq2: Seems like the sync is now dep-waiting on libkf5kio-dev, because it's actually called kio-dev here. Who could have expected this?
<tsimonq2> Aha, yes, that's known.
<tsimonq2> This will be fixed when we upload KDE Frameworks 5.27 soon. Debian transitioned to that package name but uUbuntu didn't yet.
<juliank> Alright
<tsimonq2> juliank: Could that be fixed by setting something like "libkf5kio-dev | kio-dev"? We could remove it when that package exists, but it will still allow for the dependency to be set.
<tsimonq2> It will become a transitional package either way.
<juliank> For example.
<tsimonq2> (kio-dev will)
<tsimonq2> Hm?
<juliank> Another hack might be to just add a "transitional" libkf5kio-dev package to kio for the meantime, so new rdeps of kio can be synced.
<juliank> And then that could become the real one fairly painlessly once 5.27 enters
<tsimonq2> Oh sure.
<tsimonq2> Yeah.
<juliank> But I don't have any insight into which solution is the better way, that depends on how the rdeps of kio look like
<tsimonq2> The thing is, the Kubuntu team's only person with upload access recently left, so we'll have to fall back to the old members who still have access but don't participate any more.
<tsimonq2> So for these things we're going through the sponsorship process.
<tsimonq2> So I think either one should work, but I don't have the access to Just Do It. :)
<tsimonq2> Personally I'd rather just add the delta to purpose.
<tsimonq2> I want to do that because kio-dev becomes a transitional package either way when we upload kio with the next FW.
<tsimonq2> juliank: So would you like me to file a bug against purpose to go through the sponsorship process on that too, or would you be able to just do it? :)
<juliank> tsimonq2: I can do that
<tsimonq2> Thank you. :)
<juliank> tsimonq2: I just can't built binaries right now, so we either get lucky or not. If not, we have to deal with this tomorrow (CET)
<tsimonq2> Fair enough.
<tsimonq2> juliank: You got a diff I can look at first?
<tsimonq2> More pairs of eyes if we're relying on luck. ;)
<tsimonq2> (If not, it should be fine, but still. More is always better. ;) :P)
<juliank> Well, that part is not the problem. Just if some other part of the build fails somehow :)
<tsimonq2> Oh ok
<tsimonq2> Fair enough.
<juliank> tsimonq2: That should be it: http://paste.ubuntu.com/23477837/ - there already is an equivalent dep on kio-dev further up the build-depends
<juliank> Build Dependencies seem to be installing
<tsimonq2> Why would Debian depend on kio-dev as well? O__o
<tsimonq2> I'll poke the relevant person.
<juliank> Accident probably
 * tsimonq2 watches https://launchpad.net/ubuntu/+source/purpose/1.1-2ubuntu1/+build/11200190
<juliank> tsimonq2: ppc64el is uploading
<tsimonq2> \o/
<tsimonq2> juliank: Thanks. :D
<tsimonq2> Oh, seems kio is Plasma? We'll upload that soon anyways.
<tsimonq2> juliank: Any chance you could look at ark as well?
 * juliank does not know what KDE calls what these days ...
<tsimonq2> juliank: Plasma is the desktop, Frameworks is the base APIs, and Applications is, well, the Applications.
<tsimonq2> That's the short version. :)
<juliank> tsimonq2: OK. Let me have a quick look at the ark thing
<juliank> tsimonq2: Looks sane to me, uploaded it. If there's some issue, let me know when I'm awake again :D
<tsimonq2> juliank: Ok, thank you. :)
<Unit193> juliank: ...Do I get to bother you about command-not-found this month? :)
<juliank> Unit193: aaah
<juliank> Unit193: I want to go to sleep now ...
<Unit193> juliank: Hah, lovely timing then!  Also perhaps wrong channel..
<juliank> Yea, remind me in 21 hours
 * juliank is doing university + apt stuff by day, and misc stuff before going to sleep...
<juliank> This reminds me: If someone can test the apt 1.2.16~rc1 in the xenial PPA linked in bug 1592817 and 1611010 and verify that it fixes these bugs, that would be nice. I'm reasonably (like 95%) sure it does, but I can't really be bothered to do this
<ubottu> bug 1611010 in apt (Ubuntu Xenial) "yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: ''" [Critical,In progress] https://launchpad.net/bugs/1611010
<ubottu> bug 1592817 in gdebi (Ubuntu) "gdebi-gtk crashed with ValueError in update_interface(): could not convert string to float: '0,0000'" [Medium,Confirmed] https://launchpad.net/bugs/1592817
<juliank> Anyway, I'm off now, will be back in about 8 hours
#ubuntu-devel 2016-11-15
<nacc> rbasak: smoser: after pushing the gitattributes change to allow for a source-change-less import, I was able to re-import php7.0, merge it and build it using `usd` only.
<nacc> jgrimm: --^
<nacc> to mirror the upload, i just pushed up a corresponding upload/ tag; we'll see if the importer picks it up on the next import run (it should, it has in other cases)
<nacc> jgrimm: also, we're in-sync with debian on tomcat8; i saw it was on the blueprint?
<ypwong> cyphermox, can bug 1561834 be closed since both tpm2 packages are already in xenial?
<ubottu> bug 1561834 in Ubuntu "[FFE] [needs-packaging] tpm2-tss and tpm2-tools" [Wishlist,Confirmed] https://launchpad.net/bugs/1561834
<nacc> rbasak: would you have time to sync up again tmrw AM before the UOS session?
<cpaelzer> cjwatson: thanks for the links to get my test env more like the LP infrastructure
<cpaelzer> one question in general - what openstack flavors is the infrastructure using - as I start to assume it might be a race the number of cpu/memory might be important
<cpaelzer> and good morning everybody sharing my TZ (good any other part of the day to everyone else)
<pitti> Good morning
<cpaelzer> hi pitti
<pkern> Laney: So we managed to get bash into the sponsorship queue 1.5w ago and still nothing happened. I suppose the 3w old+ list is just too scary.
<Mirv> LocutusOfBorg: hi! it seems in zesty-proposed cmake-extras is not possible to install (despite the newest uploads) because cmake < 3.7z requirement, and 3.7.0-1ubuntu1 is higher than 3.7z
<pitti> LocutusOfBorg: eek -- 3.7.z then, I figure?
<pitti> sorry for the bad piece of advice
<jamesh> should probably be 3.8~ ?
<pitti> better, just a lot more difficult to compute with a shell snippet in debian/rules :)
<Laney> pkern: I had hoped that someone would pick it up, but luckily I'll be sponsoring this week at some point
<juliank> dholbach: Can you add me to ~ubuntu-sponsors? - I currently occasionally sponsor some stuff mentioned on IRC, but let's formalize things a bit :)
<juliank> Laney: pkern: That patch actually looks quite nice, if I had a trusty chroot, I'd sponsor it (and yes, I can set one up right now...)
<Laney> juliank: thanks ;-)
<rbasak> nacc: UOS sync> yes, though am also doing the MySQL session. ping when you're in?
<juliank> whoa, seems that actually fit into my chroots partition.
<dholbach> juliank, done
<juliank> dholbach: thx
<juliank> Laney, pkern: built, verified that it fixes the bug and uploaded it
<juliank> Ooops, it misses a ":" after the LP in the changelog
<juliank> Come on, one character, what world are we living in?
<juliank> If someone rejects that, I'll upload again with a ":" in the changelog
<LocutusOfBorg> pitti, yep indeed, thanks Mirv
<Laney> juliank: you don't need to wait for the reject
<LocutusOfBorg> thanks dholbach <3 virtual hug for you :)
<juliank> Laney: Can I just replace the files in the queue? I mean, I don't want to create yet another changelog entry...
<pitti> juliank: you can -- just fix the changelog, rebuild the source, reupload
<pitti> juliank: i. e. same version number and all that
<LocutusOfBorg> does anybody know how to git-git import in launchpad, to use a daily-build recipe for a particular package?
<LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/boinc-upstream/master
<juliank> Ah cool
<LocutusOfBorg> this is failing because signed commits/bzr missing feature
<LocutusOfBorg> I would like to switch to git-git native stuff
<pitti> juliank: (and rejected)
<juliank> OK, re-uploaded with correct bug closure :)
<juliank> That was easy.
<juliank> I'm unsure about the coming apt 1.2.16 SRU - I cherry-picked commits making the time parser only accept UTC values for Valid-Until - I don't exactly remember why, but I think the other patches fixing the other locale bugs depend on them. Does that sound fine for xenial, or do we think it's too risky (no one seems to have complained about that in yakkety so far - we have that in 1.3 since June)
 * dholbach hgus LocutusOfBorg back :)
<juliank> Yep, that was the reason.
<juliank> So, I can either do some changes that were never tested elsewhere for xenial to keep things minimal, or stop accepting Release files that specify "Valid-Until" in a time zone other than UTC (we never respected the timezone specified)
 * juliank prefers the well-tried commits
<pkern> juliank: Thanks! :)
<juliank> pkern: (often) happy to help :)
 * juliank would say always, but sometimes he really has more important things to do :/
<LocutusOfBorg> Mirv, seems fixed in proposed :) please confirm
<juliank> We don't really have concrete test cases for #1592817 and #1611010 - I think the SRU in xenial-proposed (1.2.16) fixes the issues, but testing them? So many variables to account for.
<juliank> bug 1592817 and bug 1611010
<ubottu> bug 1592817 in apt (Ubuntu Xenial) "gdebi-gtk crashed with ValueError in update_interface(): could not convert string to float: '0,0000'" [Undecided,In progress] https://launchpad.net/bugs/1592817
<ubottu> bug 1611010 in apt (Ubuntu Xenial) "yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: ''" [Critical,In progress] https://launchpad.net/bugs/1611010
<Mirv> LocutusOfBorg: not yet in repos it seems but yes that should do it, thanks! :)
<Mirv> oh, I'm using a mirror
<Mirv> switching to main
<Mirv> LocutusOfBorg: yes, so confirming fixed!
<philroche> xnox: Odd_Bloke pointed me in your direction to see what your thoughts were on an issue we are having trying to unmount after running apt-key or apt-add-repository within a chroot. See https://gist.github.com/philroche/0fdeb0c31887bbf7300ef64e20e9b6db on how to reproduce. This is blocking us in creating some custom Yakkety cloud images.
<xnox> philroche, run away processes from gnupg2. But why are you doing this?
<xnox> philroche, export the key as a file, and drop it as a file into /etc/apt/trusted.gpg.d/<your-name>.gpg
<xnox> you really should not be hitting the network to retrieve the keys
<philroche> We want to be able to add a PPA within a chroot to produce an image with a package from that PPA installed.
<xnox> but don't run apt-key inside the chroot to do that.
<xnox> export the key into a file, commit it to your repository or what not, no need to call chroot, no need to copy resolve.conf
<philroche> xnox: OK. Initially we were only using apt-add-repository but I presume this calls apt-key
<xnox> simply $ cp my-ppa.gpg squashfs-root/etc/apt/trusted.gpg.d/
<xnox> ditto the lines you want for the /etc/apt/sources.list.d/
<philroche> xnox: excellent. Thank you. I will try this
<xnox> yes add-apt-repository does call apt-key and it does leave run-away processes. but you can do everything statically by just copying the exported key in place, & the text-file with deb http.... lines
<cpaelzer> cjwatson: I wanted to thank you - with your hints on how I get my build env closer to LP I was finally able to reproduce the issue
<cjwatson> cpaelzer: Not completely certain, but I believe that amd64 and i386 are on 4 vCPUs, 4GiB RAM, 4GiB swap, 60GiB disk, while arm64, armhf, and ppc64el are on the same but with 8GiB RAM.  powerpc and s390x aren't using openstack yet.
<cjwatson> cpaelzer: np :)
<cjwatson> LocutusOfBorg: I'm at the production-testing stage of git-to-git imports, so nearly done, but they aren't yet enabled for everyone to create.  Probably later this week.
<doko> xnox: looking at https://bugs.launchpad.net/ubuntu/+source/libuv1/+bug/1641628, missing a subscriber. should be the same as for cmake, but this is kubuntu-bugs. any suggestion?
<ubottu> Launchpad bug 1641628 in libuv1 (Ubuntu) " [MIR] libuv1" [Undecided,New]
<xnox> doko, why does it need a MIR? if it's only used in cmake-extras, it should only ever be a build-depends, no?
 * xnox checks that assumption
<xnox> $ reverse-depends cmake-extras
<xnox> No reverse dependencies found
<xnox> oh cmake itself...?!
<doko> xnox: yes
<doko> so currently uninstallable in -proposed
<xnox> $ reverse-depends -c main cmake
<xnox> No reverse dependencies found
<xnox> how is cmake seeded?
 * xnox guess we probably do want cmake in main... then again we don't have to.
<xnox> i'd rather push cmake to universe =)
<xnox> somehow i see cmake-doc seeded into supported.
<doko> well, pushing it into universe doesn't mean we don't have to maintain it ...
<xnox> sure. but it means we don't have to security support it on end-user machines
<LocutusOfBorg> thanks cjwatson
 * xnox does want to know how come cmake is in main though
<xnox> supported-development-common: * cmake
<xnox> that's how.
<pitti> xnox: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.zesty/all
<pitti> (yes, that shows that it's just seeded)
<doko> well, it's used as a b-d for a lot of the phone package, so we should keep it seeded
<xnox> doko, looks like cmake has embedded copy of libuv that one can use; or one can use a system one. It is only required for the cmake server mode, which unfortunately is not a separate binary.
<xnox> but one can compile cmake without server mode enabled, and thus without libuv internal or external dependency
<xnox> https://cmake.org/cmake/help/v3.7/manual/cmake-server.7.html
<xnox> yeah, make bootstraps harder, as it's one more thing to build.
<xnox> potentially.
<xnox> but that too is work.
<xnox> subscribe foundations-bugs and be done with it?
<xnox> bdmurray, do we want to take on libuv?
<doko> xnox: yes, that was my suggestion. and maybe foundations should subscribe to cmake too, because you're the expert?
<xnox> haha
<doko> one advantage of having a separate library is that the testsuite runs
<doko> cpaelzer: libvirt-python is dep-wait on a newer libvirt. do you intend to update / merge this version?
<doko> also ftbfs on amd64 and i386
<doko> tvoss: location-service and mir ftbfs in zesty-proposed
<doko> same with thumbnailer
<tvoss> Ack and thx
<cpaelzer> doko: hi, I discussed with smb just yesterday to merge a newer libvirt this cycle - although that will not be like tomorrow
<doko> ok
 * LocutusOfBorg smells libuv1 mir
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mdeslaur
<doko> seb128, willcooke, Laney: please subscribe ubuntu-desktop to emacs25 (emacs24 getting demoted)
<Laney> ok
<LocutusOfBorg> thanks doko :) for both
<cpaelzer> doko: if you meant the current libvirt FTBFS that I'm on atm btw - althou reproducibility is a nightmare so far
<doko> well, isn't libvirt a nightmare on its own?
 * cpaelzer wonders why he seems to attract work on packages that people say things like that about
<seb128> doko, Laney, why do we maintain emacs?
<Laney> seb128: I would guess that's always been there, but if you want to figure it out and get it demoted then feel free
<Laney> It's more "maintain" than maintain, at least for our team
<seb128> right
<seb128> just feels weird
<pitti> seb128, Laney "usb" seed â gettext â gettext-el â emacs-defaults â emacs â emacs24 (see http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.zesty/all)
<seb128> pitti, thanks
<pitti> oh, gettext is also being pulled in by more bits (and I think we do want/need to keep that)
<Laney> pitti: Right (I know how to chase that down) - the question is why is it the desktop team rather than any other one
<seb128> wonder if that's something that could be simplified, at the same time can't be bothered to spend work on that
<Laney> wee, glib went in
<pitti> seb128: so we could unseed gettext-el
<pitti> and emacs-goodies-el from supported-development-desktop seed
<pitti> (I'm not saying we want to unsupport emacs -- probably we do want to support it)
<seb128> pitti, right, let's keep things as their are, easier/less work, it's not like it was costing us much maintainance work, I was just a bit suprised to see emacs in main/desktop maintained
<Laney> don't peek into the supported seeds ;-)
 * Laney eek
<seb128> lol
<doko> seb128, Laney, pitti: also seeded for the desktop
<doko> maybe because there is no real emacs-gtk package
<barry> jsalisbury: i think LP:# 1627198 might be back for zesty
<barry> LP: #1627198
<ubottu> Launchpad bug 1627198 in linux (Ubuntu Yakkety) "4.8.0 kernels do not complete boot process on VM" [Critical,Fix released] https://launchpad.net/bugs/1627198
<nacc> rbasak: ack, i should be fully available at the hour
<smoser> nacc, 'git show do-no-push' ?
<smoser> second question...
<smoser>  i just imported cluod-initramfs-tools, and it seems like i have double namespacing on the pristine-tar branches
<smoser>  http://paste.ubuntu.com/23480958/
<bdmurray> xnox: What was your question?
<xnox> bdmurray, please subscribe libuv to foundations-bugs such that we are stuck maintaining it if it goes rougue, because cmake picked up an optional feature that depends on libuv
<xnox> and cmake is important, supposedly
<jsalisbury> barry, ack, looks like seth is taking a look
<barry> jsalisbury: thanks!
<barry> i have things set up right now to test new kernels without too much pain
<nacc> smoser: ignore do-not-push, it's an artifact of gbp
<nacc> smoser: hence the name
<nacc> smoser: it only exists on the importer system, it will not be pushed to LP, which is the bit that matters
<smoser> right. ok.
<nacc> smoser: yes, pristine-tar is namespaced; in theory, ubuntu and debian could be using different orig tarballs
<nacc> smoser: it could be smarter about it, but that was the easier route
<nacc> smoser: so to use pristine-tar, right now, you have to do a `git branch -M`
<nacc> smoser: iirc
<bdmurray> xnox: done
<smoser> nacc, that wasnt my question
<smoser> look at the paste
<smoser> importer/importer/debian/dsc
<nacc> yes
<smoser> importer/importer/debian/pristine-tar
<nacc> importer/ specific branches are nested
<nacc> so when they get pushed to LP they are in importer/
<nacc> this is why i'm convinced using the imported tree directly is sort of wrong
<nacc> import, push, use `usd clone`
<nacc> it will look 'correct'
<smoser> no.
<nacc> or import and ignore the leading 'importer/'
<smoser> i did that.
<nacc> oh right, it won't matter
<nacc> because importer is the remote then
<nacc> so still, ignore 'importer', that's just a namespace, right? (per remote)
<nacc> the first importer
<nacc> the second 'dir' is the purpose, sort of -- 'importer' is for importer-internal branches, 'ubuntu' for Ubuntu series tracking, 'debian' for Debian series tracking
<smoser> well, "just a namespace" .... "just a  name" .... wherefore art though romeo.
<nacc> having the pristine-tar and dsc branches a level up meant having to special-case them everywhere
<smoser> yeah, i can see that.
<smoser> but this just looks wrong.
<nacc> why?
<nacc> it's just a naming choice
<nacc> i guess we could have flipped those to be pristine-tar/debian and pristine-tar/ubuntu
<nacc> would you prefer that?
<nacc> and dsc/debian, dsc/ubuntu
<smoser> it'd look less wrong with importer/pristine-tar/debian
<smoser> yeah, that swhat i was going to suggest.
<smoser> it would seem less "wrong" then.
<smoser> or maybe just picking something other than 'importer' . maybe 'dist' or 'pristine' or something
<nacc> what is 'wrong' about it? you not liking it doesn't make it 'wrong' :)
<smoser> i dont know.
<smoser> it looks like an error
<smoser> xnox, fwiw, you could test petiboot itself without ppc64 nv
<smoser> as it just builds an initramfs
<smoser> kvm -kernel ... -initrd ...
<smoser> the difference really then woudl be the version and features of the loader kernel that the ppc64el firmware has, and the version of petitboot that is in it
<xnox> horum.
<xnox> smoser, shall i just enable it for ppc64el and wait for bug reports?! =)
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<Diziet> Is there an IRC channel where I can get help with summit ?  I want to remotely attend a session and 1. there is something wrong with my account in summit and 2. I would like to test my setup beforehand.
<cjwatson> dholbach: ^-
<Diziet> cjwatson: Hi, and thanks.
<dholbach> mhall119, popey ^ can you maybe help? I'm in a session right now
<cjwatson> (Also it possibly depends on exactly what's wrong with your account in summit, e.g. it might actually be an SSO issue)
<cjwatson> I won't be able to attend the session in question, unfortunately - prior commitment
<Diziet> cjwatson: summit -> log in -> "personal data request" from Ubuntu One -> "yes" -> The username (ijackson) with which you tried to log in is already in use for a different account
<Diziet> Very likely the other account is another copy of me from a time when summit and launchpad had different account databases.
<cjwatson> Yeah, I was just about to say the same
<mhall119> Diziet: watching or running a session?
<Diziet> I will want to be watching it.
<mhall119> Diziet: you don't need to be logged in for that
<Diziet> And ideally, if that's what can happen, have my video appear in the conf room.
<mhall119> Diziet: but it sounds like your OpenID id has changed in SSO at some point
<Diziet> I might want to scribble in the pad.
<Diziet> I don't know if the system allows remote participants to share their video.
<mhall119> Diziet: if you want to be on the hangout, ask the host for the hangout URL
<Diziet> OK.  So I may need to create a google account then.
<mhall119> otherwise the video is just a youtube broadcast, anybody can see it
<mhall119> Diziet: to be on the hangout, yes, you need a google account
<Diziet> And presumably I can test the hangouts bit separately.
<mhall119> separately from summit.ubuntu.com yes
<Diziet> Do I need to be logged in to edit the pad ?
<Diziet> Right.
<cjwatson> You need to be logged in via SSO to edit the pad
<mhall119> yes, but you need to login to pad.ubuntu.com not summit.ubuntu.com
<Diziet> Oh my account is probably not borked there.
<mhall119> there's a good chance of that :)
<Diziet> PS wot no https link from summit to pad ?
<Diziet> Also ssl cert error on https://pad
<cjwatson> Yeah, it's probably not actually necessary to unbreak summit.ubuntu.com login for any of this - that's only needed for registering attendance I think, which isn't really required
<Diziet> I tried following the pad link for the session in question and it says
<Diziet> Either you have not been granted access to this resource or your entitlement has timed out. Please try again.
<mhall119> Diziet: file a bug on lp:summit for us to fix the link
<Diziet> The https url is 404
<mhall119> Diziet: you need to join the lp:~ubuntu-etherpad team to edit the pad
<mhall119> hmm, might not have https configured for pad.ubuntu.com
<cjwatson> (This is because otherwise it gets ridiculous amounts of predictable ASCII-art body parts scribbled all over it by vandals)
<Diziet> cjwatson: Yes.
 * mhall119 blames phoronix
<Diziet> OK now I am in that team but the error message is the same.
<Diziet> | You have successfully joined Users of the Ubuntu Etherpad instance.
<Diziet> Funny that it didn't want me to get any approval.
<Diziet> Oh I'm in "Pending approval"
<Diziet> That's rather a misleading headline.
<cjwatson> yes it is, I will fix that
<Diziet> Well I'm glad I have over an hour to wrestle all this.
<popey> approved
<cjwatson> Huh, except the code says it should be "Your request to join ${team} is awaiting approval."
<cjwatson> you may need to log out of pad and back in
<cjwatson> since it's probably remembered your team memberships from the openid exchange
<cjwatson> message> ah, I see, this is specifically for delegated teams
<Diziet> Can I navigate away from this page with the misleading message or do you want it for something ?
<mhall119> Diziet: what's your LP nickname?
<Diziet> ijackson
<cjwatson> go ahead and navigate away
<mhall119> I've approved your membership in the team
<mhall119> try going to pad.ubuntu.com again
<Diziet> I can't create a google account because my mobile phone is at home.
<Diziet> FFSA
<Diziet> I guess I can probably change this number later.
<Diziet> popey: Thanks for the approval
<popey> np
<Diziet> Yay now I have etherpad
<popey> huzzah
<Diziet> Should I file a bug about my summit account ?  It would be nice to fix it for next time even if I don't need it now.
<mhall119> Diziet: file an RT, this happens when SSO and Launchpad disagree on what your OpenID id is
<Diziet> I don't suppose you could point me to the RT instructions ?  Email address, magic subject thingy, etc.
<mhall119> email rt@ubuntu.com tell them the problem you have, give them your LP name and SSO email so they can check it out
<Diziet> https://help.ubuntu.com/community/RT  <- clearly not what I wanted :-)
<Diziet> Ta
<cjwatson> SSO and Launchpad> hm, maybe I can help with that then
<Diziet> I have sent a mail to RT
<Diziet> I assume an ack from RT will be forthcoming when it has got through my greylist.
<smoser> pitti, around ?
<smoser> wondering if i can get some time to talk to you about a cloud-init sru with its systemd changes.
<slangasek> smoser: hi there
<smoser> hey.
<smoser> so, rharper and i are currently under the belief that the systemd changes do not regress anything on xenial.  systemd-networkd and cloud-init remain tricky as discussed in bug 1636912
<ubottu> bug 1636912 in systemd (Ubuntu Xenial) "systemd-networkd runs too late for cloud-init.service (net)" [High,Triaged] https://launchpad.net/bugs/1636912
<smoser> but that isn't a wide spread or supported use (cloud-init + systemd-networkd)
<rharper> specifically, xenial + cloud-init in the cloud-images still use ifupdown;
<slangasek> smoser: "the systemd changes" being the ones in the previous submitted SRU?
<smoser> slangasek, well, current zesty
<smoser>  http://paste.ubuntu.com/23481409/ is the combined result
<rharper> smoser: bbiab, afk for now
<slangasek> smoser: ok, so it includes the changes as discussed on the bugs?
<slangasek> specifically, the Before=basic.target fix
<smoser> yes.
<slangasek> ok
<slangasek> then I'm +1 for this :)
<smoser> slangasek, ok.. so i'm putting together some more info at http://pad.ubuntu.com/tMdgYGEvgL
<smoser> describing all of the changes for systemd.
<slangasek> smoser: well, it should be possible to discern all relevant information from the changelog, so that the context isn't lost later when we can't find that pad url ;)
<nacc> rbasak: do you have permission to set the hangout URL?
<smoser> slangasek, i dont know that that is true...
<smoser> changelog entries are supposed to be terse
<rbasak> nacc: no. I guess I'll need to set it up and send you the URLs?
<smoser> i'm willing to put text wherever you want it (and it exists in upstream git commits) but i dont think you really want it in the debian/changelog
<nacc> rbasak: yeah, i guess so
<smoser> nacc, rbasak i'll sit in the hangout there if you'd like
<smoser> or not if you'd like that too :)
<slangasek> smoser: well, for an SRU I want the changelog to explain each change and why (where "why" may just be a pointer to a bug that has details)
<rbasak> smoser: please
<smoser> slangasek, well, i'll try to get all in such a state and upload.
<rbasak> smoser, nacc: https://hangouts.google.com/hangouts/_/ytl/yq07F04I9D_f6YnWIxoB7HycyY363CimE_hAfjF8Ptc=?hl=en_GB&authuser=0
<rbasak> brb
<rbasak> nacc: http://youtu.be/TuSe0eBjMxE
<Odd_Bloke> slangasek: Could you copy the yakkety google-cloud-sdk in partner forward to zesty, please?
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/join-delegated-team-message/+merge/310908 (ignoring the terrible ancient doctests) should fix the misleading messages that Diziet saw.
<slangasek> rbasak, nacc: would you like anyone from Foundations on that HO?  e.g. barry or myself
<nacc> slangasek: it would probably be good to have some representation, presuming we can get it working :)
<barry> i'm happy to hangout
<slangasek> barry: https://hangouts.google.com/hangouts/_/ytl/FfvzFcwTgW8qXQc2vOX5pYOQS51NOMYubPQfO1XGCfU=?hl=en_US&authuser=0 ; #ubuntu-uos-community
<smoser> shoot.
<barry> slangasek: it says i'm not authorized to start the call
<rbasak> smoser: ^ working for you?
<slangasek> barry: wiggle the 'authuser' setting?
<smoser> pitti, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547 cloud-init-local.service still has 'Before=basic.target' i wonder if that is right or if that should also be 'Before=sysinit.target'
<barry> slangasek: yay!  i'm the first one there
<slangasek> barry: you're really not ;)
<barry> it looks pretty lonely ;)
<slangasek> barry: 8 of us in the HO
<rbasak> Pad link: http://pad.ubuntu.com/uos-1611-git-based-merge-workflow
<barry> slangasek: wtf?  oh well, irc-only i guess
<bdmurray> What does marked_keep with python-apt mean? https://apt.alioth.debian.org/python-apt-doc/library/apt.package.html
<bdmurray> I ask as the release upgrader is showing some strange behavior.  An upgrade from X to Y shows the following.
<bdmurray> ipdb> pkg.name, pkg.marked_install, pkg.marked_upgrade, pkg.marked_keep, pkg.is_installed
<bdmurray> ('linux-image-4.8.0-22-generic', False, False, True, False)
<sarnold> bdmurray: neither 'hold' nor 'held' appear in the doc, I wonder if "keep" is their spelling of "hold"
<bdmurray> sarnold: I'd think either of those imply is_installed though.
<sarnold> bdmurray: huh. good point.
<bdmurray> So I don't see why its marked_keep and nothing else.
<juliank> bdmurray: That's a very good question
<juliank> I'm not sure if it means hold or if it means "marked for keep by the solver"
<nacc> smoser: fyi, dgit does have the same behavior (e.g., 'dgit/dgit/sid')
<smoser> )
<smoser> :)
<juliank> bdmurray: As far as I can tell, one of the solver thingies uses that to mark packages it wants to keep
<juliank> maybe because it can't be upgraded?
<doko> juliank: I noticed that apt show doesn't show the component / file location any more. is this intended?
<doko> compared to apt-cache show
<juliank> doko: Yeah, I think so. It's kind of pointless in a high-level user-friendly view.
<juliank> s/high-/higher-/
<juliank> bdmurray: But really, if it uses the upgrade function thing, then that also marks hold back packages as keep first
<doko> juliank: lacking some information doesn't sound user friendly ...
<juliank> doko: Well, for the normal user, it's arguably more useful to know which source the file is from (APT-Sources), rather than the path inside that source
<juliank> It's not like they navigate to that in the web browser or download via curl
<juliank> But oh well, I'll ask the others if you want Filename as well
<sarnold> heh, I sometimes do use apt-cache show to find the url to download via wget, heh
<doko> ta
<Unit193> juliank: Howdy.
<juliank> Alright, it's Unit193 again :)
<bdmurray> juliank: okay, thanks for the information
<juliank> bdmurray: The reason why the docs are so unclear is that I did not really know a lot back when I wrote them...
<pitti> smoser: yes, I answered in https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310919
<smoser> pitti, thanks.
<smoser> pitti, but DefaultDependencies=no doesn't say Before=basic.target, it just doesn't say After=basic.target
<smoser> right ?
<pitti> smoser: correct; it's not equivalent, just says "I want to run this early"; the Before=sysinit means "I have to run it early", but AFAIK you really only want to run it before c-i, so I find it redundant
<pitti> smoser: but, it's just a stylistic question, so go ahead :)
<smoser> yeah
<smoser> slangasek, http://paste.ubuntu.com/23482240/
<smoser> does that debian/changelog look acceptable to you?
<pitti> smoser: "+ add Before=basic.target." â I thought you wanted to move that to sysinit.target?
<smoser> pitti, well, i will, but what is in zesty now is Before=basic.target
<smoser> and i'd rather copy what is in zesty since its innocent
<smoser> so, its there for now.
<pitti> smoser: oh, that's for xenial, I see
<slangasek> smoser: MAAS: improve the debugging tool - is there a bug for this?
<smoser> no. its not code that is executed at runtime
<smoser> but i can open a bug if youw ant me to.
<smoser> its only run if someone runs: python3 -m cloudinit.sources.DataSourceMAAS
<pitti> smoser: I didn't check, but please don't land the changes in bug 1636912 yet -- it's not actually that easy to run networkd before dbus.service
<ubottu> bug 1636912 in systemd (Ubuntu Xenial) "systemd-networkd runs too late for cloud-init.service (net)" [High,Triaged] https://launchpad.net/bugs/1636912
<slangasek> smoser: ok, I can ignore that then
<smoser> gah. pitti what changes do you  mean ?
<smoser> i'm not going to change systemd-networkd
<pitti> smoser: I mean right now you can't run anything After=systemd-networkd.service and Before=sysinit.target
<smoser> but i believe the cloud-init changes are sufficient to mark ti as fixed. or i can change it to not fixed and drop that bug mention if you'd rather.
<slangasek> smoser: ok lgtm
<slangasek> (the changelog)
<smoser> pitti, now i'm really confused.
<smoser> you acked that https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547
<smoser> unless i misunderstood something
<pitti> smoser: yes, that c-i side looks good, but it assumes the networkd side of that bug
<pitti> smoser: (and back then I thought it was a simple thing to do)
<rharper> pitti: it's only an issue of there's a netplan yaml on the system
<pitti> correct (or if networkd got enabled by the admin)
<rharper> otherwise netplan generator won't trigger bringing in networkd as a wants
<pitti> then you'll get dep cycles
<smoser> ok, thats what i thought. got cnfused for am inute.
<rharper> smoser: so it feels like cloud-init + networkd is blocked until the dbus.service issue is resolved;
<rharper> pitti: on that issue (networkd not getting dbus control); would a simple restart of networkd after dbus.service is up be OK ; since networkd doesn't touch/modify up'ed interfaces; would that restore dbus control and not bother the current network config ?
<pitti> rharper: it will attempt DHCP though
<rharper> really?
<rharper> that seems at odds with the 'don't bother already up interfaces' that I read about networkd
<rharper> that's due to networkd being the client itself
<rharper> unfortunate
<pitti> well, it will add new (manual) addresses and request DHCP if the config asks for it; it will not *remove* existing addresses or down interfaces
<rharper> certainly it shouldn't bother to run DHCP on an up'ed interface though ?
<pitti> rharper: well, it puts the lease into /run, maybe it won't reattempt
<rharper> that's worth testing
<pitti> (I was testing all day with failed DHCP, and restart does reattempt that)
<rharper> that's unsuccessful DHCP in the first place though
<pitti> right
<rharper> vs. successful attempts
 * rharper plays with restart networkd 
<rharper> how do you test for the dbus control of networkd ?
<pitti> rharper: d-feet, or "busctl introspect org.freedesktop.network1 /org/freedesktop/network1" or something
<rharper> cool
<pitti> rharper: current idea is to teach it to re-attempt D-Bus connection and hostname setting when it gets a SIGUSR
<rharper> OK, and if that comes through into zesty than SRU to xenial, we could land the changes
<rharper> and there's no way for dbus.service to SD_NOTIFY that it's now up and consumers wanting dbus could listen to SD_NOTIFY events ?  probably because that's implemented on dbus, right ?
<pitti> rharper: no, that's a simple Unix socket, I think
<pitti> rharper: but regardless of whether it's SIGUSR1 or sd_notify -- the action is the interesting part (less important to which signal handler you hook it into)
<rharper> yeah
<rharper> pitti: it appears from the log, that networkd did re-DHCP
<rharper> =(
<rharper> brb
<smoser> pitti, the re-attempt on SIGUSR is acceptable to upstream?
<pitti> I didn't discuss it yet
<pitti> that was in #debian-systemd with mbiebl
<rharper> https://github.com/systemd/systemd/issues/1546
<rharper> it appears that it does DHCP again, but if that's right, it shouldn't break connection if the lease is the same;  but I suppose this is only relevant w.r.t the timeframe for SIGUSR being acceptable and SRUable vs. a restart in the short term
<pitti> rharper: right; triggering a restart seems more brittle, but in the restricted context of cloud-init and netplan it may be acceptable
<rharper> pitti: I ran busctl, but I don't have what it *should* look like vs. what it does when networkd doesn't get dbus connection ;
<pitti> rharper: oh, right -- it actually gets dbus activated, so if it's not running, it will be once you try and talk to it via dbus
<pitti> rharper: if it's not on teh bus, you should get an error like "Unknown object"
<rharper> pitti: interesting
<rharper> pitti: hrm, let me confirm that in my ubuntu-core with cloud-init and networkd that I'm running networkd without After=dbus.service;  if so, then it appears to "Just Work (tm)" if the busctl output is a proper test
<rharper> ah, I'm not;
 * rharper tries that version 
<pitti> $ busctl get-property org.freedesktop.network1 /org/freedesktop/network1 org.freedesktop.network1.Manager OperationalState
<pitti> s "routable"
<pitti> if something like that works, you're good
<rharper> yeah, that's what I got but I need to test with the removal  .. I suspect it fails as you say
<pitti> (in case you don't know, it has full command line completion)
<pitti> and even the completion should fail if it's not running
<rharper> ok
<rharper> smoser: so, for the SRU, then we need to backout the After=systemd-networkd-wait-online.service then (and I suppose fix up Yakkety too) until we get a networkd dbus service solution;
<rharper> does that sound right ?
<smoser> reading
<smoser> rharper, so it would seem you mean we should back out everywhere.
<smoser> right ?
<rharper> yes
<smoser> with the justification that an unresolvable boot sequence is worse than cloud-init.service running to early
<rharper> I really doubt anyone is using it that way; but the regression potential is real;  but it does seem limited to dbus control of networkd
<smoser> the system is busted in either case.
<rharper> smoser: right, there's a good change that cloud-init gets kicked out (
<smoser> either you dont get networking, or you dont get cloud-init.service.
<smoser> either way, you're sol on first boot for sure
<rharper> if you've modified your image such that it includes a netplan yaml
<smoser> and better off if cloud-init.service loses in other boots.
<rharper> then, it will run but cloud-init won't "wait" on it
<rharper> if we tell cloud-init to wait on it, then we get a loop, unless we drop the dbus.service requirement on networkd
<rharper> if we drop it, then we break dbus control of networkd
<rharper> messy
 * rharper relocates, bb in 20 
<smoser> bah.
<smoser> ping when you're back.
<smoser> slangasek, ^ go ahead and hold off on that.
<slangasek> smoser: the potential regression is networkd + cloud-init in xenial?
<pitti> yes, if both are enabled you'll get a dep cycle
<smoser> so what happens right now is that you get a race on cloud-init running before network is configured.
<pitti> current: networkd after dbus.service after sysinit.target; new: cloud-init before sysinit.target after networkd
<slangasek> right, as they would be both enabled for certain ubuntu-core use cases
<smoser> neither dep cycle or race is good.
<slangasek> smoser: I'm deep in the current review so I'll leave it in the queue for cross-comparison with whatever you upload next
<smoser> right, the change would be http://paste.ubuntu.com/23482542/
<slangasek> smoser: doesn't that reintroduce the previous race?
<smoser> of course.
<slangasek> ok
<slangasek> so it's 'back out this one change and get the rest of the SRU in'
<smoser> yeah
<smoser> pitti, are you ther e?
<pitti> -ish
<pitti> so http://paste.ubuntu.com/23482542/ would simply not yet bring netplan support with cloud-init
<pitti> which seems acceptable
<smoser> s/netplan/any systemd-networkd/
<pitti> it's actually not really a race -- it's guaranteed to not work :)
<pitti> smoser: right, sorry (in the context of xenial, netplan is the main consumer though)
<smoser> its probably  a race in xenial now
<smoser> so what about cloud-init.service waiting (via /lib/systemd/systemd-networkd-wait-online) if it determines that it needs to
<smoser> possibly even just:
<smoser>  [ -e /etc/netplan/netplan/*.yaml
<rharper> smoser: I don't think we can work around the fact that networkd currently requires dbus, and cloud-init.service wants to explicity run *before* it's available;
<rharper> smoser: netplan already has a generator on that sort of thing
<rharper> if cloud-init.service wants to run after networkd-wait-online, and also wants to run before dbus.service; we're boned until networkd can run without dbus; and then when dbus is available, regain it's dbus control interface;
<smoser> cloud-init doesnt have to run before dbus specifically
<smoser> that was just fallout of resolvd
<smoser> rharper, so can you show me how to make a system use netplan so i canplay a bit ?
<smoser> i think just put something in /etc/netplan/my.yaml
<rharper> I don't think there's an alternative in cloud-init today to deal with early DNS timing out on resolvd ; technically in xenial we don't have systemd-resolved., but it could show up (and we'd divirge on systemd unit files)
<rharper> smoser: yeah
<smoser> and then somehow disable ifupdown
<rharper> yes
<rharper> I'll send you a paste
<pitti> remove /e/n/i and create a /etc/netplan/my.yaml with the first example in man netplan (for ens3)
<smoser> remote eni as in dpkg --remove ifupdown ?
<pitti> just moving the file aside is fine
<pitti> (or comment out the ens3 stanza at lealst)
<rharper> http://paste.ubuntu.com/23482607/
<rharper> smoser: that has a DHCP on all ethernet v2 yaml
<rharper> then you just need to remove the source in eni to prevent ifupdown from "seeing" fallback config from cloud-init
<slangasek> smoser: I don't understand the 'RequiresMountsFor=/var/lib'.  This is fixing the dep loop problem on LP: #1611074 that I pointed out on the last round, right?  Why is /var/lib the relevant path here - shouldn't you specify the full path that you care about from within cloud-init-local (e.g. /var/lib/cloud)?
<ubottu> Launchpad bug 1611074 in cloud-init (Ubuntu Xenial) "Reformatting of ephemeral drive fails on resize of Azure VM" [Medium,Confirmed] https://launchpad.net/bugs/1611074
<smoser> that probably is more correct.
<slangasek> smoser: do you mind changing that to be more correct as part of the SRU?
<smoser> i think initially i was just hesitant, and figured it was good enough.
<smoser> i'm willing to change that though.
<slangasek> smoser: I think it's best to change it
<slangasek> smoser: also, I notice cloud-init.service has Wants=sshd-keygen.service and sshd.service; that seems wrong, cloud-init shouldn't be the thing deciding to start these services, it really only cares about ordering?  But this is not a regression / not SRU relevant, so feel free to redirect me to a bug report
<smoser> slangasek, i generally prefer known working to "seems correct"
<juliank> doko: DonKult does not really want Filename in apt without a specific usecase why it should be there it seems
<smoser> zesty has this, anad no issues known since friday or so
<slangasek> smoser: that no longer sounds like "I'm willing to change it" :)
<smoser> slangasek, i'm willing to.
<doko> juliank: ok, but how do you get the component?
<smoser> but in almost all cases i prefer working to more correct.
<juliank> doko: You mean main, etc? I think you can read that in Apt-Sources
<smoser> and the case here that is solved by adding '/cloud' is a case where /var/lib/cloud is on its own mountpoint in /etc/fstab
<doko> juliank: but source and binaries can have different components
<smoser> which is fine, and yeah, it does seem more correct, but it seems a  very limited case
<smoser> one that i'm certainly willing to fix in trunk and eventually sru though
<smoser> but... all that said, ifyou'd prefer me to commit to trunk, upload to zesty and do the re-sru at the same time, i'll defer to you
<slangasek> smoser: if you're committing to making the change in trunk that's enough for me for now.  The case that's fixed by being more correct is marginal
<juliank> doko: Well, I don't know how it's laid out in the pool. So you're saying one could be in a "universe" sources.list entry and be in a pool/main directory? Doesn't dists/DIST/<component> match pool/<component>?
<smoser> i'll file a bug and fix in trunk right now.
<doko> juliank: not sure about debian, but in ubuntu, you can have the source and some binaries in main, and other binaries in universe
<slangasek> smoser: but it's definitely more correct; it will work (and would be tested as part of the SRU anyway so you don't have to take my word for it, which you shouldn't); and in addition to helping the small minority of users making a mountpoint of /var/lib/cloud, it makes it more obvious why that line is there so that future editors don't make thinkos
<juliank> doko: I got that. But then I'd expect the universe binaries to be in pool/universe and in the universe Packages file, or are you saying the universe binaries are in pool/main
<smoser> i've just been through enough "definitely more correct" with systemd recently to be gunshy
<rharper> small minority of users with a separate /var/lib/cloud mountpoint is zero; at least users of the cloud-images we build
<juliank> Because: APT-Sources gives you the Packages file the file will be fetched from basically, it will always show the binary component.
<rharper> I don't think it's unreasonable to defer the correctness bugs to be filed by said users of cloud-init outside of the cloud-images we build
<doko> so how do I get the component of a binary package?
<slangasek> rharper: except then it's not obvious why you're listing /var/lib at all
<slangasek> /var/lib/cloud is much clearer
<juliank> You look at "APT-Sources: http://localhost:3142/ubuntu yakkety-proposed/main amd64 Packages"  (for example) and see that it says /main after the archive name
<smoser> i completely agree with slangasek, and i trust slangasek. but i trust 4 days of "working"  more.
<smoser> :)
<juliank> That says: This binary is in main.
<rharper> slangasek: I agree, with both; but I don't think it's sufficient to put /var/lib/cloud for a non-existent use-case
<juliank> If you want the source component, you'd have to look up the corresponding source package.
<rharper> either we actually document in the changelog (or the file itself) the systemd magic that is invoked with RequiresMountPoint
 * juliank has the feeling he is missing something
<rharper> or we just assume magic;  if we're supposed to tell systemd wichi mountpoints the service depends on, that seems awkward; but maybe that's the price of DefaultDependencies=No
<rharper> if so, we should document it, and it should also include /var/log  as well  , and /etc and other dirs that cloud-init writes to itself;
<rharper> that leaves open the fact that user-data may want to write to other locations on the system that we can't know at build time
<juliank> doko: If there's something I'm missing, name me an example package (one binary in main, other in universe) I can look at - I don't know one right now
<doko> juliank: gcc-6 source, gcc-6 binary in main, gcj-6 binary in universe
<infinity> (base)adconrad@nosferatu:~$ apt show gcc-6 gcj-6 2>/dev/null | grep ^APT-Sou
<infinity> APT-Sources: http://us.archive.ubuntu.com/ubuntu zesty/main amd64 Packages
<infinity> APT-Sources: http://us.archive.ubuntu.com/ubuntu zesty/universe amd64 Packages
<infinity> doko: ^-- Yes, that works fine.
<juliank> ^ exactly
<doko> ta
<infinity> Of course, the stderr that I filtered out is:
<infinity> WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
<infinity> ;)
<juliank> Yep :)
<juliank> infinity: I must say the whole core-dev thing is working out well. I sponsored some stuff in the past months, although I don't really have a count of how much, LP does not seem to keep track of everything :/
<infinity> https://launchpad.net/~juliank/+uploaded-packages ?
<juliank> Yeah, that has some stuff in it. It misses some stuff I uploaded, but I can't recall exactly what that was...
<infinity> It should have everything signed by you, in theory.
<infinity> Signed and directly uploaded, that is.
<infinity> Oh, no.  Hrm.  Maybe that only has the Changed-by stuff.  Since it also has some things sponsored by others.
<juliank> Yeah, I think so. Sponsored stuff like the ark one I signed does not appear.
<infinity> We might be missing a section for actual uploads.
<infinity> File an LP bug? :)
<infinity> LP does track uploader (as you can see in any sponsored upload), so it should be trivial-ish to provide a history/count.
<infinity> The part where we've overloaded the term "uploader" is less helpful. :P
<infinity> But that really predates Ubuntu.  The .changes fields have never made sense.
<infinity> We just made it worse.  Apparently.
<juliank> I suspect there probably already is a LP bug for that
<infinity> It may be 4 or 5 digits, even.
<juliank> https://bugs.launchpad.net/launchpad/+bug/155956 is related at least
<ubottu> Launchpad bug 155956 in Launchpad itself "+me/+packages should present different sections for sponsored uploads" [Low,Triaged]
<infinity> If you ask wgrant, he can usually recite them.
<infinity> Because he's weird.
<infinity> And possibly not human.
<juliank> One thing that annoys me is that I set my contact email to my gmail recently, and the sponsored stuff now appears as signed-by: <gmail address>
<infinity> Yeah, because when we process the incoming upload, we map your GPG sig to your LP account.
<juliank> That's a bit annoying, it'd look better with the @ubuntu.com one ...
<infinity> And uploader is stored in the DB as a pointer to your LP users, not the key.
<infinity> And then we present your primary address as the user in the UI.
<juliank> I used to have juliank@ubuntu.com as my primary address, but that might have only gotten half of the emails; and there are rumours of redirect loops
<infinity> juliank: So, I think the feature you'd be asking for is to decouple "display address" and "contact address" as two different objects.
<juliank> Yeah, I think there's a bug report for that
<infinity> Which is a valid feature request, IMO.
<infinity> Especially for the reason you note.
<infinity> People are encouraged to NOT use @ubuntu or @canonical as their primary, for fear of looping the automagic machinery.
<infinity> But it's likely the one they want on display.
<juliank> https://bugs.launchpad.net/launchpad/+bug/5292
<ubottu> Launchpad bug 5292 in Launchpad itself "People setting preferred contact address to @ubuntu.com" [Low,Triaged]
<juliank> And LP people don't know how the aliasing works, as IS does that
<juliank> that's all I know
<infinity> 4 digits.  Nice.
<infinity> So, the LP argument 6 years ago that the forwarding thing is an IS bug is technically true, but it's still an LP bug that display and contact are lumped together.
<infinity> I want humans to see one and machines to send to another.
<infinity> Maybe I'll resurrect this one.
<juliank> Right. This also makes more sense than dealing with that in the redirect, because why sent it via all redirects, if I can just tell launchpad the real address behind the alias.
<infinity> It becomes a non-trivial bug when phrased the way I do, though, since we need to grep the full source and make a case-by-case decision on every occurrence of Person.email as to whether it's being used to send stuff or to display stuff.
<smoser> slangasek, uploaded. delta versus the last upload: http://paste.ubuntu.com/23482797/
<juliank> infinity: Well, it does not have to be "perfect" at the beginning. Just better than the status quo
<juliank> infinity: And the field just says "Display Contact Address (beta, might not be used everywhere yet)"
<juliank> :)
<infinity> juliank: It would also solve the longstanding misfeature where logged-in users can see your email in various places.
<juliank> You could specifiy "No Display address"
<infinity> juliank: As we can allow your *display* address to be a spam blocker or nothing at all.
<infinity> Right.
<Unit193> Now I just need to find a way where people can't just hit that shiny "Contact user" button. >_>
<rbasak> mwhudson: forgot the link> yes. Thanks!
<infinity> Unit193: "Do not display contact user button" would be a trivial change on top of this. :P
<infinity> (Though, would also need to cascade down to "contact team", etc)
<mwhudson> rbasak: no worries :)
<juliank> infinity: Just "Do not show "..." button" avoids all the hard work (hopefully)
<infinity> Contact user doesn't bug me, it's "contact team's admins" that bugs me the most, since I seem to be on that list for a lot of teams that people feel the overwhelming urge to have opinions at.
<Unit193> Oh, well if people expect a response, email may not be the best method. :D
<juliank> The button does not even say anything about email ...
<juliank> :)
<infinity> It has an envelope icon!
<Unit193> infinity: Because you're here, know what https://twistedmatrix.com/trac/ticket/5350 (#5616) status change means to #907675?
<juliank> But, but, it would be nice if LP could just send those messages via xmmp!
<Unit193> juliank: IRC!
<juliank> It could use an XMPP transport for that
<mwhudson> facebook message
<infinity> juliank: rfc1149
<juliank> transport again!
<Unit193> mwhudson: Eww, that's the worst.
<juliank> WhatsApp
<juliank> that surely is worse
<juliank> Like "everyone" uses it.
<Unit193> I might be the only one that hasn't.
<juliank> I don't use it.
<infinity> Unit193: Colin's the right person to talk to about that.
<Unit193> infinity: But he's scarier than you! :>
<infinity> Nah, he shaved off the beard.
<juliank> I only use my XMPP accounts, hangouts, signal, and fb messenger (almost never)
<juliank> Before FB it was ICQ
<infinity> I gave up on pretty much all forms of IM as everyone I knew who used them stopped doing so.
<Unit193> Skype count?
<infinity> Sure.
<juliank> Oh yeah, Skype too
 * Unit193 adds juliank.
<juliank> Good luck!
<juliank> At least I don't end up adding "friends" by accident like when I'm using FB on mobile phones...
<juliank> or "like"ing stuff
<Unit193> juliank: Telegram?  That's another popular one.
<juliank> Oh sure, funny hate comments, let's read them. Oh no, I accidentally liked one.
<juliank> Unit193: nah
<juliank> I only use Signal for encrypted chats with my family basically.
 * Unit193 looks it up.
<juliank> Sensitive stuff, like account numbers and so on
<juliank> Whoa, jabber.org finally fixed their DNS servers after 1.5 days.
<juliank> I only need that one to talk to mvo when he's not on IRC, though
<juliank> Well, I also have some people like dholbach in my roster, but never seen them in the past years
 * juliank probably should clean that up
<Unit193> kirkland:
<Unit193> Er,. wjpp;
<juliank> Now that you mention him, I always wonder if he'd like his picture flashed in a background on a screen in Mr. Robot somewhere.
<juliank> or name
<Unit193> Well I didn't mean to, meant to ping you.  Think I need people "last seen" in '13? :P
<juliank> There's been a pretty absurd scene in Mr. Robot where Elliot was basically running apt-get update
<juliank> It was entirely unclear why he was running apt-get update at that point, given that he ran it before already IIRC
<Unit193> I made it 3 episodes into season 2 and couldn't do more because it was slow and just him monologuing.
<juliank> Try again
<juliank> It's getting better
<juliank> And let's just say reality is subjective
<juliank> You gotta get to episode 7 before you understand what's going on
#ubuntu-devel 2016-11-16
<tsimonq2> Hey guys.
<tsimonq2> If you read backlog from yesterday in this channel, julienk sponsored a fix for ark that we got from upstream in bug 1636655.
<ubottu> bug 1636655 in ark (Ubuntu) "[SRU] Ark no longer opens rar files in 16.10" [Undecided,Fix released] https://launchpad.net/bugs/1636655
<tsimonq2> I'd like to start the SRU process to get it in 16.10.
<tsimonq2> I think this involves someone uploading it to yakkety-proposed if I'm not mistaken. Otherwise if it just needs a member of the SRU team to notice, well, HAI! :)
<tsimonq2> Any help would be appreciated.
 * tsimonq2 looks at patch pilot calendar...
<tsimonq2> Ah ok nevermind.
<cpaelzer> good morning
<pitti> Good morning
<nildude> hi
<tuxinator>  hi everybody, ok, think that #ubuntu was the wrong place,just found out that ubumirror is broken (atleast the cdimage part) https://help.ubuntu.com/community/UEC/Provisioning/Mirror does not work as it always tries to find "current" which does not exist
<doko> LocutusOfBorg: libpng1.6 ftbfs
<LocutusOfBorg> doko, fix dpkg :)
<LocutusOfBorg> I don't plan to have a delta for libpng in Ubuntu, sorry
<LocutusOfBorg> dpkg is broken, dpkg needs fix
<doko> why is dpkg broken?
<LocutusOfBorg> I enabled pie, because libpng was failing in Debian, bug 844429
<ubottu> Error: Launchpad bug 844429 could not be found
<LocutusOfBorg> debian bug 844429
<ubottu> Debian bug 844429 in src:libpng1.6 "libpng1.6: FTBFS: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC" [Serious,Fixed] http://bugs.debian.org/844429
<LocutusOfBorg> this fixed the static library build, but probably Ubuntu has to inject some pie flags too, when pie is not the default?
<doko> LocutusOfBorg: it's broken in Debian too, on kfreebsd-amd64 and x32
<LocutusOfBorg> yes, because dpkg is not smart enough to inject the flags
<LocutusOfBorg> I think it is broken where dpkg is not aware of the pie status
<doko> where is the bug report?
<LocutusOfBorg> https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=cf7f30aeba89f5bafe5046b7666985b661eaf217
<LocutusOfBorg> I think something like that does the job, isn't it better to enable pie everywhere like debian did?
<LocutusOfBorg> I remember you mentioning something like that
<doko> ahh, great communication. so this is turned on everywhere? without saying so?
<LocutusOfBorg> I don't speak dpkg sorry, I just can look at the commits
<pitti> Laney: FYI, filed bug 1642192 and putting the looping linuxinfo test out of its misery
<ubottu> bug 1642192 in linux (Ubuntu) "i386 4.9 in -proposed fails to boot in cloud instances" [Undecided,New] https://launchpad.net/bugs/1642192
<Laney> hey pitti
<Laney> how did you notice that?
<pitti> Laney: doko asked about it
<pitti> Laney: I would have noticed when reviewing excuses.html, but I didn't do that today yet
<Laney> Meh, I can't really spend more time figuring out asis - if someone understands this ada stuff then help welcomed
<cpaelzer> pitti: just FYI I tracked down a recent libvirt FTBFS to be caused by the recent gnutls30 upload
<cpaelzer> pitti: just in case someone else comes by and this gets a wider issue you can point them at bug 1641615
<ubottu> bug 1641615 in libvirt (Ubuntu) "FTBFS of libvirt 2.1 in zesty" [High,Confirmed] https://launchpad.net/bugs/1641615
<cpaelzer> pitti: that is where I track the work against libvirt
<cjwatson> Unit193: We need to do a big Twisted upgrade in LP, definitely, but it's especially-complicated because any newer version of Twisted than the old one we're stuck on declares pbr in setup_requires, which REALLY isn't friends with the buildbot infrastructure we use - so we need to switch our build system to pip in order to upgrade it
<caribou> pitti: what's the reason why apport does not collect the same files when a crash occurs on the CLI as opposed to when it happens for a GUI application ?
<caribou> pitti: i.e If I killall -SEGV on a vi running in an xterm, I get different content from running gvim from the desktop
<pitti> caribou: what's the difference in particular? (in principle they should be more or less the same)
<caribou> pitti: http://paste.ubuntu.com/23485451/
<caribou> pitti: the content of the desktop directory has the result of the kill -SEGV in the CLI
<caribou> pitti: ./gtk has the report created by killing gvim
<pitti> caribou: oh --
<pitti> caribou: in the GTK version you selected "show  details", but in the CLI version you didn't
<pitti> caribou: once you either submit or save or show teh contents in the CLI, apport will do the post-mortem data collection
<caribou> well, the CLI version never asked anything
<pitti> wut?
<caribou> let me try again
<pitti> apport-cli should ask you to send, show, analyze locally, save, etc.
<caribou> still, that's only true on a desktop, wouldn't happen on a server unless you add your snippet in .bashrc
<caribou> pitti: ok, I know where to look for, thanks for pointing that out
<pitti> caribou: that has nothing to do whether the crashing program is CLI or GUI; it's only related to whether or not you see the details in apport-{cli,gtk}
<caribou> pitti: k
<caribou> pitti: great, running apport-cli on the report & view does the trick, thanks!
<LocutusOfBorg> doko, please python-numpy merge? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> I hope it can fix mipp
<doko> hope?
<LocutusOfBorg> I'm trying right now, as soon as the build finishes
<LocutusOfBorg> there is a segfault in testsuite
<LocutusOfBorg> look at gdal autpkgtest against mipp
<LocutusOfBorg> test_tsx (test_xsar.Test) ... Segmentation fault
<LocutusOfBorg> and such test is using numpy, the difference between debian and ubuntu for numpy is the version
<LocutusOfBorg> so, can you please merge it anyway? :p
<doko> I'll wait for the ppa build to finish
<LocutusOfBorg> ack
<LocutusOfBorg> if you wait two more minutes I can even say if the test is fixed
<LocutusOfBorg> this is blocking gdal
<tuxinator> hi, i found out that the config example of ubumirror is broken (atleast the cdimage part) https://help.ubuntu.com/community/UEC/Provisioning/Mirror does not work as it always tries to find "current" which does not exist
<doko> xnox: could you merge auctex? last package preventing demotion of emacs24
<xnox> doko, ack
<LocutusOfBorg> doko, it fails anyway, but it might be nice to merge it anyway
<LocutusOfBorg> pitti, why postresql-common is till defaulting to 9.5? this is making a lot of dependencies FTBFS
<doko> meh, there were even some 9.3 packages seeded ...
<pitti> LocutusOfBorg: ftbfs how?
<pitti> (sorry, UOS session now, bbl)
<LocutusOfBorg> -Depends: postgresql-9.6, ${shlibs:Depends}, ${misc:Depends}
<LocutusOfBorg> +Depends: postgresql-9.5, ${shlibs:Depends}, ${misc:Depends}
<LocutusOfBorg>  Description: reorganize tables in PostgreSQL databases with minimal locks
<LocutusOfBorg> Error: debian/control needs updating from debian/control.in. Run 'pg_buildext updatecontrol'.
<LocutusOfBorg> e.g. pg-repack, but many others
<cjwatson> tuxinator: which "current" URL in particular?  current really should exist
<cjwatson> (if there's a CI gateway in place for the flavour, it's the latest build to have passed that; otherwise, it's just the latest build)
<LocutusOfBorg> how can I fix this code import now that git - git import works?
<LocutusOfBorg> https://code.launchpad.net/~blueyed/boinc/pkg-boinc
<cjwatson> LocutusOfBorg: Create a new code import per https://help.launchpad.net/Code/Git#Mirroring_repositories_from_other_sites - you can't change the existing one into a git-to-git import
<LocutusOfBorg> cjwatson, I think I just did that https://code.launchpad.net/~costamagnagianfranco/boinc-upstream/+git/boinc-upstream
<LocutusOfBorg> it was a bzr, I did click somewhere and changed to git
<cjwatson> That's a new import
<cjwatson> Why is the project name "boinc-upstream" rather than just "boinc"?
<LocutusOfBorg> because I'm creating a "boinc" that tracks the debian pkg-boinc
<LocutusOfBorg> and upstream tracks the upstream  nightly commits
<cjwatson> That should probably be an import into /debian/+source/boinc then
<cjwatson> Though you'd have to use the API to create that, so whatever
<cjwatson> Anyway, was just curious
<LocutusOfBorg> thanks!
<cjwatson> LocutusOfBorg: Note you don't need the trailing .git on GitHub URLs any more for git-targeted imports
<cjwatson> That was a workaround for their User-Agent sniffing
<LocutusOfBorg> I know, but I like to have them explicit :)
<LocutusOfBorg> and it looks similar to the debian import
<LocutusOfBorg> bzr: ERROR: bzrlib.errors.NotBranchError: Not a branch: "http://bazaar.launchpad.net/~costamagnagianfranco/boinc-upstream/boinc/".
<LocutusOfBorg> cjwatson, ^^
<LocutusOfBorg> it seems trying to use bzr to checkout it on the recipe
<LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/+recipe/boinc-upstream-daily-1
<cjwatson> LocutusOfBorg: see https://bugs.launchpad.net/launchpad/+bug/1623924 for workaround
<ubottu> Launchpad bug 1623924 in Launchpad itself "Source package recipes prefer Bazaar when lp:$foo alias is VCS-ambiguous" [High,Triaged]
<cjwatson> LocutusOfBorg: also, you can't have a mixed git/bzr recipe
<cjwatson> LocutusOfBorg: so you'll need to convert that lp:~costamagnagianfranco/+junk/boinc-upstream-merge branch to git
<LocutusOfBorg> ack thanks
<pitti> Logan: hm, these deps should be generated during package build from pg_buildext; are they hardcoded in the source?
<pitti> sorry Logan, I meant LocutusOfBorg
<nacc> rbasak: ping
<rbasak> nacc: o/
<nacc> rbasak: hey, do you have a few minutes to talk about parenting in the importer?
<rbasak> Sure
<nacc> rbasak: ho ok?
<rbasak> That's fine. Let me move to my desk.
<nacc> rbasak: thanks, sent an invite
<doko> one less lua version in main \o/
<doko> zul: Copyright: Others (See individual files for more details)    debian/copyright has to tell that :-(
<doko> who are "Others"?
<zul> doko: heh you are killing me here
<zul> doko: please reject..there are one or two other things i want to fix
<doko> zul: done
<zul> doko: thanks
 * doko shouldn't do new source reviews ...
<doko> nacc: freeradius autopkg tests are failing
<nacc> doko: thanks, will investigate
<nacc> doko: fwiw, failing in debian too -- let me see if i can figure it out there
<bdmurray> pitti: Could the result page of a retry request for autopkgtest include a link to the package page e.g. http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader
<bdmurray> or likely more specific with arch and release
<LStranger> Could anyone tell me what is exact way to close multiple LP bugs in changelog, please? In Debian I wrote (Closes: #1, #2, #3). Should I add (LP: #1, LP: #2) or what? :)
<LStranger> Since most of bugs fixed in coming lxpanel upstream release 0.9.0 are from LP, I would like to mark them for LP on upload into Debian sid (so eventually into Ubuntu as well). :)
<doko> slangasek: please merge cdbs: https://launchpad.net/ubuntu/+source/gdb/7.12-0ubuntu2
<slangasek> doko: done, though feel free to claim that one from me at any time ;)
<doko> maybe we should work on removing cdbs ...
<nacc> LStranger: that should be fine (LP: #..., LP: #...) I'm not sure LP: #...,... is supported.
<pitti> bdmurray: sure! that should be quick to do (if there is no PPA and no git branch)
<bdmurray> nacc, LStranger: LP: #, # works
<nacc> bdmurray: ah good to know!
<pitti> bdmurray: done; I fully followed the current design (i. e. euphemism for "it looks just as ugly")
<bdmurray> nacc: $changes =~ /lp:\s+\#\d+(?:,\s*\#\d+)*/pig is the perl re
<nacc> bdmurray: thanks, I should have just checked myself! :)
<bdmurray> nacc: Its not the easiest thing to find. ;-)
<juliank> If someone else is able to repro bug 1642386 - please let me know.
<ubottu> bug 1642386 in apt (Ubuntu) "At least one invalid signature was encountered." [High,Incomplete] https://launchpad.net/bugs/1642386
<juliank> I've now added most of the repos listed by sarnold to my xenial chroot, but don't manage to repro it yet
<bdmurray> I've been running 1.2.15 w/o issue since you asked for testing.
<juliank> I assume it's a corner case somewhere, that's why it's high
<juliank> Fixing this will likely require manual interaction on broken machines, as apt not being able to update repos obviously means it can't fetch newer apt versions :/
<LStranger> bdmurray: thank you very much!
<juliank> bdmurray: Another somewhat annoying thing is that 1.2.16 to fix the ValueErrors in ubiquity and friends is already tagged and in the -proposed queue (but some the bugs have no proper SRU [test case] sections yet...)
<juliank> -> If this needs some form of hotfix, it might get weird versioning wise :/
<juliank> Actually, I don't have a clue how to test the bug fixed in 1.2.16. I just know that it fixes them with 99% probability :)
<juliank> The "install google chrome .deb" in gdebi-gtk thing seems kind of straight-forward though, should probably work in a german locale.
<juliank> Testing the instance in the installer is probably tough
<bdmurray> juliank: aren't there crashes at errors for most of the fixes? the new version not showing up there, which might require a DB query, is good enough for this SRU team member.
<juliank> bdmurray: The two bugs have ValueError tracebacks AFAIK.
<juliank> Then again, even once 1.2.16 is in -proposed, who is going to run ubiquity against it?
<bdmurray> juliank: we could use a daily build for the xenial iso and it'll end up getting used w/ the next point release
<juliank> Well, I don't think I'll hear any news in the next minutes on the new APT bug, so I'm going to sleep for a bit - hopefully there'll be more info tomorrow.
<juliank> bdmurray: if you say so :)
<LocutusOfBorg> cjwatson, sorry for bothering but this python error seems a bug https://code.launchpad.net/~costamagnagianfranco/+recipe/boinc-daily
#ubuntu-devel 2016-11-17
<smoser> slangasek, if you're sitting there twiddling your thumbs, and you have any ideas on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1611074 i'd like to hear them.
<ubottu> Launchpad bug 1611074 in cloud-init "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Fix committed]
<slangasek> hard to type and twiddle at the same time
<smoser> i ususally peck with my nose.
<smoser> it wastes time that way too
<smoser> slangasek, one thing that seems wrong... but i'm not sure its entirely related.
<smoser> http://paste.ubuntu.com/23488127/
<smoser> when i run that script well after boot, sometimes i hit line 29.. that is to say systemd magically  mounts the partition for me.
<slangasek> smoser: but in this context you're repartitioning it from a booted state?  in which case the x-systemd.requires won't protect you
<smoser> correct.
<smoser> but i'd still find it odd and wrong to umount anad then have something magically mount for me.
<smoser> and i'im not convinced that its not related.
<smoser> most certainly, systaemd generator writes those files based on the stale fstab
<slangasek> it doesn't seem incorrect for systemd to automount for you a device that it discovers via udev, post-boot, whose deps are satisfied
<smoser> it seems to me that that should be a 'once' thing.
<smoser> no other mount service continually mounts automatically for you.
<xnox> unless there is .automount unit; or udev got retriggered for the device; "stop" the .mount unit manually?
<smoser> especially wrong when it could be mounting garbage of a filesystem that just happend to be at the place where you put the new partition.
<slangasek> xnox: in this context, udev has gotten retriggered for the device yes
<xnox> check the generator and the .automount / .mount units in /run/systemd ?!
<slangasek> smoser: so don't label your garbage with the exact same name that you were using to mount it by in /etc/fstab?
<slangasek> because this is the exact same code used to automount a removable device when you plug it in
<slangasek> which you might remove, and want to mount again
<xnox> use $ wipefs -a -> to wipe garbage off the partition?
<smoser> slangasek, you've not gotten a chance at that point to write a filesystem.
<smoser> and xnox your case doesn't even help... its really busted.
<smoser> yes, you can be careful and get aroudn this
<smoser> but it is nonsense.
<smoser> ie, if you want to repartition a disk, you have to:
<slangasek> smoser: yes, because your fstab refers to the partition in a way that triggers the mount before you've created a filesystem
<smoser>  a.) unmount everythin
<smoser>  b.) seek to the new partition table offsets and wipe any filesystem stuff that might possibly be there.
<slangasek> so if you're expecting to be able to do this online, post-boot... don't refer to the filesystem by a device name that shows up before the filesystem is created?
<smoser>  c.) partition it
<smoser>  d.) mkfs the partition
<smoser> you have to do 'b' because where you put the new partition might have had a valid filesystem signature.  even from an attack of some sort.
<xnox> wipefs does support offset argument -o
<smoser> interestingly, udev in all its auto-glory watches rw opens on /dev/devices
<xnox> smoser, i had hallarious bug reports in d-i w.r.t. serial re-installers in virtual machines, that use host LVM volumes as backing device stores.
<smoser> and rescans partitiontables for you automatically when wipefs closes
<smoser> so... lots of fun.
<smoser> right. this magic is quite nonhelpful when you dont want it.
<xnox> smoser, because create a fresh volume, may just align with old volume, and give you perfectly valid filesystem signatures, to bust the installations in funny ways.
<smoser> thats what im' saying
<smoser> *and* that data could actually be an attack
<slangasek> if you don't want it, that's called 'noauto'
<smoser> in your /etc/fstab entry, yes.
<smoser> which was stale
<smoser> and is still magically present when you remove it
<slangasek> how is it stale
<smoser> because /etc/fstab isn't the thing that is doing these mounts
<slangasek> ?
<smoser> its stale because its present from before the stop
<xnox> systemd-fstab-generator
<smoser> and then the new disk attached.
<slangasek> it's stale /with respect to what/?
<slangasek> your example script doesn't show any editing of /etc/fstab
<xnox> so unmount; remove ftab; systemctl daemon-reload (which should retrigger generators, and remove stale .mount generated units); do things; write new ftab; mount things ?
<smoser> sure. but that doesnt matter, slangasek.
<slangasek> it shows systemd following the instructions it's been given, faster than you're expecting
<smoser> i can do it, it doesnt stop the .mount service
<smoser> no one expects to edit /etc/fstab and stop a service to partition a disk.
<smoser> (i have specifically taken the line out of /etc/fstab)
<smoser> so yes, best case what you're suggesting is that i have to
<smoser> a.) edit /etc/fstab
<smoser> b.) systemctl daemon-reload
<smoser> c.) partition , mkfs
<smoser> d.) edit /etc/fstab
<smoser> e.) mount
<smoser> and 'b'probably doesnt work during boot
<smoser> i dont know that, but i suspect as many systemd things do not
<slangasek> isn't the *actual* problem you're trying to solve that systemd should not automount the disk at boot time, before cloud-init has run?
<slangasek> if so, let's please solve that problem, and not have a proxy battle about how automounting is designed in systemd
<slangasek> if not, I don't understand the scope of the bug so please explain it to me
<smoser> yes thats the problem. but i think it is related to the magic that i'm seeing.
<smoser> its possible its not.
<smoser> but essentially, cloud-init is doing the same thing as the script during boot, and then failing to mkfs because something has mounted the device.
<smoser> i' not certain its related to this, but it seems similar.
<slangasek> /rules.d/80-iio-sensor-proxy.rules
<slangasek> haaate
<slangasek> smoser: in the case where it has failed at boot, what are the contents of /run/systemd/generator/mnt.mount ?
<smoser> i'll recreate. it'll take me a bit.
<smoser> anything else you might want from before the failed boot ?
<slangasek> smoser: I don't know well enough what all I would want; I would really want to debug it interactively
<smoser> slangasek, i can let you in before and after.
<smoser> slangasek, my attempts to simplify fail
<smoser> ie, i've booted system... then just partitioned the existing disk and put ntfs on partition 1
<smoser> and then rebooted
<smoser> which is much the same as stop, new ephemeral diska ttached, start
<smoser> but i believe the start after resize has slower disks at first
<smoser> and so we hit it there but not on the "warm" reboot disks
<smoser> at least i've not seen it my way
<smoser> slangasek, if you want ssh smoser@40.122.215.16
<smoser> that is prior to resize
<slangasek> smoser: and without an up-to-date /etc/fstab?
<slangasek> /dev/disk/cloud/azure_resource-part1	/mnt	auto	defaults,nofail,comment=cloudconfig	0	2
<smoser> no modifications to that.
<smoser> yeah
<smoser> i saved a bunch of stuff in first-boot
<slangasek> so you'll be manually changing that before resizing?
<smoser> we can reboot ( which will do that)
<smoser> or we can manually do it
<smoser> i'm apt to reboot, and collect those logs and state and such
<smoser> and then resizse
<smoser> so far, launch, add proposed && install cloud-init , collect some info
<slangasek> smoser: if you rely on fstab being updated via reboot, then indeed you could be fighting with the systemd fstab generator
<slangasek> oh
<slangasek> you mean reboot once, to regenerate fstab; then reboot again for the resize?
<smoser> right.
<slangasek> yeah, +1
<smoser> ok. rebooted, ran 'save-old-data second-boot'
<smoser> and
<smoser> /dev/disk/cloud/azure_resource-part1	/mnt	auto	defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig	0	2
<smoser> and now api resize
<slangasek> smoser: right - fstab looks good, /run/systemd/generator/mnt.mount still wrong but that's as expected
<smoser> wrong ?
<slangasek> smoser: /run/systemd/generator/mnt.mount was generated by systemd-fstab-generator before cloud-init updated /etc/fstab, therefore it has the wrong dependencies
<smoser> right.
<smoser> slangasek, ok. its back up, and it reproduced
<smoser> and, slangasek, thank you for your help.
<slangasek> smoser: ok. 'systemctl status mnt.mount' told me 'Warning: mnt.mount changed on disk. Run 'systemctl daemon-reload' to reload unit'
<slangasek> smoser: but 'systemctl show mnt.mount' does show the correct dependencies for the running unit
<smoser> right.
<slangasek> smoser: 'systemctl list-dependencies' makes me somewhat suspicious, mnt.mount isn't shown as depending on cloud-init.service
<smoser> and nothing actually changed in the /etc/fstab, its just that systemd recognized probably a timestamp cahnge in /etc/fstab and says its out of date.
<smoser> slangasek, it does show it
<smoser> at least
<smoser>  systemctl list-dependencies mnt.mount
<smoser> does
<slangasek> yes
<smoser> thats interesting
<slangasek> smoser: and cloud-init.service is where the resize happens.  And cloud-init.service is Type=oneshot.
<smoser> right.
<slangasek> so After=cloud-init.service is basically "start this as soon as you've exec()ed the other one"
<slangasek> systemd.service(5), Type=
<slangasek> e
<slangasek> er
<slangasek> no, sorry
<slangasek> that's completely wrong, I should read more carefully teh description of oneshot ;)
<smoser> hmm.
<smoser> RemainAfterExit is odd though
<smoser> wrt oneshot and requires
<smoser> "RemainAfterExit= is particularly useful for this type of service"
<smoser> s/useful/confusing/
<smoser> what would that even mean.. if the thing remains, you could essentially never be After
<slangasek> smoser: it means that it's listed as 'active', but no changes to the behavior of After
<smoser> that makes more sense.
<slangasek> smoser: '/usr/bin/cloud-init init' wouldn't background for any reason, would it?
<smoser> well... it could start some processes
<smoser> that backgrounded
<smoser> but it wont.
<slangasek> so the top-level cloud-init process is still running while the partitioning/mkfs is happening
<smoser> yeah
<smoser> but it might start a daemon of some sort
<slangasek> smoser: why does 'systemctl status cloud-init' show the job's last status change at 01:49:06, but the last journal output entries at 01:49:07?
<smoser> try monotnoic
<smoser> the clock bounces all over the place on those system.s
<slangasek> heh
<smoser> but i dont know if you can get monotonic on status
<smoser> can you ?
<slangasek> doesn't appear so
<slangasek> but if I compare stamps from mnt.mount and cloud-init.service, mnt.mount is definitely after
<slangasek> smoser: and the timestamp shown in /var/log/cloud-init.log for mkfs.ext4 is 2016-11-17 01:49:09, which is definitely later than what was reported in the journal for either job... so seems less likely to be due to a clock bounce
<smoser> journalctl -o short-monotonic --no-pager --full
<smoser> and you can see
<smoser> [  256.905798] reprovm systemd[1]: Time has been changed
<smoser> so one really wierd thing that happens on azure...
<smoser> we bounce eth0 (ifdown ; ifup)
<smoser> because thats how you publish your hostname (if the user modified it) to the platform
<smoser> i dont think its related... but it means dhcp hooks and possibly time jumps and lots of general wierdness.
<smoser> so i'm just mentioning
<slangasek> smoser: well, hard to be sure without monotonic log output for cloud-init.log itself then
<smoser> well, you can get it..
<smoser> from journalctl
<smoser> as cloud-init writes to journal its stdout
 * slangasek looks
<smoser> so the time obviously differs by when it got seen versus when it got written
<smoser> but, kind of no way to avoid that
<slangasek> smoser: well, journalctl -u cloud-init.service is only showing me a handful of lines, not all the output in /var/log/cloud-init.log
<smoser> hm..
<smoser> just journalctl -o short-monotnoic
<smoser> i see
<smoser> [   23.003468] reprovm systemd[1]: Mounted /mnt.
<slangasek> smoser: and the output shown in journalctl -u cloud-init.service also does not appear in /var/log/cloud-init.log
<smoser> right.
<smoser> because it is set to write debug to log
<smoser> but less verbose to stdout
<smoser> we can cahnge that and try again
<slangasek> smoser: actually, this log did finally show me what I needed
<slangasek> with -o short-monotonic
<slangasek> [   22.998682] reprovm systemd[1]: Started Initial cloud-init job (metadata service crawler).
<slangasek> [   24.812954] reprovm cloud-init[1077]: Failed to exec of '['/sbin/mkfs.ext4', '/dev/sdb1']':
<slangasek> the job was marked 'started' 2 seconds before the mkfs was run
<slangasek> so cloud-init does somehow seem to be backgrounding this
<slangasek> rather, this doesn't look at all like it's running mkfs from the cloud-init.service
<slangasek> but from cloud-config.service
<slangasek> so... wrong dep?
<smoser> well, cloud-init.service is supposed to be running them.
<smoser> is there a way to tell journalctl not to rotate
<smoser> whenver i give it fire hose, i find later that it can't show me stuff saying its rotated
<smoser> you're right, it certainly does seem to be running fromcloud-config, but it should not be.
<slangasek> it's configurable, i don't recall how. you can also touch the file to get an on-disk journal, which we don't do by default, then you don't have to rotate to avoid running out of memory
<slangasek> ok
<smoser> oh.
<slangasek> but I'm guessing you can take it from there to figure out why it's being run from the wrong part of cloud-init :)
<smoser> yeah. thank you.
<cpaelzer> good morning
<pitti> Good morning
<cpaelzer> pitti: h
<cpaelzer> i
<cpaelzer> pitti: FYI on the gnutls thing I mentioned hitting libvirt yesterday
<cpaelzer> pitti: it seems we need to revert that change in gnutls instead of adapting libvirt
<cpaelzer> pitti: I added a gnutls task to the bug I was working on and currently prepping an upload for a ppa to try it out
<cpaelzer> pitti: that was bug 1641615
<ubottu> bug 1641615 in libvirt (Ubuntu) "FTBFS of libvirt 2.1 in zesty" [High,Confirmed] https://launchpad.net/bugs/1641615
<pitti> cpaelzer: that's only gnutls30, right? I thought 28 was still the default (not sure if there's a transition going on)
<cpaelzer> pitti: I must admit the gnutls package versioning is hard at first so IÃm not sure I get it completely yet
<cpaelzer> pitti: it is libgnutls30 with headers in libgnutls28-dev out of source gnutls28
<cpaelzer> pitti: did that make sens to you?
<pitti> not off-hand -- I haven't looked into this at all
<cpaelzer> pitti: the changelog says you did the merge which is why I was highlighting you :-)
<pitti> oh right, this isn't a transition; it's just weird naming
<tuxinator> anybody that may help me with my ubumirror problem? hard to offer a mirror server to the community if the actual mirror scripts don't work as expected :D
<cpaelzer> hi tuxinator I've seen your request like three times but have no experience around that
<cpaelzer> tuxinator: but I really appreciate the support willing to provide a mirror - maybe the right people are not here on the itme you are asking ... ?
<cpaelzer> tuxinator: have you tried asking at https://lists.ubuntu.com/mailman/listinfo/ubuntu-mirrors ?
<cpaelzer> tuxinator: there also seems to be a #ubuntu-mirrors IRC channel on freenode - thou I'm not sure on that one
<cpaelzer> surely there the request won't be drowned in so many other messages
<cpaelzer> tuxinator: there also is mirrors@ubuntu.com - not sure which mail is for the offical mirrors and which for mirror clones of any sort
<caribou> pitti: has systemd unit masking (i.e. linking the unit to /dev/null) a recent introduction in systemd ?
<pitti> caribou: no, that has existed basically forever
<pitti> (for sure "forever" in ubuntu)
<caribou> pitti: ok thanks just wanted to be sure
<infinity> TheMuso: I don't understand why you dropped pulseaudio-equalizer.  Yes, its deps are in universe, but it's perfectly fine for a source in main to produce a binary in universe.
<infinity> TheMuso: Seems like an entirely pointless delta from Debian.
<cjwatson> LocutusOfBorg: please file a bug against the git-build-recipe project about that
<cjwatson> tuxinator: I asked you a question to try to narrow down your problem but you didn't reply
<LocutusOfBorg> cjwatson, probably I was disconnected
<LocutusOfBorg> will look to logs
<cpaelzer> pitti: on bug 1641615 I created a gnutls fix - since you made the merge could you take a look at reviewing and sponsoring that?
<ubottu> bug 1641615 in libvirt (Ubuntu) "gnutls api breakage in 3.5.6" [High,Confirmed] https://launchpad.net/bugs/1641615
<LocutusOfBorg> oh was directed to tuxinator the second sentence
<pitti> cpaelzer: ack, queueing
<cpaelzer> pitti: thanks and if possible keep me up to date so I can follow with the matching libvirt un-fix which is needed now (or push that along if you e.g. push that via bileto - its debdiff is on the bug as well)
<tuxinator> cpaelzer: thanks
<tuxinator> cpaelzer: actually there is no hurry :D
<mdeslaur> pitti: hi! are we going to get postgresql-9.6 in zesty, or should I revert the pgmemcache package back to supporting 9.5?
<mdeslaur> pitti: I'll just revert it for now so I can get my other stuff migrated
<pitti> mdeslaur: I haven't thought much about this; TBH, I think we should avoid major version bumps in the non-LTS releases, as that simplifies maintenance
<pitti> and noone in their right mind would use a 9-month release for a server/production setup anyway
<pitti> mdeslaur: so I was going to leave it at 9.5 until people complain loudly :)
<mdeslaur> pitti: sounds good, thanks!
<bswartz> if I wanted to fix a bug in an ubuntu package file (the .dsc file) where would I go to submit that change?
<pitti> cpaelzer: this is all backported from trunk, right?
<cpaelzer> pitti: yes
<cpaelzer> pitti: the git ids are from gnutls
<pitti> cpaelzer: note, as these symbols are not really from upstream 3.5.6, .symbols must be stricter
<pitti> + gnutls_ocsp_resp_get_responder2@GNUTLS_3_4 3.5.6-4ubuntu2~
<pitti> cpaelzer: ^ like this
<cpaelzer> pitti: true, but there is no 3.5.7 nor a 3.5 release
<pitti> cpaelzer: (fixing here, just OOI)
<pitti> s/OOI/FYI/
<pitti> TLAs are hard!
<pitti> cpaelzer: ack, thanks; uploaded
<pitti> cpaelzer: either reupload libvirt after it built/published everywhere, or bump the build dep to that version
<Odd_Bloke> rbasak: If I want to request a package be added to a packageset, I should send an email to devel-permissions@lists.u.c and then add it to the agenda for an upcoming DMB meeting, right?
<rbasak> Odd_Bloke: correct. It shouldn't be a requirement to add it to the agenda, but no harm if you do - if anything it gives us a place to assign it to someone to deal with if it doesn't get looked at before a meeting.
<kdub> anyone know a trick to get a foreign build-dep to work within a cross-compile chroot? (eg, apt-get build-dep <pkg>:arm64)
<kdub> it always seems to get tangled up trying to install and run foreign packages (eg, python)
<nacc> doko: i think i figured out the freeradius issue; will send to debian and z-p
<nacc> so freeradius has a /var/log/freeradius/wtmp and /var/log/freeradius/utmp file. One of it's autopkgtests just runs `radlast` which looks at that wtmp file. However, by default, that file doesn't see to exist. Normally, what would be responsible for creating that file? A debian postinst step? The freeradius daemon itself?
<nacc> *see -> seem
<nacc> ah i think i see what is supposed to happen -- the 'unix' driver creates the wtmp file on the first accounting with freeradius
<nacc> not sure how that worked in 16.04 w/ the same tests, will go investigate
<nacc> ah ha, in 16.04, postinst created the files
<bswartz> if I wanted to fix a bug in an ubuntu package file (the .dsc file) where would I go to submit that change?
<nacc> bswartz: which package?
<nacc> bswartz: it sort of depends, but the normal way for a user without upload rights to submit, is to open a bug, and put a debdiff in the bug
<bswartz> nacc: xfce4-clipman-plugin
<bswartz> nacc: I did open a bug but I'm not 100% it was in the right place
<nacc> bswartz: bug #?
<bswartz> https://bugs.launchpad.net/ubuntu/+source/xfce4-clipman-plugin/+bug/1641802
<ubottu> Launchpad bug 1641802 in xfce4-clipman-plugin (Ubuntu) "xfce4-clipman-plugin should depend on libqrencode-dev" [Undecided,New]
<nacc> bswartz: have you worked on debian or ubuntu packages before? (just trying to konw where to start to help you out)
<bswartz> nacc: I've hacked on all kinds of things -- modifying .dsc files seems to be particularly easy
<bswartz> I'm not sure what the offcial workflow is for testing a change though
<nacc> bswartz: right, you generally wouldn't chagne the .dsc file directly
<bswartz> In my case I simply couldn't stand my eye's bleeding at how bad the xfce4-clipman plugin in Ubuntu is compared to Fedora, so I decided to fix it for myself
<nacc> bswartz: so here's my suggestion just to get you going:
<nacc> in an appropriate directory: pull-lp-soure -cd xfce4-clipman-plugin
<nacc> bah
<nacc> -d (not -cd)
<nacc> and pull-lp-source
<nacc> and actually, in your case, just pull-lp-source (no -d flag either)
<nacc> so let me start over! :)
<nacc> pull-lp-source xfce4-clipman-plugin
<nacc> cd xfce4-clipman-plugin-<tab>
<nacc> make some changes
<nacc> dch -i
<nacc> describe your changes and put the right version in
<nacc> (as well as targeting the correct release)
<nacc> dpkg-buildpackage -S -nc -d -uc -us
<nacc> cd ..
<nacc> debdiff xfce4-clipman-plugin_<old version>.dsc xfce4-clipman-plugin_<new version>.dsc | less
<nacc> (review the diff)
<nacc> if it looks good, you can do:
<bswartz> pull-lp-source: Warning: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details. Or specify a distribution.
<bswartz> I'm on xenial
<nacc> debdiff xfce4-clipman-plugin_<old version>.dsc xfce4-clipman-plugin_<new version>.dsc | lp-attach <bug #>
<nacc> bswartz: hrm, are you up-to-date?
<bswartz> I thought I was
<nacc> bswartz: i thought they had rolled out hte zesty data to the older distributions
<bswartz> turns out some things did need updating, I'm dist-upgrading now
<nacc> bswartz: ok, that will probably just make xenial aware that zesty exists (so it can recognize the name, etc)
<nacc> doko: jgrimm: freeradius autopkgtests pass now, uploaded and sent the fix to debian
<jgrimm> thanks nacc
<bswartz> nacc: now I am, and it fixed that problem
<nacc> bswartz: cool
<bswartz> nacc: where do I express the build dependencies other than in the .dsc file?
<nacc> bswartz: debian/control in the source pacakge
<bswartz> aha!
<nacc> bswartz: sorry :)
<nacc> bswartz: right so you'd edit that file, updat the changelog and then rebuild the source pacakge (which will generate a new .dsc in the parent directory)
<Unit193> -clipman-plugin is currently in sync with Debian, it'd be faaaaar better to fix it there.
<nacc> bswartz: and to be clear, note that you first need to fix anything in zesty and then follow https://wiki.ubuntu.com/StableReleaseUpdates for getting it into older releases, if applicable
<nacc> Unit193: excellent point, i figured that might be the response in the bug
<bswartz> nacc: why did lp-attach launch lynx?
<bswartz> >_<
<nacc> bswartz: hrm, not sure? maybe it tried to open the bug? if you piped to it, it doesn't do that, at least last i used it
<nacc> bswartz: you can also manually take the debdiff and attach it to the bug
<bswartz> it's trying to do an openid transaction
<nacc> bswartz: oh because you need to be auth'd to use it
<bswartz> oh well I can sort this out with a real web browser later
<nacc> bswartz: sorry, forgot that bit (i'm always auth'd at home)
<bswartz> thanks or you help
<bswartz> Unit193: what is the process for debian? do they use launchpad too?
<Unit193> Generally file a bug and attach a debdiff.
<bswartz> Unit193: file a bug in launchpad? what project?
<nacc> bswartz: you can use `reportbug -B debian`
<nacc> bswartz: no, debian uses bugs.debian.org
<bswartz> k
<hjd> I'm having a strange issue here. My zesty vm seems to be unable to ping or browser .org domains (for instance http://debian.org). Anyone know if this is a known issue or what the cause might be? My host (16.04) has no problems.
<bswartz> hjd: why do you mention .org domains? do .com domains work fine?
<hjd> Yes, various .com domains, .no domains and launchpad.net all work. I first thought it was something with debian.org, but I tried some other random .org domains and they all keep failing for some reason
<bswartz> hjd: I'd recommend testing whether DNS is resolving okay and if not, use a different resolver
<bswartz> hjd: if DNS is resolving for those org domains then you have a routing or firewall problem
<sladen> hjd: type   'host foo.org'  on the commandline and see if that resolves
<hjd> sladen: http://paste.ubuntu.com/23492450/
<hjd> I can ping the ip adresse just fine, but if I try to ping wikipedia.org I only get "Name or service not known"
<sladen> hjd: is there a difference depending on if you 'ping 2620:0:862:ed1a::1' or if you 'ping 91.198.174.192' ?
<bswartz> sladen: you mean ping6
<sladen> bswartz: yes, the aim is to see whether it might be IPv4 vs. IPv6.  The particular choice of tools is optional :)
<hjd> IPv4 works, IPv6 Network is unreachable
<bswartz> hjd: if it turns out your problems are related to IPv6 being prefered over IPv4 then you can easily change the preference with this one-liner:
<bswartz> echo 'precedence ::ffff:0:0/96 100' | sudo tee -a /etc/gai.conf
<hjd> bswartz: Hm... didn't seem to make a difference.
<hjd> Anyway, it's getting late, but thanks for the help all :)
#ubuntu-devel 2016-11-18
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: pitti
<tsimonq2> pitti: You're still patch pilot? :)
<pitti> yes
<tsimonq2> pitti: There's a diff here that should go to yakkety-proposed and start the SRU procedure: bug 1636655
<ubottu> bug 1636655 in ark (Ubuntu) "[SRU] Ark no longer opens rar files in 16.10" [Undecided,Fix released] https://launchpad.net/bugs/1636655
<tsimonq2> juliank thought it was logical enough to upload to Zesty. ;)
<tsimonq2> (not that it isn't)
<tsimonq2> pitti: Any chance you could look at that when you get a minute? :)
<pitti> tsimonq2: sure! will do
<tsimonq2> Thanks a lot pitti. :)
<pitti> tsimonq2: uploaded and accepted into -proposed
<tsimonq2> pitti: Awesome! Thanks a lot. :)
<pitti> no prob!
<tsimonq2> pitti: So then it starts the SRU procedure?
<tsimonq2> I'm not seeing what else needs to happen for that...
<pitti> tsimonq2: yes, now needs to build, and someone must verify it
<tsimonq2> Ok. :)
<tsimonq2> Oh cool, ok, I see you commented.
<tsimonq2> All published successfully!
<juliank> pkern: the bash trusty SRU failed to build on arm64 :/
<juliank> But weirdly not in a changed part ...
<juliank> ../.././builtins/../.././builtins/help.def:130:7: error: format not a string literal and no format arguments [-Werror=format-security]
<juliank> The patch changed lib/readline/misc.c
<juliank> I mean, the warning is certainly right - the line is:
<juliank> printf (ngettext ("Shell commands matching keyword `", "Shell commands matching keywords `", (list->next ? 2 : 1)));
<juliank> But why does this only fail on arm64?
<juliank> and why only now, and not in 1.5?
<juliank> Fix should be easy (unless I missed something):
<juliank> printf ("%s", ngettext ("Shell commands matching keyword `", "Shell commands matching keywords `", (list->next ? 2 : 1)));
<juliank> Worse: It only fails for the statically linked build
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<ScottK> Assuming you all are going to Qt 5.7.1 this cycle, you can leave qscintilla2 FTBFS in proposed for now and give it back when you do that transition.
<infinity> pitti: Oh, did armhf autopkgtest move to aarch64 nodes?
<pitti> infinity: yes, some months ago at last
<infinity> pitti: Can we boot them the same way we boot our buildds? :)
<pitti> infinity: tests run in lxd containers with disabled apparmor; is there anything further to it?
<infinity> pitti: compat_uts_machine=armv7l on the commandline.
<pitti> infinity: I suppose buildds use armhf schroots on arm64?
<infinity> pitti: So they pretend a bit harder to be v7.
<pitti> infinity: that's for the armhf container guest, or does that need to go into the host config?
<infinity> pitti: 'linux32 uname -m' on a buildd returns armv7l, on autopkgtest, it returns armv8l.
<pitti> where "host" == "nova instance" really
<infinity> pitti: Kernel commandline.
<infinity> pitti: So, host.  Obviously.
<pitti> infinity: and that won't break actual arm64 instances?
<infinity> Just changes the 32-bit personality.
<infinity> So, no.
<pitti> infinity: I figure this is for some glibc test or so?
<infinity> Nope.  glibc doesn't care.
<infinity> It's for every other person who thinks that testing for uname -m is smart.
<infinity> And it's not smart.
<infinity> But making our machines pretend to be armv7l kernels is easier than fixing all the stupid code.
<pitti> infinity: ok, I'll write an RT, CCing you
<infinity> (This is the same reason why linux32 uname -m on x86_64 still reports i686, and always will, despite P4 and up being "i786", and i7 possibly being "i886"...
<infinity> )
<infinity> Sadly, I lost the upstream argument about why it should be armv7l forever, but at least we have a simple downstream bodge.
<infinity> pitti: Err, oh.  When I say "host", I mean your VM.
<infinity> pitti: Confused about layering there.
<pitti> infinity: right, and I don't have control over that, it's nova instances
<infinity> pitti: The kvm host host doesn't matter, obviously.
<pitti> hence an RT
<infinity> Ahh.  Curious why yours and the buildds weren't configured the same out of the gate.
<pitti> RT sent
<pitti> infinity: hm, now that I sent it I realized I coudl probalby just add that to their grub config
<infinity> Yes.
<infinity> pitti: I'm not smart enough to map this URL back to where the test was triggered to retrigger it:
<infinity> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20161118_041037_8a45b@/log.gz
<infinity> pitti: But those "lol armv8l, what's that?" failure should go away with that cmdline option.
<pitti> infinity: you can't, it's from a snapcraft github pull request
<infinity> pitti: I can't, or nobody can?
<pitti> you can't
<pitti> mvo, sergiusens, or I CAN
<pitti> "can"
<pitti> (shift failure, although the emphasis wasn't completely wrong either :) )
<infinity> Shiny.  Can you, if you can get your VMs rebooted with the right magic?
<pitti> already at it
<infinity> FWIW, I've also taken up a parallel conversation on "why using uname -m to guess at userspace ABI is wrong", since this is Canonical code.
<infinity> But still a good testcase, given that we know this problem is far-reaching beyond places I can be bothered to fix.
<pitti> ubuntu@lxd-armhf8:~$ linux32 uname -m
<pitti> armv7l
<pitti> ubuntu@lxd-armhf8:~$ uname -m
<pitti> aarch64
<pitti> better
<infinity> \o/
<pitti> ok, now roll this out to the other 7
<pitti> infinity: this is from https://github.com/snapcore/snapcraft/pull/917
<infinity> pitti: Which tells me nothing about autopkgtest results there.  I guess there's still some integration work required? :)
<pitti> infinity: no, just since you asked where this can be retried
 * pitti currently figures that out
<pitti> infinity: ok, I think I got it; it's back to "running" and on http://autopkgtest.ubuntu.com/running#pkg-snapcraft (need to scroll down a bit)
<pitti> sergiusens: ^ FYI
<sergiusens> pitti I am trying to figure out what you are talking about :-)
<pitti> sergiusens: the failure in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20161118_041037_8a45b%40/log.gz
<pitti> sergiusens: I just fixed our armhf test envs to say "armv7l" for uname -m
<pitti> sergiusens: and kicked that test
<sergiusens> pitti oh, thanks; we can always improve our logic here too
<infinity> sergiusens: Right, so I had an email back and forth with Leo about it, but worth repeating here that "trying to determing userspace ABI using uname is wrong".
<infinity> sergiusens: But pitti's above fix will make those tests pass at least. :P
<infinity> sergiusens: That said, while I will stand by the "uname isn't userspace ABI" mantra, it's decidedly harder to determine userspace ABI when you don't know for sure what your host system is.  I'm not sure what these tests are targeting (ie: all distros, just Ubuntu, etc)
<infinity> sergiusens: For dpkg systems, "dpkg --print-architecture" is more likely to be the answer you're looking for.
<pitti> isn't there some gcc command that prints the GNU triplet? would that help?
<infinity> sergiusens: But that starts falling over when you don't know what sort of system your base actually is, then people do crazy things like try to find the linker for /bin/mv and determine ABI from that, etc. :P
<infinity> pitti: Also valid if you have a compiler installed, and you trusty it's targeting the host, yes.
<infinity> Lots of "ifs".
<infinity> s/trusty/trust/ ... That release has ruined me forever.
<sergiusens> infinity we migrated away from dpkg --print-architecture as we will be going to other distros
<sergiusens> infinity we will need to go the crazy route
<infinity> sergiusens: Might be worth tearing apart the problem to first principles and ask why you're trying to determine the userspace ABI.
<bswartz> pitti: does debian seriously not have a proper bug database? they use an email list to track bugs?
<infinity> sergiusens: And how you're using that value.
<infinity> bswartz: It's a proper database, it's just mail-driven.
<infinity> If "proper database" means "can submit via a web form", then no, they don't.
<pitti> bswartz: well, it's "a" bug database; I wouldn't call it "proper", but it's here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=xfce4-clipman-plugin
<pitti> bswartz: yes, all modifications happen over email, browsing is r/o
<bswartz> okay I see it does have a web frontend for viewing bugs
<pitti> the word you are looking for is "arcane" :)
<bswartz> ty
<sergiusens> infinity we want something similar to dpkg-architecture
<pitti> the big advantage is that it's so hard to use that bug reports are usually high quality
<infinity> sergiusens: Right, I'm trying to first principle this to "why are you asking, and what are you doing with it", though.
<infinity> sergiusens: So I can see if maybe there's a not entirely crazy way to achieve your goal on all GNUish systems.
<infinity> sergiusens: Note that this will get more complicated than you think, depending on your goal. ;)
<sergiusens> infinity I know it is; reason for us falling into these issues
<infinity> (ie: if it's about build targets, how do I define that I want to build *for* i386 on my x86_64 system with i386 libs installed?  Is that a supported usecase, or do you demand I do it in a clean i386-only chroot?)
<infinity> sergiusens: And don't be afraid to impose restrictions on the users where fixing the corner cases is Really Really Hard, IMO. :P
<sergiusens> infinity we construct gnu arch triplets, have a primitive form of cross building (specifically for kernels), translate debian arch names to all those and figure out the arch we are on. All this using something as simple as python's platform.machine() which triggers this problem
<sergiusens> and yes 32bit in 64bit userspace has been requested but I am trying not to go down that path
<infinity> sergiusens: So, the 32-on-64 recommendation for now is a 32bit chroot, and linux32 to fake the uname.
<infinity> sergiusens: Which will, indeed, fail for armhf-on-aarch64 anywhere other than our buildds and (as of a few minutes ago) our autopkgtest infra, unless you recognize armv8l.
<infinity> Which suffers from the minor issue that armv8l isn't actually entirely compaible with armv7l (it is in our infra, but only because we made it be).
<sergiusens> infinity if we can support that some how similar to dpkg --print-architecture it would be good. I was mentioning people wanting to build an "amd64" package including "i386" binaries
<pitti> sergiusens, infinity: it failed again, but this time it's not my fault.. I believe: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20161118_150313_8a45b@/log.gz
<infinity> Ahh, people who want to do that are silly.
<sergiusens> infinity I already have this issue on some systems with 64bit kernels and 32bit userspaces so I do want to solve it
<infinity> pitti: Yeahp, that looks much better.  Closes the issue Leo asked me about and I escalated to you. :)
<infinity> sergiusens: So, if a compiler is always there, and you trust it's sane, gcc -dumpmachine is pretty much what you're after for guessing "native" compilation.
<pitti> so, ${CC:-gcc} -dumpmachine ?
<sergiusens> infinity I can make it be there; I'll get a bug task up to fix this; thanks!
<pitti> or actually ${CC:-cc}, because llvm and friends?
<infinity> clang doesn't exist, it's all in your head.
<pitti> rly? my head runs with llvm? /me logs off now and washes it out with a pint of beer then
<infinity> And, unhelpfully, clang on Debian uses different triplets than gcc.
<infinity> Yay.
<sergiusens> pitti good way to start the weekend
<infinity> (xenial-amd64)root@nosferatu:~# gcc -dumpmachine
<infinity> x86_64-linux-gnu
<infinity> (xenial-amd64)root@nosferatu:~# clang -dumpmachine
<infinity> x86_64-pc-linux-gnu
<philroche> rbasak: I see you are a member of Ubuntu Development Team. Would you have any time to review https://code.launchpad.net/~philroche/ubuntu/+source/gce-compute-image-packages/+git/gce-compute-image-packages/+merge/311153 ?
<smoser> slangasek, ping.
<smoser> for bug 1611074
<ubottu> bug 1611074 in cloud-init (Ubuntu) "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Confirmed] https://launchpad.net/bugs/1611074
<smoser> i  plan to upload ro zesty and xenial today with the contents of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/311205
<smoser> to replace the existing -proposed for xenial
<smoser> so i'd like your review of that.
<slangasek> smoser: I don't have time right now to review; if you upload now and get my review in the queue, maybe it saves a step?
<smoser> well, i have a few minor thigns that i still have to fix, so i was hoping youd look at what is there, but thats ok. i understand.
<slangasek> smoser: ok. I'll look ASAP
<slangasek> just don't know yet when P is :)
<smoser> slangasek, i really appreciate your help. thanks.
<teward> pitti: thanks for handling that sync request by the way
<slangasek> smoser: changes to cloudinit/config/cc_mounts.py look good; I'm nervous about the extent of the changes to cloudinit/sources/DataSourceAzure.py if this is meant to be quick turnaround; have not had a chance yet to review those changes
<smoser> slangasek, i think ultimately the new code is more supportable, and we will be testing it explicitly.
<smoser> its *all* related to this path
<nacc> LocutusOfBorg: was there a reason to mark LP: #1624632 as incomplete rather than fix released? given that it's synced now?
<ubottu> Launchpad bug 1624632 in tomcat8 (Ubuntu) "Sync tomcat8 8.0.36-3 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1624632
<hjd> Hi all, could someone please schedule mina2 to be built in zesty? It originally failed to build when it was synced (possibly due to dependencies not synced or built yet?), but it builds successfully now on my local zesty vm.
<jbicha> hjd: done https://launchpad.net/ubuntu/+source/mina2/2.0.16-1/
<hjd> jbicha: :)
<smoser> slangasek, if you could read https://git.launchpad.net/cloud-init/commit/?id=6942c948422205502071f725fde0cc9cba329131
<slangasek> smoser: tmpf=$(mktemp "${TMPDIR:-/tmp/cloud-init-upgrade.XXXXXX}") - I think you want tmpf=$(mktemp "${TMPDIR:-/tmp}/cloud-init-upgrade.XXXXXX") ?
<smoser> yes
<smoser> wow.
<slangasek> smoser: mktemp also has a '-p' option you can use, then you could just do 'mktemp -p cloud-init-upgrade.XXXXXX' for same effect
<smoser> i'm surprised i typed that
<smoser> good job
<smoser> how old is mktemp -p ?
<slangasek> dunno
<slangasek> have just checked and see it in trusty
<smoser> checking precise... just curious really. cause that is much nicer
<slangasek> do you need it to be in precise? ok
<smoser> i dont
<smoser> mostly i'm just curious
<smoser> we'll take your suggestion
<slangasek> smoser: your awk substitution also lacks the =cloud-init.service part of the x.systemd-requires
<slangasek> or x-systemd.requires
<slangasek> whichever is correct ;)
<smoser> -p DIR              use DIR as a prefix; implies -t [deprecated]
<smoser> and -t says deprecated currenlty
<smoser> wierd
<slangasek> heh
<smoser> not sure what to  make of that
<slangasek> oh; -p requires a DIR argument
<slangasek> so maybe none of that is all that useful, or maybe you have to use the '--tmpdir' syntax
<smoser> slangasek, ok. i fixed those two things (good catch)
<smoser> with http://paste.ubuntu.com/23497537/
<smoser> gonna just not use the -p because it confuses me right now :)
<slangasek> smoser: ok, looks good. The last thing, by using a tmpfile in /tmp + cp, you'll lose things like selinux labels AIUI (and possibly even posix perms, if someone has something weird on /etc/fstab).  I believe you'll get a more correct result with just cat $tmpf > /etc/fstab
<slangasek> cp is not atomic anyway so you're not at a disadvantage there by using cat
<smoser> so you think cat ?
<smoser> i wondered on that too
<slangasek> yeah
<smoser> i thought cp might fail better
<smoser> but cat is fine. i will fix.
<smoser> i guess the safest thign to do would be to mktemp /etc/.$0.XXXXXX
<smoser> and then mv
<smoser> but i think its fine
<smoser> oh. but mv might stick perms too
<smoser> so cat i think
<smoser> thank uyou
<slangasek> smoser: n/p
<smoser> i'm gonna upload now.
<smoser> slangasek, it is in queue now.
<LocutusOfBorg> nacc, the reason is "wrong button" it is fix released now, thanks :)
<nacc> LocutusOfBorg: :) np, just wanted to check in!
<slangasek> smoser: none of this new code in DataSourceAzure should ever run if we haven't already detected that we're on azure, correct?  i.e. we're not going to have a 120s timeout waiting for a disk that will never arrive, in other clouds?
<slangasek> smoser: I ask because the previous incarnation of the code had no timeout for disk discovery, it just checked if they were present.  Possibly the new activate logic does this but I haven't traced the code enough to confirm that this is true
<nacc> smoser: slangasek: rbasak: jgrimm: barry: here is an example updated import (well just the last version) of php7.0 with both patches-applied and patches-unapplied available:
<nacc> patches-applied: https://git.launchpad.net/~usd-import-team/ubuntu/+source/php7.0/log/?h=applied/ubuntu/zesty
<nacc> unapplied: https://git.launchpad.net/~usd-import-team/ubuntu/+source/php7.0/log/?h=ubuntu/zesty
<nacc> you can see in the latter, as well, that it merged my upload tagged object into the history
#ubuntu-devel 2016-11-19
<Bluefoxicy> I don't understand why bcache couldn't operate on normal partitions without a superblock
<Bluefoxicy> It'd just need to perform writes to the partition in the same order as the filesystem itself attempted to perform them--which should be easy, since (as far as I understand) it's between the file system driver and the block device
<Bluefoxicy> then, if you yanked the bcache out after a power drop--even after writeback that didn't make it to the system--and mounted without bcache, you'd have exactly what would have happened in a power drop some time between the cache write and the actual power drop
<Bluefoxicy> You'd need a way for bcache to identify that a filesystem has changed since last mount, though, if you did that.  heh.
#ubuntu-devel 2016-11-20
<hlieberman> RAOF: I commented on #1640978 re: SRU for certbot.
<hlieberman> Let me know if there's anything else I can do to help that process along; I'm not nearly as familiar with the Ubuntu processes.
<kiran-r> I would like to get involved in ubuntu development activities. Any direction would be appreciated! :-)
<kiran-r> I am not sure where/how to get started
<krytarik> !contribute | kiran-r
<ubottu> kiran-r: To contribute and help out with Ubuntu, see http://community.ubuntu.com and https://wiki.ubuntu.com/ContributeToUbuntu
<mcgiwer> hello. I was improving from some time the bash.bashrc script and I would like to share it with You to discuss the done by me improvements and possibility that it could eventually get implemented into next versions of Ubuntu
#ubuntu-devel 2017-11-13
<doko> libguestfs doesn't seem to be recognizing gobject anymore
<doko> LocutusOfBorg: ^^^
<jibel> could someone restart update-manager tests triggered by ubuntu-release-upgrader on armhf ?
<Laney> done
<jibel> thx
<doko> jamespage, coreycb: could you have a look at the failing murano autopkg tests on ppc64el and s390x? blocking several python packages
<coreycb> doko: yes and thanks for the poke
<seb128> could somebody from the SRU team look at indicator-printers in the artful queue?
<seb128> it fixes one of the most reported issue on e.u.c in 17.10 and is waiting in the queue since 10-23
<seb128> if you would also be useful to understand why we don't manage to get important and trivial fixes like that in in a timelined fashion if somebody from the SRU team has an explanation, we got a stack of other updates more complex uploaded later and accepted earlier
<seb128> bdmurray, ^ hey, maybe you can have a look/have an idea why we have a such delay and what we could change to avoid that in the futur?
<bigon> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1713457 << cyphermox xnox: hello, an idea about this bug?
<ubottu> Launchpad bug 1713457 in network-manager (Ubuntu) "DNS search domain not removed from resolv.conf on disconnect" [Undecided,Confirmed]
<bigon> I'm seeing that on a coleague laptop and it's breaking his VPN (vpnc) dns resolution
<doko> coreycb: the other one blocking bzr is the python-testtools merge/sync
<coreycb> doko: ok i'll take a look at that too
<doko> ta
<xnox> tsimonq2, is there a transition tracker for v5 -> '' transition of e.g. cairomm? and the rest too i guess?
<xnox> as currently -dev packages are not installable.... https://launchpadlibrarian.net/345610614/buildlog_ubuntu-bionic-amd64.glom_1.30.4-0ubuntu11_BUILDING.txt.gz
<tsimonq2> xnox: No but there probably should be
<xnox> tsimonq2, i'll try to make one for cairomm
<xnox> tsimonq2, did you drop v5 suffixes from other packages too, that I should track?
<xnox> tsimonq2, http://paste.ubuntu.com/25953982/
<tsimonq2> xnox: Not remembering which off the top of my head but yes
<xnox> this is similar to the libjsoncpp tracker
<tsimonq2> I've had few Bionic uploads in November, shouldn't be hard to find ;)
<tsimonq2> xnox: Sure
<xnox> tsimonq2, i'll wait for the output generated for this one; rebuild these; and then look at what proposed migration tells me ;-)
<tsimonq2> xnox: My personal goal is to see which packages I can transition off of v5 before 18.04 so we don't have to keep transitional packages for the next 2 years...
<tsimonq2> (meaning, before release)
<xnox> tsimonq2, if you are migrating off v5 package names, it is wrong to keep providing them.
<xnox> tsimonq2, plus it is not installable as you intend them to be.....
<xnox> see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<xnox> which lists a bunch of things that are not installable, which i will rebuild for.
<tsimonq2> xnox: Oh, right. The alternative is to not Provide and adjust all rdeps?
<xnox> tsimonq2, just replaces+conflicts is what you want. but not provides.
<tsimonq2> xnox: Alright. Thanks
<xnox> tsimonq2, also the shlibs looks wrong, as you should probably generate >= 1.12.2-1ubuntu1
<xnox> tsimonq2, such that old v5-less does satisfy the new depends.
<xnox> tsimonq2, such that old v5-less does NOT satisfy the new depends.
<tsimonq2> xnox: ack, is it correctable at this point?
<xnox> tsimonq2, yes, better do that before we rebuild all the things as per the transition tracker =)
<tsimonq2> xnox: Sure, I won't be home for ~ 8 hours and will need a sponsor anyways, feel free to JFDI.
<xnox> ok
<xnox> juliank, surely if the passed argument contains '_' it means that it is a file, not a valid package name, and *only* local filesystem resolution should work. As if it is a './' path.
<juliank> xnox: hmm, I'm not sure we'd want to go down that route and assume that _ can't be in a package name (even though that's valid for debs in theory)
<xnox> juliank, debian policy prohibits _ in the package names...
<juliank> It does
<xnox> juliank, hence .changes .deb _files_ use it.
<juliank> But (1) It also forbids upper case characters, and packages are using it (2) we might want other backends allowing it
<xnox> juliank, hence *.deb which expands to foo_1_all.deb is a ./foo_1_all.deb, and never a metadata pkg specification.
<xnox> juliank, what is a backend in this context?
<juliank> Like rpm support
<juliank> But well, "valid package name" could be made specific
<xnox> juliank, rpm will not end in .deb thus ends in .deb and is _. I do hope you do not allow extensionless files to be installed....
<juliank> I don't know, I did not write it :)
<xnox> juliank, rpm will not end in .deb thus ends in .deb and has _. I do hope you do not allow extensionless files to be installed....
<xnox> lolz
<juliank> But we probably should
<juliank> Like .ddeb
<juliank> Or .udeb
<juliank> Or future extensions :)
<xnox> juliank, apt should not allow installing .udeb
 * xnox is strict
 * xnox wonders if we actually use apt to build d-i
<cjwatson> xnox: we do, with a whole pile of options
<cjwatson> build/util/get-packages
<cjwatson> xnox: though only to download udebs, not to install them
<cjwatson> I'm not aware of any situation where we use apt to install udebs, nor any where it would be sensible to do so
<xnox> ack. thanks!
 * xnox is anti easy access to self-harm
<jbicha> xnox: I don't think we want to do that cairomm transition unless Debian also does it, see https://irclogs.ubuntu.com/2017/11/11/%23ubuntu-devel.html
<jbicha> it's one thing to change the library name to drop an Ubuntu delta, it's another thing to *introduce* a delta
<xnox> jbicha, opened block-proposed bug about it https://bugs.launchpad.net/ubuntu/+source/cairomm/+bug/1731929
<ubottu> Launchpad bug 1731929 in cairomm (Ubuntu) "cairomm drops v5, whilst debian didn't" [Undecided,New]
<jbicha> the same with all of the other ones that Simon started without talking to Debian, I see at least 'afflib'
<jbicha> adplug, assimp, boolstuff
<jbicha> and bulletml
<jbicha> xnox: so I'm intending to try to find an Archive Admin later to delete those uncoordinated transitions from -proposed
<xnox> jbicha, i guess https://bugs.launchpad.net/ubuntu/+source/cairomm/+bug/1731929 should be retitled RM and subscribe ubuntu-archive?
<ubottu> Launchpad bug 1731929 in cairomm (Ubuntu) "cairomm drops v5, whilst debian didn't" [Undecided,New]
<xnox> apw, are you delete happy? rm cairomm from bionic-proposed because it is toast
<tsimonq2> jbicha: I'll file Debian bugs for all those packages then
<tsimonq2> I already did a QA upload for one of the packages
<tsimonq2> jbicha: Some of those packages have already migrated it seems, I'll give Debian those deltas too
<michael-vb> Hello all.  I have a question regarding X.Org and Wayland sessions.  I know that when the NVIDIA driver is in use an X.Org session is forced.  Can anyone tell me what the mechanism is?  I work on the VirtualBox guest drivers and it would make sense for us too.
<coreycb> doko: jamespage: i've uploaded a new murano to bionic and submitted the patch upstream to https://review.openstack.org/#/c/519369/
<bdmurray> seb128: There isn't a way to evaluate whether an SRU item is "important and trivial" just by looking at the queue. If one is important please ping an SRU team member.
<jibel> bdmurray, ubuntu-release-upgrader migrated and upgrades to bionic are green. I'll add more upgrade scenarios this week and next.
<bdmurray> jibel: Great thanks! I appreciate it.
<seb128> bdmurray, right, still shouldn't the queue mostly be processed by oldest items first? do you have any clue why that one isn't getting reviewed?
<bdmurray> seb128: Yes. No, not really - maybe because its a sync and those are harder to review?
<seb128> bdmurray, that's one thing I was wondering about ... you didn't do a review shift and skept over it for some reason?
<seb128> I wonder if Lukas or others did
<bdmurray> seb128: I have not looked at the particular upload but could now.
<seb128> bdmurray, that would be nice, thanks
<seb128> bdmurray, sorry for the stack of questions, I'm just trying to figure out what isn't working so we can maybe fix it, asking individuals to nag the SRU team members works but is a workaround at best
<bdmurray> seb128: If its really an "important" SRU pinging is still a good idea.
<seb128> bdmurray, right, well that one is not that important in sense it's not a security or data lost or can't-use-your-desktop type of bug, just a frequently reported crash which means apport noise for users etc
<seb128> bdmurray, thanks for looking!
<bdmurray> andyrock: The test case in bug 1703046 is rather weak. It'd be fine to say this is the errors bucket at errors.u.c and watch for the new version not appearing in it.
<ubottu> bug 1703046 in indicator-printers (Ubuntu) "indicator-printers-service crashed with SIGSEGV in __GI_____strtol_l_internal()" [Medium,In progress] https://launchpad.net/bugs/1703046
<bdmurray> seb128: Is it fixed in Bionic?
<andyrock> bdmurray: do you want me to update the bug description
<andyrock> for what I know that's not been merged in trunk
<bdmurray> Is there an outstanding merge proposal?
<andyrock> https://code.launchpad.net/~azzar1/indicator-printers/fix-1703046/+merge/332554
<andyrock> bdmurray: ^^^
<bdmurray> Hmm, I'd feel better if that were closer to being fixed in bionic.
<andyrock> it just need to get merged
<andyrock> seb128: ^^^
<coreycb> doko: jamespage: i've uploaded python-testtools 2.3.0 to bionic. that should unblock bzr.
<seb128> bdmurray, andyrock, k, we can merge/land that tomorrow, it was uploaded before bionic was open so usually it would have been a pocket copy but since review was delayed we need an upload
<bdmurray> seb128: Ah, given the timing I'll accept it provided the description is sorted out.
<tjaalton> should artful be able to resize partitions on an nvme ssd?
<ricotz> tjaalton, sounds like a weird question ;)
<tjaalton> ricotz: why?
<tjaalton> I've installed 16.04 on it, but can't install 17.10 next to it
<ricotz> are those things actually related?
<tjaalton> seem to be
<ricotz> I mean hardware <-> filesystem/partitions
<tjaalton> never had issues with "normal" ssd's
<tjaalton> sata disks
<ricotz> I have one here, how do you test this?
<ricotz> without actually doing it ;)
<tjaalton> boot the installer, see if it offers you an option to install another version by resizing partitions/filesystems
<tjaalton> the disk needs to be fully allocated of course
<ricotz> how is the current layout of yours?
<tjaalton> first partition is for EFI, then is the os, and rest for swap
<ricotz> I could imagine a used swap partition prevent it
<tjaalton> ok, I'll try after deleting it
<ricotz> e.g. on my running system, gparted seems to be happy and provides the required options here
<tjaalton> what options?
<tjaalton> on the installer?
<ricotz> not the installer, just confirmed that this is not prevented on purpose
<tjaalton> after deleting the swap-partition it allows install on it (of course) but not resizing the other partition
<ricotz> hmm, I see
<jbicha> slangasek: could you look into removing cairomm, adplug, afflib, assimp, and bulletml from bionic-proposed? we can wait for Debian to do those transitions
<slangasek> tsimonq2: ^^ why are you changing library binary package names to incompatibly *revert* a rename that was done in Debian?
<slangasek> (also grrr, who accepted these through NEW)
<powersj> cyphermox: seems with bionic ISOs I'm getting asked about keyboad-configuration again as it is marked high, is this expected?
<slangasek> jbicha: assimp and bulletml appear to have migrated; do you want to upload a revert or get tsimonq2 to do so?
<jbicha> thanks, he can fix those 2
<tsimonq2> slangasek: Right, apologies. I'll upload reverted packages when I get home in <= 2.5 hours
<slangasek> tsimonq2: thanks
<slangasek> tsimonq2: have you and jbicha already discussed this, and do you understand why these changes were wrong?
<tsimonq2> slangasek: We briefly discussed this, and yes, I now understand why this is wrong to do in Ubuntu and not Debian.
<tsimonq2> slangasek: One thing though, I did spot packages which the revert was only done in Ubuntu and Debian doesn't have v5 packages at all. In that case, is it alright to do the revert?
<tsimonq2> slangasek: (and if in that case it *isn't* OK, why not?)
<slangasek> tsimonq2: if the current state is that Ubuntu has a different name for the binary package (with v5) than Debian does, and the Debian history shows the bug was closed as "no transition required", it's appropriate to revert in Ubuntu and add a transitional Provides: as a delta, yes
<seb128> bdmurray, thanks
<tsimonq2> slangasek: Alright, thanks.
<seb128> andyrock, can you please update the indicator-printers SRU description according to the feedback from Brian?
<tjaalton> ricotz: gparted does let me resize the partition, just not the installer
<andyrock> seb128: tomorrow if that s fine
<ricotz> tjaalton, maybe the installer isn't comfortable with it with a specific partition layout, but I assume yours is GPT
<tjaalton> should be
<ricotz> of course this is also tied to the filesystem afaik some can't be shrinked
<tjaalton> ext4
<cyphermox> powersj: not that I know of, but what are you getting prompted for exactly? console-setup hasn't changed recently
<powersj> cyphermox: https://imgur.com/a/WAP9J
<powersj> sorry for the screenshots, but easiest way :)
<cyphermox> powersj: you're not getting that on artful?
<cyphermox> I'll go play with preseeding keyboard-configuration on ppc64el
<powersj> cyphermox: correct, not on artful
<powersj> happening on all arch we test too
<cyphermox> that's special
<rlink> Anyone on ubuntu-sponsors that can look at an SRU for network-manager?
<rlink> (For Xenial)
<doko> great, pythonqt bus error on armhf
<madigens> sladen: i just landed a job at dalton maag (barring any problems). maybe i can help move things from the inside :)
<LocutusOfBorg> doko, libguestfs is a debhelper regression
<LocutusOfBorg> the file is there
 * LocutusOfBorg debugs and opens a debian RC bug probably
<sladen> madigens: oh that would be quite spiffing, yes!
<madigens> i'm terrified about the process of switching countries though and have no idea how to find a place to stay while not already living on the isles, but maybe i'll manage.
<sladen> madigens: I guess offering to meet you on the Heidelberg-Frankfurt-Giessen axis isn't much use then?
<madigens> depends on when! gieÃen would be terrific though. frankfurt works, too.
 * sladen has a habit of being in Giessen on 24.  $certain_month,  and occasionally other times too
<sladen> but this week should be in Frankfurt on ~Friday
<madigens> which month
<madigens> i just might be in ffm on friday for dancing purposes
<sladen> well, lets aim for Thursday/Friday
<sladen> somewhere between G. and Ffm
<madigens> i'm free thursday starting at 7pm, friday after 4pm
<madigens> and live right between G and FFM
<madigens> you have my email address, tell me spcifics when you know them
<sladen> I tend to stay in Bad Vilbel
<madigens> mh, that should work out
<madigens> i'm stationed in bad nauheim
<sladen> which reminds me, I should pester the Ebay seller in Butzbach who didn't they'd lost the item won for e1
<sladen> decided
<madigens> haha :)
<rlink> Anyone on ubuntu-sponsors available to look over an SRU for Xenial's network-manager?
<tsimonq2> rlink: Have you subscribed ~ubuntu-sponsors to the bug report?
<rlink> tsimonq2: Yes.  Did so on Thursday of last week.
<Unit193> tsimonq2: Since packagesets aren't getting updated, want to sponsor a real simple one?  Just upstream bump and S-V.
<tsimonq2> Unit193: Throw me a dsc?
<tsimonq2> Unit193: Or link, rather?
<Unit193> It's in ~/ :---D
<Unit193> http://paste.openstack.org/show/E4BEhNdTBoGvr80WRauF - https://sigma.unit193.net/source/xfce4-statusnotifier-plugin_0.2.1-0ubuntu1.dsc
<tsimonq2> Unit193: Enjoy.
<Unit193> Right then, thanks.
<tsimonq2> (it's very fast through sbuild)
<Unit193> Builds quickly either way.
<tsimonq2> Well, that was sort of my point.
<Unit193> Urgh, I need to clean /source/
#ubuntu-devel 2017-11-14
<pde> Is it common for there to be malware in the Ubuntu app store? I just accidentally installed this thing: https://askubuntu.com/questions/970219/123-sogou-com-trojan-horse-in-ukui-screensaver
<pde> (as a result of trying to change the time-to-screensaver-onset in ubuntu 17.10)
<infinity> LocutusOfBorg: How much would I have to pay you to stop merging debhelper? :P
<rbasak> pde: AFAICT, that's not malware: https://en.wikipedia.org/wiki/Sogou
<rbasak> It appears to be the default (and legitimate) search engine for Kylin.
<rbasak> It does feel like a bug that ukui-screensaver depends on ubuntukylin-default-settings.
<rbasak> Though I don't know the detail.
<pde> hmmm, interesting. I noticed it because it changed Firefox's homepage to Sogou
<rbasak> I would file a bug against ukui-screensaver to argue that it isn't reasonable for it to depend on arbitrary additional unrelated settings.
<rbasak> Though that package is perhaps Kylin-"specific" so it may be low priority for them.
<rbasak> Perhaps in that case it's a separate bug that the software centre surfaces that pckage.
<LocutusOfBorg> infinity, did I make any mistake? anyhow, if you want, please steal it anytime you like :)
<LocutusOfBorg> infinity, I spotted an RC bug in debhelper, I had to followup with a new upload :(
<LocutusOfBorg> and now the delta is reducing finally
<ricotz> jbicha, hi, fyi, firefox 58 beta builds will include the EmojiOneMozilla.ttf as shipped by upstream
<niedbalski> RAOF hello there, if you have some cycles, do you mind to review LP: #1657256? (verification done).
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.5 (Ubuntu) "Percona crashes when doing a a 'larger' update" [Medium,Confirmed] https://launchpad.net/bugs/1657256
<flexiondotorg> I'm unable to update the ubuntu-mate-meta package.
<flexiondotorg> I'm running Ubuntu MATE 18.04 daily.
<flexiondotorg> Here is the traceback from germinate - http://paste.ubuntu.com/25960796/
<flexiondotorg> Ugh. Seen my mistake.
<elopio> pitti: Hello! I'm playing with a script you initially wrote: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/retry-autopkgtest-regressions
<elopio> is there any reason to use the cookie in there instead of oauth?
<pitti> elopio: it's massively simpler
<pitti> if you can work out how to use oauth with it, feel free of course :)
<elopio> pitti: well, I tried, and failed. But it might be I'm doing something stupid, of course :) I will try a little more.
<elopio> thanks! And how are you pitti?
<pitti> elopio: IIRC I did look into using oauth back then, and gave up after a short while with "argh too complicated", or something such :)
<pitti> elopio: quite fine, thanks! debugging chromium crashes in docker containers (that ruins our tests), so same old :-P
<pitti> how about yourself?
<elopio> pitti: sounds fun. I'm ok, fighting autopkgtests (same old, too :)
<cpaelzer> dannf: on 1710019 we are down to "all good who does the upload (and when)"
<cpaelzer> dannf: if you are around already let me know
<dannf> cpaelzer: i am. i can do the upload if you like
<cpaelzer> ok
<cpaelzer> dannf: do so I'll pull from there and make sure it is correctly in git as well
<dannf> cpaelzer: ack, thx!
<cpaelzer> hmm, can I pull-lp-source (or similar) from release-unapproved?
<cpaelzer> wget from LP page links feels wrong
<nacc> cpaelzer: `git ubuntu queue` can do it, iirc
<nacc> cpaelzer: otherwise, i believe there are sru tools
<cpaelzer> uh we have a queue command
<cpaelzer> checking that :-)
<nacc> cpaelzer: not displayed in top-level help, iirc, but in the manpage
<rbasak> cpaelzer: from an up-to-date repo, "git ubuntu queue sync" should do it.
<cpaelzer> nacc: rbasak: yeah working fine for me
<rlink> Still looking for someone on ubuntu-sponsors to look over an SRU for Xenial's network-manager, please.
<rlink> Or is there at least an expected turnaround time between when ~ubuntu-sponsors gets subscribed to the SRU-ed bug and when someone takes a look at it?
<juliank> rlink: According to the upstream bug, the fix there is incomplete. Is your fix different?
<rlink> juliank: It is the exact same patch.  I believe the final comment in the upstream bug diesn't account for NetworkManager itself having to be restarted for the new Notify mechanism to be usable.  Hence why they're still seeing Event fallback.
<rlink> Also note that those log messages in the final comment in the upstream bug are from a custom wrapper the submitter is running around the actual nm-dhcp-helper.
<rlink> I've deployed and tested the exact same patch/fix here and have seen nothing but successful renew Notifies.
<juliank> rlink: I think the whole SRU stuff from the comment needs to be in the description, at least that's what the doc says. It's a bit bad that it's not really testable IMO, but if you can reliably reproduce it and verify it that way, that seems OK to me.
<rlink> I can certainly move the SRU block into the description.
<rlink> juliank: I've moved the SRU text into the description and addressed your concern in the Other Info section
<juliank> rlink: OK, the patch does not seem to break anything, so good to go
<juliank> We're kind of lucky that I actually have a xenial VM
<rlink> juliank:  Cool.  What's next?
<juliank> rlink: Waiting for approval to -proposed, after which there will be a comment on the bug asking you to verify it. Once verified and 7 days have passed, you just have to wait for it to be released to -updates :)
<rlink> Cool.  Thank you!
<xnox> cpaelzer, i'm trying to change qemu code to compile roms the way debian wants them to be compiled....
<xnox> cpaelzer, where does one supposed to get roms/SLOF from?
<xnox> cpaelzer, nevermind found it.
#ubuntu-devel 2017-11-15
<RAOF> niedbalski: Do you have any insight into the percona-xtradb-cluster-5.6 autopkgtest failure with diaspora-installer? I'm not confident that it's a false-positive.
<Anticom> Hi all. Is there any reason, there are no packages for docker-compose, docker-machine, docker-machine-driver-kvm, kubectl and minikube ?
<Anticom> (I'm on Ubuntu 16.04)
<mwhudson> Anticom: there is a package for docker-compose i think?
<Anticom> mwhudson: oh, my bad, there is indeed
<mwhudson> in general dockerish things move fast enough that distributing them via the archive is a pain though
<Anticom> mwhudson: so it *should* be up to the project maintainers to provide a CI/CD to a launchpad ppa etc. ?
<sarnold> Anticom: hopefully useful, https://conjure-up.io/ https://jujucharms.com/canonical-kubernetes/ and https://www.ubuntu.com/kubernetes
<stokachu> Anticom: fwiw kubectl is packaged as a snap
<Anticom> stokachu: minikube aswell, but in like v0.8.0 where v0.32.0 or something along those lines is the current one
<NewGnuGuy> When a new version of a package (in this case libsdl2) is migrated from Debian unstable to testing, will that package automatically get added the latest Ubuntu stable release (in this case Artful) or does something have to be done manually?
<NewGnuGuy> https://launchpad.net/ubuntu/+source/libsdl2 Version 2.0.7 is listed for Bionic, but 2.0.6 is still listed for Artful. 2.0.6 suffers from these crash-inducing bugs: https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1722060 https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1727849
<ubottu> Launchpad bug 1722060 in widelands (Ubuntu) "Some programs (e.g. Widelands) crash when playing sounds with sdl2 2.0.6" [Undecided,Confirmed]
<ubottu> Launchpad bug 1727849 in libsdl2 (Ubuntu) "SDL audio does not work in artful" [Undecided,New]
<cpaelzer> NewGnuGuy: hi, once a Ubuntu release is released we no more pick up updates/changes by default
<Unit193> (Answered in #xubuntu)
<cpaelzer> NewGnuGuy: instead it then goes into maintenance which more or less means fixes yes, features no (as they often introduce new issues and could regress)
<cpaelzer> oh I see Unit193
<cpaelzer> then TL;DR https://wiki.ubuntu.com/StableReleaseUpdates
<cpaelzer> but already answered there
<Unit193> Would be nicer to have the factoid say more, but ah well.
<mwhudson> apw: is https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1692912 really in progress?
<ubottu> Launchpad bug 1692912 in docker.io (Ubuntu) "unable to run containers with /sys/cgroup/unified mounted" [Critical,In progress]
<apw> mwhudson: pretty sure that was an artful kernel systemd inert
<apw> interaction. that got resolved long ago
<mwhudson> apw: i'll close it then?
<apw> yeah please, sure that was fixed in the kernel config in the end
<mwhudson> most docker.io bugs are upgrade failures that i have no idea how to reproduce
<mwhudson> might as well try to stay on top of the others :)
<apw> good enough :)
<xnox> Laney, i'm not happy =( the autopkgtest qemu runner does not work on s390x, as it is waiting for a console that is not available. I think i actually want to use ssh runner, but with the local qemu vm that was created. Has there been any work done to achieve that? e.g. have like a uvt-kvm running?
<xnox> i think uvt-kvm + ssh runner might be a better match.
<rbasak> I pushed cpaelzer's fix for s390x to uvtool upstream earlier FWIW.
<rbasak> Not done an upload to Bionic yet.
<Laney> xnox: No, you could probably write an SSH setup script for it though
<xnox> Laney, just for myself; or do you think upstreaming / supporting such an option could be useful, in general?
<xnox> rbasak, ack, thanks.
<Laney> Fine for upstream I think, although I'm not upstream so I can't say for sure
<Laney> probably file a bug at Debian to discuss it
<cpaelzer> xnox: I think I once fixed it to work on the cloudimg - was some weird mapping of consoles to ttyS
<cpaelzer> xnox: but it never worked reliably
<cpaelzer> which is why I haven't propsed anything
<cpaelzer> All I remember is a morning of ugly details with pitti back then which was just enough to get my test working
<cpaelzer> an ssh-runner certainly sounds better if that is doable
<cpaelzer> and a more generic solution
<juliank> rbalint: hey, congrats. welcome to the core dev world :)
<juliank> rbalint: that reminds me that I'd like to hear your thoughts about my latest two comments in bug 1690980 (it's your patch to apt, after all). I'll be playing with what I proposed shortly, but if the broken state is already less broken than the current state, I guess we could mark the SRU as verified and track the "regression" elsewhere.
<ubottu> bug 1690980 in OEM Priority Project xenial "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
<rbalint> juliank: thanks!
<juliank> (The goal of that bug was to give u-u run by apt-daily more time to complete on shutdown, but the process only stops the top-level shell script. systemd considers the unit exited after that apparently, but the processes are still running. I'm not sure if it waits for them on shutdown or not - if it does, that's OK enough, if not, then it's essentially the same state as now)
<juliank> I guess we should probably fix it anyway. I'm excited to see if the shell wait trap thing works as expected :)
<rbalint> juliank: i just looked at your comment the other day and wanted to pick up the line
<rbalint> juliank: u-u-s is also expected to send TERM to u-u which will terminate it gracefully
<rbalint> juliank: this needs an sru which i wanted to prepare for a long time but did not get to it and also i was happy with the extended testing in artful
<rbalint> juliank: let me add this to the bug, too
<juliank> The thing is that systemctl stop apt-daily-upgrade.service currently just terminates the apt-daily script, which is suboptimal. It should also terminate unattended-upgrades. But, yes, I think there's a missing dependency on an u-u that actually supports SIGTERM for graceful canceling
<juliank> Though, the two are independent. Without a u-u that properly handles SIGTERM, it's still better than now.
<juliank> (where systemd just kills the entire cgroup)
<juliank> s/kills/terms/
<juliank> rbalint: I guess optimally, we'd now just tell the script to send SIGUSR1 to unattended-upgrade, then you don't need the SIGTERM change for u-u SRUed for the change to be actually useful
<rbalint> juliank: i agree that apt-daily-upgrade.service should TERM children but this step missing will not cause problems as long as u-u.service sends the proper signal to u-u when shutting down
<juliank> rbalint: I guess it depends on whether systemd waits for that to be terminated or not
<rbalint> juliank: it my tests it did
<juliank> Then I guess we should mark the bug as verified (though weird interaction with an u-u SRU, I guess), and let the apt SRUs enter, and once there are u-u SRUs, it works better.
 * juliank thinks we kind of need verified-done-<distro>-<package> :D
<juliank> s/verified/verification/
<rbalint> juliank: yes thanks for the apt changes, they are good
 * juliank has to leave (or go /away) now, but will be /back shortly (and has a bouncer anyway) :)
<Odd_Bloke> rbalint: Congrats!
<rbalint> Odd_Bloke: thanks! :-)
<juliank> Hmm has anyone considered apt running dpkg in its own systemd scope
<juliank> That sounds like it would be fun :)
<juliank> Like a dpkg.scope where dpkg and maintscrpts run in. This gets them out of any service unit whatsoever.
<jbicha> ricotz: thanks for the Firefox 58 Beta emoji fix, are you going to apply the same fix to Thunderbird?
<ricotz> jbicha, probably with the first 58 beta
<jbicha> so we'd have to wait for Thunderbird 59 for that to land in regular Ubuntu?
<mwhudson> rbalint: congrats!
<ricotz> jbicha, it could be added with 52.5.0 though
<jbicha> ricotz: are you working on the TB 52.5 update? or do I really just need to ping Chris?
<sarnold> rbalint: congratulations on core-dev :)
<ricotz> jbicha, I will likely take a look when there are tags available, but reminding chris about it won't hurt
<Unit193> ricotz: Are you still working on or interested in esr?
<ricotz> Unit193, I am maintaining them in a PPA
<Unit193> That's a "yes", then thanks!
<ricotz> Unit193, https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/
<Unit193> ricotz: I was just unsure if you became disinterested with all the 'snap' talk afterwards, good to know you haven't.
<rbalint> mwhudson, sarnold thank you! :-)
<jbicha> doko: could you look into this ftbfs: https://launchpad.net/ubuntu/+source/vcdimager/0.7.24+dfsg-0.3 ?
<mwhudson> ",  | libc-dev,"
<mwhudson> nice
<juliank> mwhudson: eww, where did you find this awful thing?
<juliank> oh, in the ubild log
<nacc> ha
<juliank> I mean, it's simply libc6-dev used to provide libc-dev, but does not
<nacc> no, it's a buggy change
<juliank> hence the first part in LIBCDEV=$(shell dpkg-awk 'Provides:libc-dev' -- Package | sed -ne 's/^Package:[[:space:]]*//p' | head -1) | libc-dev is empty
<nacc> http://paste.ubuntu.com/25970523/
<nacc> shouldn't that be in the ) ?
<nacc> or it's tryign to force a string out? then it should be i quotes, no?
<juliank> nacc: That line did not change, it used to become libc6-dev | libc-dev
<nacc> juliank: oh i see
<juliank> but libc6-dev is not providing libc-dev anymore, hence only the | libc-dev remains
<nacc> right
<nacc> it seems like an inherently fragile thing
<juliank> nacc: though actually libc6-dev seems to privde libc-dev, but I guess it needs to be installed and isn't. In any case detecting it like this is wrong.
<juliank> On my debian this would return libc6-dev-sparc64-cross | libc-dev
<juliank> that's not right
<juliank> :D
<juliank> Should just hardcode libc6-dev there
<juliank> (obviously not applicable to debian due to kfreebsd and stuff, but a right solution probably is more complicated)
<nacc> juliank: yeah, it feels weird to be build-time dependent on runtime state
<juliank> nacc: the problematic thing is just Debian kfreebsd and stuff with libc0.1-dev and whatever
<juliank> nacc: but one fun fact to realize: The dpkg-awk match matches a substring :D
<nacc> heh
<juliank> Could go with grep-aptavail -FProvides libc-dev  --and -FBuild-Essential yes -nsPackage | head -1
<juliank> but it's also not really multi-arch friendly
<juliank> Could add an and --architecture $(shell dpkg-architecture ...) in there
<juliank> Or use LANG=C apt-cache showpkg libc-dev | and grep the first line after Reverse Provides.
<juliank> My awk is not strong enough for that
<juliank> That does the trick: apt-cache showpkg libc-dev | sed -n '/^Reverse Provides/ { n; p; }' | cut -f1 -d\
<juliank> You might want to arch qualify libc-dev with whatever you are building for, though, for cross-compilation bonus points
#ubuntu-devel 2017-11-16
<teward> LocutusOfBorg: i think you broke nginx builds for the forseeable future with the latest upload in Debian from the 25th-27thish which was autosynced to Bionic
<teward> because luajit isn't detected in amd64, armhf, or i386 for Bionic (relevant excerpt from build logs is this: http://paste.ubuntu.com/25972405/)
<teward> confirmed: it's broken.
<Unit193> \o/
<teward> and now I have to make a decision for nginx-extras: drop Lua module, or switch to the much less fun full Lua libraries instead of libluajit, and further diverge from Debian.  Again.
<rbasak> Does nginx-extras have to be in main?
<teward> rbasak: it's not.
<teward> it's in Universe.
<teward> but an FTBFS on nginx-extras means nginx-core never lands
<teward> because the source package has a component FTBFS
<rbasak> I see
<teward> refer to #u-release
<teward> because i have a small minirant there
<teward> rbasak: and I just confirmed this happens with 1.12.x that's in bionic now, if someone triggered a rebuild it'd explode in all our faces
<teward> and the only thing that is failing is luajit currently, and only on amd64, armhf, and i386
<teward> works *fine* on arm64 and ppc64el
<teward> but not the three big ones.
<teward> confirmed in local schroots and PPA builds
<rbasak> Do you know what luajit upload caused the regression?
<teward> rbasak: debian autosync
<rbasak> OK, but what Debian upload caused the regression?
<tsimonq2> rbasak: I'm asking the same questions in #u-r ;)
<teward> which is why we should specifically pick one channel or the other
<doko> jbicha: who synced that? ;p
<jamespage> coreycb: ok content of PPA published to bionic-proposed; os-service-types is in the NEW queue.
<jamespage> coreycb: the issue I'm hitting in neutron is todo with eventlet - https://github.com/eventlet/eventlet/issues/147
<m_tadeu> hi...I'm trying to use SIGUNUSED by #include <signal.h>....this works ok in 16.04 but not on 17.10...any ideas?
<LocutusOfBorg> m_tadeu, the idea is to stop using it I guess
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875927
<ubottu> Debian bug 875927 in perl "perl: SIGUNUSED removal in glibc 2.26 changes PL_sig_name / SIG_SIZE" [Normal,Open]
<LocutusOfBorg> here you have some references to its removal
<m_tadeu> LocutusOfBorg: thanks for the info
<LocutusOfBorg> yw
<coreycb> jamespage: ack
<TJ-> advice request for 1710 re: nsswitch - got a user with valid /etc/hostname and /etc/hosts where sudo hangs (trying to resolve hostname when not network connected) Narrowed it down to nsswitch preferring IPv6 and no separate entry in /etc/hosts for the hostname. That's fixed, but in investigating noticed that "getent ahosts $(hostname)" returns IPv4 localhost IP addresses but not the hostname, where as
<TJ-> the IPv4 specific "getent ahostsv4 $(hostname)" returns the hostname - is this expected or a bug?
<coreycb> jamespage: are you planning to upload remaining packages directly to bionic or still use the ci-train ppa/
<coreycb> ?
<jamespage> coreycb: hmm
<jamespage> coreycb: I might do the neutron ones together once we have the unit testing issues sorted
<jamespage> coreycb: but the other leaf packages could go direct
<coreycb> jamespage: that would make sense
<jamespage> coreycb: I started on swift but need to fix eventlet
<coreycb> jamespage: ok
<jamespage> coreycb: zigo is hitting the same issue with neutron@pike into debian unstable; something in the dep chain is causing the problem
<jamespage> coreycb: we're still ok in artful so I'm trying to bisect exactly what's going on
<coreycb> jamespage: ack
<jamespage> coreycb: the stacktrace is misleading - its a bug, but not the direct cause of the problem
<doko> coreycb: who usually cares about mysql?
<coreycb> jamespage: i think the server team usually manages that
<coreycb> jamespage: sorry that was meant for doko
<jamespage> hehe
<jamespage> doko: rbasak
<doko> rbasak: please could you have a look at ruby-mysql2? the debian/start_mysqld_and_run.sh needs some modernization
<rbasak> doko: Skuggen (Oracle; not here) should be able to look at that I think. I filed https://bugs.launchpad.net/ubuntu/+source/ruby-mysql2/+bug/1732710.
<ubottu> Launchpad bug 1732710 in ruby-mysql2 (Ubuntu) "ruby-mysql2 0.4.10-0ubuntu1 FTBFS" [High,Triaged]
<doko> ta
<rbasak> doko: hang on
<rbasak> doko: looks like you dropped the patch that was already there that fixes this.
<rbasak> doko: what were you trying to do?
<doko> wait ...
<doko> rbasak: ahh, my bad. will reapply
<rbasak> Thanks.
<rbasak> OOI, why are you jumping ahead of Debian on this package? Is it needed for Ruby maybe?
<doko> rbasak: seeing bus errors in the autopkg tests on armhf
<doko> so nothing what debian will see ... and fix
<rbasak> I see. Thanks.
<juliank> cjwatson: katie/archive robot synced gsmartcontrol 1.1.1-1 from debian, updating from 1.0.2-1. There was an 1.1.0-1 in debian in between those two. It then closed bug 1713311 as that was fixed in the skipped release, but only had the top-entry in the comment.
<ubottu> bug 1713311 in wifi-radar (Ubuntu) "Unable to launch applications which use su-to-root from menu package as root on Wayland session" [Undecided,New] https://launchpad.net/bugs/1713311
<juliank> Sounds a bit weird
 * juliank thinks that's kind of your thing
<cjwatson> juliank: sounds deliberate - in at least some situations LP deliberately reconstructs things from the changelog
<cjwatson> juliank: oh, the comment in the bug is non-ideal I suppose
<juliank> yeah, the comment was confusing
<sladen> madigens: ping
<sladen> madigens: emailed a few hours ago.  Probably too late for me to leave now
<cjwatson> juliank: Looks like https://bugs.launchpad.net/launchpad/+bug/1385660
<ubottu> Launchpad bug 1385660 in Launchpad itself "reason that Janitor closed a ticket is unclear" [Low,Triaged]
<cjwatson> juliank: Bit much for me to tackle just at the moment though, I'm afraid
<juliank> cjwatson: Well, at least you found a bug report :)
 * juliank subscribed
<cjwatson> If anyone wants to dig, lib/lp/soyuz/model/processacceptedbugsjob.py is probably the place to start
<cjwatson> The problem is probably something like that close_bugs_for_sourcepackagerelease does a since_version check for bug_ids but doesn't then pass that information down to close_bug_ids_for_sourcepackagerelease
 * cjwatson braindumps briefly into the bug
<madigens> sladen: just came back from work
<elopio> infinity: hey, do you know who can release this? https://code.launchpad.net/~elopio/ubuntu-motd/appreciation/+merge/333552
<infinity> elopio: kirkland
<elopio> kirkland: ping :)
<scientes> I can't get my program which calls gettext() to look for translations
<scientes> checking via strace
<coreycb> jamespage: https://github.com/openstack/requirements/commit/daa2bedb1ed5ff48c6d95cdc0c6f02fcf68d9089
<coreycb> jamespage: i'd like to see if we can reject python-oslo.serialization 2.21.2-0ubuntu1 from bionic-proposed and upload 2.21.1 instead
<coreycb> jamespage: or, we could just hold off on glance uploads
<scientes> I read the gettext manual
<bdmurray> niedbalski: Do you agree with cpaelzer about bug 1729858?
<ubottu> bug 1729858 in libvirt (Ubuntu Zesty) "virt-clone fails with: Unknown driver 'iso'" [Undecided,Fix committed] https://launchpad.net/bugs/1729858
<jamespage> coreycb: neutron bits going to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3043/+packages first
<jamespage> coreycb: hmm - alot of the networking-* projects have missing release tarballs?
<jamespage> does that ring bells? I see you did some already
<coreycb> jamespage: i noticed some missing tarballs but didn't look into it
<coreycb> jamespage: just skipped for now
<coreycb> jamespage: so i think we can just hold off on uploading glance until a fixed oslo.serialization comes out, since all the other pkgs were build with 2.21.2
<jamespage> coreycb: ok sounds sensible
<sil2100> bdmurray: hey, doing SRU reviews now?
<sil2100> bdmurray: I'd like to tackle some queue reviews later today as well - if you have a moment, could you take a look at the zesty and xenial livecd-rootfs SRUs in the queues? Those are now good for review as we got the old zesty one released finally (thanks to Tribaal!)
<bdmurray> sil2100: I've made a note of it
<acheronuk> oSoMoN: hi. I notice you upload Libreoffice. do you anticipate Libreoffice 6 getting into Bionic if it's out on schedule?
<sil2100> bdmurray: thanks
<jbicha> acheronuk: we've always taken the Libreoffice releases since LibreOffice's release schedule is based on making it easy for Ubuntu
<acheronuk> jbicha: didn't know that. thanks
<oSoMoN> acheronuk, yes, according to libreoffice's release plan, 6.0 should be in bionic
<acheronuk> oSoMoN: great. I ask as that should have the first release of the Qt5 VCL plugin, meaning we (Kubuntu) can get rid of the old KDE4 one, and maybe have all KDE4 stuff off our iso
<acheronuk> thx
<kirkland> elopio: done
<kirkland> infinity: actually, anyone on ~ubuntu-motd can commit/push
<elopio> kirkland: thank you! You have my appreciation :)
<elopio> wait, I
<kirkland> elopio: ;-)  np
<elopio> 'm confused. The MR is still open.
<elopio> I see it now, great!
<bdmurray> sil2100: How is bug 1731492 fixed in more current releases?
<ubottu> bug 1731492 in livecd-rootfs (Ubuntu) "[SRU] Release "minimized round 2" changes to Xenial" [Undecided,New] https://launchpad.net/bugs/1731492
<bdmurray> or Tribaal ^^
<Tribaal> bdmurray: it isn't AFAIK
<Tribaal> bdmurray: you mean for zesty and artful?
<bdmurray> Tribaal: and that bionic release too.
<Tribaal> bdmurray: I think bionic was covered by https://code.launchpad.net/~vorlon/livecd-rootfs/minimize-round-two/+merge/332529 ?
<Tribaal> bdmurray: there is no incentive to add those minimization changes to z and a AFAIC - so I backported only to Xenial (since that's where the changes were actually needed). Is that the wrong approach?
<slangasek> yes, it landed in livecd-rootfs 2.482; closing the trunk bug task with this explanation saves questions
<nacc> Tribaal: i think it's more what slangasek just said -- the bug does not indicate it's fixed in the development release -- and there could be tasks for a and z that say won't fix, perhaps (with a bug comment)?
<slangasek> he doesn't have privs to open the tasks to mark them wontfix
<Tribaal> right, I was going to say just that :)
<nacc> slangasek: ah
<nacc> can still nominate, though, right?
<bdmurray> Isn't Tribaal an upstream developer of livecd-rootfs?
<nacc> (or put in a comment, i guess, that's what i've asked other contributors to do inn the past)
<Tribaal> I guess I should apply for the bug squad
<bdmurray> Tribaal: If you are an upstream developer there is a way to join the Ubuntu Bug Control team.
<Tribaal> well, I applied for the bug squad anyway :)
<nacc> heh
<jbicha> bdmurray: hi, did you see the software-properties autopkgtest failures on artful and bionic?
<jbicha> it doesn't look like it's gtk3's fault so it would be nice to get the gtk3 update in to artful to fix LP: #1720400
<ubottu> Launchpad bug 1720400 in gnome-control-center (Ubuntu) "/usr/bin/gnome-control-center:11:update_buffers:image_get_buffers:intel_update_image_buffers:intel_update_renderbuffers:intel_prepare_render" [High,In progress] https://launchpad.net/bugs/1720400
<bdmurray> Tribaal: bug squad won't give you any permissions though
<Tribaal> bdmurray: well, I'll just have another badge then :) SO nominating for ubuntu releases stems from what? either per-project "upstream" status or Ubuntu Developer for "accross the board" nominations?
<bdmurray> Tribaal: members of Ubuntu Bug Control can nominate a bug for fixing in a release. Ubuntu Developers can accept or directly add those tasks if they can upload the package.
<Tribaal> bdmurray: ahh that clears it up some, thanks.
<Tribaal> bdmurray: then the bug squad still seems to be a good place where I can help in the grant scheme of things - just not for this particular case :)
<doko> jbicha: gtk-doc ftbfs in bionic, otoh I see build failures because gtk-doc is not recent enough. could you have a look?
<doko> hmm, builds locally
<jbicha> I was confused by it too
<jbicha> what fails to build because of older gtk-doc?
<doko> hmm, closed the tab in the browser
<doko> jbicha: hmm, failed again on the buildd
<jbicha> bdmurray: thanks again :)
#ubuntu-devel 2017-11-17
<Unit193> juliank: Downside to Ubuntu's command-not-found is that it doesn't have update-command-not-found. :/
<teward> rbasak: infinity: did we ever figure out the issue?  (Yesterday was a crazy hellish day, I apparently was not straight-thinking on a regular basis...)
<cpaelzer> niedbalski: see question by bdmurray above - and if possible ack in the bug so the SRU Team sees it
<rbasak> teward: I think LocutusOfBorg pointed out what to cherry-pick from a different package to you or something?
<LocutusOfBorg> yes
<LocutusOfBorg> on the bug report, I uploaded the patch in my ppa
<LocutusOfBorg> btw completely not a luajit fault
<LocutusOfBorg> and please don't force me to look at that hell again
<didrocks> cpaelzer: rbasak: hey! I have a small question for you: how do we request some packages to get autoimported in your git machinery? and how long will it take to get the first import done? I have 3 potential packages which can help us on our new community theme effort (only autoimport, we won't push to them yet as we discussed during the Rally)
<cpaelzer> didrocks: https://git.launchpad.net/usd-importer/tree/gitubuntu/source-package-whitelist.txt
<cpaelzer> didrocks: this should mostly be it for the sense of auto-importing
<didrocks> cpaelzer: excellent, let me do a MP against it
<cpaelzer> didrocks: but nacc / rbasak work on getting everything imported so a lot of things might (have) change
<cpaelzer> for now that should be it AFAIK
<cpaelzer> yeah worst case it is a simple MP and you'll get told in the review of it
<didrocks> how long is the first import taking approx, once this is merged? (so that I can give some timeline for the community)
<cpaelzer> didrocks: would a single manual import help you?
<didrocks> doing immediately :)
<didrocks> yes!
<didrocks> just to get them started
<cpaelzer> let me take a look then at a manual import
<didrocks> ah, excellent :)
<cpaelzer> didrocks: list of packages?
<didrocks> cpaelzer: gnome-shell, gtk+3.0, gnome-themes-standard
<cpaelzer> didrocks: all three imports are running - no commit ment on duration or success chance
<cpaelzer> didrocks: will let you know
<didrocks> cpaelzer: haha, no worry, thanks a lot! :)
<cpaelzer> didrocks: gz to your spotlight btw!
<didrocks> cpaelzer: thanks ;)
<cpaelzer> didrocks: sorry - had to abort for a shrotage on storage, but looked good so far - rerun after some cleanup
<didrocks> cpaelzer: thx for keeping me posted (and good luck!)
<rbasak> cpaelzer: thanks :)
<rbasak> didrocks: please note that we expect to rebase the world still.
<didrocks> rbasak: yeah, not a biggie, I just need a way for the community to git clone and get easily the current content from ubuntu, they won't branch from it
<rbasak> OK great. The whitelist should be sufficient for that I think.
<juliank> Unit193: Well, if we merge it would have both the static db and update-command-not-found :D
<juliank> I'm not sure if the local one should take precedent or if they should be merged somehow
<juliank> u-c-n-f is far less effective than the ones shipped in the package.
<juliank> like, no alternatives
<doko> ginggs: the autopkg test are far by complete, but could you have a look at the ones triggered by gdal?
<doko> cpaelzer, rbasak: rdma-core now builds libibverbs*, which wants to promote to main. server team was subcribed to it. please can you file a MIR for that?
<cpaelzer> I was following rdma-core for dpdk reasons
<cpaelzer> yes I can file the MIR
<cpaelzer> did id now complete in Debian?
<rbasak> rdma-core is in universe though?
<cpaelzer> IIRC on wednesday it wasn't
<cpaelzer> rbasak: it is meant to replace  libibverbs1 (and many more)
<cpaelzer> which is in main
<rbasak> Ah
<cpaelzer> transition from many (MANY++) sources to one source
<cpaelzer> which means many source pkg -> rdma-core
<rbasak> I see
<cpaelzer> doko: let me just infishe the debdiff here and then I'll file one
<ginggs> doko: i will look
<rbasak> Looks like it's pulled in by libvirt, ceph and boost.
<rbasak> Also tgt
<cpaelzer> doko: rbasak: filed 1732892
<cpaelzer> doko: it is a bit of a special case as it is a reorg of the source packages - so for all in main before this is kind of clear but as the source now contains more ...
<cpaelzer> e.g. the security POV on the case might be different now
<cpaelzer> anyway the bug to process it now exists - thanks for the ping doko
<cpaelzer> didrocks: gnome-themes-standard complete (https://code.launchpad.net/~usd-import-team/ubuntu/+source/gnome-themes-standard/+git/gnome-themes-standard), others still running
<doko> rbasak: one more thing ... who could look at the postgresql-10 triggered autopkg test failures?
<doko> citus, postgresql-plproxy, psqlodbc
<xnox> doko, some of these were due to out-of-date postgresql-common and just need retry with like all-proposed. let me double check things.
<xnox> doko, the thing to grep is "supported-versions: WARNING: Unknown Ubuntu release: 18.04"
<Laney> you can trigger with just pg-common from proposed if it's that
<xnox> citrus pg-repack postgresql-plproxy psqlodbc look retriable
<xnox> pglogical looks like a perl/postgresql regression?
<xnox> Laney, hmmmm imho pglogical/armhf should be bad tested.... it is always failed everywhere else.
<cpaelzer> didrocks: gnome-shell complete as well, one more to go ...
<ginggs> doko: these look good now http://autopkgtest.ubuntu.com/packages/p/pdal/bionic/armhf http://autopkgtest.ubuntu.com/packages/o/otb/bionic/armhf
<doko> ginggs: nice, thanks
<abeato> sil2100, hey, I've noticed that ubuntu-image is pulled when installing livecd-rootfs now, why is that? It clobbers ubuntu-image from the snap
<nacc> cpaelzer: which version of the snap did you use to import (thi sis important)
<didrocks> cpaelzer: seems gtk+3.0 is taking a lot more time (just checked and not here yet), thanks a lot for the 2 others! I will use that opportunity to get familiar with the repo layout as well
<nacc> cpaelzer: did you a skip-applied import?
<nacc> cpaelzer: also, i guess i didn't tell you this before, but please update the whitelist ifyou manually import packages
<nacc> cpaelzer: otherwiset the repo will immediately fall out of date
<BlessJah> is AWS image naming convention ducumented anywhere?
<Faux> There's https://bugs.launchpad.net/cloud-images/+bug/1458825 (opened by me, over two years ago).
<ubottu> Launchpad bug 1458825 in cloud-images "Please explain "root store" terms (hvm-io1, hvm, ...)" [Undecided,New]
<nacc> BlessJah: Faux: wrong channel?
<nacc> probably want #ubuntu-server
<Faux> I was replying to BlessJah.
<Faux> Oh my, you saw that.
 * Faux -> coffee.
<nacc> Faux: :)
<Unit193> juliank: But if someone adds an external repo with working contents, Debian gets them whereas Ubuntu won't.
<BlessJah> nacc: you're right, thanks
<juliank> Unit193: Yes, that's why I'd want to merge that stuff
<BlessJah> Faux: I'll try to get answer on #ubuntu-server
<Unit193> Thanks for that.
<mitya57> mardy: Hi, do you know if cordova-ubuntu is still a living thing, or can be removed from archive? The latest commit in https://github.com/apache/cordova-ubuntu was >1 year ago.
<mitya57> I am asking because it is the only reverse dependency of qtsystems-opensource-src, which I would like to remove.
<mardy> mitya57: there are repos in github, let me check if they have seen some activity lately...
<mardy> mitya57: yep, last commit is from 1 year ago there too, so my guess is that you can remove them; I didn't contribute much to them so I'm not 100% sure whether anyone is still using them, but given that they are unmaintained...
<mitya57> mardy: thanks for confirmation! You were the only one of last committers whom I found on IRC ;)
<mardy> mitya57: yep. BTW, any plans for QtPim? I recently updated it to the latest git, the patch delta is considerably smaller now: https://github.com/ubports/qtpim-opensource-src-packaging/pull/1/commits/c41708bcde351ebbdd7d3e4fedbc4d48c399d24b
<mitya57> mardy: its rdeps are cordova-ubuntu-3.4 and messaging-framework. If the former is removed and the latter is compatible with the new version, then it makes sense to update it to Ubuntu.
<mardy> mitya57: kde is not using it?
<mardy> they are probably using some stuff of their own
<mitya57> According to reverse-depends, they are not using it.
<mardy> ok
<mitya57> mardy: Let's wait for the current Qt transition to migrate, then I'll maybe take your packaging and upload it.
<BlessJah> Faux: could you join #ubuntu-server to discuss you bug report?
<nacc> cyphermox: doko: i'm about to be out on vacatio, and am a bit hesitant anyways to process a MIR I filed; LP: #1687454. Is it possible one of you can look so we can get that in this cycle? I think based upon c#2, it should be approved since we have the security ack?
<ubottu> Launchpad bug 1687454 in nghttp2 (Ubuntu) "[MIR] nghttp2" [Undecided,New] https://launchpad.net/bugs/1687454
<nacc> dpb1: --^ if you could help keep track of that
<cyphermox> nacc: yes I'll review it
<nacc> cyphermox: thanks!
<dpb1> nacc: will do.
<nacc> dpb1: thanks
<nacc> dpb1: anyone on the squad should be able to cherry-pick the necessary change from the history (as I uploaded a version with the depenency changed during the last cycle) and upload it (or request it be sponsored)
<nacc> dpb1: necessary change = build mod_http2 for apache2, if MIR is approved
<nacc> cpaelzer: fwiw, i would really rather folks not use skip-applied except when testing the importer (purely for speed of import). If you are pushing to the repo, no special options should be passed (unless there is a very good reason, e.g. patches-applied fails)
<niedbalski> cpaelzer, bdmurray I think you can proceed with the SRU.
<bdmurray> niedbalski: which one was that again?
<bdmurray> niedbalski: And how much confidence do you have in "I think"
<niedbalski> bdmurray, cpaelzer I am seeing a problem on the upgrade with virtlogd not being properly started after upgrade, but the problem isn't reproducible with exception of this particular environment.
<niedbalski> so I can't hold this because of a single case.
#ubuntu-devel 2017-11-18
<clivejo> anyone having trouble gunzip in bionic?
<clivejo> gzip: buildlog_ubuntu-bionic-amd64.kf5-messagelib_4:17.11.80+p18.04+git20171117.1745-0_BUILDING.txt.gz: not in gzip format
<doko> ginggs, tumbleweed, jtaylor: there's definitely something wrong with numpy/scipy on i386. see the python-cdo build just hanging in the tests
<ginggs> doko: where do you see that? i'm only seeing what look like more precision errors in the blas and atlas tests
<doko> ginggs: https://launchpad.net/ubuntu/+source/python-cdo/1.3.5-2
<ginggs> doko: ah, ok. let's see what the latest numpy upload does
<gsilvapt> Anyone experience any issues in Launchpad?
<gsilvapt> Well, running all comands with pip3 and sudo worked
<gsilvapt> Oops, sorry, wrong channel
<doko> ginggs: hangs again
<fantoro> Hey, I'm new to Ubuntu/Debian packaging and I want to become a ppa maintainer for an open source port of a game, right now I'm trying to make the .deb package but when I add debian/install file I get an error.
<fantoro> Wait, I just found out that the content of my install file are somehow wrong
<fantoro> btw these are my contents of the install file: https://pastebin.com/raw/eWdHZkaA
#ubuntu-devel 2017-11-19
* BrownShitNuggets changed the topic of #ubuntu-devel to: I SHIT MY PANTS.  LOL DONGS.
* Ampelbein changed the topic of #ubuntu-devel to: Artful Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<doko> ginggs, jtaylor: python-numpy autopkg tests now down to python-scipy failure.  the one on amd64 is y pathon2 test called test_gzip_py3. should that one even run for python2? the i386 one ... I don't know
<ginggs> doko: tomorrow i'll try to check whether upgrading scipy to 1.0.0 helps
<doko> ginggs: the amd64 issue is gone by testing against -proposed. only the i386 one left
<ginggs> doko: ok, so it's just the precision errors then?  should we get scipy marked badtest for i386?
<doko> from my side fine ... python-numpy in main doesn't show any failures anymore
<NikTh> Hi, any suggestions about this build failure ? https://goo.gl/ZcTpmh
<NikTh> ping apw
<ginggs> doko: i *think* this patch to scipy will do it: https://paste.ubuntu.com/25998603/ - i can't test it because i can't reproduce the failure in my VM
<LocutusOfBorg> doko, https://launchpad.net/ubuntu/+source/rubberband/1.8.1-7ubuntu1 this is making mpv uninstallable
<LocutusOfBorg> and then this fails https://launchpad.net/ubuntu/+source/gnome-mpv/0.13-1ubuntu1/+build/13746173
<LocutusOfBorg> should I no-change rebuild mpv?
<TJ-> anyone on 17.10 can check what "keyctl show" reports for their regular user? is the top-level session keyring  owned by UID 0 ?
<Faux> zsh: command not found: keyctl
<TJ-> Faux: it's part of the keyutils package; should be installed if ecryptfs-utils was installed I think
<TJ-> Faux: trying to get to the bottom of a rather serious bug on 17.10 for a user who's lost access to encrypted home, and it seems to be down to the keys being inserted into the wrong keyring (again ... been an on-and-off problem for many releases)
<Faux> https://paste.debian.net/hidden/733a3e67/ is my desktop, if it's useful to you at all. I do not have ecrypt.
<Faux> /away
<TJ-> Faux: is that 17.10? in your's the session keyring is owned by the UID 1000 but it's got root's user keyring linked :)
#ubuntu-devel 2018-11-12
<PenguinPerk> Anyone using kubernetes ?
<valorie> PenguinPerk: for what?
<valorie> I know people on twitter etc. who do
<doko> cpaelzer_: for 1799397, is that seen with gcc-7 (or gcc-8) in disco as well?
<cpaelzer_> doko: I asked the guys who recreate it atm
<cpaelzer_> didn't do so on my own yet
<jbicha> apw: hi, it looks like you copied linux-aws cosmic instead of cosmic-proposed to disco? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is complaining
<apw> jbicha, looking
<apw> aws
<apw> jbicha, hmmm some tooling failure there for sure, i'll clean up the mess and get that sorted so it never happens again
 * Laney hears muffled screams
<apw> it is a good job britney is ever-vigilant
<TJ-> apw: did you pick up yesterday's reports of the mainline builds failing since 4th Nov, due to 4.20 having removed oldsilentconfig but the kteam-tools adhoc/any-syncconfig-fallback.trigger still being applied?
<apw> TJ-, why would they do that
<TJ-> apw: who do what? silentoldconfig has been deprecated for a long time, and was removed for 4.20
<apw> right, but changing a user interface is always bad
<apw> anyhow, that patch is meant to only get added if we have syncconfig added
<apw> or don't have syncconfig or something
<apw> did they re-get-rid of syncconfig ?
<TJ-> apw: right, it adds it for 'future' proof but now needs removing
<apw> but it should only get added when we don't have the new interface that i am now using
<apw> so if we have that interface we should be good
<TJ-> synconcfig is there in scripts/kconfig/Makefile, but the comments against it say it's "internal only" now
<TJ-> apw: anyhow, the BUILD.LOG for the mainlines since 4th show the problem
<apw> so they are changing the interface again, having changed in like 2 releases ago
<apw> they should be beaten with sticks
<TJ-> apw: indeed; commit 79123b1389cc7 says syncconfig is now an 'internal implementation detail' and is deprecated for external use!
 * apw sighs
<TJ-> silentoldconfig removed in 0085b4191f3e
<apw> yeah which we are coping with
<apw> just they changed the form of syncconfig so i cannot find it any more
<apw> TJ-, ok ... fixed I believe and i have thrown the necessary rebuilds at the builders
<ahasenack> bdmurray: hi, when able, could you please check rbasak's last comment in https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/1677755 ?
<ubottu> Launchpad bug 1677755 in backuppc (Ubuntu) "Missing dep8 tests" [Wishlist,Confirmed]
#ubuntu-devel 2018-11-13
<ginggs> doko is #913626 only with s390x ?
<doko> ginggs: apparently yes
<ginggs> doko: thanks, i'll have a look
<ginggs> doko: i find it weird that r-cran-stringi and r-base are both in dependecy level 1 in the ubuntu tracker
<xnox> didrocks, Could not open desktop-minimal from checkout of (any of):
<xnox> destkop-minimal
<xnox> desktop
<xnox> didrocks, you need a faster keyboard =)
<xnox> fixed
<jibel> xnox, thanks
<jibel> (for fixing the typo)
<didrocks> grrrrr, I will never be able to type desktop properly!
<didrocks> thx for fixing!
<ogra> didrocks, time that we rename it to "bureau" ?
<didrocks> ogra: ofc! that's my followup commit
<didrocks> :)
<ogra> !
<bdmurray> coreycb: so bug 1795424 is v-done correct?
<ubottu> bug 1795424 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Fix committed] https://launchpad.net/bugs/1795424
<coreycb> bdmurray: yep, finally!
<bdmurray> coreycb: Do you mind modifying the tags?
<coreycb> bdmurray: done
<infinity> coreycb: Any plans to fix cinder in disco? (see the autopkgtest failures)
<coreycb> infinity: taking a look
<infinity> coreycb: Ta.
<ahasenack> is this something that can be easily fixed in bileto, or should we really stop using it for disco onwards?
<ahasenack> E: The repository 'http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu disco Release' does not have a Release file.
<ahasenack> looks like all we need is one package in that ppa built for disco
<xnox> ahasenack, that is fixable.
<xnox> ahasenack, not built =) _copied_
 * xnox does that
<ahasenack> yep, copied
<xnox> are we both doing it?
<ahasenack> I'm not
<xnox> i have
<xnox> =)
<xnox> good
<ahasenack> good
<ahasenack> thanks
<xnox> will be published eventually.
<infinity> Better idea, the stable-phone-overlay stuff should all be torn out of bileto.
<xnox> infinity, we thought we did.
<xnox> infinity, i think it still is wired up to britney triggers, cause bileto triggers britney with that --extra-ppa or some such.
<xnox> infinity, and sil is away to fix it =/
<teward> stupid question I know, but what's the suggested/proposed timeline for a Py2 removal?
<teward> if there even is one (since that has a huge number of rdeps too)
<doko> Rejected:
<doko> libecpg-compat3-dbgsym_10.5-1build3_s390x.ddeb: Version older than that in the archive. 10.5-1build3 <= 11.1-1
<doko> libecpg-compat3_10.5-1build3_s390x.deb: Version older than that in the archive. 10.5-1build3 <= 11.1-1
<doko> libecpg-dev-dbgsym_10.5-1build3_s390x.ddeb: Version older than that in the archive. 10.5-1build3 <= 11.1-1
<doko> [...]
<doko> so postres 10 and 11 are not co-buildable?
<doko> postgres even
<xnox> there should be like an upload of 10 which drops the transitional packages, no?
<infinity> doko: Once the transition is complete, it should just be removed.
<infinity> doko: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913353
<ubottu> Debian bug 913353 in ftp.debian.org "RM: postgresql-10 -- ROM; superseded by postgresql-11" [Normal,Open]
<infinity> doko: Unfortunately, entangling psql and icu might make that fiddly.
<seb128> bdmurray, thanks for fixing update-notifier, we (desktop) were looking at that earlier since we did the previous update that was blocked in proposed and we were about to upload https://www.irccloud.com/pastebin/WsNmykoB/ ... do you prefer your solution? L_aney also pointed out that update-manager went for ignore W503 and that it would be good to be using a consistent style between those projects
<bdmurray> seb128: I don't really have a preference and being consistent would be sensible.
<seb128> bdmurray, you are ok if I do the change from the pastebin then?
<bdmurray> seb128: Yeah, that's fine by me. Maybe sending an email about 503 vs 504 would be good too.
<seb128> bdmurray, where do you suggest sending it?
<bdmurray> seb128: ubuntu-devel?
<seb128> just to ask if as a project we have an opinion/preference?
<bdmurray> If the goal is consistency then saying this one is preferred
<seb128> k
<wxl> doko: do you have any idea why calamares would be looking for a liboost-python tied to python 3.6?
<wxl> (i ask you because you recently did a no change rebuilt of calamares, assumedly for that reason)
<wxl> fwiw this is true also with the version in proposed, though i had no hope of that fixing things
<mwhudson> wxl: i don't know about this package at all but a lot of packages have bad code to find the libboost_python soname :(
<wxl> mwhudson: well it's been working. fwiw https://github.com/calamares/calamares
<wxl> searching that for libboost i only return a cmake module which is i doubt what we're looking for
<wxl> yeah the naming stucture of the soname at least hasn't changed since cosmic.. this couldn't in some way be a result of merged-usr could it?
<wxl> doesn't seem like it would...
<wxl> and i DO have libboost_python37.so.1.67.0. this does indeed suggest something amiss with calamares...... but then we did a no change rebuild already so color me confused
<tsimonq2> wxl: Try grabbing these packages locally real quick: https://launchpad.net/ubuntu/+source/boost1.67/1.67.0-10
<tsimonq2> It could very well be an outdated boost1.67.
<wxl> @tsimonq2: even though the same version's in proposed which i pulled down?
<udevbot> Error: "tsimonq2:" is not a valid command.
<tsimonq2> @@@@@@@wxl: Oh really?
<udevbot> Error: "@@@@@@wxl:" is not a valid command.
 * tsimonq2 runs
#ubuntu-devel 2018-11-14
<doko> stgraber: never got a reply on my lxd question. now filed https://bugs.launchpad.net/lxd/+bug/1803344
<ubottu> Launchpad bug 1803344 in lxd (Ubuntu) "lxd fails it's autopkg tests on arm64 in 18.04 LTS" [Critical,Confirmed]
<smoser> xnox: around ?
<smoser> https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/358737
<smoser> ii've tried to add a test that verifies that the service is running, but I can't seem to get the test to pass.  even though when i run it and log in and look, iscsid will be running.
<smoser> i suspect this is just due to how the udev fired WANTS ends up getting done and that it happens too late for the test to see it done.  the test runs as cloud-init user-data.
<smoser> any thoughts on how i could test this in a dep8 test?
<xnox> smoser, hey, yes, i am around. and I did see your merge proposal and it did look fine.
<xnox> it should be testable.... trivially..... to check
<smoser> xnox: well, having cluod-init runcmd with systemctl is-active does not seem to work
<smoser> shows inactive
<smoser> xnox: ^ thoughts ?
<rbasak> xnox: unfortuntely the released media has a bunch of bugs :-/
<rbasak> (eg. not enabling universe)
<rbasak> Right now there is no released media that does the right thing by default.
<rbasak> That doesn't need manual intervention to fix.
<rbasak> (tbh, I don't understand why that bug wasn't a release blocker)
<smoser> xnox: my question is just when can i guarantee that the Wants that was added by the udev rule will have been realized and put into effect
<akshayrkapadia> Hey, I want to start contributing to Ubuntu development. Do you guys have any advice on where to start? I've read some of the wiki and checked out Launchpad, but its quite overwhelming.
<rbasak> akshayrkapadia: I would start by picking a thing that you want to fix, and focusing on that. It might take a few attempts to find something that is both interesting to you and also easier to fix (to avoid diving in at the deep end).
<rbasak> akshayrkapadia: try searching for bugs labelled "bitesize"
<akshayrkapadia> Thanks
<smoser> akshayrkapadia:  and what things interest you?
<smoser> if you have interest in kernel development, then bugs in libreoffice wont be too interesting
<akshayrkapadia> I'm interested in android integration with GSConnect and Ubuntu desktop experience as a whole. I'm willing to contribute to any project that.
<akshayrkapadia> *any project that is coded in python or java
<sladen> akshayrkapadia: best way to begin, is to start with that is there.  Use it until you find a bug/spelling mistake/crash, and then try to work out how to fix/improve it
<xnox> smoser, yes, that's an easy question. i don't have the answer to that off-hand.
<xnox> smoser, on boot, i expect this to be done after udev coldplug retrigger service runs... and udevadm is settled, and all systemd pending jobs are done.... but it's racy.
<xnox> cause it's like polling systemctl list-jobs after a udevadm settle
<roaksoax> win 10
<infinity> vorlon, doko: Any idea who demoted mozc-utils-gui without actually removing it from ibus-mozc recommends?
<vorlon> infinity: me
<infinity> vorlon: Seems a bit premature. :P
<vorlon> infinity: because qtbase grew a new dep on libvulkan-dev
<vorlon> and I'd rather have it in c-m than either have a) busywork MIRs or b) qt reuploads while we're trying to work this transition through
<vorlon> and the Desktop Team knows they're supposed to figure out the demotion of mozc-utils-gui <-- seb128
<infinity> vorlon: Seems plausible that vulkan will land in main soon anyway, but fair enough.  I guess I'll just not look at c-m for a while. :P
<seb128> vorlon, yeah, still in our backlog, thx for the reminder :)
<vorlon> seb128: it would be helpful to have that done sooner rather than later now, because the above impact to component-mismatches clutter.  Should I consider just uploading to drop the Recommends?
<seb128> vorlon, let me look more tomorrow before we do that
<vorlon> seb128: ok, cheers
<seb128> np
<stgraber> doko: latest result shows a success
<doko> stgraber: no, not according to http://autopkgtest.ubuntu.com/packages/l/lxd/bionic/arm64
<doko> cpaelzer, rbasak: please subscribe the server team to postgresql-11 (same as for -10)
<doko> promoted now
<vorlon> Laney: seeing as didrocks referenced you in the git commit, fyi I'm dropping ubuntu-desktop-* on s390x.  They were added without consultation with the folks that own the s390x product after having been explicitly excluded from the package; and I don't agree at all with hacking the seeds to make them installable with a different definition of what constitutes the ubuntu-desktop vs other architectures
<cpaelzer> doko, thanks I subscribed myself
<cpaelzer> ahasenack: you as well please 11
<cpaelzer> ^^
<ahasenack> hmm?
<cpaelzer> powersj: for subscribing the team that would be you who has the right "powers" to do so :-)
 * ahasenack scrolls up
<cpaelzer> subscribe to postgres-11
<ahasenack> hah
<ahasenack> I thought your "11" was meant to be "!!"
<cpaelzer> ahasenack: powersj: here https://launchpad.net/ubuntu/+source/postgresql-11
<stgraber> doko: are we looking at the same page?
<ahasenack> "you as well please !!"
<cpaelzer> hehe
<stgraber> doko: that URL shows me a pass on 3.0.2-0ubuntu1~18.04.1 on 2018-11-09 14:17:52 UTC
<cpaelzer> the 1 is just one key away from my ^
<powersj> cpaelzer, thanks for the link
<powersj> doko, cpaelzer, ahasenack: ubuntu-server is now subscribed to postgresql-11
<cpaelzer> thanks
<doko> stgraber: that's a different trigger
<stgraber> doko: but the same LXD version so it's either some kind of race because of arm64 being slow (has happened before for TLS code) or an actual regression that happened in bionic-proposed
<stgraber> doko: anyway, asked for a re-try, we'll see if that one passes
<doko> ta, I didn't see any python related, but I wanted to check, and the history isn't all passing ...
<jbicha> I started a conversation about mozc: https://community.ubuntu.com/t/removing-mozc-utils-gui-from-19-04/8717
<jbicha> qtwebengine-opensource-src failed to build again :( https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.11.2+dfsg-2build1/+build/15658038
<Laney> vorlon: Alright, I'm not bothered about building it there. I'm initerested in the "own the s390x product" claim though - you're saying this is a special architecture and we should consult with people before working on int?
<Laney> it*
<sarnold> no log file? :/
<xnox> Laney, it is special, in a sense of the hardware is rediciously expensive and nobody ever owns them, but only leases them from IBM. It is a server architecture only, as it will never have graphics stack on it. And none of the upstream desktops support it. Thus Ubuntu Desktop product is simply not possible on s390x as it currently stands.
<Laney> xnox: I understand arguments along the line of "this isn't an Ubuntu desktop"
<Laney> What I want clarification on is "folks that own the s390x product"
<xnox> Laney, and in practice it is a sponsored port, as without s390x lease from IBM of the mainframe we will not have it anymore.
<Laney> In other words, do I have to get permission from someone to do s390x work?
<xnox> Laney, no, you don't need permissions.
<xnox> Laney, but we are limited by lease terms as to what we are supposed to use it for. And ubuntu desktop is not it.
<Laney> This should probably be communicated to developers and enforced.
<Laney> If builds can cause Canonical to violate a lease...
<xnox> Laney, it was intentional that ubuntu-desktop was not built on s390x, and my change to ubuntu-meta was reverted, without even a mention in debian/changelog.
<xnox> Laney, by someone not knowing why we don't build ubuntu-desktop on s390x, and not bothering to ask either.
<xnox> Laney, and it slipped the radar, hence it should be reverted.
<xnox> Laney, the contract is vague around those things. the biggest takeaway, is that yes ubuntu-desktop does own the desktop product. but only on arches that you support....
<xnox> Laney, and ubuntu-desktop arches is amd64 only.
<xnox> (canonical supported)
<xnox> there is community support for other arches of ubuntu-desktop (somewhat, under ubuntu project umbrella)
<xnox> but there is neither for s390x or ppc64el for ubuntu-desktop.
<Laney> Right, well, this is where a mismatch comes in for me I think. Up until nrecently all of the desktop was buildable on s390x, so I don't really see why it's incorrect to have shipped ubuntudesktop there. If there wass some special out of band knowledge required then that really ought to have been
<Laney> communicat[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[4~ed t.
<Laney> Sorr for al lthe typos, I'm on a train and its' too hard to go fix them all
<xnox> bah
<xnox> looks like you faceplanted the keyboard there =)
<Laney> The interwebs angels left my side for a moment
<xnox> Laney, it was communicated at the start of the project 3 years ago, that irrespective what it builds or runs; s390x is ubuntu server and cloud only.
<xnox> ditto ppc64el
<xnox> Laney, and there is no canonical time to work on desktop/graphical things.
<Laney> There is not, that is why we didn't fix mozjs60 when it broke.
<Laney> But when things were working for free, sure, we ship things.
<xnox> not
<xnox> shipping ubuntu-desktop meta was not free, and costed us money. hence the bug of removal is escalated again.
<xnox> porting mozc gui from qt to gtk looks interesting though.
<Laney> I don't understand that
<xnox> it looks small enough.
<xnox> Laney, hours of engineering and management time spend both at internal IBM and in Canonical managing the relationship, which could have been spent improving the port for things our users actually want.
<Laney> Anyway you're telling me my understanding of the *Ubuntu* archive is wrong apparently
<xnox> don't revert intentional changes, without asking the previous upload, when one doesn't understand why it was made?!
 * xnox thought that is obvious to all of us.
<jbicha> xnox: would you be interested in splitting out ubuntu-desktop-meta to a separate source package?
<xnox> Laney, what's your understanding? in terms of .debs we generally build whatever. but the meta-packages are a bit special, as they define what it means /Ubuntu Desktop/ or /Xubuntu/ etc. and they are only built when we can support them, as an official flavour.
<xnox> which ubuntu-desktop on s390x was never the case, even when we had all the binaries.
<jbicha> it doesn't matter to me whether ubuntu-desktop is available on s390x or not, but I was annoyed at seeing changelog entries like
<jbicha> https://launchpad.net/ubuntu/+source/ubuntu-meta/1.397
<xnox> jbicha, no, why? it makes no sense to do that. And it doesn't matter which source package it is in.... as it still will not allow us to enable s390x ubuntu-desktop.
<jbicha> it was inaccurate because those technically weren't added to desktop [s390x] since that package didn't exist
<jbicha> it's a limitation of the ./update script compared to debian/control as I understand it
<xnox> jbicha, one second.....
<xnox> jbicha, i explicitely remove s390x from desktop; and none of those entries relating to s390x were there.....
<xnox> jbicha, until you reverted my change....
<xnox> jbicha, they will be gone again, and never appear in changelog anymore, once steve's upload is done.
<jbicha> xnox: not true, look closely at https://launchpad.net/ubuntu/+source/ubuntu-meta/1.397
 * xnox is finding commits
<Laney> I found the diff the added it by the way
<jbicha> that will happen if suddenly gjs starts to be buildable again on s390x
<Laney> https://launchpadlibrarian.net/345242595/ubuntu-meta_1.406_1.407.diff.gz <- think it was an accident
<xnox> jbicha, https://git.launchpad.net/ubuntu/+source/ubuntu-meta/commit/?id=68cb6941bca36314dda3a3d7894b93529e3278a2
<xnox> jbicha, is where you reintroduced s390x back for ubuntu-desktop, without consultation
<Laney> I still don't know about this built-when-supported argument, that's one I've never heard before
<jbicha> yes, the immediate driver was https://launchpad.net/ubuntu/+source/ubuntu-meta/1.406
<jbicha> those wrong changelog entries annoy me
<Laney> Presumably we should go and proactively remove all the other non-supported architectures then. But I don't see anyone kicking up a fuss so I'm a bit confused.
<xnox> jbicha, it was fine in 1.345... archive wise. Let me look at changelogs.
<jbicha> I apologize for the 1.407 upload which was wrong
<xnox> jbicha, sure, we understand.
<xnox> jbicha, if there are spurious changelog entries it is annoying.
<jbicha> it was wrong for me to not mention in the changelog what I was doing.
<vorlon> Laney: it matters for s390x because we have a contract *specifically* around server enablement, and the lack of any display hardware means that an s390x desktop port is always going to be a bastard stepchild
<xnox> jbicha, we totally understand that it was a change, with unintentional consequences
<Laney> I just have no knowledge that the architectures a seed-generated metapackage is built for ends up implying a support commitment
<vorlon> Laney: people come to us and say "but it's in main"
<jbicha> if you can figure out a way to avoid the changelog bug, I'm happy to see ubuntu-desktop go away on s390x
<vorlon> Laney: we've been deflecting escalations about supporting Network Manager on z. You're welcome ;)
<Laney> vorlon: I presume the contract doesn't include supporting that?
<xnox> Laney, the bits in launchpad for archive publishing the supported fields do define lots of things, for various parts and arches.
<vorlon> ideally, we would have a way at the germinate level to say desktop is not-for-s390x
<vorlon> so that none of the binary packages would be in main at all
<jbicha> once you remove ubuntu-desktop/s390x there is an interesting question about whether we should even have ubuntu-desktop for other unofficial desktop arches thoughâ¦
<vorlon> but barring that, at least not having ubuntu-desktop present makes it easier to explain
<xnox> Laney, recall that server & desktop had different LTS lengths in the past; and it was also true on per-arches basis too. where we had "official" and "ports" arches.
<xnox> Laney, jbicha, vorlon - the most annoying thing is that arch:all packages get the "best" lts supported stanza of all.
<xnox> jbicha, now i see what you mean by separate package.
<vorlon> jbicha: as I said, there's a hardware aspect here.  For each of the other arches, it's at least possible to run the desktop with GPU acceleration and adequate bandwidth to the display hardware
<xnox> vorlon, would ubuntu-meta-desktop source package help?
<vorlon> xnox: wouldn't help /me/...
<vorlon> xnox: I guess the point would be to have a separate update.cfg that doesn't list s390x?
<jbicha> yes
<vorlon> I'd prefer fixing ./update to honor debian/control
<Laney> why do we bother building / testing most packages if the architecture is not intended to encompass the full archive?
<Laney> presumably people see some value in having 'unsupported' software available
<Laney> it's probably OK to not have this discussion, not sure it's that useful :P
<Laney> I could go read the draft withdrawal ageement instead
<vorlon> Laney: sure; as I said, for the general case, it'd be enough to demote these desktop binary packages to universe on s390x if there was a way.  And then I wouldn't care from a contract/relationship/support POV whether the ubuntu-desktop package existed on s390x
<vorlon> but I would still think it's wrong to provide it, precisely because it's busywork to have it there
<vorlon> if you have to add architecture exclusions to make it installable, it's not really the Ubuntu Desktop experience, so why prefer pretending that it is vs. removing the binary?
<Laney> I'm behind that, as I said earlier. I just lose my understanding of the subject when we start mixing building binary packages in Ubuntu and Canonical's support contracts.
<Laney> I understood that we were able to distinguish on a more fine grained level than main/universe
<Laney> Train's pulling in now, thanks for the discussion :-)
<vorlon> :)
<infinity> xnox: Wait, wait, wait.  I read some of that backscroll.  Are you really saying "ubuntu-desktop not existing and then existing exposing a bug in ubuntu-release-upgrader was the fault of people making ubuntu-desktop exist"?
<infinity> xnox: That bug triggering was not "by design". :P
<xnox> infinity, dude it's 10pm here
<xnox> infinity, thank you for that message
<infinity> My apologies for getting to the discussion late? :P
<infinity> I still think the "we define our support based on the existence of metapackages" argument is bunk.  "We're not building the metapackages because the rdeps don't exist" is entirely reasonable and needs no debate.
<infinity> But tearing jbicha a new one because re-adding the (at the time) installable ubuntu-desktop exposed a release-upgrader bug that we had to fix is ridiculous.
<infinity> It was a bug.  We fixed the bug.  The end.
<xnox> infinity, i think you brought up something else entirely, which is not what i was referring to at all.
<xnox> infinity, the ubuntu-release-upgrader bug was not at all in my mind, i forgot about that a long time ago - and that was just that, a bug in u-r-u.
<infinity> xnox: What were the countless hours/days of engineering time that resulted from ubuntu-desktop existing, then?  I'm genuinely curious.
<xnox> infinity, there were half a dozen of private bugs filed by ibm qa; and quite afew meetings/hangouts, and f2f, explaining things.
<infinity> xnox: Cause no one seemed to notice at all until the release-upgrader bug, when multiple minds were lost.
<infinity> xnox: And again, I'll say that if we're defining our contract with IBM by the existence of a metapackage, something's terribly wrong. :P
<xnox> infinity, similar timeline, but as far as i recall the upgrade bug was not actually raised by them.
<xnox> infinity, let's not go down the path of what's terrible =)
<xnox> see Brexit
<infinity> xnox: "We're as bad at contracts as the UK Conservative government" does not instill me with confidence.
<xnox> infinity, the question of confidence or no confidence is lingering on the tip of everyone's tongues
<xnox> Conservative... and Unionist!
<TJ-> I've got to page 340 of the UK withdrawl exit agreement... of over 500 pages... I've come to the conclusion it's designed to put readers to sleep so they never reach the most contentious protocols. It's rather like reading Perl code really
<jbicha> I think perl is usually a bit more concise than 500 pages
<Unit193> I'd like to take this momennt to link a very important perl script: https://unit193.net/beer.pl
<jbicha> see, much more concise!
<sarnold> beautiful
#ubuntu-devel 2018-11-15
<cjwatson> Unit193: I see your script and raise you https://www.chiark.greenend.org.uk/~cjwatson/tmp/beerglass.pl (needs LINES and COLUMNS exported in your environment; benefits from big terminal)
<cjwatson> I applaud that obfuscation though.  I think.
<Unit193> Hah, nice.  Yeah I didn't write it though, so don't get the credit.
<andrewsh[m]> cyphermox: https://salsa.debian.org/debian/netplan.io/
<Unit193> ...Heh, just looked up a package you orphaned, surprising timing!
<andrewsh[m]> which one?
<Unit193> libmowgli-2, since atheme now uses the bundled one.
<andrewsh[m]> hah
<andrewsh[m]> does it? hmm
<andrewsh[m]> mowgli seemed like an interesting library some time ago
<andrewsh[m]> but it somehow failed to gain popularity
<Unit193> Yeeep, the idea was to allow others to use it, they never did though... :P
<andrewsh[m]> what do you mean? :)
<Unit193> In packaging it outside of atheme itself.
<andrewsh[m]> you mean atheme services?
<Unit193> Yeah.
<andrewsh[m]> it was originally used by Audacious
<Unit193> ..Huh.
<andrewsh[m]> but then it's got rewritten
<andrewsh[m]> and I guess at that time glib became much more performant
<andrewsh[m]> so there was no point in keeping custom implementations of data structures
<stgraber> doko: there, you got a shiny green tick on autopkgtest
<tjaalton> doko: is debootstrap from cosmic/disco going to be backported to bionic to support merged-/usr? I don't see a bug for it
<doko> tjaalton: please ask xnox about that
<ogra> vorlon, did the pi3 b+ core images finally get released or are we stil waiting for something
<xnox> tjaalton, doko: it already has been.... check proposed or unapproved.
<doko> ahasenack, cpaelzer: openhpi gained a new dep librabbitmq, which currently ftbfs
<jamespage> doko: you probably already noticed but coreycb and I are working through the openstack pkgs switching to python3 - leaf packages are dropping py2 support completely, and we'll work that into the 1st and 2nd level depends as that all works through
<jamespage> we'll be doing the shebang fixes at the same time
<doko> jamespage: yes, noticed that in component-mismatches :-/
<tjaalton> xnox: ok, it's wrapped together with adding cosmic release
<tjaalton> didn't notice that
<cpaelzer> doko: what happened to the updates of https://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses_by_team.html#ubuntu-server ?
<cpaelzer> last is 2 weeks old ws that transitioned to another place?
<doko> cpaelzer: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html looks recent, but I think it's not run for released versions. mwhudson, vorlon?
<cpaelzer> doko: well for now I was mostly looking for -dev
<cpaelzer> hopefully any such blockers on released versions is detected by the people doing the SRU
<cpaelzer> thaks for the link
<cpaelzer> doko: the rabbit issue you mentioned is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911693
<ubottu> Debian bug 911693 in src:librabbitmq "librabbitmq FTBFS: setup_connection_and_channel: Assertion `rc == AMQP_STATUS_OK' failed." [Serious,Open]
<vorlon> ogra: I'm waiting for qa signoff of the pi3 b+ core images
<xnox> tjaalton, cosmic is a typpo bug # btw.
<cpaelzer> doko: I also saw that you merged kopanocore, thanks it builds but fails all its tests
<cpaelzer> that is broken in Debian
<cpaelzer> https://ci.debian.net/packages/k/kopanocore/testing/amd64/ doesn't look much better
<cpaelzer> I wanted to look into that anway, but not soon
<cpaelzer> is that urgent to you?
<cpaelzer> doko: ^^
<doko> cpaelzer: yes, kopanocore is involved in the icu transition, so that would help
<ogra> vorlon, so we need to ping cwayne or plars  again ?
<lool> vorlon: hey! who's to QA this? cwayne and team?
<lool> Oh ups  :0
<ogra> first !
<ogra> :D
<lool> thanks ogra
<vorlon> ogra, lool: correct
<lool> ok cool, getting close  :)
<lool> now we have to repeat for 3A+  :)
<ogra> no hurry please ... lets get HW first :)
<ogra> ... a world full of pi's and nobody brought whipped cream ...
<doko> jamespage, coreycb: I'll try to keep up with the python3-* binary promotions, but please give back all failed autopkg tests yourself, if needed
<jamespage> doko: will do
<jbicha> ricotz: mythtv fails to build with latest x264. Do you think you'll have time to take a look? https://launchpad.net/ubuntu/+source/mythtv/2:29.1+fixes.20180414.329c235-0ubuntu4
<ricotz> jbicha, does it even build in cosmic?
<jbicha> I don't know but the build log strongly points at x264
<ricotz> mythtv ships an internal copy of ffmpeg which is likely really outdated
<jbicha> is mythtv something you think you'll have time to fix?
<jbicha> otherwise I guess we could remove it from disco-release so that it doesn't block transitions until someone can fix it
<ricotz> I don't see this package is worth patching, so either trying with a new upstream snapshot or drop it
<ricotz> I think the port to ffmpeg 4 isn't trivial and lead to some removals
<vorlon> yes, mythtv built fine in cosmic http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20180911-cosmic.html#multiverse
<ricotz> upstream seems to be quite active though
<ricotz> vorlon, yeah, thank to the internal copies
<vorlon> hmm?
<ricotz> internal ffmpeg
<ricotz> jbicha, https://code.mythtv.org/trac/ticket/13314
<jbicha> thanks, I'll try that
<ntd> anyone using amdgpu-pro on ubuntu xenial in here? looks like support got broken between kernel 4.4.0-134 and -138 and somehow i am the first to notice
<ntd> dmesg when trying to load amdgpu on > -134:
<ntd> amdkcl: exports duplicate symbol arch_io_free_memtype_wc (owned by kernel)
<ntd> i've tried amdgpu-pro 17.40, 17.50, 18.10, 18.20, 18.30 and 18.40 on on 4.4.0-134+ -138 and 4.15.0-34 + -36/38
<ntd> support gets broken between 4.4.0-134 and -138 and 4.15.0-34 and -38
#ubuntu-devel 2018-11-16
<plars> ogra: vorlon: this is a newer image than the one I tested a few weeks ago? I'm at a sprint in Taipei right now btw, so my tz is different from the normal
<mwhudson> plars: i'm not sure i remember your tz ever being normal :)
<plars> mwhudson: it's all a matter of perspective
<vorlon> plars: yes, this is newer, http://cdimage.ubuntu.com/ubuntu-core/16/stable/20181109.4/
<plars> vorlon: I'm looking at it now. Do you know what all changed in it? I don't see a fix for the ethernet LED issue yet on rpi3b+, but I know that's not really a regression since 3b+ wasn't supported previously on 16
<vorlon> plars: it should be the same as the previous image, just validating that the image still DTRT now that the snaps are promoted to stable
<cpaelzer> Hi, I have an odd case and hope somebody might have a hint
<cpaelzer> I build in sbuild and it fails on dh_install
<cpaelzer> it complains about this
<cpaelzer> dh_install
<cpaelzer> cp: cannot open 'debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24' for reading: Too many levels of symbolic links
<cpaelzer> dh_install: cp --reflink=auto -a debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24.0.0 debian/libgps24//usr/lib/x86_64-linux-gnu/ returned exit code 1
<cpaelzer> but
<cpaelzer> it actually is not on insane symlinks
<cpaelzer> ls -laF debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so*
<cpaelzer> lrwxrwxrwx 1 paelzer paelzer     16 Nov 16 09:48 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so -> libgps.so.24.0.0*
<cpaelzer> lrwxrwxrwx 1 paelzer paelzer     16 Nov 16 09:48 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24 -> libgps.so.24.0.0*
<cpaelzer> -rwxrwxr-x 1 paelzer paelzer 630408 Nov 16 09:48 debian/tmp/usr/lib/x86_64-linux-gnu/libgps.so.24.0.0*
<cpaelzer> and even more so, if I chroot into the build env and just do the copy command
<cpaelzer> then it works
<cpaelzer> anyone an idea what I might look for?
<cpaelzer> the same build (with the issue described above) works for cosmic, but fails for disco and debian-unstable
<cpaelzer> on the above issue with the so not able to be copied - it fails also in launchpad. But it behaves different per archietcture
<cpaelzer> ppc fails https://launchpadlibrarian.net/397834496/buildlog_ubuntu-disco-ppc64el.gpsd_3.18.1-1_BUILDING.txt.gz
<cpaelzer> s390x works https://launchpadlibrarian.net/397834398/buildlog_ubuntu-disco-s390x.gpsd_3.18.1-1_BUILDING.txt.gz
<cpaelzer> they build the same thing
<cpaelzer> the same args
<cpaelzer> why would one have a different symlink depth ?!?
<cpaelzer> ahasenack: I trade the review for your MP for a good idea here :-)
<ahasenack> something related to usr-merge?
<cpaelzer> I was in the chroot, it works fine
<cpaelzer> it almost seems like a racy thing
<cpaelzer> that works soon after
<cpaelzer> I've thrown it into https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3522/+packages
<cpaelzer> soem work some fail
<cpaelzer> I'm tempted to believe that on rebuilds they might even work/fail differently
<cpaelzer> ahasenack: checked, no usrmerge symlink in that path
<ahasenack> cpaelzer: link to a failed build?
<ahasenack> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3522/+build/15668073/+files/buildlog_ubuntu-disco-ppc64el.gpsd_3.18.1-1_BUILDING.txt.gz ?
<ahasenack> (just got an email about that one)
<ahasenack> cpaelzer: perhaps you will have to do some debugging builds. Like overriging dh_install and adding a ls -la to it, something like that
<ahasenack> or what's that other command that shows all path components, I forgot its name
<ahasenack> namei
<cpaelzer> ahasenack: yearh a good idea
<cpaelzer> ahasenack: I could also add a sync call to test my theory on too much FS laziness
<cpaelzer> also I did the review
<ahasenack> thanks
<cpaelzer> suspicious that debian-testing and cosmic work
<cpaelzer> and the same in disco and unstable fai
<cpaelzer> l
<cpaelzer> unless my race has a love for making up its chances to set me on false tracks
<acheronuk> tianon: hi. there are now disco tars @ https://partner-images.canonical.com/core/disco/
<acheronuk> do you know when docker images will come?
<ejat> hi, who to safely remove python2.7 from cosmic without removing dependencies ?
<ejat> how*
<cjwatson> err, if there are still things depending on it that you aren't happy to remove in turn, then you can't safely remove it
<cjwatson> sort of the definition of dependencies :)
<rbasak> bug 1781529 is ready to be approved now I think - blocks mysql-5.7 migration now.
<ubottu> bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,In progress] https://launchpad.net/bugs/1781529
<vorlon> rbasak: promoting
<rbasak> Thanks!
<rbasak> vorlon: did you miss mecab-ipadic?
<rbasak> (difference source package, same upstream project, same bug)
<vorlon> rbasak: I didn't miss it, I don't see it listed on either http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed or http://people.canonical.com/~ubuntu-archive/component-mismatches
<rbasak> Oh
<rbasak> I'll look into that, sorry.
<rbasak> Skuggen: ^ do you remember where the dependency on mecab-ipadic should be coming from?
<sarnold> "mecab depends on mecab-ipadic. Other dependencies are in main"  https://bugs.launchpad.net/ubuntu/+source/mecab/+bug/1781529
<ubottu> Launchpad bug 1781529 in mecab-ipadic (Ubuntu) "[MIR] mecab" [Undecided,Fix committed]
<tsimonq2> Unit193: Where is the code for udevbot?
<tsimonq2> I just can't find where it's kept, hm.
<tsimonq2> Maybe internally at Canonical?
<tianon> acheronuk: nice catch; mwhudson usually handles that but he's probably swamped on his other ever-increasing responsibilities so I've opened https://github.com/tianon/docker-brew-ubuntu-core/pull/139 to get the ball rolling
#ubuntu-devel 2018-11-17
<acheronuk> tianon: thanks :)
<Skuggen> rbasak: What do you mean by where it should be coming from?
<Skuggen> Sorry, been travelling this week :)
<jbicha> xnox: could you merge meson for disco? it fixes a build problem I'm having with tracker
#ubuntu-devel 2018-11-18
<mwhudson> acheronuk, tianon: oh woops
* scrotumsack changed the topic of #ubuntu-devel to: scrotum sacks and penis dongs
<scrotumsack> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, lamont, kees, darkwing, Unit193, idleone, dax, infinity, Laney, or slangasek!
* scrotumsack changed the topic of #ubuntu-devel to: genital rape
* hggdh changed the topic of #ubuntu-devel to: Archive: Open | 18.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Cosmic | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
#ubuntu-devel 2019-11-11
<vicamo> Hi, need sponsor https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1848922 for SRU backport-iwlwifi-dkms to Eoan (bug-1848922)
<mwhudson> how much ram do the default autopkgtest runners have again?
<mwhudson> guessing it's 1G
<cpaelzer> kanashiro: FYI https://github.com/theupdateframework/notary/issues/1469#issuecomment-552050160
<cpaelzer> this hit your nss upload and the nspr sync
<cpaelzer> you might want to check if applying https://github.com/theupdateframework/notary/pull/1514/commits/006963f1ded582c2cc5f5eb4d48dc6089ce3229b fixes notary to be a FTBFS
<cpaelzer> if it does bring that to Debian which would then hopefully also resolve the dep8 test failures (which build it as well)
<cpaelzer> but there seems to be more to it, so don't expect it to be a smooth ride, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944346
<ubottu> Debian bug 944346 in notary "FTBFS due API change of `github.com/docker/distribution@v2.7.1`" [Normal,Open]
<cpaelzer> But with that much known you might consider adding a badtest for notary (for now) to https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu
<cpaelzer> kanashiro: let me know what you think
<kanashiro> cpaelzer, thanks for the pointers, I'll take a look now and I'll let you know my thoughts
<cpaelzer> ok
<rafaeldtinoco> good morning o/
<cpaelzer> ahasenack: postgresql-12 made it into release, but postgresql-common 209 still has test issues
<cpaelzer> That is 12/23 resolved by my test triggers of last week, but leaves 11 to check what/why is breaking.
<cpaelzer> Left are wal2json, rdkit, postgis@s390x (flaky in the past), php-horde-db, pgrouting, pglogical-ticker, pgl-ddl-deploy, patroni, mediawiki, hypop, cstore-fdw
<cpaelzer> ahasenack: if you want to help the weirdest seems to be asyncpg (which also is important to doko IIRC) whcih fails with rather odd cython issues now exceeding my python-foo
<cpaelzer> the steps so far would be in bug 1850136
<ubottu> bug 1850136 in asyncpg (Ubuntu) "FTBFS in Focal with PG-12 present" [Undecided,Confirmed] https://launchpad.net/bugs/1850136
<ahasenack> k
<ahasenack> I was caught by u-a-t again, though: #1851858
<doko> o/
<cpaelzer> sorry to hear that ahasenack, I'll continue to keep you in the loop
<cpaelzer> and doko, if that cython error that I linked in the bug looks familiar to you let me know any pointers that you might have
<doko> cpaelzer: sorry, no. there's a new cython upstream, but nothing which looks related
<cpaelzer> ok, thanks
<doko> but I'll NMU that to debian, anyway
<rafaeldtinoco> bryce: looks like we need python3-tornado >= 6 (pcs is blocked by that)
<rafaeldtinoco> couldn't find it in the merge board, not sure if we're already on it or not
<rafaeldtinoco> anyone aware ? ^
<kanashiro> rafaeldtinoco, I am on it, I didn't do the merge yet because of a bug in usd-importer
<rafaeldtinoco> ah great
<rafaeldtinoco> thx!
<kanashiro> cpaelzer, could you please sponsor the lm-sensors package? since you reviewed it
<cpaelzer> sure
<gpiccoli> Hi sil2100, sorry for the ping! I was out on Friday, not sure if you checked the britney MPs, if I may need a change or anything hehe
<gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-bionic/+merge/375279
<gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-disco/+merge/375280
<gpiccoli> Let me know your thoughts! Tnx in advance, sorry to annoy heheh
<cpaelzer> kanashiro: done
<kanashiro> cpaelzer, thanks!
<cpaelzer> kanashiro: rafaeldtinoco: ahasenack: since you are around (and I seem to be blind atm), any good idea why "Conflicts: libapache2-mod-php7.2" in d/control doesn't make it into the built package?
<cpaelzer> belongs to bug 1850933
<ubottu> bug 1850933 in apache2 (Ubuntu) "after upgrade 19.04 to 19.10, apache serves php code" [High,Confirmed] https://launchpad.net/bugs/1850933
<ahasenack> nope, use DH_VERBOSE?
<cpaelzer> yeah, maybe the right next step
<ahasenack> or did you add it to the source section?
<cpaelzer> no it is in the binary I want it
<ahasenack> cpaelzer: I got logs in pvt email for that bug, btw
<cpaelzer> DH_VERBOSE was already on, but nothing helpful in the log
<cpaelzer> yeah me as well
<cpaelzer> based on that I found that it seems to be a real issue
<cpaelzer> the reporter didn't want to share all his logs in the bug itself
<ahasenack> ah, so you aren't clairvoyant
<cpaelzer> nope
<ahasenack> not yet, at least
<ahasenack> the singularity is coming
<cpaelzer> working on it
<cpaelzer> bulding with conflicts+breaks over lunch and then takign a look again
<kanashiro> cpaelzer, re notary: the upstream commit you mentioned fixes the current issue we have but there is another one while running the tests (not the same in Debian because they updated a b-d some weeks ago which breaks even the build)
<cpaelzer> kanashiro: yes that is what the debian bug report said
<cpaelzer> so we might for now mark it as badtest
<cpaelzer> kanashiro: have you done that before or do you need guidance where to start with it?
<cpaelzer> ahasenack: there is a d/control.in file - I guess that is the explanation ... :-/
<ahasenack> aha
<vicamo> Hi, need sponsor https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1848922 for SRU backport-iwlwifi-dkms to Eoan (bug-1848922)
<cpaelzer> doko: question about https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1849785/comments/28
<ubottu> Launchpad bug 1849785 in libseccomp (Ubuntu Eoan) "FTBFS on i386/ppc64/s390x (Eoan+Focal)" [Medium,Triaged]
<cpaelzer> python 3.7: /usr/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py
<cpaelzer> pytohn 3.8: /usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py
<cpaelzer> see the missing "m"
<cpaelzer> that is what makes libseccomp FTBFS
<cpaelzer> is that something that needs/should be fixed in the python 3.8 build - and if so it is known for a bug to track
<cpaelzer> or should I just modify the d/rules of libseccomp to use the name without "m" in the 3.8 case https://salsa.debian.org/debian/libseccomp/blob/debian/sid/debian/rules#L28
<cpaelzer> I know that you are on https://bugs.python.org/issue37561 which sounds very very similar to the naive me :-)
<doko> cpaelzer: yes, the modifier was dropped
<cjwatson> cpaelzer: https://wiki.debian.org/Python/Python3.8
<cpaelzer> thanks cjwatson and doko
<cpaelzer> fixing up libseccomp then and retrying my build
<sil2100> gpiccoli: hey! Looking in a moment o/
<gpiccoli> Hi sil2100 o/
<gpiccoli> Thank you =)
<kanashiro> cpaelzer, I have spent some time trying to fix notary by myself with no success, so let's mark it as a badtest (I've never done this, would appreciate some guidance)
<cpaelzer> kanashiro: https://wiki.ubuntu.com/ProposedMigration#Are_there_any_exceptions.3F__I.27m_sure_acmefoo_has_just_made_it_into_the_release_pocket_despite_not_satisfying_all_of_the_requirements.
<cpaelzer> which means clone, modify and propose a change to http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/changes
<cpaelzer> kanashiro: when you have taken a look feel free to ask questions about the format in there
<kanashiro> cpaelzer, thanks again
<sil2100> gpiccoli: commented! +1 on hinting the failures, but -1 on an unversioned hint
<sil2100> gpiccoli: those are too easy to forget about, could you modify it to a versioned one?
<gpiccoli> ok sil2100, I can change that! Thanks! So, how to proceed from the MP point-of-view? We drop the current MP and do another one?
<sil2100> gpiccoli: no, just modify those MPs
<sil2100> Push commits on top of them
<gpiccoli> ok, perfect! I'll do that now sil2100 =)
<gpiccoli> Tnx again for the advice, as soon I finish that, I'll ping you
<kanashiro> cpaelzer, do I need to update this file https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release ? I didn't get the difference among all those files
<cpaelzer> kanashiro: in the past several people  had their own file, but it slowly converges to a unified approach
<cpaelzer> new things should be in ubuntu-release and after the release happened things will be added to ubuntu-sru
<cpaelzer> the only reason to these days modify the other files if the badtest you are looking at was already in those and you only bump the number
<cpaelzer> but even then you might consider moving it since you are touching it
<kanashiro> cpaelzer, good, so I am on the right way :)
<kanashiro> cpaelzer, can I just link this bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944346 as a comment? Or do I need to be more verbose?
<ubottu> Debian bug 944346 in notary "FTBFS due API change of `github.com/docker/distribution@v2.7.1`" [Normal,Open]
<gpiccoli> sil2100, done both! Now they are versioned =)
<gpiccoli> Thank you for approving sil2100 =] <saw the email hehe>
<gpiccoli> Now, the package goes automatically from -proposed to -updates, or should someone trigger autopkgtests again?
<sil2100> gpiccoli: so normally, for the development series, migrations happen automatically if autopkgtests and installability are fine
<sil2100> But for SRUs, someone from the SRU team needs to manually release those
<sil2100> I'll be doing my releasing shift soon, so hopefully I'll be able to do that
<gpiccoli> Great sil2100, thank you very much for the help in all fronts =]
<gpiccoli> We have users waiting for this kdump-tools for months heheh
<gpiccoli> Had problems in the previous release, they'll appreciate much =)
<ahasenack> infinity: if you are still around, if I could pick your brain for a sec
<ahasenack> ubuntu@trusty-i386-ua:~$ uname -m
<ahasenack> i686
<ahasenack> but
<ahasenack> ubuntu@trusty-i386-ua:~$ dpkg --print-architecture
<ahasenack> i386
<ahasenack> soooo...
<infinity> Yes and?
<infinity> Never use uname to determine dpkg arch.
<ahasenack> in postinst I'm gating on i386/amd64
<ahasenack> but the ua client seems to be using uname -m
<ahasenack> ubuntu@trusty-i386-ua:~$ sudo ua enable esm-infra
<ahasenack> One moment, checking your subscription first
<ahasenack> ESM Infra is not available for platform i686.
<ahasenack> Supported platforms are: i386, x86_64
<ahasenack> bug in ua client?
<infinity> The UA client is wrong.
<ahasenack> ok, figured
<infinity> I assume it's already rewriting amd64, or that also wouldn't work.
<infinity> But it shouldn't be using uname at all.
<ahasenack> oh yeah, I didn't even see x86_64 in there, thanks for pointing that out
<ahasenack> I'm doing amd64/i386 in postinst, as reported by dpkg --print-architecture
<infinity> Okay, so, that said, I'm not sure we want to "fix" that part of the bug if we're also fixing the mirrors.
<ahasenack> I think we will want to make it clear what's supported and what isn't
<infinity> I think the client warning about lack of support on !x86 is fine, but having the enabling behaviour be the same on all is less hassle.
<infinity> Plus, it means we can selectively push some stuff to !x86 if we really want.
<infinity> (Well, not really, but sort of)
<ahasenack> infinity: in any case, the good names are i386 and amd64, right?
<ahasenack> as reported by dpkg --print-architecture
<infinity> The experiment we were going to try for the mirrors was to mirror tzdata and distro-info-data to all arches.
<ahasenack> I haven't heard back from that rt yet, I asked if we have a staging repo to test the idea with
<infinity> ahasenack: Yeah, using uname to determine userspace arch is always wrong.  Always use the package manager's view.
<infinity> ahasenack: I was told they'd work on it "Monday morning", which is vaguely nowish.
<ahasenack> somewhere, yes :)
<ahasenack> US holiday too
<infinity> ahasenack: It's a bank holiday here, so I've not been working, but I'm keeping an eye on things.
<infinity> Oh, it's possible that it's also a holiday for the GSA who said he'd do it Monday, not realising what day Monday was...
<ahasenack> ./uaclient/util.py:    platform_info["arch"] = uname.machine
<ahasenack> :/
<infinity> Gross.
<ahasenack> wonder how this is working since the contract server uses "amd64"
<ahasenack> ah, no
<infinity> They might rewrite it elsewhere.
<ahasenack> the contract server is using x86_64
<infinity> Or that.  Also gross.
<infinity> I mean, I can see the urge to do that because x86_64 is how the modern world refers to amd64.
<infinity> But that should STILL use dpkg arch, then rewrite to x86_64, if that's what they want.
<infinity> Cause uname is never guaranteed to match userspace.
<infinity> (i386 or armhf chroots on amd64 or arm64 hosts, just for starters, but there are any number of ways to make them not match)
<ahasenack> yeah
<infinity> os.system("dpkg --print-architecture | sed 's/amd64/x86_64/'") would likely get what they want.
<infinity> Might also need to trim the newline.
<infinity> Or, not os.system.  os.popen.  Derp.
<infinity> os.popen("dpkg --print-architecture | sed 's/amd64/x86_64/'").read().rstrip()
<infinity> ahasenack: ^-- I'd replace the uname.machine with that.
<infinity> Maybe do the sed as a python regex instead for people who hate forking more than they need to, but whatever.
<ahasenack> we can change this on either side, server or client
<ahasenack> server is using a mix of old and new
<ahasenack> server is using i386 and x86_64
<infinity> If the use of x86_64 was intentional to be "less confusing" to people who don't know what amd64 means, I could see that.
<infinity> But yeah, if not, one could fix the server.
<infinity> Client needs fixing either way though, so...
<ahasenack> infinity: dpkg --print-architecture uses the first column of /usr/share/dpkg/cputable?
<ahasenack> "<Debian name>"
<ahasenack> hm, no armhf there
<infinity> ahasenack: Trying to interpret how dpkg uses those tables isn't really a path to sanity.  dpkg itself is the authority on its primary arch, don't reinvent that wheel.
<ahasenack> I wasn't going to parse that, just checking which other names we might have wrong without booting up an instance in each one
<infinity> ahasenack: 'rmadison coreutils' is always a good source of 'what dpkg arches do we have'. :)
<ahasenack> ah, those names match --print-architecture? ok
<infinity> ahasenack: If you want to know which ones will mismatch with uname, the answer is "most of them".
<infinity> powerpc == ppc or ppc64, ppc64el == ppc64le, armhf == amrv7l, i386 == i686, arm64 == aarch64, s390x might actually match, I don't recall now.
<infinity> But yeah, uname bad.
<ahasenack> yeah, this need fixing
<ahasenack> now it was just x86 that bit us
<infinity> If we could go back in time and do it all over again, I suspect there are lots of people that would prefer dpkg arches (mostly) match kernel arches, but honestly, I think that would just muddy the waters further.
<infinity> Since, (a) some kernels can run multiple ABIs, and (b) kernel and userspace are never guaranteed to match.
<infinity> So, having almost all the dpkg arches mismatch is almost helpful. :P
<infinity> Forces people to think a bit about which arch they're really interested in, kernel or userspace.
<infinity> It would arguably be nice if there was some read-only file somewhere that just had the userspace arch in it, though, instead of having to fork a binary.
<infinity> Multiarch complicates even that simple wish, though.
<xnox> infinity:  s390x matches
<infinity> One of the few. :P
<infinity> Possibly the only Ubuntu arch that matches, actually.
<ahasenack> ppc64el also matches
<infinity> ahasenack: No it doesn't.
<ahasenack> I just checked uname -m and dpkg --print-architecture on a ppc64el instance
<infinity> ahasenack: kernel arch is 'le', userspace is 'el'.
<ahasenack> oh!
<ahasenack> my eyes
<ahasenack> oh man
<ahasenack> w.t.<badford>
<ahasenack> word even
<infinity> BADFORD
<ahasenack> :)
<ahasenack> little endian, and... endian little?
<infinity> Yeah, you can blame me (and Debian history) for that.
<ahasenack> did they apply endianness twice?
<infinity> It was a fun "joke" in Debian history when doing endian flips (I think mips might have been the first, but also arm later) where we had be on way and el the other.
<infinity> I did ppc64el that way to match mipsel and armel.
<infinity> But upstream chose ppc64le for the kernel, so here we are.
<infinity> Again, don't really mind, the mismatch serves a strangely useful purpose.
<ahasenack> haha
<infinity> The original upstream kernels were just ppc64 (cause, really, they are), but Other Parties who love to use uname for evil purposes whined that it should be unique.
<infinity> Fun side-note, you can endian-flip POWER8 and above at runtime.  In the same address space.
<infinity> It's mind-bending.
#ubuntu-devel 2019-11-12
<Unit193> seb128: I guess I'm curious, not that it matters.  What specific feature of the new libshout were you looking at?
<cpaelzer> doko: asyncpg doesn't look too good for now
<cpaelzer> doko: I ahve updated bug 1850136 as well as the Debian bug that you opened as well as an upstream issue
<ubottu> bug 1850136 in asyncpg (Ubuntu) "FTBFS in Focal with PG-12 present" [Undecided,Confirmed] https://launchpad.net/bugs/1850136
<cpaelzer> there are MRs open but I'm not convinced that we ahve to fix their py3.8/cython compatibility
<cpaelzer> I'm not sure if this is just a "lets wait and see" or a "lets work on removing it" case
<doko> cpaelzer: it's not blocking anything for now, until we make 3.8 the default
<cpaelzer> doko: I'd be interested to hear what you think on this case
<doko> except for pg itself
<cpaelzer> doko: it is not even blocking pg itself as it has no autopkgtest to do so
<cpaelzer> pg-12 migrated a few days ago btw, just postgresql-common is still on the list (tests of 11 packages to go, 12 former fails done)
<cpaelzer> I see in focal is still asyncpg 0.13 and in f-proposed is 0.18
<cpaelzer> IMHO that will need upstream to rlease a 0.20 with py3.8 compatibility and then getting this into focal
<cpaelzer> doko: I'm keeping a watch on these asyncpg bugs/issues but will stop to actively work on it for a while to give upstream a chance to get py3.8 support
<cpaelzer> that means it will hang in -proposed for quite some time I guess
<doko> sure, the alternative would be to just build for the default python3 to let it migrate
<doko> then you get the testing for 0.18
<doko> rbalint, mwhudson, ginggs: please let's coordinate further py3 work here.
<doko> rbalint is looking at python-motor and python-taskflow afaik
<doko> pygame needs an update to 1.9.6, but I didn't figure out how to create the debian .orig
<doko> python-oslo.utils, jamespage wanted to have a look, but he's currently traveling
<doko> i3pystatus, no progress yet
<doko> after that, maybe try to get pytest migrating, having different versions of test frameworks in use is odd
<doko> and dask is a numpy issue, afaics. rebecca commented in some bug
<doko> and I'm taking a day off tomorrow
<mwhudson> doko: i'll try to stare at pytest for a bit
#ubuntu-devel 2019-11-13
 * mwhudson rubs eyes
<mwhudson> i think the python2 pytest in proposed is totally broken
<Unit193> Hopefully not with sand.
<mwhudson> Unit193: this python3.8 transition has been a bit like that
<Unit193> Yeah, all paths changing is...Not ideal.
<mwhudson> ok not completely completely broken
<sarnold> just "python version update" broken
<mwhudson> doko: a bunch of the pytest autopkgtests failed because of a strange pkg_resources problem that doesn't seem to happen any more so i've retried those
<mwhudson> does anyone want to remove the python2 autopkgtest from python-qtpy?
 * mwhudson falls asleep
<cpaelzer> ahasenack: there are new versions of  patroni and pgrouting which are part of the open pg12 issues
<cpaelzer> ahasenack: I have triggered tests using the new pg-common and pg-12
<cpaelzer> maybe that resolves those two
<cpaelzer> there also is a new pglogical-ticker, I guess that will be my next merge ...
<cpaelzer> nice, the only delta we had was by me, is accepted upstream and in the new debian version
<cpaelzer> so it is in fact a sync now
<cpaelzer> syncing and triggering tests later, maybe doing a test build and test before ...
<matttbe> Hello! I am using Ubuntu Focal and I am surprised to see that Git is 4 versions behind the latest one. The version in 20.04 repo is 2.20.1-2ubuntu1 since Disco while the latest (2.24) is available in Debian testing. I didn't find any reason, "excuse" tag, nor build failures explaining why v2.24 is not available in Ubuntu repos. May you guide me where I can find explanations to know why some popular softwares are not updated?
<matttbe> In fact, I would like to validate that some scripts I have using Git can still work with the latest version of Git.
<matttbe> I understand that many tools are depending on Git and updating it can be difficult. Maybe it cannot be upgraded because some build systems rely on it and are not compatible with more recent versions? :)
<rbalint> doko i suggest dropping python-motor from release to get python3-defaults in, i've fixed part of the regression, but waiting for upstream on this one: https://jira.mongodb.org/browse/MOTOR-460
<rbalint> doko python-taskflow is done
<cjwatson> matttbe: In general anything with Ubuntu modifications doesn't get automatically updated until a developer goes and looks at the Ubuntu-specific modifications to decide whether they need to be forward-ported or can just be dropped.
<cjwatson> matttbe: That is probably the case here.
<cjwatson> jbicha: ^- the delta to git is yours and I think it probably needs a merge - is this on your list?
<matttbe> cjwatson: thank you for your reply. I will then check with the Ubuntu maintainers :)
<cjwatson> matttbe: I've just checked above with the person who made the change in question
<matttbe> cjwatson, thank you for that!
<jbicha> cjwatson: git's not on my list. See also Debian bug 911997 ð¢
<ubottu> Debian bug 911997 in src:git "git: Apply diff from Ubuntu" [Normal,Open] http://bugs.debian.org/911997
<cjwatson> jbicha: merges.u.c thinks it should be on your list :)
<jbicha> cjwatson: hire me for the Foundations team and then I'll make sure it's on my list :)
<cjwatson> jbicha: I haven't been on Foundations in some years ;-)
<cjwatson> jbicha: Should I take this as it being OK for me to do the merge?
<jbicha> please go ahead :)
<cjwatson> OK
<matttbe> cjwatson: thank you for your help :-)
<cpaelzer> ahasenack: pglogical-ticker delta is in upstream and builds fine, it won't resolve the PG12 test issue but making it a sync will help to pick it up automatically once it gets a PG12 upload in Debian
<cpaelzer> I also pinged Myon for those that are left open
<cpaelzer> maybe he already ahs a lead on some of them
<doko> rbalint: \o/
<Skuggen> matttbe: If you want to test, you could use something like https://launchpad.net/~git-core/+archive/ubuntu/ppa for now, maybe?
<mdeslaur> Skuggen: the mysql on s390x hang turned out to be an openssl issue
<mdeslaur> Skuggen: https://git.openssl.org/?p=openssl.git;a=commit;h=e1cce612a6520555805c25be2539f231c22696d9
<Skuggen> mdeslaur: Oh!
<Skuggen> Good (sort of) :)
<mdeslaur> yeah, unfortunate combo of openssl bug and the way mysql initializes it
<Skuggen> If the bug title "incorrect call to openssl_malloc_init() can lead..." is accurate, maybe MySQL is doing something wrong with the call?
<doko> mwhudson: done by ginggs
<Skuggen> Maybe we still need to call it to support older platforms (8.0 doesn't seem to use it, but we dropped some older platforms for that) with lots of fiddly conditionals
<mdeslaur> Skuggen: yeah, it got dropped in 8.0...I'm note sure what the impact of removing it is...upstream bug seems to hint that it's unnecessary
<mdeslaur> Skuggen: in any case, I'm fixing bionic's openssl, so it shouldn't happen anymore
<cjwatson> matttbe_: on its way into focal now
<cjwatson> (modulo builds, tests, regression tests against other packages ...)
<Skuggen> mdeslaur: Seems it got dropped for 8.0 because we had the same issue there on Windows, but on 5.7 (where we only use static linking for openssl) we went straight from 1.0.2 to the 1.1.1 with this issue fixed
<matttbe_> Skuggen: thank you for the suggestion! I was going to use the PPA but I was also wondering why it was not in the main repos (did we lost track of it or did the new versions introduce severe regressions, even if it would have been strange :) )
<mdeslaur> Skuggen: cool
<matttbe_> cjwatson: excellent, thank you for the very quick update :-)
<ahasenack> Skuggen: hi, did you see those bugs where a config parameter that worked in 5.7 no longer works in 8.0, which fails to start after the upgrade?
<ahasenack> I was wondering if it was expected that the 8 package remove those config options, or replace them
<ahasenack> so far I've seen two such config options
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1850998 and https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1850895
<ubottu> Launchpad bug 1850998 in mysql-8.0 (Ubuntu) "NO_AUTO_CREATE_USER removed in mysql-8, broke upgrade" [Undecided,Confirmed]
<ubottu> Launchpad bug 1850895 in mysql-8.0 (Ubuntu) "query_cache_limit removed in mysql-8, upgrade broke" [Undecided,Incomplete]
<Skuggen> ahasenack: Ah, sorry, I looked for it shortly after you mentioned it before, but didn't see it and then it slipped my mind. Will  take a look now
<ahasenack> Skuggen: thanks! I renamed the bug title a bit to indicate what each one is about
<Skuggen> NO_AUTO_CREATE_USER has been removed because the ability to use GRANT to create users has been removed (so it has no use): https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html
<Skuggen> Query cache has also been removed
<Skuggen> Was the query cache setting in the default config file? We have some logic in the packaging to comment out some query_cache settings since they were in the default 5.7 config (we did something similar for the 5.5->5.7 transition)
<Skuggen> https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/ (it's also mentioned briefly on the nutshell page)
<ahasenack> Skuggen: there is nothing about query_cache_limit in debian/**
<Skuggen> https://salsa.debian.org/mariadb-team/mysql/blob/mysql-5.7/debian/master/debian/additions/mysql.conf.d/mysqld.cnf#L60
<Skuggen> That might be a packaging bug
<Skuggen> https://salsa.debian.org/mariadb-team/mysql/blob/mysql-8.0/ubuntu/devel/debian/mysql-server-8.0.postinst#L116 is a hack to deal with it (for focal I'd like to strip away|comment as much of the default config as possible, to avoid problems like this in the future)
<Skuggen> Oh! It looks like your config is in /etc/mysql/my.cnf instead of /etc/mysql/mysql.conf.d/mysqld.cnf as we expect?
<ahasenack> Skuggen: I think there are commented lines suggesting the user could use my.cnf
<ahasenack> Skuggen: all those config files for mysql are very confusing, there are several
<Skuggen> The server by default uses /etc/mysql/my.cnf
<Skuggen> Yeah, it's an ancient mess which I think was just put in place because MariaDB and MySQL use the same files
<ahasenack> so postinst handles it if it was in a particular config file?
<Skuggen> Yeah
<ahasenack> is that the case for other deprecated config options as well? Not just for the 5.7->8 upgrade path
<Skuggen> It just comments it out with an extra line with something like "this option was automatically commented out because it is no longer valid"
<Skuggen> Just the ones that are in the default Ubuntu 5.7 config file
<ahasenack> I mean, from other major upgrades, was postinst always only concerned with one particular config file?
<Skuggen> Yeah, the 5.7 postinst handled it the same way
<Skuggen> There's a mechanism to help support users, but I see now we haven't properly updated it for 8.0:
<ahasenack> is it worth it to look at other config files? Or too messy and error prone, since users can include stuff from anywhere?
<Skuggen> Yeah, the MySQL config system is too tangled. You can ask MySQL which settings it's using, but not where they're coming from
<Skuggen> But we run mysqld --verbose --help as a "trial" startup to detect bad config. However that only works for 5.7. 8.0 now has a proper --validate-config flag
<ahasenack> that wouldn't make the upgrade work in the end, though
<Skuggen> No
<ahasenack> so option is "sorry, it's a valid bug, but we only try to upgrade config file X"?
<ahasenack> or should we look at least at /etc/mysql/my.cnf as well? Is that historically the main config file?
<ahasenack> or is it shared with mariadb?
<Skuggen> /etc/mysql/my.cnf is shared with maria, yes
<Skuggen> So by default all it does is include the variant-specific locations
<ahasenack> but this guy had his actual config in it?
<Skuggen> It looks a bit like he's been upgrading since at least 5.5 (Ubuntu 14 or older)
<Skuggen> His config file contains the lines the 5.7 postinst would add to the settings removed between 5.5 and 5.7
<Skuggen> For the 5.7 transition I think we had a catch-all bug for issues with invalid configuration, which just instructed users in fixing it
<ahasenack> cpaelzer: where are the mysql standard/template bugs again? The list?
<Skuggen> https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1571865
<ubottu> Launchpad bug 1571865 in mysql-5.7 (Ubuntu Xenial) "mysql fails to start after upgrade if previous defaults were customised" [High,Fix released]
<ahasenack> shouldn't dupe to a fix released bug
<ahasenack> we can say opinion or wontfix if we think it's not worth fixing
<Skuggen> Yeah, don't think we should revive that issue, but it has a discussion on many of the same things
<ahasenack> can you add a comment then saying we do handle the upgrade if the config file is X, but that we can't chase down all possible config files? Something like that? What do you think?
<Skuggen> Yeah, I'll do that
<ahasenack> ok, and the other bug about NO_AUTO_CREATE_USER ? Is there handling for that?
<Skuggen> Just remove the option from sql_mode
<Skuggen> That is not part of any default config
<ahasenack> ah, we only take care of the default config, makes sense
<Skuggen> Yeah. MySQL has something like 400 flags that can be set :D
<cpaelzer> ahasenack: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bugs?&field.tag=triage
<ahasenack> cpaelzer: thanks
<Skuggen> Ah, 1612517
<ahasenack> Skuggen: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1612517
<ubottu> Launchpad bug 1612517 in mysql-5.7 (Ubuntu) "Server fails to start after upgrade because of customized config and obsolete/renamed directives" [Medium,Confirmed]
<ahasenack> yep, just saw it
<ahasenack> but postinst is better now, it handles some cases
<Skuggen> https://dev.mysql.com/doc/refman/8.0/en/server-option-variable-reference.html would be the correct link to use instead of the 5.7 one listed there, I think
<ahasenack> by "custom configs", you actually mean two possibilities there: a) different config file; b) non-default config option
<Skuggen> Right
<Skuggen> If /etc/mysql/mysql.conf.d/mysqld.cnf from a 5.7 installation hasn't been altered by the user it'll just be replaced
<Skuggen> But if they edit it or add a new one (any .cnf files in that directory will be used) they can get this issue
<ahasenack> ok
<ahasenack> Skuggen: ok, I think we can dupe #1850895 to #1612517, wdyt?
<Skuggen> Yeah. Should be updated to affect 8.0, I guess?
<ahasenack> I updated the description a bit
<ahasenack> but yeah, let's add a myusql-8 task to it
<Skuggen> It probably isn't relevant for 5.7 any more unless there are still people upgrading from trusty
<ahasenack> but if we aren't planning on fixing it, maybe it should be a wontfix or opinion bug?
<ahasenack> I'm not sure
<ahasenack> there are
<ahasenack> (people upgrading from trusty)
<ahasenack> ok, done (dupes)
<Skuggen> Yeah, right now it's working as intended (until we can think of a robust way to do more)
<ahasenack> thanks Skuggen
<Skuggen> np :)
<kanashiro> doko, I am working on libpam-radius-auth merge and the only delta we have now is the addition of the build flag -fno-strict-aliasing added by you. If it's possible I'd like to know if this flag is still needed and why?
<vorlon> didrocks: LP: #1852256 is definitely filed in the wrong place, I wonder if Desktop wants to triage it a bit (not enough info to say if this is a desktop or kernel issue)
<ubottu> Launchpad bug 1852256 in Ubuntu CD Images "Ubuntu ne s'ouvre plus aprÃ¨s update" [Undecided,New] https://launchpad.net/bugs/1852256
<didrocks> vorlon: I doubt we can do anything about that bug, really vague and "I didn't do anything special". The user says that he is deleting it and reinstalling
<didrocks> (posting once launchpad stops timeouting)
<vorlon> didrocks: indeed.  I just didn't know if there was a good generic place to reassign such bugs, since ubuntu-cdimage is wrong
<doko> kanashiro: are you asking me about an upload from 2008? ;p
<doko> seriously, check for warnings in the build logs
<kanashiro> doko, no need to use a time machine :) I checked the logs and there is no warning related to this, I'll request a sync from Debian. Thanks
<mwhudson> ginggs: thanks :)
<ginggs> mwhudson: yw! i did python-qtawesome too
<mwhudson> ginggs: thanks
<mwhudson> pytest autopkgtest results looking a bunch happier now
<Laney> cpaelzer: hey, can you re-check https://bugs.launchpad.net/ubuntu/+source/tpm2-tss/+bug/1841595 please? superm1 says all the issues should be resolved & it's now blocking fwupd from migrating
<ubottu> Launchpad bug 1841595 in tpm2-tss (Ubuntu) "[MIR] tpm2-tss" [Undecided,Confirmed]
#ubuntu-devel 2019-11-14
<DarkTrick> Hello
<DarkTrick> I would like to go into Ubuntu programming. Particularly I'd like to be able to work on distribution development (e.g. Filemanager, ... )
<DarkTrick> I'm diving into GTK for a while, but I miss getting the whole image.
<DarkTrick> X-Window-System, GDK, DBus, configs, ....
<DarkTrick> Question:
<DarkTrick> Is there any book(online/offline), that rounds everything up , not too detailed, not too rough ?
<sarnold> DarkTrick: probably all those topics are far too much for one book
<sarnold> DarkTrick: I've just skimmed this for thirty seconds but it looks like it's probably a reasonable enuogh intro to a subset https://people.gnome.org/~swilmet/glib-gtk-dev-platform.pdf
<DarkTrick> sarnold, thank you for the link
<DarkTrick> I didn't know there was a 2019 version!
<sarnold> that's one of the hard parts, there's a lot from 20 years ago .. hehe
<DarkTrick> I liked the 2017 already. Maybe a reread helps :)
<sarnold> oh nice
<sarnold> this is one of my all-time favourite programming books, but it's unlikely to cover anyu of what you asked :) http://www.apuebook.com/
<DarkTrick> sarnold, I will check it out! Thank you very much!
<DarkTrick> I feel like in the jungle of information, where it's hard to get the needed one.
<sarnold> DarkTrick: indeed, there's no way one person can know everything
<mwhudson> not sure what i think about autopkgtests failing on stderr by default
<The_LoudSpeaker> where do I find the source code of the captive portal detector in ubuntu?
<sarnold> The_LoudSpeaker: I believe that's a feature of networkmanager
<The_LoudSpeaker> it must have its source code somewhere na?
<Unit193> sarnold: It is.
<sarnold> The_LoudSpeaker: if your deb-src lines are configured correctly, apt-get source network-manager will retrieve it
<sarnold> Unit193: woo :)
<The_LoudSpeaker> sarnold: okay. I will check.
<The_LoudSpeaker> Thanks!
<Unit193> The_LoudSpeaker: You..You guys are trying to re-invent the wheel again?  Why?  Just use (https://sources.debian.org/src/xfce4-session/4.14.0-1/debian/patches/0002-use-xscreensaver-through-the-wrapper-it-ships.patch/) the xscreensaver wrapper (https://sources.debian.org/src/xscreensaver/5.42+dfsg1-1/debian/xscreensaver-wrapper.sh/) and not risk breaking it for everyone else...
<tarzeau> can someone with ubuntu 18.04 lts apt install sextractor, and confirm it behaves like: https://bugs.launchpad.net/ubuntu/+source/sextractor/+bug/1852535
<ubottu> Launchpad bug 1852535 in sextractor (Ubuntu) "symbol lookup error" [Undecided,New]
<cpaelzer> Laney: yes I'll look for tpm2-tss again
<cpaelzer> LocutusOfBorg: what exactly would I build of in 1840749 actually?
<cpaelzer> I can't even identify 5.2.18 in https://github.com/mirror/vbox or https://www.virtualbox.org/browser/vbox/trunk
<cpaelzer> I guess I need to page-fault my forgotten svn foo back in .. :-/
<cpaelzer> but if there is an easier way let me know
<LocutusOfBorg> cpaelzer, would you mind joining vbox-dev irc channel here on freenode?
<LocutusOfBorg> they might already have test builds
<CarlFK> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/SHA512SUMS  has ...818dc6f301e  debian-10.1.0-amd64-netinst.iso  - I curl |cut...| and I have 10.1.0  which I can use to construct debian-10.1.0-amd64-netinst.iso
<CarlFK> is there something similar where given either 18.04 or bionic I can construct cdimage.ubuntu.com/releases/18.04.3/release/ubuntu-18.04.3-server-amd64.iso
<CarlFK> I have a script that wgets files needed to make a usb installer - it is a pain to have to manually look up what the point release is (the .3 in 18.04.3)
<rafaeldtinoco> xnox: for when you're back, do you remember, by any chance, why you added --force-depends to fix autopkgtest on ubuntu cloud VMs (crmsh package). i'd like to remove that delta if possible. (debian/tests/utils.sh).
<infinity> rafaeldtinoco: You can see the red Xs going green here: http://autopkgtest.ubuntu.com/packages/c/crmsh/bionic/amd64
<rafaeldtinoco> autopkgtest [07:29:31]: ERROR: erroneous package: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U.
<rafaeldtinoco> I see.
<infinity> + dpkg --purge vim
<infinity> dpkg: dependency problems prevent removal of vim:
<infinity>  ubuntu-server depends on vim.
<infinity> Now, arguably, our autopkgtest VMs shouldn't have that metapackage in the first place.
<infinity> And, indeed, current ones don't.
<infinity> So we probably don't need that delta anymore.
<rafaeldtinoco> awesome!
<infinity> More recent runs show:
<infinity> + dpkg --force-depends --purge vim
<infinity> dpkg: warning: ignoring request to remove vim which isn't installed
<rafaeldtinoco> i see what you mean now
<rafaeldtinoco> i should have checked that =). i was going to try bileto and reproduce but couldnt get rights yet
<rafaeldtinoco> tks!
<infinity> I'll just drop that bit of the delta and upload.  No need to keep the cruft now that our VM images seem approrpriately slimmer.
<rafaeldtinoco> infinity: i have an ongoing merge
<rafaeldtinoco> https://code.launchpad.net/~ubuntu-server-ha/ubuntu/+source/crmsh/+git/crmsh/+merge/375457
<infinity> Oh, or you do that there instead.  Sure. :)
<rafaeldtinoco> great. thx a lot
#ubuntu-devel 2019-11-15
<cpaelzer> hiho, did we change tests in Focal to no more install "Recommends" ?
<cpaelzer> autopkgtests I mean
<cpaelzer> If I sapwn an autopkgtest I see a recommends not installed, but if I log into the same env and do "apt install" it consideres recommends - so it is not that there would be a conffile
<cpaelzer> seems to be special to the autopkgetest package install
<cpaelzer> for the deps that come out pf d/t/control
<cpaelzer> bad https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal-ci-train-ppa-service-3838/focal/amd64/s/strongswan/20191114_160816_8b50b@/log.gz good https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/strongswan/20191115_065554_930e1@/log.gz
<cpaelzer> testcase name "daemon"
<cpaelzer> package I wonder behaving differently is "strongswan-charon"
<cpaelzer> odd, both run today/tonight so they should behave the same right?
<cpaelzer> locally the issue reproduces with old and new (test ppa) binaries
<cpaelzer> the fix for this case is clear, it should be a harder dependency anyway - but I wonder what I'm missing on those two test excutions to make them behave so differently
<cpaelzer> hmm, is something going on with the builders atm, there are plenty free ones but it started to get (a small) queue
<cpaelzer> cjwatson: wgrant: Laney: highlighting you just because you all usually know about the status of the builders ^^
<cpaelzer> nothing urgent at all, just wondering
<cpaelzer> FYI: builders picked things up - so things seem to work (although at a slight delay maybe?)
<cjwatson> cpaelzer: That happens sometimes.  Nothing sinister AFAICS; there was a batch of language pack updates which usually cause a brief spike.
<cjwatson> cpaelzer: Also, small queue reported on /builders even though there are free builders means private packages waiting for publication before they can build.
<cjwatson> cpaelzer: Nothing you need to worry about.
<cpaelzer> great, good to know - thanks cjwatson
<The_LoudSpeaker> Unit193: I just saw the patch. It says it conditionally uses dm-tool or gdmflexiserver. The problem is, we don't have dm-tool. It comes with lightdm afaik. Correct me if I am wrong but I don't see dm-tool with sddm. Nor do I see gdmflexiserver.
<The_LoudSpeaker> Sorry for late reply. irssinotifier didn't start again on reboot.
<Unit193> I don't know sddm, if there's a good way to detect use and a tool in sddm to do the same, add it to the wrapper in Debian and then start using it.  That way everyone benefits.
<The_LoudSpeaker> Yup! Running dm-tool -v on Elementary OS gives it as lightdm 1.26.0
<The_LoudSpeaker> Okay. I will add it to wrapper and then use it once I find it.
<The_LoudSpeaker> I asked #sddm those folks said there's a dbus we can use. I am trying to find out exactly which one.
<Unit193> There's "support" for kdm in there, it seems the KDE/etc people don't care too much about it. :P
<The_LoudSpeaker> Kde doesn't use screensaver. I pinged them once. I will ping again. :)
<The_LoudSpeaker> *xscreensaver
<Unit193> Heh, certainly not, KDM is long gone from what I know. :P
<mdeslaur> rbasak, Skuggen: FYI, the wordpress setup script in eoan and focal needs updating for mysql 8.0: bug 1852775
<ubottu> bug 1852775 in wordpress (Ubuntu) "setup script needs fix for MySQL 8.0" [Undecided,New] https://launchpad.net/bugs/1852775
<Skuggen> mdeslaur: Ah, thanks. Looks like the same GRANT ... IDENTIFIED BY issue we've seen for some other packages as well
<vorlon> doko: fwiw your py2-d-u-diff.sh seems to truncate some things (or else the report its pulling from does), software-center-aptdaemon-plugins is truncated as software-center-aptdaemon-
#ubuntu-devel 2019-11-16
<tjaalton> swap on zfs as created on eoan zfs install seems to kill interactivity when the system uses swap
<tjaalton> is this known?
<tjaalton> swapoff /dev/zd0 makes it behave better
<infinity> tjaalton: eoan doesn't swap on zfs, you installed from a pre-release image.
<infinity> tjaalton: We changed it during release week for that very reason.
<tjaalton> infinity: oh dang
<tjaalton> what does it do now?
<tjaalton> with the release image
<tjaalton> oh, a swap partition
<tjaalton> guess I'll just put moar ram on this
#ubuntu-devel 2019-11-17
<croraf24> Hi, where can I see the commits from the yesterdays daily build up to todays?
