#ubuntu-devel 2005-05-09
<Simira> come on guys! Time to get up and moving!
<tseng> gosh
<tseng> im up
<Simira> you seem somewhat lonely to me, tseng ;)
<tseng> everyone else is still in at breakfast
<tseng> slow eaters.
<Simira> hm. Tollef is not a slow eater. Just a large-eater :p
<tseng> tollef is a sleepy head
<Simira> he's sick, poor boy!
<tseng> :(
<Simira> physically, I mean.
<dilinger> d'oh
<Simira> it's your airconditioning, I think
<dilinger> apparently making suggestions at a BOF that you're not actually attending, but just happened to spring up around you, gets you listed as a Key Person
<tseng> dilinger: rock on.
<Simira> yay
<tseng> dilinger: i think jane and the gang are being really cool about scheduling, all things considered
<Simira> jane and the gang, actually :)
<tseng> hm?
* Simira misses Tollef a lot and lot and lot
<tseng> any idea what UBB is?
<Simira> Ubuntu Breezy Bounties?
<Simira> No idea
<tseng> oh, good call
<dilinger> tseng: yea, i haven't had any complaints really
<dilinger> other than two things being scheduled at the same time that i was interested in, but i didn't mark myself interested in the wiki, so that's my own fault
<tseng> dilinger: http://pearls.tuxedo-es.org/patches/security/linking-protections-2.6.11-rc3.patch is the trulux patch
<tseng> dilinger: he stuck it in namei.c
<tseng> dilinger: and it has no sysctl
<tseng> or actually, even a build option
<dilinger> yea, i noticed the lack of sysctl
<tseng> we cant make it always on.
<dilinger> tseng: he said they're disabled via arguments passed to the module and sysfs
<tseng> um.
<dilinger> (again, i just skimmed through, so i didn't verify)
<tseng> there must be more to the patch then
<tseng> there is no bit for Kconfig or anything to even make it a module
<tseng> id rather make it work just like spenders copy
<Unfrgiven> good morning tseng!
<tseng> hey dude
<Unfrgiven> how are we this morning?
<tseng> fine thanks
<tseng> we have a "getting involved in universe" bof today
<tseng> so we can pick up from yesterday
<Unfrgiven> yeah ill b there for sure
<Unfrgiven> i was up past 3 trying to get dpatch to work... no luck :(
<Unfrgiven> i even read ur blog
<tseng> ill show you later, its easy
<Unfrgiven> tseng: my problem is that pbuilder doesnt seem to apply the patch
<Unfrgiven> anyways no matter... ill see you there
<Unfrgiven> im gonna go get ready
<Unfrgiven> cya
<tseng> yes, we'll look later
<tseng> Simira: tollef is here and looking chipper!
<Simira> tseng: without me? Hm... what's he been up to, I wonder...
<Simira> tseng: give him a kick to get online, then :)
<Simira> tseng: he'd probably good  use for a long night's sleep, then. :-)
<dholbach> morning
<Simira> morning Sydney
<jsgotangco> good morning
<tseng> hi.
<jammcq_oz> Riddell: hey, does kubuntu use kdm instead of gdm?
<Burgundavia> jammcq_oz, you can choose either is you do an install on an Ubuntu box
<mdke> jammcq_oz, #kubuntu
<jammcq_oz> tanks
<mdke> hi smurfix 
* smurfix waves
<mdke> smurfix, how is the locoteam stuff coming along?
<dilinger> i'm hitting the mentos early this morning..
<tfheen> cc: any reason why SpecProcess is both Draft and Edited?
<fabbione> pitti: you around?
<pitti> fabbione: yeah
<pitti> fabbione: sublime 3
<cc> tfheen: oversight, lets get it fixed
<Riddell> jammcq_oz: yes it uses KDM of course
<fabbione> pitti: gamin inotify backend is broken. Once i upload the new kernel with inotify, half of the apps using fam7gam will break
<tfheen> cc: ok, it's edited?  I'll change it, put it in the queue
<fabbione> pitti: i suggest to temporary disable it in gamin
<tfheen> s/, / and /
<smurfix> mdke: EditedSpec, I cleaned up the last outstanding issuses last night
<fabbione> pitti: mind if i do the upload?
<pitti> fabbione: of course not :-)
<fabbione> pitti: or do you want to do it?
<cc> tfheen: yeah it is
<fabbione> pitti: ok thanks
<pitti> fabbione: I won't upload until next week
<mdke> smurfix, come again?
<tfheen> cc: ok, thanks.
<smurfix> mdke you wanted to know about the locoteam stuff
<mdke> smurfix, yeah just that your answer went a bit over my head
<mdke> ;)
<smurfix> mdke: http://udu.wiki.ubuntu.com/LoCoTeamProcess
<mdke> ty
<pitti> thom: here?
<thom> pitti: not if i can help it
<pitti> thom: which package contains the default firefox page?
<tfheen> ubuntu-artwork, I think
<pitti> tfheen: that's what I hoped :-)
<mdke> it definitely used to be in ubuntu-artwork
<thom> ubuntu-artwork
<pitti> thom: the translations, too?
<thom> what translations?
<pitti> thom: okay, thanks :-)
<mdke> pitti, did anyone chat to you about getting documentation into the language-packs?
<pitti> mdke: into the language-support packages at most; we covered the topic briefly yesterday, but we will flesh it out in today's bof
<mdke> cool
<mdke> see if you can get jsgotangco along :)
<jsgotangco> what time is that
<mdke> *laughs*
<mdke> poor jsgotangco 
<jsgotangco> grrr
<jsgotangco> i havent been sleeping well lately
<mdke> pitti, i discussed it briefly with mdz and he was keen, but i understand it will be quite difficul
<mdke> at the moment we are sticking translations into ubuntu-docs but its all a little bit improvised
<pitti> mdke: can you come to today's BoF?
<fabbione> pitti: gamin on the way
<pitti> rock
<mdke> pitti, other side of the worl
<mdke> d
<pitti> thom: ... and the default bookmarks?
<jsgotangco> haha
<mdke> dig a hole straight down, and you'll get to me
<pitti> mdke: I think we developed a pretty good idea yesterday, just needs some fleshing out
<thom> pitti: individual packages
<pitti> thom: that means in m-ffox and so on?
<mdke> pitti, by the way that firefox default page is the same as about-ubuntu isn't it? we have some translations of that
<thom> yeah
<mdke> maybe they could be transposed
<pitti> thom: do you think it would be possible to move them into u-artwork?
<pitti> thom: there must be some sort of dependency already for the startup page anyway?
<pitti> mdke: yeah, but I think we don't use them in hoary
<thom> pitti: possibly
<mpt> That kind of bothers me
<mdke> pitti, ok, if you want them, they are in the docs package ;)
<mpt> MSIE's default home page in OS X isn't "About Windows"
<mpt> er, Windows, sorry
<mdke> its msn ;)
<mpt> and Safari's default home page in OSX isn't "About OS X"
<mpt> Yes, MSIE's is MSN, which lets you search the Web and stuff
* mdke nods
<mpt> and Firefox's is Google, which lets you search the Web and stuff
<mdke> i also agree, there is a prominent about-ubuntu icon in the gnome menu
<mpt> and Safari's is ... what is Safari's?
<mdke> so no real need for the home page
<mpt> I think it's some Apple-branded Netscape.com
<thom> mpt: one of our cases is offline users
<thom> which means a local page
<mpt> http://apple.netscape.com/
<jsgotangco> that is nice
<mdke> what offline stuff does firefox get used for?
<mpt> People, of their own volition, start up Firefox when they're offline?
<thom> mdke: we can't assume our users actually *have* internet connections
<mpt> without intending to go online?
<HrdwrBoB> could be a local netwok
<thom> mpt: totally, all the time
<HrdwrBoB> network
<tfheen> mpt: frequently, yes.
<HrdwrBoB> or documentation
<mdke> thom, agreed, but firefox is for the internet
<mpt> If that's true, that's a bug in Nautilus
<tfheen> I do it to read docs on planes and stuff
<thom> mdke: no, it's for viewing html
<fabbione> pitti: gamin accepted
<jsgotangco> its good for html docs
<jsgotangco> not just for the net
<thom> whether it is online or off
<mdke> thom, i think that people when reading html will open it from nautilus
<mpt> i.e. it's too hard to find the doc in Nautilus and double-click it
<tfheen> or actually, I run mozilla than since I've got session saved in ff.
<jsgotangco> right
<mdke> its really inconvenient to open ff and then go to "file/open"
<mdke> i always open from nautilus
<tfheen> mdke: that does not match how I use it, I use it for browsing for html files.
<mdke> tfheen, fair enough
<thom> mdke: totally disagree, i never use nautilus, i do use firefox offline; we need to support that case, which means no online home page
<tfheen> mdke: I'm not saying both use cases are interesting, but your is not the only one.
<mdke> tfheen, yes i see
<mdke> tfheen, i suppose the solution adopted covers all bases
<mpt> thom: Or, it means having an online home page and incorporating decent fixes for bug 28586 in the Ubuntu Fx package.
<tfheen> mpt: which tracker is that bug # in?
<thom> 28586 does not exist
<tfheen> thom: b.m.o
<tfheen> https://bugzilla.mozilla.org/show_bug.cgi?id=28586
<mdke> is the firefox home page synched with the about ubuntu yelp page?
<mpt> I know that bug number off by heart because I reported it so I can't unsubscribe from it :-)
<mpt> Five years of bugspam
<jsgotangco> haha a bug on the buglist
<fabbione> tfheen, smurfix: aorund 11:30 will come a guy from the local university that is working on xen as upstream/derivate project to talk with me, if you are interested we can meet up in global?
<tfheen> fabbione: rock
<fabbione> tfheen: according to what he wrote me in the mail, it is a really interesting thing they are working on
<tfheen> Kamion: ping?
<cc> tfheen: minu-buntu or mini-buntu?
<tfheen> cc: mini-ubuntu, I think, and buntu would be pronounced microbuntu.
<cc> tfheen: yeah, figured ;-)
<cc> i'l fix it
<tfheen> cc: thanks
<hypatia> I've been calling it mu-buntu ;)
<tfheen> I don't think there are any pronounciation rules for blends of greek and Zulu words.
<cc> anyone see a dr. evil link ?
<tfheen> fabbione: I'm going to be in sublime 2 until 11:30, just ping me if the guy shows up.
<fabbione> tfheen: no problem.. i will
<tfheen> sladen: get up to sublime 2, you're second.
<smurfix> Anybody seen doko / abaxter around?
<fabbione> Kamion: http://linux.slashdot.org/linux/05/04/27/1836227.shtml?tid=189&tid=190&tid=106
<zul> fabbione: someone just ported anaconda
<ogra> zul to ubuntu ?
<zul> gentoo
<ogra> ah, ok...
<odyssey> are packages in main allowed to depend on a package that is in the universe?
<tfheen> no
<seb128> they are not
<odyssey> thats what i though
<seb128> why ?
<odyssey> i cant install libgda2-common from main without libgda2-3 that is in universe
<seb128> don't use breezy
<seb128> it's known to be broken
<odyssey> k
<fabbione> tfheen: want to join us in global?
<tfheen> fabbione: two minutes
<fabbione> ok
<jammcq_oz> pitti: in the audio bof yesterday, did you say that network audio wasn't going to be supported in breezy?
<jammcq_oz> or do we get that for free, with polypaudio?
<d3vic3> http://lists.debian.org/debian-devel/2005/04/msg01048.html
<d3vic3> :)
<d3vic3> *speechless*
<pitti> jammcq_oz: if we switch to polypaudio (very likely), then  you should have reasonable net support
<fabbione> tfheen: time is out: you are the weakest link. kthxbye
<tfheen> thom: could you look at buntu and address cc's comments?  Just steal my lock.
<thom> tfheen: sure
<cc> tfheen, thom: thanks
<tfheen> thom: thanks a lot
<thom> has anyone had breezy-changes mail today?
<|QuaD-> thom: i did earlier on
<jiyuu0> guys.. any inputs?
<jiyuu0> Unofficial UbuntuGuide 5.04 Add-On CD Guide
<jiyuu0> http://www.ubuntuforums.org/showthread.php?p=150651
<Kamion> tfheen: yes?
<Kamion> fabbione: whatever :)
<lifeless> cc: ping
<lifeless> can you please review TlaAndBazBranding ?
<louie_> hello, lifeless
<lifeless> louie_: hi
<lifeless> back home now ?
<Janux> hi, anyone knows how to show chinese characters in the xmms playlist? or music player in Ubuntu?
<tfheen> Kamion: uhm, forgotten what I was going to ask about.
<Kamion> heh
<AndyFitz> http://andy.fitzsimon.com.au/Screenshot.png  maybe ?
<jnc> Janux: 'rhythmbox' *should* do it
<spiv> Hmm?
<spiv> Argh, death lag from hell.
<jnc> hell hath no fury like a server split
<jnc> i give up
<tfheen> daniels: you going to sit around here for a little while?
<tfheen> (it seems to be easier to catch your attention on IRC than RL. :P)
<robertj> heya all, how is udu?
<daniels> tfheen: yes
<louie_> oh, hrm, any opinions on how badly broken current breezy is?
<thom> mucho if you use evo
<Lathiat> and any mono stuf
<jdub> louie_: don't dist-upgrade, just upgrade ;)
* Lathiat wonders how to figure out why nautilus cant find burn:///
<Lathiat> lathiat@archer:~$ cat .xsession-errors |tail -n1
<Lathiat> ...Too much output, ignoring rest...
<louie_> jdub: refresh my atrophied debian brain; what's the difference?
<Lathiat> theres a good debugging feature :)
<jdub> louie_: dist-upgrade will add and remove to satisyf the upgrade
<jdub> louie_: upgrade just does what it can without removing
<louie_> ah
<louie_> right
<Lathiat> what bit me was i had breezy running and then wanted to install evo which i previously had uninstalled :)
<louie_> hrm
<louie_> yeah
<louie_> evo
<tfheen> Kamion: if you're happy with oemrescue, please move the post-it note on the wall and add it to mdz's queue.
<jsgotangco> tseng, ping?
<cc> elmo: ping; launchpad wiki lacks working spell checker; same problem as the udu wiki, so i presume its the same fix (utf-8 blah)
<robertj> oeminstaller seems pretty nice
<robertj> as an idea anyway
<robertj> too bad AFAIK partimage-server is b0rk in hoary
<tfheen> oeminstaller is basically a nice wrapper around dd
<tseng> jsgotangco: ?
<tseng> jsgotangco: pongles
<dilinger> jbailey: ping
<cc> if anyone sees  JuanjeOjedaQueue, OliverGrawertQueue, tell them to rock up please
<tseng> rocks out, bottoms up dude.
<ogra> cc ?
<ogra> cc, whats wrong ?
<cc> ogra: this is in regards to GraphicalPartitioningTool; and also, do you read your Activity page? because its been waiting on you for a while...
<cc> ogra: please fix, thanks. or have another BOF and fix :)
<Lathiat> cc: they are keeping you busy :)
<cc> Lathiat: definitely; i pretty much know all the specs in my head now...
<ogra> cc, i read it about hourly....
<Lathiat> heh
<ogra> cc, whats missing ? what we meant with "ship" is explained in the brackets... i see no other comments 
<Kamion> I explained the ship thing
<Kamion> it's standard Ubuntu terminology
<ogra> yep
<Kamion> although not standard outside Ubuntu :)
<ogra> :)
<cc> ogra: i want information on packages affected; UI requirements (you have no thoughts on how it should look for the user), and the implementation plan can definitely be expanded, i'm sure
<cc> Kamion: yeah, i figured that out after reading other docs in general. but i think others who are going to be picked up by google juice might not as well
<Kamion> nod, that's why I explained ;)
<ogra> cc, i'm not sure if we look at the same version....
<cc> then that: Check with parted list about preferred frontend - there have been some issues with qtparted and error handling in the past. May be fixed now, it's been a little while since I hung out on the list (StewartSmith)
<cc> ogra: http://udu.wiki.ubuntu.com/GraphicalPartitioningTool
<cc> ogra: you're welcome to come here so i can tell you in person...
<ogra> cc, i'll do :)
<Kamion> is there any other Qt-based parted frontend?
<tfheen> Kamion: 06:12 < tfheen> Kamion: if you're happy with oemrescue, please move the post-it note on the wall and add it to mdz's queue.
<cc> Kamion: qt-parted is dead upstream iirc
<Kamion> tfheen: yeah, was just doing that :)
<Kamion> (done)
<tfheen> Kamion: ok, goodie.  Just didn't know if you'd seen me poking you
<Kamion> cc: we do need something Qt-based for Kubuntu though - maybe that means one of us has to pick it up
<Kamion> naturally the Ubuntu one would be GNOMEish
<Kamion> or GTKish or whatever
<Lathiat> gparted seems to work
<cc> Kamion: i keep on forgetting about KDE users ;-)
<Kamion> so if necessary, the spec might need to say that we need to assume maintenance ...
<Kamion> dunno
<cc> ogra: hear all that from Kamion okay... and make it into the spec
<mako> if you are at UDU and want to do the keysigning: http://mako.yukidoke.org/projects/ksp-udu/
<mako> Riddell: ^^
<tfheen> Keybuk: if you could take a look at udevraces when you have time, I'd appreciate.
<Keybuk> haven't we got a session on that one later?
<tfheen> we have, but I wrote up what we have so far. :P
<dilinger> mako: you just got verbed
<dilinger> "i almost mako'd my laptop"
<Keybuk> could be worse, the laptop could've been allouched
<schweeb> you guys apparently don't know about whiprushing
<mako> dilinger: heh
<dilinger> schweeb: whiprushing/
<dilinger> ?
<Lathiat> mako: what did you do to your laptop :)
<tseng> schweeb: wha?
<schweeb> dilinger: it involves carelessly dist-upgrading :)
<schweeb> and has been extended to just about anything whiprush does to his systems to screw then up
<Keybuk> mako has been known to pour water over his laptop
<schweeb> tseng: here's some dirt
<Lathiat> haha
<Keybuk> and then in the madness to clean it up, pour water over someone else's laptop
<Lathiat> Keybuk: are you serious?
<schweeb> tseng: whiprush's shutdown commands on certain boxes have needed to have been moved... he's been known to type shutdown -h now in the wrong terminal window
<Lathiat> in hind site, that be funny :)
<Kamion> Lathiat: see mako's blog passim
<tfheen> Keybuk: and to drop his laptop into a bucket of water.
<Lathiat> tfheen: was it on?
<tseng> schweeb: i believe that
<Lathiat> thats just scary :)
<Kamion> the 'shutdown -h now' thing happens to us all, with variations
<daniels> schweeb: the best solution I've seen is to divert shutdown to shutdown.hostname on every machine
<mako> Lathiat: he's seriously
<Kamion> 'ifdown eth0' OH SHIT is also a common variant
<tseng> schweeb: i really enjoyed today listening to him bash gentoo people when he is like that
<Lathiat> i had a friend who, on a friday night, shut down the wrong box
<tfheen> Lathiat: I don't know.
<daniels> so sudo shutdown.tycho on gabe is harmless
<Keybuk> killall python...oh fuck, it's SunOS
<daniels> well, sudo shutdown.tycho -h now
<daniels> Keybuk: heh
* Lathiat has far too many times gone 'ip r d default' instead of 'ip -6 r d default'
<schweeb> tseng: I'm not too fond of gentoo myself...
<Lathiat> that hurts
<tfheen> Kamion: I've stopped doing shutdowns without doing a fresh login.  That helps a fair bit.
<tseng> schweeb: me neither, but he's a bigot :P
<schweeb> daniels: yea... or have the hostname in your prompt, and think before you type :)
<schweeb> thinking before you type is the best preventative method :)
<daniels> i have the hostname in my prompt, but thinking before I type is not my strongpoint
<tfheen> differently coloured terminals for different hosts help too
<tfheen> friend of mine uses that.  And has a fair amount of hosts to attend to
<Lathiat> mako: ahh, good work.
<jdub> http://perkypants.org/misc/the-fridge.jpg
<tseng> zomg
<elmo> omghfsnw
<jammcq_oz> mdz_: ping
<hawke> The bug here:  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154504 seems to apply to ubuntu also...where should I report this?
<ctd> to bugzilla.ubuntu.com
<hawke> ctd: thanks
<Unfrgiven> jdub: what is the fridge bof about?
<moquist> Unfrgiven: a website where folks can stick the best work to show mom & dad.
<ogra> Kamion, isnt that up tothe kubutu guys to care for the qt-parted maintenance (find someone) ? i really cant judge qt tools...
<Riddell> ogra: why are we talking about qt-parted
<ogra> Riddell, http://udu.wiki.ubuntu.com/GraphicalPartitioningTool
<ogra> Riddell, do you know any alternative for usage in a liveCD installer ?
<jbailey> Anyone seen silbs?
<fabbione> jbailey: she is in global
<fabbione> right in front of me
<jbailey> Thanks. =)
<Unfrgiven> moquist: ur not serious right?
<Riddell> ogra: qtparted, but I've never used it
<hawke> jbailey: enjoy your new bug.
<Riddell> ogra: but yes, it'll be up to kubuntu to make it usable
<ogra> Kamion, so we wouldnt have to cover it in _this_ spec, right ? 
<jbailey> hawke: Which one?
<hawke> jbailey: 10245
<jbailey> Reduced testcase!
<jbailey> Sweet!
<jbailey> hawke: Thanks. =)
<hawke> jbailey: Well, I didn't come up with the test case(s), so I can't take credit for that.
<moquist> Unfrgiven: only a tiny bit.  :)
<Janux> jnc, hi, sorry I was afk, but how do I make it working?
<pitti> Keybuk: where are you?
<Keybuk> pitti: vibe out
<pitti> Keybuk: I was asked by elmo that you are a wanker
<Keybuk> I am?
<pitti> Keybuk: elmo ... to tell you that ...
<pitti> Keybuk: no idea what that is
<Keybuk> he's such a charming character
<Keybuk> is he actually coming to this bof?
* Keybuk is waiting
<pitti> Keybuk: he just started to go up
<pitti> carlos: here?
<carlos> pitti: hi
<pitti> carlos: you totally confused me, my original desktop proposal was right
<carlos> pitti: ok, sorry then... O:-)
<jbailey> Has anyone explained to pitti what a wanker is yet? =)
<d3vic3> O.O
<tfheen> jbailey: I suspect not.
<pitti> jbailey: someone did
* Treenaks hands pitti dict
* d3vic3 hands pitti brain soap 
<zyga> hello
<Amaranth> mpt: I just found http://mpt.phrasewise.com/discuss/msgReader$173. Seems like you've been at this for awhile. ;)
<cc> pitti: ping
<pitti> cc: pong
<cc> pitti: do you want to add anything to BrandingForDerivatives? kamion is satisfied with it, but just checking w/you
<pitti> cc: we reviewed it together, it's fine for me
<cc> pitti: excellent. i'll ping you again when i'm done with it
<pitti> cc: thanks, great
<seb128> cc, what do you want to get changed for GdmRoadmap ?
<cc> pitti: go ahead physically move it along; its an EditedSpec now
<cc> seb128: scope and use cases (for the new changes); will it affect any migration? like people's current gdm stuff?; what packages besides gdm will be affected (do you need to include anything into main?); any UI requirements (new features must still be accessible, etc...?)
<seb128> k, thanks
<cc> seb128: ping me again when done (or just add it to my queue)
<seb128> k
<tfheen> Keybuk: had the time to read udevraces yet?
<fabbione> elmo: please -> forum
<Keybuk> I'll read it in the BOF :)
<tfheen> blah, user.
<pitti> carlos: can you please review LanguagePackRoadmap?
<JaneW> nice to actually know who you guys are now .. ;)
<Keybuk> and nice to know we do change t-shirts?
<daniels> JaneW: do you really mean that, or are you frightened and working on your resum now?
* tfheen tries to decide whether he should go to the keysigning tomorrow or not.
<Treenaks> daniels: that happened last time, right? :P
<fabbione> can somebody ping elmo please?
<JaneW> Keybuk: yeah that especially
<fabbione> ah here he is
<JaneW> Keybuk: except I fear it;s only because you get given free new ones, and get excited to try them on...?
<JaneW> daniels: hehehe - maybe...
<daniels> JaneW: mmm -- I'm now five shirts up from when I left home a week and a half ago
<JaneW> fabbione: he's not anywhere near me.
<JaneW> daniels: did you bring a spare suitcase to get them home in?
<Lathiat> i didnt even get my linux.conf.au shirt
<Lathiat> they didnt get them in until thursday, by the time i asked, they were all gone
<daniels> JaneW: nope, my current one can apparently expand to 30% of its size
<daniels> JaneW: either that, or I'll start throwing some of the older shirts out :P
<JaneW> that would be contract technically
<Lathiat> haha
<daniels> JaneW: ber, 130
<JaneW> 130%?
<JaneW> or expand and extra 30%?
<daniels> an extra 30
<daniels> being able to shrink to a third of its size is a neat party trick
<JaneW> ok, at least we are clear on that now
<cc> mpt: remember to check MatthewThomasActivity (as it seems thru the wiki you might be thinking you're MatthewPaulThomas (which you are), but you only have an actiivty page without the paul bit)
<jiyuu0> is there a command where i can get the path only minus the filename
<tfheen> dirname
<cc> mdz: Kamion was looking for you earlier (he popped in here); he might've found you i dont know
<jiyuu0> thanks i'll give it a try
<mdz> cc: if it was more than about an hour ago, he found me
<cc> mdz: no idea, time has become a void to me it'd seem
<tfheen> cc: please ping me if you have any comments on udevraces.
<cc> tfheen: is that in my queue?
<tfheen> should be
<tfheen> as of five minutes ago or so
<cc> tfheen: since you're online, lemme read that.. 
<tfheen> cc: yay, thanks
* cc puts ogra's back in the queue
<ogra> cc, for which one ?
<cc> ogra: hwdb
<cc> ogra: its really interesting btw. i'm half-way thru
<ogra> there are three ;)
* cc didn't realise you're online too i guess
<ogra> heh...
<ogra> need input ? i have spare time now
<cc> ogra: give me 10 mins, finish with tfheen 
<ogra> ok
<thom> Even when the Canonical employees are factored out (the company seems to have moved its offices to Canberra for the conference), Ubuntu has clearly claimed a significant part of the distribution "market" among Linux developers.
<thom> (from LWN)
<tseng> wow
<tseng> canberra
<thom> LCA last week
<tseng> oh.
<dilinger> offices relocate weekly
<jsg_> did LCA go well?
<elmo> ubuntu was scarily prevalent there
<tfheen> jsg_: yes
<Treenaks> elmo: how?
<elmo> Treenaks: eh?
<Treenaks> 11:08 < elmo> ubuntu was scarily prevalent there
<seb128> somebody knows where is jdub ?
<tseng> Treenaks: alot of people were using it/ interested?
<tseng> seb128: vibe out
<seb128> has he planned to move downstair ?
<smurfix> tseng: more than half of the panelists IIRC said they're using Ubuntu
<smurfix> tseng: The rest mostly Debian, with one lone Gentoo hold-out ;-)
<tfheen> seb128: he seems fairly comfy where he's sitting
<seb128> tfheen, k, thanks
<tfheen> seb128: I could probably throw stuff at him until he goes away, if you really want that
<jdub> seb128: pong?
<ogra> lol
<tseng> tfheen: mentos
<tseng> tfheen: go.
<seb128> jdub, ah nice
<seb128> query
<daniels> can someone please throw fruit mentos with the clear plastic tabs at me, very gently?
<daniels> i need sugar
<Unfrgiven> tseng: lol
<daniels> i repeat: very gently
<dilinger> i think i'm sitting in the wrong place for this mentos tossing game
<tfheen> dilinger: come to vibeout
<tfheen> bring mentos
<tfheen> go wild
<dilinger> tfheen: i am in vibeout
<daniels> tfheen: he's *in* vibe out
<tseng> right behind you!!!!!ONE
<thom> tfheen: HE'S BEHIND YOU!
<daniels> a good one point five metres from you
<daniels> sniper in the trees!  sniper in the trees!
<tfheen> dilinger: then just bring mentos and go wild.
<daniels> dilinger: yeah dude, where's the mentos?
<daniels> slacker
<dilinger> i ate 'em all
<dilinger> they were tasty
<dilinger> so very tasty
<tseng> its too much effort to get back out of this little chill pad
<daniels> goddamnit, dude
<tseng> to get anything.
<dilinger> the a/c rocks
<dilinger> i wish i discovered this room earlier
<daniels> tseng: i suspect it would be even less effort if you had a cushion in the chair
<daniels> do you want it?
<tseng> fuck yes
<tseng> lets have it
<tseng> daniels: cheers
<daniels> i live to give
<d3vic3> :-D
<ctd> those mentos things are addictive
<daniels> a little, yes
<ctd> I think by the end of the installfest the whole room of them had gone. :)
<tseng> and the keep refilling them
<tseng> its a healthy crack substitute
<daniels> i wonder what the hotel's mentos bill is
<ctd> heh
<tfheen> daniels: 1 megadollars/day.
<tfheen> at least with us around
<tseng> 80 megamentos limit
<ctd> 2megadollars on monday
<tseng> slow down with the throwing
<thom> especially when lamont MIRVs them
* ctd wishes UDU had flumotion streaming love.
<tseng> its a bunch of 20 something guys sitting in a cold room talking on irc
<cartman> ctd: me too
<ctd> or I could magically appear in vibeout.
<tseng> when they could just yell across the room
<tseng> you dont need a feed
<lamont_r> tseng: we're _BEING_POLITE_ dammit. :-)
<Treenaks> oh no.. another candy-throwing episode?
<tseng> lamont_r: you're in another room, dude!
<dilinger> tseng is totally downplaying the hot mentos action
<ctd> hell, maybe I should convince school to let me attend UDU tomorrow. :)
* Treenaks remembers the foodfights in Mataro
<jsgotangco> ctd, you should :)
<lamont_r> tseng: true
<tseng> lamont_r: come up, ill throw candy at you
<tseng> unless you got sucked into a bof
<ctd> If not tomorrow, I'll turn up Saturday. :)
<daniels> tseng: DO NOT WASTE IT ON LAMONT.  THROW IT AT ME IF YOU HAVE ANY.
<daniels> (gently!!)
<ctd> and throw mentos at daniels 
<jsgotangco> hehe
<astharot> ciao
<daniels> oh my god
<daniels> tseng is the mentos fairy
<ctd> going to shops
* ctd ponders buying mentos
<JaneW> ctd: don't do it!
<thom> there is probably a sydney wide shortage now
<jsgotangco> don't bother all the mentos are here
<jsgotangco> i ate like a thousand already
<tseng> thom: they could get more if they looked on the floors and in the cushions
<daniels> jsgotangco: only?
<JaneW> hehehe
<jsgotangco> daniels, for the day
<jsgotangco> hehe
<thom> or just around lamont
* JaneW may never eat mentos again
<jsgotangco> i had like 5 redbulls this afternoon only
<jsgotangco> im so full of caffeine
<daniels> JaneW: you'l be chasing that sweet, sweet first hit
<daniels> jsgotangco: clearly what you need now is shitloads of sugar
<JaneW> too many traumatic memories associated...
<lamont_r> jsgotangco: not much caffeine in redbull
<lamont_r> daniels: he got that in the redbull
<daniels> i have a very good caffeine hit upstairs
<daniels> about ten packs of foosh mints
<jsgotangco> heh
<tseng> yet you are begging for mentos
<ctd> redbull isn't very effective.
<cc> lotsa mentos here
<daniels> http://www.thinkgeek.com/caffeine/candy/6e27/
<ctd> I find V better.
<cc> sublime 3 is the place to be (for mentos at least)
<ctd> heh
* ogra thinks offering mentos on conferences is based on a conspiration of the dentists
<daniels> tseng: it's been almost three weeks since I've had caffeine yet
<daniels> oh my god, yes
<jsgotangco> gyahh
<daniels> it's even worse than jelly belly
<ctd> peer-to-peer mentos trading.
<tseng> cc: ill give you a 2AUD thingy to come in here and throw a shitload at thom 
<cc> tseng: where is here?
* cc could use the walk
<tseng> cc: vibe out
<tseng> it has to be a good hit
<cc> till jbailey rocked up, i was the only one here for hours. boo hiss
<tseng> and you cant run
<thom> cc: i'll raise you a piece of eight
* cc starts coming
<thom> to hit tseng instead
* thom runs away to a bof
<d3vic3> cc the sweet assassin
<ctd> You can't hide in BOFs!
<ctd> so, when's the Mentos BOF going to be?
<tseng> it just happened
<jsgotangco> yeah
<dilinger> that's every bof
<ctd> heh
<jsgotangco> ooohhh Pepsi Max
<bob2> it's like pepsi
<tseng> whats the max
<d3vic3> eish! mentos flying around 
<bob2> but with artificial sugar
<bob2> ten times as much
<dilinger> it's raining
<thom> men...tos
<jsgotangco> you cant finish the BOFs with Mentos raining around
<JaneW> your BOF is finished now
<d3vic3> so are the flying mentos 
<dilinger> thom: parallel mentos init, with dependencies (the freshmaker)
<ogra> *g*
<bob2> the foomaker.
* JaneW finishes another red bull
<bob2> careful with that
<tseng> man
<JaneW> ~~WIRED~~
<tseng> id hate to be the one cleaning this up
<bob2> or you'll be bouncing off the walls too much to catch the omlettes
<dilinger> it's only a matter of time before i become a human shield
<tseng> theyll be finding mentos for weeks
<jsgotangco> lol
<tseng> daniels hit some dude right in the face
<tseng> brutality.
<cc> so, do i get my money? ;-)
<daniels> tseng: abentley
<tseng> for what?
<tseng> i didnt even see you come in here
<cc> tseng: pfft. daniels be  my witness, i did
* cc figures tseng doesn't know who he is
<tseng> i do
<daniels> cc came in here yeah
<tseng> did he rain mentos on thom ?
<cc> thom ran away unfortunately
<JaneW> note to all: DINNER IS AT 20:30 - AS USUAL
<tseng> well then
<tseng> you get nothing.
<bob2> JaneW: but I'm hungry NOW
<cc> JaneW: not 20:15
<tseng> JaneW: pfft
<JaneW> ok ok, 20:19
<d3vic3> we are in diet *runs*
<JaneW> compromise ;)
<d3vic3> s/in/on/
<daniels> cc: thom's here, dude
<JaneW> d3vic3: after this week I need one!
<dilinger> ogra: ooh, i hope we have fish again.  how about you?
<cc> dand: i'm back editing ogra's thingo now
<daniels> tseng with the headshot
<daniels> 12q1`````````5~5
<tseng> rock out.
<jsgotangco> I hope they wont give me fish anymore for dinner
<ogra> jsgotangco, ;)
<ajmitch_> you liked the fish, right?
<jsgotangco> i only ate the fish
<tseng> dinners here are such crack
<jsgotangco> i wanted the bloody meat
<tseng> where is dholbach
<ogra> tseng, global
<tseng> blah
<JaneW> and I keep getting meat when *I* want fish
<JaneW> go figure...
<tseng> JaneW: crack!
<tseng> they try to give me vegan food for some reason
<tseng> i dont like green leafy crap
<JaneW> it's like they want to try break us all
<JaneW> which will be oretty soon
<JaneW> pretty
<JaneW> they broke kinnison already
<JaneW> with the feather thing
<jsgotangco> the pillows?
<tfheen> yeah, he's really allergic to feathers.
<koke> hey, I'd kill for some fried eggs & chips :)
<tseng> fried eggs?
<jsgotangco> id like a big mac for a change
<tseng> you guys are sick
<tfheen> mcdonalds isn't food.
<jsgotangco> exactly
<smurfix> That's kindof the point with McD ;-)
<tseng> ogra: why isnt dholbach online
<seb128> cc, GdmRoadmap updated
<cc> seb128: ok, looking at it now (looks a lot nicer, yes)
<seb128> thanks
<ogra> tseng, dunno... i'll poke hm....
<tseng> im on a mentos downer
<ogra> in global there are still plenty of mentos
<daniels> tseng: dude, there are shitloads on the table
<daniels> like, bowls
<tseng> i know
<tseng> i mean
<tseng> sugerbomb
<daniels> heh
<tseng> AndyFitz: <3
<koke> I think mentos+red bull was not a sensible mixture
<koke> clock runs slower before dinner
* koke hunnngry
<jsgotangco> me too
<lamont_r> mjg59: where you at?
<bluefoxicy> should "Marked Changes" be in "Status"? and not "Custom"?
<cc> daniels: http://udu.wiki.ubuntu.com/XorgAutoconfiguration is that like a draft spec?
<Taliesin`> o.O
<Taliesin`> buh bye telstra? :P
<hypatia> could be
* Lathiat pats his westnet adsl, not at UDU :)
* Lathiat cries cus hes not at UDU
<Taliesin`> i didnt know about it until yesterday
<ctd> so, earlier discussion has caused me to find the mentos song on my desktop.
<cartman> http://www.pcworld.com/reviews/article/0,aid,120520,00.asp <-- check out
<solomarv> sweet
<ctd> "became the second fabulously rich guy to literally buy his way into orbit."
<ctd> Not what I heard. :|
<solomarv> ctd, what have you heard?
<ctd> I don't think he really bought his way in from what he said at lca.
<solomarv> ctd: he did pay $20 mil, didn't he?
<ctd> can't remember that bit, but it wasn't just a holiday or anything.
* ctd 's memory is bad right now.
* solomarv kindly suggests reading third paragraph on http://en.wikipedia.org/wiki/Mark_Shuttleworth
<hypatia> as I understand it, he paid the money, but also underwent the complete training program.
<hypatia> which is probably true of all the "space tourists" to date.
<Lathiat> yeh he did
<Lathiat> i went to his talk at linux.conf.au
<Lathiat> the training he went through was rather horrendous :)
* ctd should be banned from irc 'till his memory returns
<jsgotangco> ogra, hi hehehe
<ogra> jsgotangco, evil .au server
<trulux> heya folks
<trulux> pitti: hey!
<pitti> hi trulux 
<trulux> pitti: how's it going? I have many thinks to talk about, regarding the pro. sec. BOF
<pitti> trulux: please look at http://udu.wiki.ubuntu.com/ProactiveSecurityRoadmap, there might be things that interest you
<pitti> night, folks
<trulux> pitti: I printed that early in the morning
<trulux> oops :(
* trulux has been working out stuff from there
<trulux> fabbione: there?
* ajmitch_ waves night to pitti
<trulux> ajmitch_: one moment
<trulux> ajmitch_: just two things: where did you put the fixed pam packages, and, if you can be reached by phone at UDU, I might call you for telling you about a few details regarding our BOF/UDU politics
<trulux> as I can't go there, you might be able to help out
<trulux> just on concrete things around the SELinux BOF and the PS one
<ajmitch_> email me
<jsgotangco> it would be nice to have a mentos food fight before we all go to bed
<trulux> ajmitch_: ok, to the gnu.org, right?
<ajmitch_> ihug.co.nz may work better
<trulux> oh, ok
<trulux> if you have your account on fencepost I would just send to localhost ;D
<ajmitch_> it is
<ajmitch_> night all
<souki> hello, where to post bug-report for hoary ?
<zul> bugzilla.ubuntulinux.com
<souki> zul, thanks, do I need to register?
<Burgundavia> yep
<Burgundavia> souki, what package?
<souki> Burgundavia, firefox
<souki> I've noticed a strabge bug with textarea
<Burgundavia> ok, that is bugzilla
<zyga> hello
<Janux> hi, anyone here can help me? my xmms and music player play list cannot show chinese characters, any clue?
<Burgundavia> #ubuntu for help
<Burgundavia> this channel would be for your patch to fix it
<Janux> Burgundavia, someone directed me from there to here, and they even directed me to ubuntu-zh but I didn't get any help from there.
<Burgundavia> I would try google for an answer
<Janux> Burgundavia, okay.....thanks
<Burgundavia> sorry I cannot be of help
<jnc> Janux: not sure.  i'll take a look at it if i find the time to do so
<Janux> thank you for both of you...:)
<enrico> Hello.  Is there some arch/tla/baz hacker I can query for a question?
<zul> i think they have their own channel
<enrico> right
<Lathiat> #voodoo-magic-evil-of-the-dark
<Burgundavia> no no no
<Burgundavia> #small-children-sacraficed-here
<zul> or even #bazaar?
<Lathiat> sounds less evil
<zul> sounds more right though
<Lathiat> true
<spo0nman> is there any way to make uml boot into a kernel other than the running one?
<zul> huh?
<spo0nman> zul, :-?
<zul> what was the question?
<spo0nman> is there a way to make user mode linux boot a kernel off an installation media?
<zul> like a cd-rom?
<spo0nman> zul, yes.
<zul> i havent seen it done before but check goocle
<zul> google
<spo0nman> hmm k
<trulux> someone here able to do some prelink work?
<trulux> I'm fixing the stuff on http://udu.wiki.ubuntu.com/ProactiveSecurityRoadmap
<Simira> morning Sydnay
<Simira> Sydney, even
<kay> When will gcc 4.0.0 come into Breezy?
<tseng> its already there.
<Simira> tseng, always the first one...
<Simira> still breakfast, eh?
<tseng> Simira: i slept in today, miss
<tseng> havent even showered yet
<Simira> tseng: so you're not really up yet, heh?
<tseng> nope :P
<kay> hm.... why is still named gcc-4.0_4.0-0pre11_i386.deb then :p
<tseng> erm, we cant upload this week
<kay> what?
<tseng> what I said.
<kay> ok, then please tell me why, is Breezy already frozen ? ;-)
<tseng> there is no bandwidth here to spare
<kay> wow, that's bad news
<Simira> mornin, mdke
<tseng> kay: i said 1 week
<kay> Sorry if I get on your nerves, but can you say how this comes?
<tseng> http://udu.wiki.ubuntu.com/UbuntuDownUnder/
#ubuntu-devel 2005-05-10
<kay> ah, i see
<kay> That's Ok, I read on the site you pay per MB there 
<kay> So, it's not a problem of server infrastructure not up to the task or something
<kay> That's fine then.... :-)
<kay> (Not that I believe I matter#)
<mdke> hi Simira 
<mdke> although its evening here :)
<zyga> hello
<Simira> mdke: sorry, i forget you're not in au :p
<Simira> all others is...
<mdke> rub it in
<zyga> how is UDU going?
<Simira> *impatiently waiting for Tollef to get online*
<Simira> mdke: hey, I'm not, ok! I've been alone for two weeks. So just you shut up!
<mdke> Simira, *grins*
<mdke> Simira, 2 weeks?
<Simira> mdke: linuxconf.au and UDU
* mdke gets out his abacus
<mdke> Simira, married to some high flying ubuntu dude huh?
<davidj> Capslock on hoary doesn't work properly for "c" and "e".  I used the bug report tool but never got a response.
<davidj> the problem only happens on the console.  How should I report it?
<Simira> mdke: not yet. I'm engaged to Tollef (tfheen/Mithrandir)
<mdke> Simira, nearly as good
<Simira> mdke: yep. The travelling firefox is mine. If you've seen him hanging around Tollef, more or less literally speaking...
<zyga> davidj: what's your locale setting/
* mdke 's head swims
<mdke> Simira, oh well, irc isn't a bad way of keeping in touch
<davidj> en_US.UTF-8
<Simira> mdke: you're single, aren't you?`
<mdke> Simira, no
<zyga> davidj: does changing the locale to C makes any difference
<davidj> The problem appeared to be in /etc/console/boottime.kmap.gz
<davidj> zyga: No
<Simira> mdke: ok, you've just been married or whatever too long, then :p
<davidj> The only fix I've found so far is to edit boottime.kmap and remove the stuff that makes Alt-E a Euro sign.
<davidj> zyga: Hang on a sec, please.
<mdke> Simira, nah... my g/f lives in another country at the moment
<mdke> *catches sight of the topic*
<Simira> mdke: I don't understand how you make it...
<Simira> mdke: they've not started working yet, anyway :p
<mdke> its not great
<mdke> or cheap ;)
<Simira> I once had a boyfriend in another part of the country.  I'll never leave sight of Tollef that way, I tell you!
<davidj> zyga: I've removed the line in boottime.kmap that was causing the problem, makes it a bit difficult to test ;-)
<zyga> davidj: I know little of boottime.kmap.gz actaully but since the problem does not appear to happen here I'd be glad do diff our files
<zyga> actually even
<zyga> which program generates that file?
<mdke> Simira, its a work thing
<mdke> but its certainly not a good long term strategy, you're right
<davidj> zyga: I've misplaced my notes, I'm not certain.
<zyga> davidj: dpkg does not seem to know about it
<zyga> davidj: the best I can do is offer my version for you to check
<davidj> zyga: OK
<zyga> davidj: one moment
<Simira> mdz: do you allow those guys eating breakfast for this long? 
<zyga> davidj: www.suxx.pl/boottime.kmap.gz
<mdz> Simira: they have 25 more minutes
<davidj> zyga: thx, getting it now.
<davidj> zyga: Your file is different from mine.
<davidj> It looks like it's been fixed behind my back ;-)
<Simira> mdz: what do they need all that food for, then? :p
<zyga> davidj: I'm running breezy
<Simira> zyga: how works it?
<zyga> davidj: is the difference significantly large
<zyga> Simira: breezy? fine but some thing are broken
<zyga> ;-)
<zyga> (as long as you can call that fine)
<davidj> No, the difference is "keycode 18 = +e +E +ecircumflex +Ecircumflex +Control_e" instead
<davidj> of "keycode 18 = e"
<zyga> Simira: if you are interested in anything specific feel free to ask
<Simira> zyga: just checking the status. I'll be running Breezy on my laptop in short time, I guess
<zyga> Simira: amd64 has problems with openoffice2 but I'm not sure that's breezy specific 
<zyga> Simira: ndis and gcj are not upgradable at this time
<Simira> zyga: I've got this amd64-guy in bed, so that's no problem. I don't run amd64 yet, either
<zyga> Simira: it's fine as any other devel version I guess
<mdz> Simira: they need fuel
<Simira> it's time for you to send them home soon, mdz. They'll get the fuel they need ;p
* mdke shakes his head
<Simira> mdke: I'm lonely, and besides torn almost in pieces after falling from a horse earlier today
<mdke> gosh
<mdke> Simira, everything in one piece?
<zyga> night everyone
<Simira> mdke: mostly. Possibly a lesser concussion, and my back looks like something ran over it. I'm ok now, but I won't bet on being able to get out of bed tomorrow.
<mdke> Simira, staying in bed sounds like a good idea
<Simira> I've noone here to pick dirt out of all the scratches, though...
<mdke> well i'm sure your bf is sorry he's missing that
<Simira> mdke: I'll hit bed as soon as Tollef has come online and we've had a short chat
<mdke> :/
<mdke> Simira, did you see a doctor?
<Simira> mdke: nope. I'm taking it easy a couple of days anyway. No need to pay someone to tell me.
<mdke> k
<mdke> Simira, what country are you in? just curious
<Simira> mdke: Norway
<dilinger> mjg59: heh, nice shirt
<Simira> where's Tollef? He's awfully late today
<mdke> *grins*
<Simira> hey, I'd like to (try, at least) go to bed myself at some point...
<IFR> HI, all checking to see if anyone's using fuse successfully with hoary?
<Kamion> Simira: he said he was off into town this morning with Fabio to talk to some folks about virtualisation; I don't know if he's actually left for that yet
<Simira> oh, great...
<Simira> Kamion: well, tell him I went to bed, a bit offended for having waited for him this late without him showing up... He knows I'm usually waiting!
<Kamion> oops, I guess I got Tollef into trouble ...
<mdz> Kamion: Tollef got Tollef into trouble ;-)
<daniels> heh
<jbailey> My eyes are dim, I cannot see, I have not got my specs with me...
* JaneW hands jabiley some specs
<jsgotangco> need redbull now
<JaneW> they are still in draft, please progress
<jsgotangco> JaneW, what does it mean when the post-it notes have check marks
<JaneW> jst: that we scheduled them for today
<JaneW> jsg I mean
<JaneW> jsg: I was a way to reduce the scheduling time last night, and to show mgmt what had been put in already
<jsgotangco> right ok that means i have a lot of time drafting the spec and have it edited
<jsgotangco> thanks
<JaneW> jsg: have a red bull with a side order of metos?
<JaneW> mentos
<jsgotangco> sure want to start a mentos fight?
* JaneW slaps self - wake up and type PROPERLY
<hypatia> was I the only person craving some nice fresh fruit on Monday? ;)
<jsgotangco> no fruits just mentos
<hypatia> There's no point craving mentos when they're there for the taking.
<JaneW> hi cc
<cc> hi JaneW 
<JaneW> cc: did I get your msg across ok?
<cc> JaneW: yes; and i've got your schedule on the door already
<JaneW> cc: thanks, but I mean did I convey your spec msg adequately
<jsgotangco> at the back of the redbull can it said Usage: 2 Cans Max Daily
<cc> JaneW: yeah, and if folk rock up here, SpecProcess witll be good for them
<tseng> jsgotangco: they should put that on Bawls
<daniels> cc: hey dude
<cc> hi daniels 
<cc> daniels: http://udu.wiki.ubuntu.com/XorgAutoconfiguration is ready? or still drafting?
<daniels> cc: dumped XEyeCandy into your queue -- hope it's OK
<daniels> just looking at XorgAutoconfiguration now
<cc> sure thing, its always okay. 
<daniels> cc: xorgautoconfiguration is all yours :)
<JaneW> mentos madness starts again
<dilinger> ah, beanbag <3
<zul> hey
<novatux> hi, i downloaded a many files from ubuntu repositories and now i want to install this packages in another machine, how i can skip de gpg signed, the synaptic try to download from internet and no from my local repositorie
<zul> is it friday in sydney?
<JaneW> so who is going to be first to upload their UDU photos? I made a new heading on the warthogs photo page...
<novatux> in ubuntu channel say, go to ubuntu-devel ;)
<JaneW> zul: yes
<zul> damn the week has gone by quick
<zul> ...its be lonely on #ubuntu-kernel :)
<daniels> JaneW: why don't you be the first? :)
<daniels> JaneW: set the pace!
<JaneW> daniels: I'd love to but I nuked the USB interface on my camera, so need a card reader to get pics off the camera - got one?
<daniels> oops ...
<JaneW> *nod*
<daniels> mjg59 has a CF adaptor floating around, but I left my card reader at home
<JaneW> I should just get a new (better camera) anyway
<JaneW> SD card
<daniels> i have SD, but it's the one thing on my laptop that's unsupported
<JaneW> we have an HP laptop back home with a built in card reader
<JaneW> daniels: I'd love to lnow what I did, but it seems I furkled the firmware or something
<cc> JaneW: whats the warthogs photo page?
<JaneW> the canonical wiki's page with links to conference photos etc
<zul> ah so it aint public
<JaneW> nope
<AndyFitz> anyone using breezy ?
<tseng> zul: top secret crack
<zul> tseng: :P
<zul> mmmm...crack pipes..
<d3vic3> tseng, more like G14 classified 
<syn-ack> Who is the maintainer of libaspell?
<daniels> JaneW: i'd love to know what furkling is
<ogra> cc, any reason why http://udu.wiki.ubuntu.com/GraphicalPartitioningTool went back into juanje's queue instead of being a edited spec ?
<d3vic3> hehehe
<syn-ack> I thought I would let them know that there was a bug in it for breezy and I went ahead and recompiled a fixed .deb for it.. went ahead and submitted to the bugzilla.
<tseng> AndyFitz: yes
<cc> ogra: because i'm having to deal with simon whom isn't exactly doing a 100% tech review and occasionally playing with the process. can you please move the queue physically (post-it notes)? i've made it an editedspec
<AndyFitz> tseng,    yeah but that doesn't help cause you can't update ubuntu-artwork and check it out while on this connection  :-P
<jbailey> Keybuk!!!!
<tseng> AndyFitz: i cant? :P
<elmo> jbailey!!!!!
<tseng> how big is it
<Keybuk> jbailey!!!
<zul> hey jbailey and Keybuk 
<elmo> tsenf: dude, do not start downloading debs
<tseng> we can move it on my camera
<Keybuk> tseng: <--------->  (* not to scale)
* jbailey waves at elmo
<elmo> I will throw stuff at you
<jbailey> I appear to be in the line of fire.
* jbailey backs away slowly.
<tseng> AndyFitz: do you have a deb on your laptop?
<d3vic3> jbailey, i know the feeling 
<d3vic3> jbailey: next thing you know, you have to duck
<syn-ack> heyas Pizbit.
<Pizbit> Heyyas
<Pizbit> syn-ack: There is nothing worse than flatmates who only want to pay 5c/year on internet:)
<syn-ack> heh
<AndyFitz> tseng,  nope  jdub made the deb
<AndyFitz> tseng, my 4rtw0rk w3s t3h st0l3n...
<d3vic3> O.O
<Pizbit> syn-ack: How's it going?
<JaneW> daniels: furkle means fiddle - but usually break in the process
<cmj> eish taken 
<syn-ack> Pizbit: Not too bad, just did a rebuild of a package and I thought I would let these fine gents know of it. :)
<Pizbit> syn-ack: *grin* Which package(s) are you toying with?
<syn-ack> Pizbit: libaspell15 in Breezy.
<syn-ack> Pizbit: https://bugzilla.ubuntu.com/show_bug.cgi?id=10272
* Pizbit nods.
<ogra> cc, thanks :)
<cc> ogra: physically moved?
<tseng> AndyFitz: i can get it from jdub
<cc> thanks
<tseng> AndyFitz: where is he?
<ogra> cc, yes ;)
<daniels> jane	ah
<AndyFitz> tseng,  no idea bro.  but the dude upped it last night apparently
<pitti> carlos: ?
<Burgundavia> can I canonical employee tell the docteam what is on -->http://udu.wiki.ubuntu.com/UbuntuDocImports
<seb128> syn-ack, that's your bug ?
<syn-ack> seb128: There was a symbols error with libaspell15... a rebuild fixed it... a.ubuntu.com/show_bug.cgi?id=10272
<carlos> pitti: ?
<syn-ack> seb128: ltns, how goes it, btw?
<carlos> Burgundavia: nothing yet
<carlos> Burgundavia: I'm answering the email about that issue
<pitti> carlos: can you please review http://udu.wiki.ubuntu.com/LanguagePackRoadmap and put it into SimonSharwoodQueue if you are satisfied?
<Burgundavia> carlos, thnaks
<carlos> pitti: sure
<jdub> tseng, AndyFitz: it's not up yet
<tseng> jdub: ARE WE THERE YET?
<ajmitch_> jdub: but we need the bling
<tseng> jdub: sneakernet
<fabbione> doko: ping?
<seb128> syn-ack, sending a deb file is useless for this, we do sources upload and maintainers know how to rebuild a package
<seb128> and there is several dups of this bug
<syn-ack> Ah, well. Sorry to have sent it then. :/
<syn-ack> seb128: I wasnt trying to imply that you didnt know how build a package, was mearly trying to help.
<fabbione> Kamion: i am in forum...
<seb128> syn-ack, no problem, thanks for the efforts
<seb128> syn-ack, it'll probably be fixed soon
<fabbione> can somebody ping Kamion please?
<daniels> firefox BITES.
<dilinger> daniels: yep.  http://weblog.dividedsky.net/~dilinger/index.php?p=27
<dilinger> wow, i really need to nuke all that comment spam
<tseng> dilinger: wordpress 1.5 has some built in stuff
<tseng> word blacklists, dnsbl
<dilinger> tseng: yea, i'm still running 1.2 (i didn't even install it, i was lazy.  i just whined, and someone else installed it and gave me a shell)
<carlos> pitti: http://udu.wiki.ubuntu.com/LanguagePackRoadmap?action=diff do you agree with the changes?
<pitti> carlos: later, I'm in a BoF
<carlos> pitti: ok
<cc> carlos: Open``Office please (escape wiki names)
<carlos> cc: ok, not too used to the Wiki, sorry
<cc> carlos: no worries
<carlos> cc: I was thinking on move it into simon's queue but if you are reading it now... should I do it?
<cc> carlos: read already, move it over to him
<carlos> ok
<carlos> cc: thanks
<cc> http://udu.wiki.ubuntu.com/TranslationProcess is this a braindump or a draft spec?
<mike_douglas> what is the correct way to compress a changelog when building a debian/ubuntu package?
<jbailey> I think dh_docs just does it.
<carlos> cc: It's a brain dump, I think we need to review it a bit before moving it into your queue, but more or less the content is there
<cc> carlos: ok, review review then i guess
<pitti> carlos: fine for me
<pitti> carlos: please put it into Simom's queue
<JaneW> Andreas Mueller
<smurfix> doko: ping
<tseng> JaneW: amu.
<fabbione> elmo: ?
<elmo> fabbione: meh
<fabbione> elmo: we are in forum :)
<elmo> meh
<mvo> has anyone seen Kamion?
<fabbione> PimpleBackaupSolution
<fabbione> mvo: he just left forum 5 minutes ago
<jsgotangco> pimple?
<pitti> cc: TranslationProcess was just rediscussed by Adi and me; now it's a DraftSpec, Adi will review it again (I did the typing), then she will assign it to you
<cc> pitti: ok.
<jsgotangco> pitti, ok with you if i add some stuff on PDASupport?
<pitti> jsgotangco: by all means :-)
<tfheen> jdub: aren't you supposed to be in VO now?
<pitti> daniels: sublime 2 for PrintingRoadmap?
<daniels> pitti: on my way
<pitti> cool
<jbailey> lamont_r: ping?
<lamont_r> jbailey: sup?
<jbailey> lamont_r: The changelog for MailRoadmap says that sabdfl gave you feedback in person.
<jbailey> lamont_r: Wondering if you'd care to share. =)
<lamont_r> jbailey: where are you?
<infinity> VibeOut
<jbailey> Vibeout
<daniels> vibeOut
* lamont_r wanders
<infinity> WIBEOUT!!
* jbailey starts drumming.
<infinity> Has anyone seeen AndyFitz in the last two hours?
<tfheen> we should equip everybody with trackers
<dholbach> infinity: yes, he's in "global"
<infinity> That would be helpful.
<infinity> dholbach : Ahh, cool.  I'll wander down in a bit, then.
<infinity> dholbach : Tell him not to go far. :)
<thom> rfid tags in the namebadges
<dholbach> infinity: right
<hypatia> thom: in the not too distant future, you can just use passports.
<tfheen> hypatia: not in Real Countries.
<hypatia> thfeen: meaning which countries?
<tfheen> .no for instance.
<maswan> elmo: saw my msg?
<maswan> elmo: if you're still around that is
<tfheen> maswan: he's in a writeup bof
<maswan> tfheen: ok
<Riddell> jdub: is pia on IRC?
<carlos> cc: http://udu.wiki.ubuntu.com/OpenOfficeLocalisation <- If you could take a look at it... Thanks
<jdub> Riddell: as greebo sometimes
<jdub> tfheen: i'm sick of moving around, just working on drafting atm
<daniels> jdub: PROPRIETARY DRIVERS
<jdub> oh
<jdub> that's different then
<Riddell> poke sladen 
<jdub> crap, i thought that was next session
<tfheen> jdub: you're going to hold the bof or not?
<pitti> mvo: can you please review AutomatedTesting?
<ajmitch_> pitti: seen mdz's feedback on ProactiveSecurityRoadmap?
* tseng looks
<carlos> cc: around?
<cc> carlos: yes; just read OOo Localisation
<carlos> cc: thanks
<mvo> pitti: yes
<carlos> cc: What am I supposed to do with http://udu.wiki.ubuntu.com/RosettaOneDotZero ? it's in my queue and with the Edited flag
<cc> carlos: go get it approved. then remove it from your queue.
<pitti> ajmitch_: not yet, looking at it in a minute
<cc> carlos: alos, remove it from your queue and go get it approved. either works
<carlos> cc: ok, so it does not means we need to change anything from its contents, right?
<cc> carlos: nope.
<cc> carlos: read ?action=info
<carlos> ok, thanks
<cc> jbailey: jill has a wife? " Jill wants to make her pictures on her Ubuntu computer available to her wife's Windows machine."
<thom> cc: seems reasonable to me
<thom> this _is_ the 21st century
<cc> thom: yes, agreed...
<mdz> fabbione: on ClusterFilesystems, when you say that the userland is a work in progress, do you mean upstream or the packaging?
<mdz> fabbione: will we have GFS userland for breezy?
<fabbione> i mean the packaging
<fabbione> i have almost done with it
<fabbione> so yes.. it will be in breezy
<dholbach> mdz, ogra: added the script and the points about notifying the maintainers on ExpandingUniverse
<schweeb> o_O
<dholbach> mdz, ogra: added the script and the points about notifying the maintainers on ExpandingUniverse
<pitti> ajmitch_: could you come to global (or I come to you) to discuss ProactiveSecurityRoadmap?
<ajmitch_> alright, I'll come down from VO
<smurfix> mako: ping
<pitti> ajmitch_: I'm going to Forum now
<ajmitch_> ok
<mdz> dholbach: thanks
<dholbach> mdz: de rien
<seb128> ogra, where are you sitting ?
<seb128> cc, LaunchpadIntegration updated
<mako> smurfix: hey dude
<fabbione> mdz : did you get my msg before the global Kline?
<mako> smurfix: do we have a bof?
<thom> jbailey: are you jeff.bailey@canonical?
<elmo> thom == janew?
<thom> elmo: hush, you :P
<elmo> of course he's jeff.bailey@; everyone has first.last
<chmj> smurfix, ping 
<smurfix> mako: no BOF - I just want to write up the notes we do have into a reasonable spec
<smurfix> mako: right now it's still just a rough outline, and starting to longhand it with missing data isn't how I like to work ;-)
<chmj> smurfix, MentoringCommunity?
<smurfix> mako: NB: Who's "the" person to approve LoCoTeamProcess?
<smurfix> chmj: yeah
<smurfix> chmj: (not with mako though)
<smurfix> chmj: but JeffElkner is nowhere to be found :-/
<chmj> I'm in global 
<smurfix> chmj: so am I ;-)
<whiprush> anyone seen jdub?
<tseng> yes.
<tseng> he just left vtfo
<JaneW> elmo: huh?
<whiprush> tseng: vtfo?
<tseng> whiprush: vibe the fuck out.
<whiprush> k
<chmj> heh
<ajmitch_> jeff elkner is in forum
<pitti> Keybuk: got a minute?
<Keybuk> pitti: sure
<pitti> Keybuk: where are you?
<Keybuk> vibe out
<pitti> okay, coming up
<JaneW> anyone seen ddaa?
<thom> JaneW: sublime 1
<tseng> ajmitch_: um
<JaneW> thom: k, thanks. He ok now?
<tseng> "This helps to reduce the number of security updates we have to do after a release, and confines the impact of actual vulnerabilities to a minimum."
<tseng> ajmitch_: thats evil
<ajmitch_> blame pitti, he's just going up to VO
<tseng> ajmitch_: we still have to fix every CAN regardless
<thom> JaneW: seems angry still
<ajmitch_> of course, but it makes it a bit less urgent
<tseng> can I change it? im dying inside
* JaneW feels bad...
<ajmitch_> let me save my edits
<ajmitch_> talk to pitti, and then edit away
<tseng> he is busy with scott
<ajmitch_> ok
<ajmitch_> jbailey: is glibc using nptl on amd64?
<jbailey> ajmitch: Yes, since Hoary
<tfheen> jbailey: no, since warty.
<ajmitch_> ok
<jbailey> eh?
<jbailey> Oh, right.
<tfheen> amd64 glibc has been nptl the whole way through
<tfheen> unless you count the pre-biarch stuff from the early stone age
<fabbione> doko: i did add some extra details to SmallBusinessServer on mdz request, can you please review them?
<doko> fabbione: still in Forum?
<fabbione> doko: yes
<fabbione> doko: heading out for a fast smoke :)
<doko> '##
<doko> #
<thom> JaneW: i think he's angry with humanity rather than just because of you
<tseng> Riddell: i just noticed the 45+ channels on your irc client
<tseng> Riddell: hardcore.
<Riddell> tseng: it actually goes up to 69, but nothing interesting has happened in them today
<ajmitch_> tseng: editing proactive again..
<tseng> ajmitch_: alright.
<dilinger> Riddell: holy shit, and i thought i was bad w/ my 25
<|QuaD-> Riddell: 69 channels? are you able to monitor them all?
<|QuaD-> what client can do that efficiently?
<lamont_r> Riddell: which client?
<thom> |QuaD-: irssi copes with that quite happily
<tseng> i often have > 20, but i am seriously OCD about having lit channels
<schweeb> irssi can undoubtedly handle it. irssi rules.
<tseng> even for join/part
<schweeb> tseng: same here
<|QuaD-> thom: yeah i know irssi can handle it
<tseng> i cant keep myself from switching to the window.
<tseng> :(
<thom> tseng: same
* thom is up to 55 windows, but probably only 20 or so channels
<thom> hrm, maybe 30
<|QuaD-> thom: how do you know which window is which
<tfheen> tseng: don't show activity for join, nick, leave and so.
<tseng> i used to put more than one channel in one window
<bob2> 336 here.
<schweeb> tseng: this is why I run multiple irssis in multiple screen sessions... can ignore certain networks when its convenient
<bob2> er, 376
<tseng> tfheen: great idea
<Riddell> lamont_r: irssi
<tfheen> I'm usually on 20-ish channels.  before my home system crashed due to a bad disk, I was up to ~60 windows.
<tseng> tfheen: know the command for that offhand?
<Riddell> |QuaD-: a lot of them are old /msg conversations that I could probably close
<dilinger> i'm about to about 35 windows, and xchat's handling of it all is utter crap
<|QuaD-> Riddell: ahhhh, ok
<dilinger> s/about/up/
<tfheen> tseng: /set activity_hide_level JOINS PARTS QUITS MODES NICKS
<tseng> tfheen: rock on dude, thanks!
<tfheen> adjust as applicable, obviously.
<|QuaD-> tfheen: how do i set that in the config?
<tseng> |QuaD-: run /save after
<|QuaD-> tseng: nice
<tseng> or.. never exit your client
<|QuaD-> can someone cahnge their nick :)
<schweeb> tfheen: wow, you rule
<schweeb> guess SOMEONE reads the irssi docs
<schweeb> lol
<tfheen> and then /save
<tfheen> schweeb: irssi docs?  Where?
<mdz> fabbione: yes, I received your message
<schweeb> heh
<fabbione> mdz: ok thanks
<tseng> hah /help 4 life
<tfheen> |QuaD-: just type it on the command line.
<|QuaD-> tfheen: i did :)
<tfheen> schweeb: it's probably easier to just read the source.
<schweeb> rofl
<schweeb> alright, it's about time for me to head to sleep
<schweeb> start me new job tomorrow
<|QuaD-> schweeb: i start in june... my first real job
<tseng> |QuaD-: my appologies
<daniels> the discussion above about open windows sucked
<daniels> someone in this channel has >370 open windows
<tfheen> daniels: howso?
<daniels> in irssi
<Kamion> pitti: you added EditedSpecification to ProactiveSecurityRoadmap, but it is also BrainDump; it was sent back to you guys by the reviewer
<tseng> daniels: you face sucks.
<|QuaD-> tseng: heh, not your fault... graduated and i need to make a living, at least i get to do some programming 
<schweeb> |QuaD-: as in first non-part time job, or first job in the industry
<|QuaD-> schweeb: first job in industry
<Kamion> pitti: I've removed EditedSpecification for now
<|QuaD-> schweeb: where you working
<schweeb> |QuaD-: would have liked to have gotten a degree before I started this job, but the money is too tempting :)
<tseng> |QuaD-: he switches tapes
<schweeb> |QuaD-: EDS
<tseng> |QuaD-: he's a backup "admin"
<|QuaD-> haha, nice
<schweeb> hey, make fun all you want
<schweeb> the pay is good enough I can't complain
<|QuaD-> i wanted a network admin/security job at a bank (they would train me and stuff) but the money was better at my job
<pitti> Kamion: I noticed, we just updated the page again; I send it to cc now
<schweeb> and it gets my food in the door further
<cc> pitti: err? send what? i can look at it now
<schweeb> s/food/foot/
<pitti> cc: in a minute
<|QuaD-> tseng: out of curiosity what do you do for a living
<Kamion> pitti: ok, thanks
<pitti> cc: it's updated now (had to resolve some conflicts); ProactiveSecurityRoadmap
<tseng> |QuaD-: programming/sysadmin/networking ?
<|QuaD-> tseng: ahh nice. I might get to use mono at my job :)
<|QuaD-> (tseng, hence the reason i bug you soo often, i want to familiarize myself with it :) i don't mean to be a pain)
<tfheen> jbailey: ping?
<tfheen> jbailey: we have two braindumps to write up, it seems..
<cc> pitti: if it reads sanely, do i re-bump it to EditedSpec?
<cc> and place it in Kamion's queue?
<schweeb> |QuaD-: mono rocks.  I did sysadmin/networking for the last 2 years, but backup admin pays mad cash
<tseng> lunchtime.
<pitti> cc: yeah; however, I think this is rather mdz-ish
<tseng> lets roll dudes
<schweeb> tseng: I trust you're taking care of properly abusing whip
<pitti> cc: although I'd appreciate a review from Kamion, too
<cc> pitti: ok.
<cc> pitti: i'll put it in his queue
<|QuaD-> schweeb: i use mono when i can here, is an EE they make me use c most of the time, but i have gotten a good amount of experience
<pitti> cc: thanks
<|QuaD-> schweeb: i use vs.net for most of my development because back when i started to learn c# i was learning asp.net (not really c# soo much) and i like to take the easy way out and use the layout editors.... but then i started using mono more and more
<tfheen> mdz: could you please add stuff to people's queues if the specs are not approved?
<tfheen> mdz: and not just bump them back to braindump without any kind of notification.
<|QuaD-> schweeb: now that swf is implemented in mono (i haven't tried it out yet, trying to learn c#) i can't see my future employer carrying whether or not i use mono or vs.net, as long as i get the job done and have it run on windows (and linux too [and mac, though i don't know anything about ppc mono] )
<schweeb> |QuaD-: if you only have to target mono, it doesn't really matter anyways
<Riddell> |QuaD-: swf being flash?
<schweeb> Riddell: swf = system.windows.forms
<|QuaD-> Riddell: lol, swf beeing system.windows.forms
<|QuaD-> schweeb: target mono?
<schweeb> Riddell: .NET's GUI stuff
<Riddell> ah, how confusing
<schweeb> |QuaD-: i.e. not .NET
<Riddell> there should be an acronym registry to prevent clashes
<schweeb> the mono framework rather than .NET
<schweeb> GTK#, etc..
<|QuaD-> schweeb: i need to use the .net framework, but that shouldn't be a problem
<|QuaD-> schweeb: i am trying to teach myself gtk#, its not that easy :(
<schweeb> is there even .NET for OSX?
<schweeb> |QuaD-: glade
<Amaranth> schweeb: mono
<|QuaD-> not enough examples/documentation (esp cuz i don't know regular gtk)
<schweeb> Amaranth: I meant real .NET :)
<|QuaD-> schweeb: i am trying not to use that yet, cuz i want to learn  the hard way, so i always no how
<Amaranth> MS .NET Framework (.NET is many things) is Windows only
<schweeb> that's what I figured
<|QuaD-> schweeb: we will see what happens. the companies goal is maximum portability
<schweeb> |QuaD-: which would mean you should target the mono/GTK# framework IMO :)
<|QuaD-> schweeb: yeah, when we go there, i am going to sit down and talk to them about it. basically they got a huge contract and we are researching the best solution. the only thing is, the software product has to get tested by the clients (like conedison, a big utility company in nyc, and they require regular .net)
<schweeb> ah
<JanC> GTK# has no GUI/code-editor like SWF has in VS.NET & in SharpDevelop
<|QuaD-> JanC: right, but i am trying to avoid anything to help me, i like learning the hard way :)
<|QuaD-> i am excited about my job :)
<schweeb> hopefully MonoDevelop improves a lot soon... and Stetic should help too
<|QuaD-> schweeb: yeah... if tseng wasn't so lazy and got the next version of mono in there i could start learning more! (just kidding tseng, if you are reading this, i appreciate your work)
<JanC> I constantly swap between the graphical view & the code view
<JanC> changing code --> immediate changes in the graphical editor and vice versa
<|QuaD-> JanC: i use glade to show me what is available when i use gtk# cuz i don't know gtk that well
<|QuaD-> but i don't use it to help me code (not even sure if thats possible)
<JanC> I think there must be a way to use .glade files at runtime in GTK# ?
<|QuaD-> JanC: no idea, i don't want to be lazy yet though, so i don't learn
<schweeb> JanC: yes, there is Glade#
<|QuaD-> schweeb: my goal is is to actually start some useful gtk# or swf OSS project, i just can't think of one to start :(
<schweeb> |QuaD-: good LDAP browser/editor
<schweeb> :)
<|QuaD-> schweeb: ldap as in addresses? or can it be used for other stuff too
<schweeb> bunches of other stuff
<|QuaD-> schweeb: like what?
<JanC> it's a protocol to query hierarchical databases
<|QuaD-> schweeb: i am planning on doing a sync program for my cellphone, but thats easy and 3/4 done
<schweeb> you can store just about anything in LDAP
<|QuaD-> hmmm, interesting
<|QuaD-> i need to learn more about it :)
<schweeb> it's quite useful for authentication
<schweeb> and virtual users
<|QuaD-> interesting
<|QuaD-> well, it sounds like a good project, only problem is 1. i have no remote server to play with it on 2. i really don't have a need for something like that
<schweeb> heh
<schweeb> apt-get install slapd :)\
<|QuaD-> schweeb: but i don't really have a use for it either
<schweeb> okay, off to bed I go
<schweeb> night
<|QuaD-> schweeb: night :)
<Safari_Al> mike_douglas, any luck with the getupdates stuff? 
<mike_douglas> Safari_Al: ya, works great. About to do a full lab using it
<Safari_Al> mike_douglas, nice one!  Have you needed to modify anything in the core scripts?
<mike_douglas> Safari_Al: no, most of my time has been spent on the changesets
<Safari_Al> yes.  They do most of the work. 
<Safari_Al> It'd actually be cool to have a changeset tips & tricks repository online
<Safari_Al> Let me start that right now!
<mike_douglas> ya, that would be great
<Safari_Al> mike_douglas, http://dev.openmonkey.com/getupdates/discussion/tips
<Safari_Al> mike_douglas, I'll add some of my own stuff when I have finished writing this essay for uni.  Feel free to add your own there :)
<mike_douglas> cool, on the weekend I'll hopefully get out a man page for it. Then I can tackle packaging
<Safari_Al> mike_douglas, SWEET.  That's a really important thing that needs to be done to make it easier for people to use.
<mdz> tfheen: I am sending email for any spec that needs changes
<tfheen> mdz: email sucks when we're already using the wiki for workflow.
<seb128> jdub, around ?
<jdub> seb128: yo
<fabbione> Kamion: there are some comments on Installer Volume Manager.. do you want me to work on them?
<tfheen> does the wiki support strikethrough?
<mdz> tfheen: the wiki workflow sucks ;-)
<tfheen> mdz: not really.
<tfheen> mdz: it sucks significantly less than email.
<mdz> asynchronous notification is better than having people poll pages which search every page in the wiki for keywords
<mdz> but it's no problem to queue things in addition to emailing
<tfheen> mdz: thanks.  I need to poll email so it doesn't make much sense for me.
<tfheen> mdz: do you prefer us to leave the reviewer comments in place or should we remove it?
<tfheen> (after it has been adressed, naturally)
<mdz> tfheen: please remove them after they have been addressed
<jsgotangco> dumb question how do i put my draft in queue?
<jdub> jsgotangco: mention 'ColinCharlesQueue' or 'SimonSharwoodQueue' in your status field
<thom> jsgotangco: add ColinCharlesQueue or SimonSharwoodQueue
<tfheen> cc: when we have editedspec -> braindump and we've addressed the issues, should it go through you or just bump back to editedspec?
<jsgotangco> ok thanks
<cc> tfheen: back to us, then we'll move it up if required
<tfheen> cc: ack
<cc> tfheen: i'll put it in mdz's queue now
<thom> `anthony: care to have a look at http://udu.wiki.ubuntu.com/Firewalls please?
<tfheen> cc: thanks
<jsgotangco> amu, ping?
<ogra> cc, http://udu.wiki.ubuntu.com/HardwareDatabaseRoadmap re-edited after review, please have a look (moved it to your queue )
<cc> ogra: yes, it looks okay
<amu> jsgotangco: jep? 
<jsgotangco> amu, put the dial-up support on queue ok with you?
<jsgotangco> amu, i just put it on queu
<amu> jsgotangco: efine wieth me, date in the late evening or tomorrow
<jsgotangco> amu, ok
<dholbach> whiprush: around?
<whiprush> yeah
<whiprush> I have your lighter
<whiprush> coming down
<whiprush> smoker's bof?
<dholbach> whiprush: you took the words our my mouth
<thom> slackers :P
<tseng> smoking is for suckers.
<infinity> Only half the time, the other half involves blowing.
<jsgotangco> blowing
<jsgotangco> tsk tsk
<Kamion> fabbione: no problem, I'll do them
<Kamion> thanks
<Speedy2> mdz: Bug filed: https://bugzilla.ubuntu.com/show_bug.cgi?id=10189
<jbailey> Feh, the editors "fixed" my spec to have a mispelling of colour.  
<jbailey> Err, US spelling..
<dilinger> haha
<jbailey> =)
<Speedy2> Blimey.
<Keybuk> fix it back
<Keybuk> CANONICAL IS A UKish COMPANy
<Keybuk> KTHXBYE
<Lathiat> haha
<daniels> heh, 'ish'
<jbailey> You have to admit, if someone nuked the UK, we'd be screwed. =)
<thom> i'd be upset
<Lathiat> heh
<daniels> jbailey: i had one of my specs edited the other day for typos -- every single change was UK->US
<Keybuk> daniels: Manx is _technically_ not UK
<daniels> thom: what, you'd have to move somewhere sunny?
* Lathiat laughs
<Keybuk> like Melbourne?
<Lathiat> anyone here use irssi on a whtie background terminal who has a theme that doesn't suck?
<thom> white background terminals by definition suck
<jbailey> Does .au use US spelling?
<ajmitch_> no
<crimsun> I'd think british
<daniels> no friggin' way
<jbailey> Whyever are they changing it that way then?
<daniels> our language has not been coloured by us english
<thom> i'm surprised the FTA doesn't mandate us english :P
<Lathiat> haha
<daniels> tell me about it
<Lathiat> whens that come into effect?
<Lathiat> soon i think?
* Lathiat sigh
<daniels> australia's collective arse is definitely an input device
<pitti> mvo: PING (Bof starts in -7 minutes)#
<fabbione> Kamion: ok.
<jsgotangco> brb
<dholbach> jdub: wow... you changed quite a bunch on UBuntuAndUpstreams
<cc> mako: hey, whats a TB ?
<dholbach> cc: technical board
<cc> ah, okay, thanks dholbach 
<dholbach> cc: wiki.ubuntu.com/TechnicalBoard
<mdz> cc: tuberculosis
<dholbach> mdz: come on, it's not that bad
<cc> mdz: heh, funny :) 
<ogra> lol
<dholbach> doko: you need some cheering up
<dholbach> doko: that's absolutely not polite
<jdub> dholbach: just turning bullet points into text
<dholbach> jdub: hrm
<fabbione> mdz: i did add a few comments to AudioInfrastructure and (i think) explained some of the questions you had. Can you please review it again?
<jdub> the editors don't like bullet points ;)
<fabbione> one of the editors still uses fedora
<fabbione> we should hang him in a public place!
<dholbach> jdub: my approved specs HAVE bullets
<thom> the other is on winxp, so neither of them have taste ;-)
<Kamion> Speedy2: note reassignment; cdrom-detect has no drivers
<fabbione> we will burn the others on the highest hill in Sydney
<Kamion> dholbach: as long as the *entire thing* is not un-fleshed-out bullet points :)
<jdub> dholbach: maybe they're getting softer now they have so much to do ;)
<dholbach> HRM
<tseng> jdub: i use bullet points on wiki alot just to force sane line breaking
<tseng> easier than [[BR] ] 
<jbailey> Easier than learning the wiki syntax of the week.
<mako> cc: tech board
<cc> mako: yah, since been fixed; i did have a comment, sent back to you
<mdz> fabbione: are you sure that you mean an applet, rather than a daemon?
<mdz> fabbione: that is the only point that does not make sense to me
<fabbione> mdz: a daemon should still be able to connect to the local X server to show up something to the user. an applet serves that task imho
<mdz> fabbione: an applet is something which displays an icon on the panel
<mdz> we don't want an icon on the panel
<fabbione> mdz: hmmmm
<fabbione> so what do you suggest instead to notify the user?
<pitti> mdz: hm, we don't?
<pitti> mdz: well, we additionally want to pop up a message asking whether to make the new card the default
<pitti> mdz: ... and whether to configure it (mixer)
<fabbione> pitti: i think we forgot that part out of the specs
<pitti> mdz: if this message box explains where to change this setting, we can do without a notification applet
<pitti> fabbione: "#
<pitti> On a hotplug add event, a dialog should appear asking whether to make this
<pitti>     *
<pitti>       device the default and offer to set the mixer levels.
<pitti> "
<fabbione> oh yeah we did
<pitti> fabbione: oops, broken formatting
<fabbione> np
<pitti> mdz: so what about s/panel applet/user daemon/?
<tfheen> I would use "session daemon"
<pitti> yeah, sounds fine
<mdz> yes
<mdz> in fact, I think you could use event-notifier
<tfheen> since it's connected to the session and aren't stuff like @reboot cron-based daemons which could be considered user daemons.
<pitti> since we want to use hal anyway, we already have dbus
<pitti> but for dbus we need a permanently running daemon, don't we`
<pitti> s/`/?/
* ogra wonders why smileys are enabled in the wiki....
<fabbione> pitti: i leave the last call to you. for me any solution is ok, given that i won't implement it :)
<pitti> fabbione: easiest thing would actually be to add it to gnome-volume-manager (*hackhack*), that saves another daemon
<pitti> fabbione: and given that "volume" can be interpreted as "sound related", this would actually fit :-)
<pitti> no, seriously, I'm not sure about this
<mdz> pitti: event-notifier is already there and listening, and it has a generic name :-)
<fabbione> pitti: <crack>go for it</crack>
<pitti> mdz: sounds fine, but I thought e-n was mostly vaporware for now. I'll talk to mvo
<mdz> pitti: it is the daemon currently known as update-notifier, formerly known as uprgade-notifier ;-)
<mdz> s/uprg/upgr/
<pitti> mdz: ah, that one. Yeah, sounds fine
<fabbione> oh using that one is EASY!
<pitti> mdz: I already tried to abuse that for crash reporting, but that gives us some trouble, so we won't
* fabbione just implemented it for the kernel
* pitti thinks that qualifies fabbione to write it
* pitti runs away
* fabbione sends some fireballs towards pitti, crossing all of global
* pitti gives fabbione another dildo to calm him down
<fabbione> pitti: you want to retest the crashreporting with the latest gamin
<pitti> fabbione: ENOBREEZY
<fabbione> pitti: that have the inotify backend turned off
<fabbione> ah ok
<pitti> fabbione: I don't want to upgrade my box, that'll cost $1000 or so...
<fabbione> pitti: i only have glibc from breezy :)
<pitti> fabbione: me too
<lifeless> http://fun.sdinet.de/pics/windoof/longhorn.jpg
<lifeless> http://fun.sdinet.de/pics/windoof/longhorn.jpg
<tseng> lifeless: thats more riced out that gdesklets on crack
<lifeless> don't blame me ;)
<fabbione> pitti: are you going to clear up the last bit from AudioInfrastructure
<fabbione> ?
<tseng> lifeless: i wonder how far that is from real.
<fabbione> lifeless: we just figured that one of our last baz commit did corrupt some chars in the kernel tree...
<pitti> fabbione: sure
<seb128> ogra, I've updated the wiki for the audiocd stuff if you want to read it
<Lathiat> lifeless: heheh. :)
<fabbione> lifeless: you really want to be part of the kernel team now.. don't you?
<ajmitch_> lifeless: we *need* bling like that!
<lifeless> fabbione: say what ?
<ogra> seb128, thanks, i'll do :)
<seb128> cc, LaunchpadIntegration for review if you want to look on it
<Lathiat> man, eog displaying a 14M jp thast 10,000x10,000 uses 42% of my 512M ram, crack.
<fabbione> lifeless: last commit we did to the kernel baz archive did corrupt stuff around....
<fabbione> lifeless: so we were giving you the welcome to the kernel team as tre rebuilder :)
<carlos> cc: How are we supposed to ask the questions you put in the wiki? ( I'm talking about: "is RosettaLanguagePackExport done?")
<fabbione> s/tre/tree
<lifeless> fabbione: that baz version ?
<carlos> cc: pinging you here? going to talk with you directly?
<tfheen> carlos: answer them in the spec.
<cc> carlos: well, no, it was just a question in jest i guess
<cc> carlos: but answer it in the spec
<cc> seb128: where? udu or launchpad one?
<carlos> ok
<fabbione> lifeless: Version: 1.4~200504250634
<lifeless> fabbione: hmm. weird
<lifeless> fabbione: when you say 'corrupt' what do you mean ?
<cc> seb128: LaunchpadIntegration needs to go for review again; i've sent it to your queue
<lifeless> fabbione: oh and -izgtkbug
<pitti> mdz: btw, seb recently forwarded me the mail thread about Cooperative Bug Isolation. Since this will blow up our packages and is not a general solution, I think this is not really desirable
<mdz> pitti: regarding AutomatedTesting, I'm not convinced that 'check' should be a dependency of 'binary'
<mdz> I think we should be able to enable/disable the tests independently of the build
<pitti> mdz: it would be nice for at least packages where it makes sense, so that a build will FTBFS
<mdz> the simplest way is to explicitly invoke check
<pitti> mdz: so we avoid publishing regressions
<pitti> mdz: explicitly invoking is fine, too, but requires buildd changes
<pitti> mdz: if that's not a problem, fine for me
<mdz> pitti: dpkg-buildpackage?
<mdz> I believe sbuild uses dpkg-buildpackage
<pitti> mdz: hmm, why do you think a dependency would be evil?
<seb128> cc, k, thanks
<mdz> pitti: it would make it difficult to build the package without running the tests
<mdz> pitti: and the tests can be very time-consuming
<pitti> mdz: hmm, ok
<lamont_r> sbuild uses dpkg-buildpackage
<pitti> mdz: so, dpkg-buildpackage --no-check?
<mdz> flac includes comprehensive self-tests which take hours to run on normal hardware
<mdz> though the build requires only minutes
<mdz> pitti: yes, something like that
<pitti> mdz: ok, sounds sane
<pitti> mdz: I will update the wiki page
<fabbione> lifeless: it did lost a few chars here and there in the commit
<mdz> mvo: regarding IdentifyingPrimaryPackages, the seeds would be another good source of input
<mdz> pitti: thanks
<mvo> mdz: good point, thanks
<infinity> mdz : sd;fljasd;lkj 
<infinity> sdfasf
<lamont_r> infinity: it works already!
<infinity> Oops.
<infinity> <cough>
<infinity> mdz : We can't invoke debian/rules check in dpkg-buildpackage, cause we have no way of knowing if it's there.
<infinity> mdz : It was the same reason for not having dpkg-buildpackage call build-arch
<infinity> mdz : We can't test for non-make targets...
* infinity stares at jbailey.
<tfheen> infinity: you can, scott argues.
<tfheen> infinity: using -np
<Unfrgiven> i just computed an md5sum on mako's file (as he instructed) but got a different checksum to what he specified in the email. anyone else have the same problem? im just wondering if gmail messes with the file at all
<infinity> Then why was the build-arch thing shot down not that long ago?
<tfheen> infinity: that was doogie
<infinity> What, precisely does -np do?
<infinity> CDBS2 aims to have wildcard targets, apparently.
<infinity> Which blow any detection out of the water.
<Keybuk> infinity: actually, it doesn't, because make expands the wildcard target if given arguments
<fabbione> Unfrgiven: md5sum is correct.
<fabbione> no problems here
<Keybuk> so build-% shows up as build-arch if you do "make -pn -fdebian/rules build-arch"
<infinity> Right, which is wrong.
<Unfrgiven> fabbione: uggh... damn gmail... i noticed that the file was in dos format as well even though I downloaded it through firefox on ubuntu
<infinity> If your rules file is a wildcard that calls a shell script, the "target" will always exist, even if it isn't supported in the script.
<infinity> So, we call it and fail miserably.
<mako> Unfrgiven: did you?
<fabbione> Unfrgiven: i can forward to you mako's email to another address if you want
<fabbione> but you will need to trust my file
<fabbione> or compare it with the one you got from mako
<mako> no.. he only needs to trust the md5 sum
<Unfrgiven> mako: i didnt understand your question
<Unfrgiven> ive got it now guys, thanks
<Unfrgiven> i got it off mako's website
<fabbione> mako: right.....
<mako> http://mako.yukidoke.org/projects/ksp-udu/ksp-udu.txt
<Unfrgiven> mako: thanks mako
<Unfrgiven> must remember these gmail-isms in the future...
<mako> Unfrgiven: no problem :)
<mdz> mako: dude, your keysigning instructions are buggy
<mako> mdz: dude.. i organized it in like 20 minutes
<lifeless> fabbione: I'm not clear on what that means
<mako> mdz: file bugs in malone ;)
<mako> mdz: whats the bug?
<mako> mdz: is it with the website or the email?
<mako> or is it the numbering issue?
<mako> 1, 2, 4
<mdz> mako: you had an entire BOF Slot scheduled for preparation! ;-)
<mdz> mako: 1, 2, 4, and it is missing important bits
<mako> yeah, 1 hour before it started :)
<mako> mdz: which part?
<mdz> mako: like verifying that your fingerprint is correct in the file
<mako> oh fuck
<mako> it is
<mako> i will follow-up
<mdz> mako: I would also argue that there is a hypothetical attack possible unless you verify that there is one, and only one, key in that file which could be associated with you
<mako> mdz: no, that's not an attack
<mako> mdz: because you will verify the keys in the file by number
<mako> welll.. ok
<mdz> mako: by verifying your fingerprint and the md5sum, you are asserting "that file contains my key"
<mako> you will say "#60 and #61 are mine"
<mdz> yes, that would be another way, if you verified the number
<mako> well, it's sort of a logistical necessity
<tfheen> thom: around?
<mako> because people need to check it off on their piece of paper
<pitti> lamont_r (cc mdz): if we call debian/rules check explicitly without a dependency, will it be a problem if the invocation fails because the target doesn't exist?
<mdz> pitti: no; it can be handled the same way that 'clean' is
<mdz> well, sort of
<fabbione> pitti: and what if it exists but it doesnt do what is supposed to?
<pitti> mdz: but can you tell apart "target doesn't exist" from "test failed"?
<pitti> lamont_r: ^
<thom> tfheen: yes, in the bar
<mdz> pitti: right, that would be the issue
<mdz> pitti: supposedly it is possible to test whether a makefile supports a given target
<pitti> mdz: it was the primary reason why we made it a dependency
<mdz> zsh seems to do it, though I'm not sure how correct it is
<tfheen> thom: we have a braindump to write up.  Care to come up?
<tfheen> oops, I managed to make emacs segfault.
<pitti> mdz: indeed, bash expands makefile targets as well; could take a look at this
<thom> tfheen: i'm mid edit of shtoomvoip, can we catch up later?
<tfheen> thom: sure
<tfheen> thom: I'm sitting around, just come up when you're free?
<thom> tfheen: sure
<thom> you could come down ;-)
<mdz> pitti: we could also require that the target indicate success/failure in some other way
<mdz> pitti: such as writing to a file
<tfheen> I'm sitting well up here.
<mako> mdz: cool, mailed folks
<mako> mdz: good catch with the missing #3
<thom> tfheen: is dilinger up there?
<tfheen> thom: yes
<mdz> mako: was it purely a coincidence, or was #3 "check your fingerprint"?
<thom> lifeless says he should be in global, unless vieout is quiet, in which case he'll go up
<dilinger> oh yea
<thom> tfheen/dilinger: ^
<dilinger> i have a BOF now, don't i
<thom> yes ;-)
<dilinger> lifeless: global or VO?
<mako> mdz: it was not just that.. i removed something else irrelevant and accidently removed that instruction as well
<thom> dilinger: is VO quite or insane?
<thom> uh, quiet
<tfheen> it's fairly quiet now
<tfheen> just elmo and daniels being nice to each other
<thom> dilinger: he's coming to you
<dilinger> i'll go down to global
<mjg59> Excvept daniel won't get me the fucking cakes
<dilinger> there's no guarantee it'll stay quiet
<dilinger> unless he's already on his ay
<dilinger> way
<thom> he's already on the way
<dilinger> ok
<fabbione> dilinger, lamont_r: adding the abinum to the debversion as 2.6.X-ABI-1 doesn't work
<fabbione> otherwise we need to release a different orig.tar.gz for each abi change
<fabbione> what about 2.6.X-ABI.1 ?
<elmo> mjg59: that you're a whole 2 feet from
<dilinger> fabbione: epoch! ;)
<fabbione> dilinger: ahahha
* fabbione doesn't want to roll orig.tar.gz for abi changes
* dilinger doesn't blame you
<fabbione> dilinger: i suggest to switch to point release...
<fabbione> what do you think?
<mdz> fabbione: 2.6.X-ABI+debver? ;-)
<fabbione> mdz: 2.4+2.6.X*ABI/debver^"
<fabbione> mdz: "+" will break even more
<zyga> what are you guys breaking?
<mdz> THE WORLD
* fabbione reverts the changes from done to fucked up in the wiki
<zyga> nah, politicians do that
<fabbione> zyga: right
<fabbione> we break MAIN AND UNIVERSE AND MULTIVERSE AND RESTRICTED
<fabbione> we are more cool than politician
<jbailey> Dude, we need Westley Crusher.
<jbailey> Only he can save the multiverse.
* fabbione starts to show the first sympthoms of skyzophrenia and muktiple personalities
<zyga> oh geez... that australian sun must have boiled your brains ;-)
<zyga> *THAT'S INSANE* ;-)
<cartman> hehe
<jbailey> The sun today is wet and dripping.
<cartman> btw is there a ubuntu amd64 channel?
<fabbione> yeah.. it's dripping blood of all the virgins we had to sacrifice last night to survive till today
<jbailey> fabbione: JaneW did remarkably well at Mao yesterday...
<fabbione> cartman: not afaik
<cartman> ok
<fabbione> jbailey: oh? ehhe
<jbailey> cartman: Pretty unlikely, the arch tends to Just Work.
<cartman> jbailey: :)
<cartman> I can't seem to apt-get mono on amd64
<jbailey> cartman: You're more likely to find channels for crazy things like Sparc..
* jbailey hides.
<zyga> jbailey: openoffice2 Just Doesn't (tm)
<cartman> so wondrered
<cartman> zyga: yeah that monster
<jbailey> zyga: Same as on PPC, probably best to send it to bugzilla.  Not alot of hacking happening this week.
<pitti> mdz: I updated AutomatedTesting, shall I leave MZQueue and EditedSpec? 
<zyga> cartman, jbailey: is that a java issue there or is just something plain broken?
<cartman> zyga: OpenOffice is not 64bit clean afaik
<zyga> cartman: yeah I remember it was being compiled as 32bit stuff
<thom> cartman: 2 should be
<tfheen> cartman: mono will work on amd64 after UDU when tseng gets around to uploading a new version.
<cartman> tfheen: cool
<tfheen> thom: it's not.
<cartman> thom: good to know
<cartman> oh well
<thom> tfheen: i said should be ;-)
<tfheen> but it's far, far, far closer.
<zyga> btw I've heard that oo is pretty short on developers
<zyga> is that true?
<tseng> sortof
<tfheen> don't know
<cartman> zyga: yeah
<tseng> its short on non-sun developers
<tfheen> it's too bloody big.
<cartman> I heard they use german comments ;=
<cartman> ;)
<tfheen> cartman: it has its basis in staroffice which was developed by germans
<tseng> tfheen: mono is building right now.
<tfheen> tseng: you're not doing uploads from here?
<tseng> no.
<cartman> tfheen: there was a fun discussion about importing its doc filter to kword where people wouldn't understand those comments :)
<tfheen> cartman: heh
<zyga> geez german comments ;>
<zyga> somebody should adapt babelfish for comments I guess ;] 
<cartman> hehe
<zyga> commments.pot
<zyga> 150MB
<cartman> rofl
<zyga> 0 of 12452336 untranslated messages, get to work ;] 
<zyga> s/un//
<lamont_r> fabbione: what about just making the version include the abi number?  ala linux-source-2.6.12_2.6.12-1-27
<zyga> lamont_r: that's a lot of version numbers to parse
<fabbione> lamont_t: that requires an oirg.tar.gz upload each abi bump
<fabbione> meh.. orig
<zyga> lamont_r: how about 2.6.12_xxx_abi_whatever ? (with 'abi')
<fabbione>  dpkg-source -b -i linux-source-2.6.12-2.6.11.91/
<fabbione> dpkg-source: warning: source directory `./linux-source-2.6.12-2.6.11.91' is not <sourcepackage>-<upstreamversion> `linux-source-2.6.12-2.6.11.91-1'
<fabbione> dpkg-source: building linux-source-2.6.12 in linux-source-2.6.12_2.6.11.91-1-1.tar.gz
<fabbione> that's with 2.6.11.91-1-1 in the changelog
<lamont_r> fabbione: so rename hte .orig.tar.gz...
<lamont_r> since that says upstream version is '2.6.11.91-1'
<fabbione> lamont_r: dude.. it's a 50Mb of upload each abi change and a NEW approval from james....
<lamont_r> fabbione: yeah
<fabbione> elmo would hang me on the top of the empire state building
<lamont_r> fabbione: I'm sure he'd find somewhere closer...
<pitti> cc: AudioInfrastructure edited and reassigned
<tfheen> mdz: around?
<mjg59> http://www.makezine.com/blog/archive/2005/04/hacking_in_iraq.html - Ubuntu CDs being distributed in Iraq
<jbailey> mjg59: Great.  Like it's not hard enough to visit the US as it is...
<jsgotangco> good evening evil .au users
<dilinger> fabbione: i got caught up in a BOF.  have you given in and decided to go the epoch route yet? :)
<fabbione> dilinger: die :)
<thom> infinity: fancy visiting the bar quickly?
<mjg59> thom: For b33r?
<fabbione> thom: too many jacket and ties at the bar :)
<thom> no, for ServerTeam spec
<thom> fabbione: you'd like the skirts though ;-)
<jsgotangco> wooo
<fabbione> dilinger: i am more for -ABI.debnum
<mjg59> Bah
<fabbione> thom: i saw them already passing by :)
<thom> fabbione: heh
<fabbione> thom: that's why your call was suspicious
<thom> mjg59: b33r in 30?
<thom> fabbione: *g*
<mdz> tfheen: yes
<fabbione> mdz: are you free now?
<mjg59> thom: SUBSCRIBE
<tfheen> cc: what's up with 
<cc> tfheen: wqith what ?
<tfheen> cc: uhm, what's up with buntu and EarlyUserspace?
<fabbione> mdz: mdz: (nothing urgnet)
<cc> tfheen: have i even looked at 'em. hmm
<tfheen> cc: that is, are you insanely overworked and I should go away or haven't you seen them?
<cc> tfheen: haven't seen 'em yet
<tfheen> cc: ok, I'll go away then.
<cc> tfheen: seeing earlyuserspace now
<dilinger> fabbione: the main problem i'd see w/ that is things considering all uploads a NMU (an issue for the debian BTS; i'm not sure whether any ubuntu infrastructure would behave differently because of it)
<fabbione> dilinger: we don't care.. it's a point release
<fabbione> we don't have NMU as a concept
<fabbione> we all maintain everything or along that line 
<dilinger> ok
<seb128> cc, what's the issue with AudioCDBurning ? The number of issues ? I don't expect to get a reply from upstream that fast by example, what are we supposed to do ?
<cc> tfheen: i'm satisfied with earlyuserspace; but i want simon to read it, so i'm going to push its status up, but let simon read it
<tfheen> cc: it's the second time it passes you, but sure, your call. :)
<cc> seb128: more like place the bottom at the top; i.e. the conclusion (i.e. what system do you want) at the introduction. so if its serpentine, say why you're basing on that. or the other
<seb128> k
<jbailey> cc: Thanks. =)
<seb128> thanks
<cc> jbailey: ta.
<cc> seb128: and if you fix that, i'll up your status
<cc> but let simon read it too
<seb128> k
<jbailey> cc: WindowsInteroperability got punted back, I think we've editted it right and passed it back to your queue.  Is there anything we should do to tell you that it might be worth just looking at the diff?
<cc> jbailey: i'll look at the diff, tbh
<jbailey> cc: Cool.  I'd hate for you to have to go through the whole thing just for a few edits.
<cc> jbailey: ja. that'd drive me insane
<jbailey> cc: We'll know that's happened when your tourettes extends into the spec's you mark as editted ;)
<Kamion> tfheen,ajmitch,Keybuk,thom: I'm creating a new InitProcess BOF for coordination between DependencyInit and UdevRaces, to make sure the overlap between them doesn't result in too much confusion when we actually come to implement them
<tfheen> sounds fine
<Kamion> dilinger: ^-- for you as well :)
<ajmitch_> Kamion: alright
<thom> Kamion: thanks dude
<infinity> Kamion : Don't forget to sign me up for that one.
<Kamion> infinity: oh yes, I added you as well already
<infinity> Kamion : Snazzy.
<seb128> cc, AudioCDBurning updated if you can take a quick look on it
<cc> seb128: i will, definitely
<seb128> thanks
<cc> seb128: not quite what i wanted, but i think we'll let simon look at it further. he's mr. english anyways. but its technically sound, generally
<ctd> daniels: my vga out stopped working, fix it.
* Lathiat grins
<daniels> ctd: figment of your imagination
<astharot> ciao
<eruin> has anyone reported aspell issues in breezy?
<eruin> I think I saw something, but I can't find it on bugzilla nor lists anymore
<cartman> eruin: I got some problems but define yours
<eruin> cartman: undefined symbols error keeping, say, bluefish from starting
<eruin> resolved by downgrading to hoary version
<cartman> eruin: cxx related symbols?
<cartman> it seems to miss some stdc++ symbols here, I guess a linking problem
<eruin> now that I wouldn't know
<eruin> :p
<cartman> eruin: eh
<eruin> sigh, launchpad search isn't quite optimal
<eruin> cartman: https://launchpad.ubuntu.com/malone/tasks/403/+edit
<eruin> cartman: I get the same, not while starting gaim, but bluefish
<cartman> not related to mine
<eruin> :/
<eruin> I don't think anyone is actually watching launchpad ;-)
<Robot101> mjg59: been fiddling with some network stuff in perl. tcp over DNS is easier really...
<astharot> Robot101: ozyman ?
<Robot101> hm?
<Robot101> just because nstx is so poor
<astharot> what do you use for tcp over dns ?
<Robot101> scabbing free wireless :)
<astharot> lol
<astharot> ever tried ozyman dns ?
<Robot101> no, hmm
<astharot> try it
<Robot101> excellent
<astharot> it does ssh over dns
<Robot101> wasn't aware of that, or too keen on setting up NSTX... :)
<astharot> eheh
<astharot> but that one is multi platform
<astharot> nstx is just for linux
<Lathiat> is 'prelink' crack?
<Unfrgiven> hey all
<Unfrgiven> is there a good way to batch sign a bunch of keys without entering in my passphrase for each one?
<Lathiat> i think theres a script for it
<Unfrgiven> do you know where i could get it?
<eruin> Lathiat: yes, prelink is crack
<Treenaks> and very BAD crack at that
<eruin> agreed
<Lathiat> right, i thought so
<Lathiat> does it actually make a difference?
<Treenaks> it might be a bit faster
<Lathiat> noticably, faster :)
<Treenaks> Lathiat: ask on www.funroll-loops.org
* Lathiat laughs
<Treenaks> Lathiat: it's definately more annoying
<Lathiat> Treenaks: how so?>
<Treenaks> Lathiat: (re-prelink on every library upgrade \o/)
<Lathiat> eww
<Lathiat> ugly
<Treenaks> Lathiat: and afaik libc etc. can't be shared in memory
<Lathiat> eww
<Lathiat> total crack. :)
<Treenaks> and it only affects startup
<Treenaks> not runtime performance
<Lathiat> someone should make someone remove it from ubuntuguide.org :)
<Lathiat> Treenaks: oh yeh i know that
<Treenaks> it's on ubuntuguide.org?
<Treenaks> CRACK
<Lathiat> yeh
<Lathiat> "How to make programs run faster? (prelink)"
<Lathiat> also, there are no sane documentation on how to decently install ndiswrapper
<Lathiat> i hate wrong documentation :\
<Lathiat> its so easy with ubuntu
<Treenaks> Lathiat: fix it ;)
<Lathiat> module-assistant auto-install ndiswrapper
<Lathiat> none of this compiling from source crap
<Lathiat> (manually)
<Treenaks> oh that yes
<Lathiat> module-assistant is cool
<Lathiat> i only just discovered it today
<Treenaks> Lathiat: mail Chua Wen Kiat about it
<Lathiat> it totally rocks
<jsgotangco> Chua Wen Kiat is joining documentation (at last) so we'll get to fix a lot of stuff
<Lathiat> all we need is some magic that rebuilds each one you auto-install when new kernel versions are installed
<Lathiat> andit'd be all set.
<Treenaks> Lathiat: ndiswrapper modules are included, you just need to load them afaik
<Lathiat> jsgotangco: cool
<Lathiat> Treenaks: not until breezy afaik
<Lathiat> its in the 2.6.12 test kernels
<Treenaks> installing ndiswrapper-utils - Userspace utilities for ndiswrapper
<Treenaks> should be enough
<Lathiat> oh, it is in 2.6.10-5
<Lathiat> just ndiswrapper-utils fails to install
<Treenaks> ah
<Lathiat> unless ndiswrapper-modules-1.1 is installed
<Lathiat> so that was a bug
<Treenaks> *headdesk*
<Lathiat> i might try fix that
<Lathiat> so i dropped out of X and stuff
<Lathiat> to do something
<Lathiat> and i cant remember what
<Treenaks> mkfs /dev/hda
<Lathiat> heh
<Treenaks> editing xorg.conf?
<GheRivero> res everyone
<AndyFitz> whats with the topic header ?
<AndyFitz> mom is awake ! ?
<trulux> hah
<wasabi> It seems like evolution in breezy is in a fairly inconsistant state.
<Lathiat> blame UDU
<AndyFitz> no way man  
<AndyFitz> we knew about this when LCA was on
<AndyFitz> there's no excuse  :P  well UDU is a pretty good exvuse
<Burgundavia> meetings for 12 hours a day are no excuse
<AndyFitz> jdub quietly said to me the other day "  oh , you use evolution..   .. better not upgrade to breezy for a while "
<wasabi> oh heh.
<AndyFitz> Burgundavia,  is not the meetins 12 hours a day.  its the badwidth
<Burgundavia> lol
<AndyFitz> 2:30 am here in syd
<AndyFitz> time to go to bed
<AndyFitz> ciao guys ...  update ubuntu-artwork in breezy ROCK
<ali4728> help needed ubuntu mysql server setup / how do I give permission to the users?
<cartman> ali4728: #ubuntu
<ali4728> ??
<mdke> ali4728, the #ubuntu channel is for support and they can help you
<ali4728> yeah they great there
<zul> or #mysql
<zul> oops..
<_nyn_> hi. i've been here the other day complaining that gnome isn't customizable, a claim that was boldly denied by others in this channel. and now one my greatest fears about this [perceived, if you will]  rigidity has been confirmed: there is no way to change the menu root structure: it is just hardcoded.
<_nyn_> is that also considered acceptable/desirable? to have the root menu structure hardcoded?
<_nyn_> oh, and i really can't believe that the thing *is* really hardcoded... i'm waiting for someone to tell that it isn't...
<astharot> ciao
<mdke> _nyn_, you need to consult gnome bugzilla about that
<mdke> this channel is not the correct place
<_nyn_> there is no irc channel for discussion of the design issues of GNU/GNOME/*?
<mdke> _nyn_, there may be, but its not this one
<_nyn_> :)
<mdke> _nyn_, you can try irc.gimp.net i think
<robertj_> heya all, does anyone know if there is anything specific with the livecd that would prevent it from creating files larger than 2gb?
<robertj_> or more accurately, might cause a program to think that it wouldn't be able to create files larger than 2gb even on a network mount
<bur[n] er> smbfs??
<robertj_> hrmm, yeah
<robertj_> could that be it?
<bur[n] er> is that how you're mounting it?
<bur[n] er> it's a windows share?
<robertj_> yeah, thanks
<bur[n] er> yw?  
<Lathiat> might be possible windows wont take a file larger than 2GB
<bur[n] er> :)
<Lathiat> afaik, it doesnt
<Lathiat> at least on fat32
<bur[n] er> well...
<robertj_> Lathiat: who uses ffat32 anymore ;)
<bur[n] er> smbfs may not check to see if it's fat or ntfs
<bur[n] er> fat can't be 2 gigs
<robertj_> its actually hfs
<robertj_> hfs+ to be exact ;)
<bur[n] er> even still...
<bur[n] er> smbfs 'may' just assume fat?
<robertj_> yeah, I'm reading up
<bur[n] er> i don't know the validity of that claim :)
<bur[n] er> but sounds rational
<robertj_> I thought it was partimage checking something with the kernel
<robertj_> but smbfs sounds more reasonable
<robertj_> I cheated and just split the file into chunks ;)
<bur[n] er> aww, part image
<robertj_> you have feelings about partimage?
* bur[n] er still uses norton ghost on a windows PE bootable cd :)
<bur[n] er> it's just not as simple and automatic
<robertj_> burner: did you read norton's licencing agreement?
<bur[n] er> they dont' allow that?
<robertj_> your supposed to have one ghost licence per hd
<bur[n] er> ooh
<bur[n] er> ouch
<robertj_> so theoretically if you ghost 100 hds you are supposed to dole out $15/piece for some enterprise licence
<robertj_> which also of course comes with tons of crap you don't need
<bur[n] er> naturally
<bur[n] er> i've been lookign for a solution for some time
<bur[n] er> partimage is ok, but it's not a readable format
<bur[n] er> a nice .tar.bz2 would be nice
<robertj_> so partimage seems nice, if it had a gui and integrated with gnomevfs and if gnomevfs wasn't the worst vfs I have ever used, then it would be great
<bur[n] er> mount a network share, and tarball up the drive so it can be read by any old file-roller or winzip :)
<bur[n] er> lol
<bur[n] er> gnomevfs is getting better
<robertj_> burner: I'm thinking I'll do windows backup wizard to OS X smbfs
<robertj_> burner: slowly, and ftp was agonizing yesterday
<bur[n] er> to each their own :)
<bur[n] er> simply safe backup is free on windows
<bur[n] er> nto sure if it could be popped on a livecd though
<robertj_> burner: well professional includes the backup utils as well
<bur[n] er> can it work from a livecd though?
<bur[n] er> how you supposed to copy files that are in use?
<bur[n] er> windows doesn't like that :)
<robertj_> burner: dunno, it will eventually get a copy of everything though
<robertj_> the real risk I suppose is your email client getting it's message store lost because you never close out
<robertj_> but I guess the real answer would be have the machine log out and do it at night
<robertj_> I only am interested in the Documents and Settings folder though
<robertj_> Carbon-Copy-Cloner on the Mac is great though, having a Gtk Version of that would be great
<Lathiat> man why do i always get sucked into helping in #ubuntu when im there
<Lathiat> i think i pity all the people getting back advice :\
<bur[n] er> if you only want docs & settings, why even partimage :)  just 'cp' :)
<robertj_> burn: well this is for the initial rollout
<robertj_> GhettoGhost
<bur[n] er> awww, i see
<bur[n] er> ghetto fab :)
<bur[n] er> hope it works for ya
* bur[n] er googles for partimage gtk interfaces
<sivang> hey all
<trulux> hey sivang 
<sivang> yo trulux , what's up? are you in UDU ?
<trulux> sivang: no, I've contacted Mark asking for the sponsorship he did for some devs but still no reply
<trulux> I'm sad about not going to the UDU
<trulux> but that's life.... 
* trulux has now another problem, a broken screen
<trulux> sivang: it's not my day <- s/day/week/
<sivang> trulux: ah well, I've felt that way for some time, but things will get better, I can promise.
<sivang> trulux: :-)
* Lathiat ponders
<Lathiat> given marks background, youd think ubuntu.com could have a real ssl certificate. :)
<trulux> Lathiat: why? isn't it a bit fascist to trust an enterprise for giving you something you can have done at your own for free?
<trulux> Lathiat: It's the monopoly of SSL certificates, dumb thing that it's supported by more than just one funky man
<trulux> Lathiat: better if Mark puts some money on open infrastructure like OSDL does with their distributed compilation and testing network
<trulux> it simply would rock
<Lathiat> ssl certificates are hardly that expensive :)
<Lathiat> but yeh
<trulux> Lathiat: at least the money that it normally costs can be spend to feed those can die tomorrow because of starvation, that's sufficient for me to think on *not* investing any money in certificates (dis)authorities
<fabbione> hey doko
<moquist> jdub: pong
<jdub> moquist: hey
<jdub> moquist: i'll remember in a moment :)
<fabbione> jdub
<jdub> morning fabbione 
* fabbione feels aussied
<HrdwrBoB> aussie++
<fabbione> jetlag is already hitting back
<pitti> Hey folks!
<pitti> what a ride...
<fabbione> hey pitti
<fabbione> yeah
<pitti> Hi fabbione 
<pitti> had a good trip?
<pitti> I had 2.5 hours delay, fine otherwise
<fabbione> pitti: syd -> lon = great
<fabbione> lon -> cph = hell
<fabbione> no delay.. just a royal mess
<Treenaks> fabbione: what kind of hell?
<fabbione> Treenaks: i was supposed to arrive to the hotel in london around 10pm
<fabbione> i was there at 1:30am without money and without being able to cash anywhere to pay the taxi to go to the airport again in the morning
<Treenaks> ouch
<moquist> jdub: heh; k
<dilinger> syd->california flights have been great
<dross> is there a log for #ubuntu-devel. I dropped out a conversation last night because of stupid Charter
<dilinger> california<->nyc flights have been awful.  packed flights, no room at all..
<fabbione> dross: unfortunatly no
<fabbione> hey dilinger 
<fabbione> dross: the log server has been down for almost 3 days
<Robot101> dross: it looks like you dropped out about an hour ago and missed nothing, or do you mean before that?
<fabbione> it come back online not too long ago
<Robot101> oh, 03:33
<Robot101> I have it all in scrollback if you want
<dilinger> fabbione: hey
* fabbione needs to go and crash... too much jeglat
<fabbione> jetlag
<pitti> Hi dilinger 
<dilinger> pitti: hi
<dross> well I was having a conversation with robertj, and how useless it was to reinvent the wheel when there are more near perfect wheels already out there
<mjg59> Beagle is a wheel. We do not wish to reinvent it.
<dross> mjg59: wasn't referring to beagle, was referring to C#/mono implementation
<mjg59> dross: In reference to someone saying something along the lines of "Beagle will soon be in Breezy", you started complaining about Mono
<mjg59> Personally, I'm not that concerned about Mono. However, people are writing high-quality software that uses it, and so it's worth supporting
<mjg59> (since the alternative is rewriting all of that software)
<Treenaks> mjg59: it's a bit like java in that respect :)
<dross> mjg59: theres Python, a language which has been out. Python has been better(python2), has much more libraries, and much more support
<dross> mjg59: mono/C# is useless
<Treenaks> mjg59: "people write cool software for it, but the fact that you need a VM sucks"
<dross> mjg59: its basically a cruch for MS users
<mjg59> dross: I don't really know how to phrase this more clearly. Good software is being written in it. Ubuntu wish to ship good software. The two choices are (a) rewrite that good software, or (b) ship Mono
<dross> mjg59: I'll rewrite it :P
<mjg59> Fine. When you're finished, we can discuss dropping Mono.
<dross> I guess mono could be a good prototype langauge since its useless and not stable everywhere
<dross> it certainly isn't stable on bsd, and won't work well or build on sparc.
<dross> python on the other hand works everywhere. So do the other langauges like ruby. I care about programs that are portable. Mono almost as proprietary as Microsoft for Linux
<mjg59> Sigh. Yes, compilers and VMs tend to be somewhat platform specific.
<mjg59> Python works everywhere because it's been ported to those platforms.
<dross> mjg59: yes, well. Python seemed to write it correctly the first time around. So did Ruby
<dross> mjg59: and why waste time creating another language while there are others. This is what I don't understand.
<dross> Python is the more perfect language(unfortuntely, but I'll use it because its the more perfect dynamic OO language) (*hint: I like ruby design more :P)
<mjg59> I am so unbelievably uninterested in language advocacy that you wouldn't believe it.
<pitti> Hey sivang 
<Treenaks> dross: ruby is what you get when you put python + perl in a box and shake violently
<sivang> pitti: Hey Martin, mjg59
<luis_> surely there must be some channel better suited for a language flamewar?
<sivang> Treenaks: is this a good thing then?
<sivang> Treenaks: (sounds so)
<dross> Treenaks: well. The user commmunity has really screwy ideas, which I like. They seem to implement interesting ways of doing things. Which creates more ideas
* dilinger would like to see muine in ruby
<dross> luis_: you should recognise the difference between flamewar, and intellectual conversation
<luis_> hrm
<luis_> so
<dross> dilinger: unfortunately ruby lacks speed :)
<luis_> perhaps 'flamewar' was too strong a word
<luis_> but 'intellectual conversation' is also quite a bit too strong
<dross> dilinger: I only use it to create ideas. Its one of the slowest langauges I've _ever_ used. Its a good langauge though
<luis_> for at least what I've seen in the past ~10 minutes
<dross> luis_: get used to longer words :)
<dilinger> dross: a muine-alike wouldn't need speed.  gstreamer's in C, the only thing that might be slow is the album cover lookups during the first import (which would probably be slowed down by network more than anything else)
<dross> oh god :P you don't understand how slow this is. 
<bob2> dross: you've actually profiled it and determined it's a C# problem?
<dross> dilinger: I made a nice mysql applet for a server, and client as well. It could only perform about 150-200 users a second. Its slow
<dross> bob2: I'm talking about ruby
<bob2> dross: or are you just assuming that is the case since you already dislike mono?
<bob2> same thing
<bob2> you seem to be a python fanboy
<sivang> guys, isn't this channel supposed to be about ubuntu development?
<Treenaks> Please continue in #flamewars
<bob2> yes
<sivang> for instance, I'd be interested to know what work have been done about launchpad integration lately :-)
<bob2> five trillion specs were generated
<Treenaks> bob2: the fact that they were generated in such an out-of-the-way timezone didn't help me (as non-attendee) tracking it
<sivang> Treenaks: yep ;-)
<bob2> I'm not sure timezones would have been a problem
<bob2> since all the discussion was done in person, anyway
<sivang> bob2: in person? what do you mean? weren't there BOFs?
<Treenaks> sivang: well, aren't BOFs "in person"? :)
<Treenaks> bob2: (assuming you don't mean 1-on-1)
<bob2> they were bofs only in name
<bob2> most were 3-4 people on an assigned task
<Treenaks> hmm..
<bob2> sivang: by "in person" I mean, "even if you were on IRC at the time, there was no discussion for you to participate in"
<dross> bob2: my question still stands, "Why create another langauge when theres others out there?"
<dholbach> hellas!
<pitti>  Hey dholbach, had a good train ride?
<bob2> dross: why judge what other people do with their free time?
<bob2> anyway, this is off-topic and pointless
<dholbach> pitti: car :-)
<dholbach> pitti: you arrived alright?
<pitti> dholbach: yes, I got a later flight at 09:05
<dholbach> bob2: hey! how are you?
<bob2> dholbach: aloha
<dholbach> bob2: i forgot all the VB, i wanted to take to germany
<dholbach> it's a pity
<bob2> haha
<bob2> there's a word to describe that sort of thing, you know :P
<dholbach> ;-)
<dross> bob2: people could be more productive to the rest of the community than wasting time? 
<dholbach> dross: it's volunteer work and everybody chooses himself, what he does in that spar time
<bob2> dross: oh so very off-topic, so last comment, but think about it: it's their time, you have no right at all to tell them what to do with it or to get annoyed if they don't work on what you want
<dross> dholbach: what about the women? :P
<Gandalfar> who is responsible for ubuntu wiki? it seems a bit 404-ed
<dross> Gandalfar: every human is responsible for the wiki
<Gandalfar> dross: I see, yet i'm a bit confused how to fix this one
<Gandalfar> dross: if I go to main ubuntu page, and click 'wiki' I get some error
<luis_> I just got there, but it was slow
<dross> oh, I see.
<dross> AttibuteError
<dholbach> hey luis_ 
<dross> that looks awefully familiar, what is the ubuntulinux wiki written in?
<dross> *awfully
<bob2> zwiki
<dross> I thought so
<dross> I couldn't get the "AttributeError out of my head since I seen it so much :)
<dross> could somebody have deleted the frontpage?
<dross> I bet it was a Gentoo terrorist
<pitti> Mithrandir: here?
<dross> wow.. beagle is a very small application
<Treenaks> dross: yes.. it only eats 100M/day on my work machine
<Treenaks> (SuSE 9.3 version)
<dross> Treenaks: it might take many resources, but its still small.
<Treenaks> uh probably
<dholbach> see you later
<ogra> hello world 
<pitti> Hey ogra
<sivang> hello ogra :-)
<ogra> :)
<sivang> ogra: what's up? 
<ogra> sivang, jetlaging .... trying to stay awake while my body thinks its 20 past midnight...
<ogra> (its afternoon here)
<sivang> ogra: then go to sleep , rest abit what can happen?
<pitti> argh, seb128 does the upload rave again
<sivang> pitti: heh
<sivang> pitti: seb the "chainsaw" 
<ogra> sivang, if i rest now it will be similar tomorrow....so i'll try to get back to normal TZ as fast as possible
<sivang> ogra: ah right, well, small price to pay for attending the conference :-)
<ogra> sivang, sure :) 
<sivang> ogra: anyway nice to see all back in place, now going to back to a more normal time zone for working 
<pitti> bye folks, see you tomorrow
* luis_ takes the breezy plunge
<dholbach> seb128: must feel good to be back, right? ;-)
<seb128> yeah :)
<dholbach> seb128: breezy-changes tells me :-)
<seb128> bah, need to do something to not sleep :p
<seb128> elmo: can you drop evolution-data-server1.2 from universe and sync libgnomeprint quick-lounge-applet libgnomeprintui from debian experimental ?
<dholbach> hey tritium, hey doko__ 
<tritium> hi dholbach 
<tritium> I thought you'd be napping, dholbach :)  How are you?
<dholbach> tritium: i was :-)
<dholbach> tritium: i'm a bit confused about all the time and feel sleepy, but ok
<tritium> dholbach: :-)
<GheRivero> res
<zyga> hello
<cartman> any ETA for a new gcc upload? Current kde cvs blacklisted gcc 4.0.0 as it miscompiles KDE and this is fixed in gcc 4.0 branch
<usual> omg! mom is awake?
<usual> you guys do the devel, where would I find an upgraded packages change log
<Burgundavia> the archive of breezy-changes?
<cartman> usual: http://lists.ubuntu.com/archives/breezy-changes
<cartman> for breezy
<usual> k
<usual> thats what I wanted
<usual> thanks
<cartman> np
<mdz> morning
<luis_> morning, mdz
<dholbach> hey mdz 
<Lathiat> moaning
<usual> ooo
<Treenaks> wow, seb is back in Upload Mode :)
<mako> dude, i have sleep poisoning
<Burgundavia> mako, did you see my email?
<mdz> mako: you live
<mako> mdz: i slept for like 14 hours
<mako> Burgundavia: yep, i saw last night but i was a little too tired to respond
<Burgundavia> mako, np
<mako> Burgundavia: i'm glad that things went well, bummed that whoever was supposed to order cds didn't
<mdz> mako: I slept a bunch on the plane, got home in the early afternoon, stayed up until a reasonable hour, went to sleep, and then fought my way awake at like 1100
<mdz> and I think I'll be OK from here
<mdz> going the other direction was far worse
<mako> mdz: hopefully last night was just recovering from the trip and i'll be alright from here on out
<Burgundavia> mako, it still worked out. We were to be the only distro with cds there
<mako> Burgundavia: nice
<mdz> there was no period of time that I could have slept on the plane which would have aligned me time-zone-wise
<mdz> mako: don't forget about the weekend after next
<zyga> seb128: ping
<seb128> pong
<zyga> seb128: I'm trying to make that lshal output usefull now
<zyga> seb128: but I've found something strange, can lshal ... hang?
<seb128> I don't think so
<zyga> seb128: after 'logging in' with the broken cd in drive the system hanged (even gnome-panel was hanged for a moment)
<zyga> seb128: I've quickly logged in on tty1 and did
<zyga> lshal > lshal.out
<zyga> and ... lshal hanged as well
<zyga> after a moment (30 seconds) everything went on just as usual
<zyga> I cannot eject the cd now
<zyga> pressing the button on the drive opens the tray
<mdke> do launchpad bugs get files under distribution:Ubuntu?
<zyga> but it immediatly comes back (even though I'm no longer attempting to mount the cd)
<seb128> how have you broken the CD on this way ?
<zyga> seb128: It's a semi writtien cd-r disk
<zyga> seb128: burining 'succeeded' in k3b but the disk is dead
<zyga> seb128: my dad was trying to clone an audio disk
<zyga> seb128: what should I do to eject the disk?
<zyga> seb128: could any lsof / lshal output be usefull for you?
<zyga> seb128: note, lshal hangs ATM
<zyga> seb128: lsof goes on allright
<zyga> seb128: join #flood please
<seb128> to be honest I've no clue about this bug
<seb128> I doubt than anybody else is going to screw a CD on this way
<seb128> and I don't get the bug
<zyga> the last two lines appeared after about a minute
<mdz> sounds like a hardware problem
<zyga> mdz: broken drive?
<zyga> seb128: anyway I'm more than willing to offer any help (even shell account on the offending box) if you'd like to investigate this 
<seb128> I've around 300 bugs waiting
<seb128> and that's not really a top priority to be honest
<zyga> seb128: undestood
<zyga> :-)
<zyga> seb128: sure
<seb128> but thanks for the help
<seb128> if you can look wheter hal detect the correct media type
<seb128> if not that's a kernel/hal/hardware issue
<zyga> seb128: I'll look at that lshal output and notify you if there is anything relevant there
<zyga> thanks
<seb128> you're welcome
<mdz> mdke: no, launchpad bugs get filed in Malone
<mdke> mdz, sure, i know that, but do you know where in malone?
<dholbach> hey jbailey 
<mdz> mdke: https://launchpad.ubuntu.com/malone/products/launchpad
<jbailey> Heya Daniel! =)
<dholbach> :-)
<mdke> mdz, i'll try poking around there. at the moment malone is asking me for a linux distribution and source package to file it under
<mdke> mdz, ok yes got it, thanks
* ogra yawns
<dholbach> hey ogra 
<ogra> hey dholbach 
<dholbach> see you tomorrow
<ogra> ciao dholbach 
<Burgundavia> elmo, ping
<abelli> ciao
<Lathiat> Is there an irc channel for projec tutopia?
<Lathiat> like udev, hal, hotplug and stuff?
<GheRivero> res
<zyga> ls
<zyga> ... wrong terminal
<Echylo> haha zyga :S
<Burgundavia> I am edit RootSudo to be cleaner. Is this true? --> Using sudo as opposed to gksudo/kdesu can sometimes lead to file ownership problems.
<ogra> Burgundavia, http://udu.wiki.ubuntu.com/UsingSudo
<ogra> (not yet approved)
<Burgundavia> hmm
<Burgundavia> ok
<ogra> and no, it should be similar as long as you dont use switches in the commandline sudo
<Burgundavia> I have mostly edited the wikipage so that it emphasizes sudo as good
<Burgundavia> ok
<Burgundavia> then I will remove the sentence from the page
<ogra> ok
<Burgundavia> ok, I significantly rewrote the page
<Burgundavia> https://www.ubuntulinux.org/wiki/RootSudo
<Burgundavia> can I get some feedback from a dev?
<ogra> Burgundavia, please get in contact with sladen about it, since he has this task on his todo list...
<Burgundavia> ok
<ogra> oh :(
<ogra> you ripped my favorite comment off
<ogra> (from stuart bishop)
<Burgundavia> me?
<lamont_r> ogra: he stole it, or removed it?
<ogra> dunno, its gone...
<Burgundavia> oh, I gutted all the comments
<Burgundavia> I felt that they added nothing to the page
<ogra> hmm
<Burgundavia> this is supposed to be documentation, not a chat forum
<ogra> its a wiki....
<Burgundavia> its a doc that happens to be one a wiki
<Burgundavia> s/one/on
<ogra> but if it offers the option to add comments, they should stay there..... 
<Burgundavia> ogra, I am looked at it from a doctem perspective. Do the comments add to the doc? If they do, then leave them, if they don't then they go
<Burgundavia> the less words on the page, the more likely that people are going to read it
<ogra> i found the comment from stub one of the best explanations for the use of sudo though...
<Burgundavia> ok
<Burgundavia> I will try and incorporate it into the doc
<ogra> and especially the sudo thing is a heap bigger then the one page, thats why we had a BOF about it in sydney and sladen took the task to review all of the sudo things on the wiki....
<Burgundavia> there are more pages than just that one?
<Burgundavia> RootSudo is where most people go
<Burgundavia> it is also the default place to send people on #ubuntu
<ogra> thats ok... but sudo is used and mentioned on many pages 
<Burgundavia> true
<ogra> the target is to have a clean explanation and to make sure all the other page follow it
<ogra> (consistency)
<Burgundavia> I just read the comment by stuart
<Burgundavia> I don't see anything in the comment that isn't already said in the page
<ogra> password maintenance is mentioned there.... (i dont remember it from the top of my head, its a while ago since i read it)
* hunger just listens in.
<ogra> but i often cited it by copying and pasting it in private mails with admins i know for example
<ogra> s/cited/quoted
<Burgundavia> ok
<Burgundavia> I am doing some more work on the page right now
<Burgundavia> but generally quotes really don't have a useful place in docs
<ogra> Burgundavia, but please get in contact with sladen....
<Burgundavia> ok
<ogra> and i'm not sure if its right to just wipe out users commets of wiki pages just to make them clearer from a documentation pov....it might upset users...
<Burgundavia> hmm
<hunger> ogra: I won't mind if my glibberish is removed (or moved)
<Burgundavia> does warty have an admin group?
<ogra> hunger, you dont... but i remember cases....
<Burgundavia> I am thinking about the adding users to sudo part
<hunger> ogra: Yes, I took a couple of flames when cleaning up our wiki once, too;-)
<Nafallo> Burgundavia, that group was added in hoary AFAIK.
<Burgundavia> Nafallo, that is what I thought
<Burgundavia> ugh
<ogra> hunger, and if you feel its a valuable addon to the page you would be upset if someone just wipes it out without talking to you...
<hunger> ogra: Wrong... I know that I made valuable addons and so I would be wondering about the mental state of whoever removed my stuff:-)
<ogra> ...since we encourage people to edit and add to the wiki...
<hunger> ogra: Sometimes delusions do help with normal live;-)
<hunger> ogra: I'd edit and add way more, but I am too stupid to find things in the Wiki worth editing.
<hunger> ogra: In fact I can not even find my own stuff anymore!
<hunger> ogra: Whenever I search the wiki I get exactly no result:-(
* hunger would like to contribute more, but is too stupid to find out how/where.
<ogra> might be a wiki bug, dunno.... anyway, its sladens task to care for the sudo stuff, if he is fine with Burgundavia's edititions its ok... i just wanted to point out that there is a bigger task in the works for it anyway...
<Burgundavia> I realize taht
<Burgundavia> the page has been bugging me for a long time
<Burgundavia> but I hate our wiki
<Burgundavia> this is a major event, me editing it
<willis> if you've been following hoary development should you reinstall before you start following breezy?  just wondering, i did myself but i'm wondering whether or not to recomend it to other people
<ogra> Burgundavia, its a task of the UdU spec to have a local documentation for sudo/gksudo, if the spec gets approval, i'd like to have you aboard for writing a sane helpfile
<Burgundavia> that is what the doc team is for
<hunger> Hey! searching the wiki for ubuntu brought some results.
<ogra> Burgundavia, if there is local documentation, you can point people there instead of the wiki :)
<Burgundavia> indeed
<Burgundavia> ok, take a look now
<sm> hunger, what's the problem with search ?
<ogra> Burgundavia, it should be a general explanation, but include either the help or pointers to the help of the certain commands (sudo/gksudo)
<Burgundavia> ogra, hmm, I am not quite understanding
<ogra> Burgundavia, the local documentation described in the spec that is....
<crb> mako: awake?
<Burgundavia> are you talking longterm? patching gksudo/kdesu or are you talking additions to the wikipage right now?
<mako> crb: yes, but about to take a phonecall
<mako> crb: give me a second
<crb> sure thing
<ogra> Burgundavia, quoting from the udu wikipage:
<ogra>  gksudo should have a help button pointing to local documentation that explains the need/usage of sudo and gksudo
<Burgundavia> ok, that is future stuff
<Burgundavia> I was wondering about editing the wikipage just this second
<ogra>  Status: BrainDump, BreezyGoal, DistroSpecification, DraftSpec
<ogra> (breezy goal)
<Nafallo> ogra, all things that have Status: BreezyGoal is Breezy Goals? or just the approved stuff?
<ogra> has to go from draftspec to editedspec though .... and waits for approval...
<ogra> Nafallo, the Approved ones a safe....
<Nafallo> ogra, dang. that's what I thought :-). well, enough things to droll at anyway ;-).
<ogra> Nafallo, the others might go through several edits before approval...
<ogra> cc, do you guys still go on doing the editing ?
<Burgundavia> mako, ping
<mako> Burgundavia: i'm back
<mako> crb: back
<Burgundavia> mako, join #ubuntu-doc
#ubuntu-devel 2005-05-11
<Nafallo> are there any info on how to write initscripts to be compatible with USplash avalible yet?
<jbailey> Nafallo: I think the idea is to use the lsb hooks for the initscripts.
<Nafallo> jbailey, yepp. are those log_begin_msg, log_end_msg and the likes?
<Nafallo> I want to use locate IRL to find my USB-stick and see if I have a backup of my firewall-init.d ;-)
<jbailey> Nafallo: Yup.
<jbailey> You might be able to do some other magic with hal and such rather than locate.
<jbailey> That way the stick doesn't have to be mounted.
<Nafallo> *s*
<Nafallo> jbailey, will your idea with iptables.d be implemented soon now that hoary is out? :-)
<jbailey> I suggested it for the firewalling bof, but I don't know if that became the proposed solution.
<jbailey> Have you looked at the wiki from udu at all
<jbailey> ?
<Nafallo> jbailey, I had a working script. that's what I try to find. I've reinstalled my server, purging it, since ;-).
<Nafallo> jbailey, yepp. I'm rather up2date. there are just so many pages ;-)
<Nafallo> jbailey, I'll go check it out again :-).
<jbailey> Look for the firewalling stuff
<jbailey> It should say where we're going for breezy on it (assuming that it's an approvedspec)
<Nafallo>  Status: EditedSpec, DistroSpecification, MattZimmermanQueue
<Nafallo> missed that one completly :-P
<mako> wow.. a hoary box set: https://www.ixsoft.de/cgi-bin/web_store.cgi?cart_id=2677340_11915
<mako> with a free t-shirt :)
<Nafallo> mako, nice! :-)
<mako> well it's not really free
<mako> you pay 20eur and you also get a t-shirt :)
<Nafallo> and handbook
<mako> really?
<mako> i can't read the german
<mako> very well
<Nafallo> not me either. but Lieferumfang: Box mit CD, dt. Handbuch und T-Shirt, just HAVE to say that :-).
<Nafallo> now I see where swedish got that word from ;-).
<ogra> mako, hmm, it talks about installation support
<mako> handbuch :)
<ogra> yep
<mako> pretty cool
<ogra> i'll order one... to see whats in there....
<Nafallo> ogra, :-)
<ogra> no idea who wrote a german handbook or why we arent aware of that....
<Nafallo> jbailey, I should probably not use iptables.d for future compability in my script I guess? :-)
<ogra> hmm, the "features" talk about GNOME 2.9.4
<Burgundavia> "OpenOffice is superior to all commercial software packages in this Segement"
<jbailey> Nafallo: I still haven't read the bof (doing something else atm), so I don't know. =)
<ogra> mako, it also says its 10 cent cheaper then advised by the original manufacturer....
<Nafallo> jbailey, hehe. you want a direct link for later? :-)
<ogra> Preisempfehlung des Herstellers:  19,90
<ogra> Unser Preis:  19,80
<ogra> hmm, and it's offered under the term "debian for the desktop", funny
<Nafallo> hehe. I just LOVE hoary for my server :-)
<Nafallo> haven't needed to go outside main yet ;-)
* ogra wonders if they have approval for the logo
<ogra> oh, and manufacturer is "OpenSourceFactory"
<jbailey> Nafallo: Sure. =)
<Nafallo> jbailey, msg :-)
<jbailey> tx
<jbailey> Nafallo: Ah, nice.  It didn't change much from the bof I attended then.
<Nafallo> jbailey, I do hope that level-configs can be made from console though...
* lamont_r heads home
<Nafallo> lol. just found my usb-stick ;-)
* ogra pays the jetlag toll
<ogra> night all
<astharot> ciao
<jbailey> g'n ogra =)
<Nafallo> ogra, bye
<astharot> ogra: news about community council ?
<Nafallo> hmm
<Nafallo> gparted should have warned me about erasing my usbkey when converting the filesystem... :-P
* Nafallo files bug #531
* infinity decides his weekend is over and gets to work.
<tseng> hi all.
<Nafallo> hi tseng :-)
<tseng> holy crap i have a real net connection
<|QuaD-> tseng: that means the uploading can begin :)
<tseng> erm
<tseng> oh man evolution is installable too
<|QuaD-> :)
<jbailey> Hey, I've never noticed "Al Gore Ithm"
<jbailey> creepy.
<jbailey> (Who needs drugs, you can just change timezons)
<|QuaD-> my algorithm teacher put that on one of our assignments once :)
<infinity> jbailey : Were you still keen on doing the samba merge?
<jbailey> infinity: For some value of keen.
<jbailey> infinity: I'm still willing to do it, since I have a bug that the merge will fix.
<jbailey> infinity: It won't be today though.  Tomorrow's not looking so good.
<infinity> Heh.
<jbailey> Day after, almost certainly though.
<infinity> jbailey : Well, if I do it today, I'll close your bug.
<jbailey> infinity: Tx.
<infinity> jbailey : Otherwise, I'll leave the whole mess for you.
<jbailey> infinity: luvly.
<Nafallo> hmm
<Nafallo> Karma? :-P
<mdz> are there any UDU photos up yet?
<tseng> i have some I can post in a few minutes
<tseng> i dont have any gallery software setup yet, it will be raw
<dilinger> raw, uncensored UDU?
<tseng> yeah
<tseng> like, your keyboard
<jbailey> dilinger: I think that was Friday night at the Stonewall..
<astharot> mdz: news about community council ?
<dilinger> jbailey: i went to bed before midnight.  i'm an old fart.
<mdz> astharot: what about it?
<astharot> mdz: the date
<mdz> mako would be the best person to ask
<mdz> assuming you already checked the wiki page
<jbailey> dilinger: I stayed up late but decided that I couldn't cope with the smoke.  It gives me hangovers worse than the alcohol does.
<astharot> mdz: yes
<astharot> pitti this morning told me that it will be decided when you'll come back home ;P
<astharot> The next meeting of the Council will be on Apr 13th 2005 at 0400 UTC.
<mdz> astharot: I don't set the schedule for Community Council meetings; the Community Council does
<astharot> ok
<astharot> :)
<tseng> ok dudes, can anyone rebuild libaspell15?
<tseng> it has unresolved symbols atm, maybe from glibc
<zul> hey
<tseng> good test cases are tomboy (create new note) or running gedit from bash
<mako> astharot: yeah.. we need to plan a new cc meeting
<mako> astharot: let me ping the other members
<astharot> mako: eheh ok :)
<Nafallo> night all!
<lamont> mdz: you around?
* lamont prepares to upload 11 packages to main. :-)
<blahrus> lamont: what packages do you work on?
<cc> lamont: hey, thanks for sending my little gift up to the room the other day. much appreciated!
<lamont> blahrus: everything that {Depends,Recommends,Suggests}: .* | mail-transport-agent
<lamont> well, in main
<lamont> cc: was no issue at all
<blahrus> lamont: cool ;)
<BeerDump> good morning
<jsgotangco> hey lamont how was your flight
<lamont> jsgotangco: _LONG_
<lamont> but otherwise uneventful
<lamont> even customs went quickly
<lamont> which left me 2.5 hours to kill in SFO, but hey.. :-(
<jsgotangco> hehe
<jsgotangco> i just arrived yesterday at home
* lamont grumbles at the 3 ftbfs packages
<lamont> then remembers that one of them is trivial
<mdz> lamont: yes
<lamont> mdz: you want the seeds changed once nothing in base or desktop need spostfix?
<mdz> lamont: yes
<lamont> ok.
<lamont> fetchmail and subversion are ftbfs, maybe courier.  will update seeds, push new ubuntu-meta, and then go on a 'missing Depends of ubuntu-{base,desktop} merge crusade'
<lamont> mdz: delta is: mailx,mutt,lsb,postfix->ship (and postfix-tls goes away completely)
<lamont> hrm... /me needs to upload a good postfix first
<jsgotangco> whiprush, ping?
<whiprush> pong
<schweeb> whiprush: either go to sleep, or stop whining about being sick :p
<whiprush> heh
<ajmitch_> hi jsgotangco, have a nice flight home?
<jdub> hey dudes
<jsgotangco> ajmitch_, hey, i had a good flight yeah just arrived last night
<jsgotangco> jdub, hey hey hey
<ajmitch_> hey jdub 
<jsgotangco> jdub, i got myself intentionally lost in the CBD after we separated
<jdub> jsgotangco: haha
<jsgotangco> i asked one of the cops and he has no clue where rushcutters bay is
<jsgotangco> that made me laugh
<jdub> haha
<jsgotangco> its so funny i asked the newstands and the people at 7-11 and they have no clue of streets outside the cbd
* lamont feels like being lazy about reading manuals...  anybody want to answer a stupid Replaces: question?
<ajmitch_> lamont: I got mail from you about my key, without the signed key attached
<lamont> ajmitch: yeah - there's a bug in the script... I'm gonna probably have to send out a blastogram asking people if they got the key in the mail, then figure out what happened with the script
<jdub> hrm
<jdub> what's our current policy on rebuild-only uploads?
<jdub> tseng has requested an upload of libaspell15
<lamont> jdub: if it's currently failed, you kick lamont and he requeues it.  If it's in the archive, and needs to be rebuilt, then you do a no-source-change upload
<lamont> well, no change other than the changelog entry, of course.
<jdub> lamont: nmu style version number?
<lamont> jdub: wait
<lamont> does the package currently have an 'ubuntu' in its version number?
<jdub> Version: 0.60.2+20050121-2
<lamont> if yes, then bump that...
<lamont> in your case...
<lamont> I _believe_ that we chose: 0.60.2+20050121-2build0
<lamont> that is, all the debian version numbers are taken (by debian, for futures...).  ubuntu version numbers make elmo cry, since the next debian upload should just auto-sync.
<lamont> elmo still needs to teach the auto-sync stuff to be happy.  /me struggles to remember _which_ BOF that was discussed in - sometime thur or later.
<lamont> jdub: on the todo list is 'find all the ubuntu packages that differ from debian in only the changelog, and fix that'
<dholbach> morning
<jsgotangco> i still want to sleep
<jsgotangco> my back is aching all over
<dholbach> hey jsgotangco 
<jsgotangco> dholbach, hey how was your flight?
<dholbach> jsgotangco: i just woke up at 04:00
<dholbach> jsgotangco: still a bit confused, time-wise... i could have done with a bit more of sleep, but it was alright, how was yours?
<jsgotangco> dholbach, i just arrived last night, only an 8 hour flight but after our farewells at the hotel, we had lunch with jdub and crew and I intentionally got myself lost at the CBD
<jsgotangco> its fun having no clue where to go
<dholbach> jsgotangco: now your back hurts?
<jsgotangco> oh that's another story
<jsgotangco> anyway i woke up too early today hehe
<dholbach> :-)
<ajmitch_> it was hard to get up for work this morning :)
<jsgotangco> aye
<bluefoxicy> is something broken in breezy that now when Istick a USB pen drive in no /dev/sda entry appear
<jdub> bluefoxicy: yes
<bluefoxicy> jdub:  alright, thought I had damaged my system in the last power drop and was trying to replace most of my packages to fix it.
<bluefoxicy> (synaptic crashes if you try)
<dholbach> hey jdub 
<bluefoxicy> jdub:  out of curiousity and need to get a piece of data on pen, any work-around?
<bluefoxicy> i.e. mknod major/minor?
<jdub> morning dholbach 
<jdub> bluefoxicy: hrm, haven't tried - that might work
<bluefoxicy> it does.
<bluefoxicy> the major is 8, minor is the partition (0 for whole device), and type is block of course.
<dholbach> hey jblack 
<jblack> Hello. I'm looking at the project "aspell-en" that you guys asked to be imported. as best as I can tell, its a part of aspell -- even shares the same cvs. So what's up? 
<dholbach> jblack: you arrived finally? :-)
<ajmitch_> hi jblack 
<jblack> yeah.
<jblack> Hi ajmitch
<ajmitch_> bluefoxicy: modprobe sd_mod
<bluefoxicy> aj:  I have that already
<bluefoxicy> it's just not autoloading
<dholbach> jblack: are two soruce packages with the same CVS problematic?
<dholbach> s/soruce/source
<bluefoxicy> oh wow, it does now
<jblack> well, as far as I can tell from savannah, they're the same thing.
<bluefoxicy> it autoloaded the module when I mknod'd the device earlier?
<bluefoxicy> ajmitch: thanks.
<jblack> I'm new to doing imports, but my limited understanding is that we'd end up with two differently named products with the exact same sources. Not very useful. :( 
<dholbach> jblack: they seem to be packaged as two different source packages, two make binary updates different from the actual dictionary
<dholbach> s/binary updates/updates of the binary
<bluefoxicy> man :/
<jblack> Hmmm. I'm able to find aspell at savannah, but not aspell-en
* dholbach should go back to bed or grab another coffee
<bluefoxicy> I want a tool that'll generate a livecd for me.  I'll just master my own later when I have several hours on hand but eh
<bluefoxicy> I wanna make a proper Ubuntu Hoary Live CD with a load of security tools on it
<jsgotangco> i should go home early and sleep
<bluefoxicy> security/rescue/utility, for a swiss army knife :)
<dholbach> bluefoxicy: there's a howto on the wiki
<jblack> dholbach: here's a good test for you. Where is the module for aspell-en, and what module is it? 
<jblack> where is the cvs, and what is the module? 
<bluefoxicy> dholbach:  several hours of work
<dholbach> bluefoxicy: most of the guys in here didnt mind several hours of work... maybe you could speed up the process at some stage
<bluefoxicy> dholbach:  it's for me having to do things like unpacking and repacking stuff on the CD manually, then keying a 50000 character mkisofs line
<bluefoxicy> and making a compressed fs and such
<bluefoxicy> dholbach:  i could write a script for it but eh.
<bluefoxicy> I suggested at a point that a possible future utility be a liveCD generator based on sets of packages and files to add to the CD after the packages were installed
<bluefoxicy> but it was shot down because "nobody needs that"
<blahrus> not sure what you have all looked into for a bootsplash, but I am running splashy right now and it works great and is not a resouce hog
<bluefoxicy> TBH I'm lazy, but I also think giving many people the tools to do it easily would take the weight off of people who have better things to do than repetedly go through tons of crap involved in remastering a livecd 
<bluefoxicy> more focus could be put on finding a reason to remaster livecds
<dholbach> i just wanted to state, that stating "it takes too much time", isnt helpful... i can imagine, that people work on things they more desperately want to see in ubuntu
<bluefoxicy> like mythtv livecds, or security, disaster recovery, instant routers, etc
<bluefoxicy> dholbach:  I know but I'm not a dev :)
<bluefoxicy> at least
<bluefoxicy> not when I have a job and college
<jsgotangco> so am i but it doesnt stop me i have a dayjob as well
<bluefoxicy> jsgotangco:  good to know you don't m-- . . . spend time reading slashdot?
<dholbach> bluefoxicy: telling people what they should is just wrong in the open source world :-/
<bluefoxicy> dholbach:  and there's a bugzilla why?  :)
<dholbach> ...
<bluefoxicy> more pertainently, an "enhancement" severity level
<bluefoxicy> there's nothing wrong with telling people what you want or making an argument
<bluefoxicy> it's fine until it gets to the point where you're raising hell and trying to force people to do what you want in some antisocial way
<fabbione> morning
<dholbach> i think most of us got your point by now... but it's more helpful to just start writing that script and not saying "TBH i'm lazy"
<bluefoxicy> i'll figure something out
<bluefoxicy> when I get around to it.
<jsgotangco> theres no rush :)
<jdub> mjg59: ping
<lifeless> win 60
<jdub> ~.
<jdub> heh
<dholbach> jblack: where did you find aspell-en in there?
<jblack> the info files, which doesn't list cvs at all, list savannah. when I go to savannah, there's no aspell-en, but there is jus an aspell
<dholbach> hrm
<schweeb> BeerDump?  should that be like "put beer here! *gestures towards mouth*"
<BeerDump> yeah
<BeerDump> redbull looks so much like beer too with the bubbles and all
<schweeb> heh
<schweeb> redbull plus vodka is even more similar to beer :)
<BeerDump> that would come handy now
<charles> yay nigger developement!!!
<charles> ubuntu=nigger right?
<tseng> dude, fuck off
<charles> im black dude
<schweeb> wtf
<charles> i dont care
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [-o+b charles *!*fiendofmi@*.comcast.net]  by fabbione
* charles was kicked off #ubuntu-devel by fabbione ([BX-bk]  bye)
<fabbione> i do
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<schweeb> fabbione: u-motu now too
<fabbione> schweeb: i don't have op on motu afaik
<schweeb> :(
<fabbione> sorry :/
<schweeb> hrm
* schweeb tries to remember if he knows any freenode server ops
<schweeb> <3 dholbach
<fabbione> schweeb: try to ping lilo
<fabbione> only sladen and riddel are ops there
<schweeb> fabbione: dholbach resolved the situation
<fabbione> ok
<schweeb> although he's probably in #ubuntu now
* schweeb does a whois
<schweeb> no, but he's in  just about every other ubuntu channel
<tseng> oh man
<BeerDump> lunch bbl
<tseng> Lathiat: were you the one talking about improving evolution imap?
<tseng> Lathiat: something about sorting the folders
<Lathiat> tseng: ermm
<Lathiat> tseng: dont think so
<Lathiat> i was whinging about it implementation sucking. :)
<Lathiat> tseng: have you tried 'imap4rev1', its better
<tseng> yes
<tseng> someone said something about changing the ordering of the folders iirc
<tseng> mine are coming up alphabetically with rev1 rather than inbox as a special folder at the top
<Lathiat> oh, interesting
<Lathiat> my INBOX's appear as a special one
<Lathiat> maybes its confued and you have a folder called inbox
<tseng> it says i do
<tseng> but i dont
<Lathiat> as well as whatever your imap serverr thinks is INBOX
<Lathiat> (/var/mail/$user usually)
<Lathiat> hrm
<Lathiat> interesting
<tseng> well, i have .INBOx
<tseng> yeah i think its the server
<tseng> Lathiat: fixed it
<Lathiat> cool
<tseng> had to edit .subscriptions to trick it
<tseng> Inbox vs INBOX
<Lathiat> ah ok
<Lathiat> what imap server?
<tseng> dovecot
<Lathiat> hrm, my dovecot is INBOX
<tseng> or dovecrack atm
<Lathiat> i have 3 dovecot servers and they all play happy
<tseng> is your inbox .maildir/cur or .maildir/.INBOX
<tseng> i had .INBOX with stuff in it was the problem
<tseng> meh, my bad
<Lathiat> oh
<Lathiat> i dont use maildir
<tseng> oh
<Lathiat> and y INBOX is /var/mail/INBXO rather than a folder
<tseng> I see
<Lathiat> .. s/INBXO/lathiat
<tseng> better sleep, cya
<Lathiat> cya
* lamont wonders how long he needs to wait for seeds to mirror to the right place
<dholbach> hey mvirkkil 
<dholbach> hey mvo
<mvo> morning everyone
<lamont> morning mvo
<mvo> morning lamont! did you had a good trip back?
<lamont> yes
<lamont> elmo about?
* lamont sends email instead
<ajmitch> hi mvo, mpt
<mvo> hey ajmitch
<cc> hey, hey everyone :P
<ajmitch> cc! :)
<dholbach> hey cc 
<ajmitch> mvo: does python-apt depend on a newer libapt than aptitude currently wants?
<mvo> ajmitch: not in ubuntu ... do you get some sort of error when trying to install?
<ajmitch> mvo: just trying to go sid->breezy, so I've got a few things to fix up or upgrade :)
<dholbach> fix rather ;-)
<ajmitch> apt pinning will take care of most of it
<mvo> ajmitch: you will need the apt version from breezy (that is identical to the one in hoary right now)
<jblack> Hey, anybody know why uucp was removed? 
<dholbach> jblack: removed?
<jblack> removed.
<BeerDump> mvo, hey how are you
<dholbach> jblack: it seems to be in the archive...
<jblack> This hit me when I installed a hoary cd today. Said uucp was removed because 'cu did everything uucp did'. 
<jblack> (which isn't true) 
<dholbach> seems you should have a talk with Peter Palfrader <weasel@debian.org>
<mvo> hey jsgotangco! I feel pretty good, I hope the jetlag will not hit me today
<jblack> Perhaps. uucp adds stuff like uupoll, which, afaik, cu doesn't do.
<dholbach> brb
<jblack> perhaps cu does what uupoll does, but it doesn't seem to read /etc/uucp/sys
<mpt> hi ajmitch
<jsgotangco> who has some UDU pics online?
<Simira> Mithrandir's will be up in few minutes, rumor says
<jsgotangco> goodie
* ajmitch has to hunt down a laptop first
<jblack> let me free up some diskspace, and then I'll put mine up
<jsgotangco> yay i'm trying to get some stuff for my album
<jblack> I desperaately need another hard rdive.
* lamont makes a note to download his from the camera
* lamont chokes on ubuntu-meta
<fabbione> hey ogra
<Simira> mornin fabbione
<fabbione> hi Simira 
<Mithrandir> hello people
<infinity> Hey Mithrandir.
<infinity> doko : Alive?
<fabbione> hye mith
<fabbione> hi infinity 
<doko> infinity: yes, waking up early ...
* fabbione gives doko the good morning lart
<infinity> doko : Ouch. :)
<fabbione> i guess jbailey is not awke yet
<lamont> fabbione: more like "has gone to sleep"
<fabbione> yeah
<lamont> is either 2300 or 0200 at his place - can't remember which...
<lamont> hrm... 0200, I'm pretty sure
<lamont> Kamion: you awake yet?
* lamont hesitates to upload ubuntu-meta, since it required adding ubuntu-standard to match the seeds...
<fabbione> time to do some gpg dance
<jsgotangco> heh
<jsgotangco> spare pics...spare pics please...
<jblack> jsgotangco: Patience my man. It takes time to upload dozens of pics at 3 megs a piece.
<jsgotangco> ouch
* jblack strokes mercury with love as he moves mp3s uploads photos and tries to reload a page at the same time, all while getting mail and squidding
<Lathiat> mercury?
<jblack> 300 megs of pics. :) 
<jblack> lathiat: one of my servers here at home. the primary.
<Lathiat> ah right
<jsgotangco> i should get a new camera
<jblack> Once a day it was a nice machine. These days its a 2ghz machine with only a half gig of ram. 
<Lathiat> my server is a p200 so count your blessings. :)
<jblack> once apon a time, that is.
<mvo> elmo: can you please sync findutils from debian (overriding our changes is ok)
<jsgotangco> 42
<Lathiat> don't forget your towel
<Lathiat> i should go see that tonight
<jblack> 96 pics uploaded, now resizing 96 pics
<mdz> jblack: how did the group photo turn out?
<fabbione> hey mdz
<mdz> fabbione: morning
<jblack> mdz: Looking now
<infinity> mdz : Speaking of; the next time someone wants to do group photos, give me some warning.  I had a mess of equipment upstairs, including an SLR with a remote control.
<jblack> mdz: pretty good. :) 
<jblack> But I'm not in it, so pretty bad. ;( 
<jsgotangco> doh
<jsgotangco> that group photo was good
<mvo> elmo: please mergs gsfonts from debian (the ubuntu changes are now in debian)
<Lathiat> poor elmo
<jblack> mdz:  private pong
<lamont> mdz: want to review what I did to ubuntu-meta (base seed appears to have split into base & standard --> new meta package)
<jblack> Ok. here we go. http://gallery.linuxguru.net/UbuntuDownUnder-4-2005
<jblack> please be kind. its dsl. 
<mvo> lamont: is the name set (base & standard)? I was wondering if we could use something like "ubuntu-essential" so that ubuntu-base keeps what it is now
<fabbione> elmo: please sync aoetools from Debian. go for override
<jblack> I can never remember kiko's name.
<fabbione> Criss
<lamont> mvo: that's part of why I want some review on ubuntu-meta...
* lamont didn't do the seed stuff - just moved the MTA stuff around
<lamont> http://people.ubuntu.com/~lamont/ubuntu-meta/ubuntu-meta-0.44.mta
<pitti> Morning
<fabbione> hey pitti
<dholbach> hey pitti 
<lamont> mvo: note also that this upload breaks ubuntu-meta on ia64 :-(
<mdz> infinity: I didn't have any more advance warning than you did, and the light was fading fast :-)
<mvo> morning pitti 
<infinity> mdz : I think I had enough master/slave flash equipment to even counteract the light issue. :)
<infinity> mdz : Next time, I suppose I should advertise that I travel with a small studio.
<jsgotangco> jblack, gracias
<jsgotangco> whoa the group photo is awesome
<Mithrandir> note to self: do not flash infty in the eyes with puny small compact cameras.  His revenge will be sweet.
<bob2> haha
<jsgotangco> heh
<bob2> he'll chase you around and beat you with an x40!
<infinity> (thom's)
* lamont reboots
<fabbione> jblack: where is the pic we had together?
<jblack> that's what I've got? 
<fabbione> jblack: ok :) i remember we took a pic together :)
<fabbione> lamont: did it boot?
<jblack> That's enough caption editing for now.
<lamont> fabbione: that was actually booting to get rid of the APIC errors that were keeping klogd looping
<lamont> and filling the disk, etc.
<pitti> Hey infinity 
<lamont> May  2 22:12:42 mix kernel: APIC error on CPU0: 40(40)
<lamont> May  2 22:13:13 mix last message repeated 84 times
<lamont> May  2 22:14:13 mix last message repeated 212 times
<lamont> May  2 22:15:14 mix last message repeated 214 times
* lamont doesn't like it when it does that.
<jblack> How is the server holding up? 
<pitti> Mithrandir: here?
<fabbione> lamont: is that with 12rc3 ?
<Mithrandir> pitti: pong
<mvo> elmo: please sync foomatic-filters from debian (our patch is now included upstream)
<Lathiat> i think someone needs to start a list somewhere
<Lathiat> ive seen at leat 10 requests go past today on irc. :)
<mdz> amu: you took the other group photo, yes?
* fabbione might be in the need to relocate from dk to another country
<Lathiat> fabbione: whys that?
<fabbione> this country is insane
<fabbione> they just add 8% more taxes with validity from 1 Jul 2004
<fabbione> without any notice
<fabbione> so everybody working for a foreign company needs to pay heaps load of money now
<fabbione> they are retarded
<fabbione> ok i need to go off for a while and boil down
<fabbione> this is frigging insane
<Lathiat> fabbione: :(
<lamont> fabbione: 2.6.10-5-<whatever final hoary is>
<GheRivero> res
<dholbach> jdub: ping
* Lathiat wonders if he shoudl jump ship to breezy yet
<Lathiat> any major breakage atm?
<p0m> I heard of some, but can't recall them off-hand.
<p0m> Ahh, here we are.
<p0m> ubuntu-desktop won't install unless you disable universe.
<p0m> And something about vermagic.
<pitti> Hi sivang 
<p0m> They don't seem to be major Lathiat.
<Lathiat> yeh i mean tlike major application breakage. :)
<sivang> morning pitti, what's up?
<p0m> Lathiat: Evolution's apparently broken, and there's GCC4.0, go figure :)
<p0m> And from my irc logs, there's at least one complaint about an initrd bug.
<Lathiat> evolution was fixed, an dyeh ik now about gcc4, its ok. :)
<p0m> Never found out what that bug was.
<fabbione> infinity: ping?
<Kamion> lamont: morning. please don't do ubuntu-meta yet
<lamont> Kamion: wasn't planning to...
<lamont> my seed changes are committed, though
<lamont> so whoever does ubuntu-meta will incorporate them, perforce
<Kamion> mdz: we never quite got the names sorted out - {minimal,base} maybe? I don't like "essential" for the first bit because it isn't quite just "Essential: yes"
<mdz> Kamion: I don't like "essential" either
<Kamion> yay for jetlag, you two aren't normally around when I get up :-)
<Mithrandir> *chuckle*
<Mithrandir> hi Colin
<lamont> Kamion: actually, I've been babysitting a kernel build, for the last little bit... finally did the commit
<lamont> only been up for 20 hours at this point - should really go to bed soon
<seb128> elmo: thanks
<dholbach> hey seb128 
<seb128> morning daniel :)
<lamont> Kamion: how about core instead of essential?
<sivang> hey seb128
<seb128> hi sivang 
<seb128> I've not replied to your mail but the wiki is updated
<dholbach> seb128: GNOME team: http://gallery.linuxguru.net/UbuntuDownUnder-4-2005/img_0278 :-)
<seb128> about the launchpad bof
<sivang> seb128: yes, I've seen it, however it's rather minimalistic spec don't you think? ;-)
<seb128> dholbach: hum, I look a bit sleeping on this one :)
* lamont considers beating doko with gcc-3.4, decides to wait for it to actually _fail_ before doing that.. :-)
<seb128> sivang: what do you want to change ? comments are welcome
* dholbach thinks: . o O { poor doko }
<Kamion> lamont: I can live with core
<sivang> seb128: sure, btw, I had a feeling we are going to revert to a centeralized app to do it rather then patching 200 apps/libs ;-)
<mdz> Kamion: otoh, I also dislike having the smallest set be something other than 'base'
<lamont> dholbach: nah - it just takes forever to build
<Kamion> mdz: likewise - I think we're stuck with it though, due to the metapackage thing
<mdz> Kamion: didn't we decide that we could have ubuntu-<foo> depend on ubuntu-base?
<Kamion> mdz: doesn't help
<seb128> sivang: any objection with the BOF specs ?
<lamont> Kamion: couldn't base Depend: core?
<Kamion> mdz: for people who only have ubuntu-base/hoary installed, they'll want to get ubuntu-<whateverreplacesbase>/breezy
<seb128> rahh, my fonts look ugly with the new fontconfig
<ogra> morning
<Kamion> lamont: yes, it works provided that ubuntu-base retains its current semantics
<Kamion> I share mdz's dislike of base not being the smallest set - I brought it up at the BOF too
<sivang> morning ogra
<lamont> yeah - annoying
<Kamion> but I don't see a better way :(
* doko points a mirror to lamont to show the person trying to build hppa crack
<lamont> doko: this is on debian...
<Kamion> base-installer would probably still say "installing base system", too
<mdz> Kamion: we could avoid adding new packages to whateverreplacesbase in breezy
<Kamion> how about we stop using base altogether?
<Kamion> call them core and standard, and have ubuntu-base be transitional
<Kamion> or minimal and standard, or whatever
<mdz> I could live with that
<Kamion> then it won't break people's brains when base-installer still says "installing base system"
<lamont> Kamion: that actually sounds kinda nice...
<mdz> base -> standard, create minimal, and have ubuntu-base depends: ubuntu-standard, ubuntu-minimal
<Kamion> as long as we don't try to split minimal up again in the future, it works :-)
<mdz> s/in the future/in breezy/
<Kamion> (ubuntu-standard would depend on ubuntu-minimal anyway, I'm guessing)
<mdz> it would?
<mdz> we don't do that with the current metapackages
<lamont> no reason that it shouldn't, other than the weight of tradition
<sladen> fabbione: just ask chanserv for ops
<lamont> well, maybe _some_ reason... but not sure I 100% buy it
<Burgundavia> sladen, you want to join #ubuntu-doc to discuss wiki/sudo stuff?
<Kamion> mdz: I think it should, though I don't feel strongly about it
<sladen> ogra: I have masses more that RootSudo one but it didn't merge when I clicked save
<ogra> sladen, got a backup ?
<mdz> lamont: with the current scheme, one can remove a base package, and still get updates to desktop
<sladen> ogra: I saved it on the laptop, need to paste it again when I have bandiwdth that isn't a windows machine
<lamont> right
<ogra> sladen, i think its still editable
<doko> lamont: the buildd doesn't have the build logs yet
<Kamion> mdz: I guess
<lamont> not having standard Depend: core means that base has to stick around for a bit, to Depend: both of them
<ogra> sladen, has Burgundavia talked to you ? 
<Kamion> ok, shall I 'baz mv base minimal' then, and we can get fixing?
<lamont> doko: gcc/p/test is still building
<ogra> sladen, he wanted to tweak the RootSudo wikipage too, i asked him to talk to you first
<lamont> Kamion: btw, once you get a new ubuntu-meta uploaded, we'll want a new debootstrap too, since postfix is now ship-seed... then mdz can test the love.
<lamont> s/mdz/I/
<Kamion> lamont: yep, naturally :)
<Kamion> there are a bunch of changes debootstrap needs to pick up
<lamont> sure looked like it
<sladen> Burgundavia: tweak away, I'
<sladen> Burgundavia: tweak away, I'll merge it later anyway
<Burgundavia> actually, I am looking for the whole plan
<Amaranth> so...was seb128 just really busy or UDU or was he uploading lots of things to debian? :)
<Amaranth> s/or UDU/at UDU/
<Mithrandir> we didn't have bandwidth.
<Lathiat> fwoar, autosync went nuts
<Mithrandir> you should have seen him, walking around: "I need to upload, I need to upload.".  Scary. :P
<Amaranth> that must have been painful
<Amaranth> haha
<Lathiat> Mithrandir: haha
<Amaranth> hey, now he can make up for it. :D
* Amaranth needs new crack
<Lathiat> doesnt he go into withdrawl if he doesn't upload something every 4 hours or something? :)
<seb128> bah
<seb128> was nice to have a packaging break :)
<Mithrandir> seb128: I don't believe you. ;)
<Amaranth> who are you and what you have done with the real seb128?
<Mithrandir> or possibly, you too might need to recharge batteries once in a while.
<seb128> right :)
<ajmitch_> seb128: managed to get your fix then?
<Amaranth> ooh, new python2-gnome-extras
<Amaranth> too bad only about 5 people in the world know how to use it
* mvo waves to seb128 
<Kamion> mdz: ok, so I should: 1) rename base to minimal etc. 2) remove the inter-seed dependencies I added at UDU 3) update ubuntu-meta to cope, and add new ubuntu-base with Depends: ubuntu-minimal, ubuntu-standard
<Kamion> mdz: ?
<Lathiat> fark just got another 121 autosync mails, it sgone nuts. :)
<seb128> mvo: hey!
<Lathiat> or maybe not, evolution jut sucks
<Amaranth> Lathiat: This is why you don't subscribe to breezy changes. :)
<mdz> Kamion: yes
<seb128> ajmitch_: right, I've fixed the breakages yesterday
<Amaranth> just read the archives
<Lathiat> Amaranth: nah i subscribe to it for a reason. :)
<Lathiat> im interested. :)
<Lathiat> its 
<Lathiat> ignore that, stupid irssi
<Amaranth> err
<Amaranth> 0x17?
<Lathiat> ^W
<Amaranth> oh
<Lathiat> irssi has an issue where for some reason on a lagged SSH sessions
<Lathiat> control keys turn into characters
<Lathiat> yet it works fine if you rssh isnt lagged
<Lathiat> its really whacked out and i have nfi what cuases it
<Mithrandir> it includes control characters verbatim if they are together with other characters in the same packet.
<Amaranth> ok, ^W in random apps is bad
<Mithrandir> it's a feature to avoid random tab-expansion and so on when pasting.
<Lathiat> Mithrandir: ohhh
<Lathiat> i see
<mvo> seb128: mind if I take #9342 (gksu-merge)?
<Lathiat> that makes sense
<Lathiat> i need to make it ignore ^W
<seb128> mvo: not at all :)
<Lathiat> cus i usually hit ^W a few times
<Lathiat> or hold it down . :)
<Lathiat> i should use ^U or something
<seb128> mvo: my bugs mailbox has still 274 mails to go, so feel free to grab some of my bugs, you are welcome :)
* Mithrandir watches his new smart card reader blink while generating keys.
<Mithrandir> shiny, shiny.
<mvo> seb128: thanks
<seb128> thank you
<jsgotangco> anybody has some more nice UDU pics?
* ogra is still sorting pics
<jsgotangco> ogra, not the ones where you were fooling around in kings cross ;)
<ogra> heh, nope, but my camera is to cheap.... half of them are to blurry, to dark etc
<jsgotangco> same here heh
<Amaranth> arg, updatedb is making my HD thrash :/
* Mithrandir whistles "blame the equipment"
<zyga> Mithrandir: what do you use the smart card for/
<Simira> zyga: for fun ;)
* fabbione spams people with gpg signatures
<dholbach> fabbione: rock
<jiyuu0> new version of ubuntu add-on cd is out: http://ubuntuguide.org/add-on-cd
<Lathiat> jiyuu0: are you the person who runs that site?
<lamont> seb128: did you want to know that epiphany-browser_1.6.3-1ubuntu1 does not like amd64?
<seb128> sure
<jiyuu0> Lathiat, yes 
<seb128> lamont: it doesn't like gcc4/amd64?
* seb128 looks on the build logs
<Lathiat> jiyuu0: could you please get rid of the prleink recommendation? its total crack. :)
<jiyuu0> is there a prob with prelink?
<jiyuu0> some recommend me to put it
<lamont> seb128: yeah
<Lathiat> it smokes crack, nto really a good idea since it modifies all your binaries and has to be run-run every tie you update packages and stuff, for no real gain
<lamont> checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
<lamont> that'd be mad
* jiyuu0 tryin prelink again...
<lamont> seb128: concordia's breezy chroot should be able to produce the config.log that you need - it's not saved by the build daemons
<Lathiat> jiyuu0: basically, its not a really good thing fo rgeneral users to do, so it shouldnt be on such a page. IMO and others)
<jiyuu0> ok...
<jiyuu0> i'll remove it
<Lathiat> and im told it doesnt really give that much of a gain anyway
<jiyuu0> going to remove on next release
<Lathiat> cool
<jiyuu0> puttin dvdrip instructions in
<Lathiat> site seems generally pretty cool, nice work
<hunger> Lathiat: I didn't notice any speedup when loading ooo with prelink... but then I hardly ever notice speedups.
<jiyuu0> thanks
<Kamion> very strange; many of the packages in that add-on-cd are already on the Ubuntu 5.04 CDs
<Kamion> I don't understand why you're providing them again
<Kamion> they are not installed by default, but they should be in /var/cache/apt/archives after installation
<jsgotangco> thats cracked up
<jiyuu0> Kamion, those cds are not in ubuntu cds
<jiyuu0> e.g. xmms, mplayer, audacity...etc
<Kamion> the ones I spotted are bazaar, lilo, linux-headers-386, nis, devscripts, fakeroot, cvs
<Kamion> there are doubtless many more
<jiyuu0> some of em duplicate as... after install it would not be there
<Kamion> they are in /var/cache/apt/archives after installation
<jiyuu0> and when apt-get it will prompt for it
<Kamion> if apt-get prompts, that's a bug in apt, not a lack of packages
<jiyuu0> i installed a fresh... then took the list 
<jiyuu0> and compared it
<Kamion> look at the ship seed
<Mithrandir> zyga: PGP key signing
* jiyuu0 tryin to find
<Kamion> it's documented in a number of places
<Amaranth> jiyuu0: Hey, I have a new version of the menu editor. It's going into hoary backports though so I think having the guide point there would be best.
<Amaranth> jiyuu0: The package name is smeg.
<Kamion> a quick count suggests 54 packages on the add-on-cd that are already in ship
* dholbach cries... he read the BAD BAD word
<jiyuu0> Amaranth, smeg is in it already
<Kamion> you could remove those and reclaim lots of space for more useful stuff
<jiyuu0> i updated it yesterday
<Amaranth> jiyuu0: Did you put the new pyxdg and gnome-menus in too?
<jiyuu0> Amaranth, that i only got it today :(
<jiyuu0> so not in it yet
<Kamion> bazaar bpalogin build-essential console-terminus cvs devscripts eagle-usb-data eagle-usb-utils emacs21 emacs21-bin-common emacs21-common emacsen-common fakeroot g++ g++-3.3 gawk gcc gcc-3.3 language-support-en libpcap0.7 libpcre3 libstdc++5-3.3-dev libungif4g lilo linux-headers-386 linux-wlan-ng mozilla-firefox-locale-en-gb myspell-en-gb myspell-en-us ndiswrapper-utils nfs-common nfs-kernel-server nis ntp-server ntp-
<Amaranth> Ok. Smeg is basically useless without them.
<ajmitch_> dholbach: it's ok, really..
<jiyuu0> Kamion, thank :)
<jiyuu0> so those will be in the shipit cd
<Kamion> yes
<jiyuu0> but the current version won't copy to cache right?
* ogra shades his eyes by seeing the BAD B word here
<Kamion> it does; apt may not honour that though
<Kamion> as in, it may try to get at the CD to confirm that the packages in the cache are right, or something crackful like that
<hunger> Why does ubuntu ship modprobe.modutils?
<jiyuu0> i got that a couple of times
<ogra> hunger, for people that want to use old kernels....
<Kamion> hunger: we stopped shipping modutils in hoary
<Kamion> 2004-11-09 21:57:42 GMT Matt Zimmerman <matt.zimmerman@canonical.com>   patch-10
<Kamion>     Remove modutils from base, 2.4 kernels from supported
<ogra> hunger, err, yes... it was on warty....
<Kamion>     Summary:
<hunger> Kamion: Huch, where did modutils come from here then...
<Kamion>       Goodbye, Linux 2.4.x
<Kamion> hunger: perhaps you upgraded from warty
<Kamion> we do not force the removal of modutils
* hunger had installed hoary and then upgraded to breezy.
<Amaranth> sid autosync pulled it in?
<hunger> Oh great! modutils is not installed at all.
<Kamion> Amaranth: autosync does not affect seeds
<hunger> But something set up symlinks for those tools anyway.
<Kamion> hunger: it appears to be module-init-tools' preinst that creates those symlinks
<Kamion> diversions, strictly
<Amaranth> yay, my app is #1 on the ubuntuguide app install howto :)
<Lathiat> heh
<ogra> Amaranth, does it work now ? 
<Amaranth> ogra: Smeg?
<ogra> without wiping submenus etc...
<jiyuu0> Amaranth, :)
<Amaranth> ogra: wiping submenus?
<ogra> no, menu editor...
<Amaranth> oh, you mean without totally killing the applications menu
<hunger> Amaranth: Which app is that that it is so horrible that it needs a entry in app install howto ;-)
<Amaranth> menu editor is now Smeg
<ogra> ah
<Amaranth> hunger: It isn't in Ubuntu. ;)
<Amaranth> ogra: works fine here
<Amaranth> i released a new version, needs a new python-xdg and gnome-menus
<ogra> ah
<seb128> elmo, thom: ping ?
<Amaranth> i didn't know how to use cdbs's patch system or dpatch at the time so i don't have a patch of what changed in those two
<seb128> Amaranth: have you tried to ping upstreams to work on a common stuff?
<seb128> there is 3 menu editors now
<Amaranth> seb128: 3? i only know of two
<Amaranth> I've talked to Manny, not much we can do to bring the two together, I don't know C.
<lamont> g'night all
<ogra> night lamont 
<fabbione> lamont: noght
<fabbione> night
<Amaranth> seb128: g-m-e, Smeg, and what else?
<hunger> Do usb-sticks work for you? Mine suddenly stopped working.
<hunger> usb-storage gets loaded, but no device nodes get created.
<seb128> Amaranth: what is Smeg?
<jsgotangco> Simple Menu Editor for Gnome
<lamont> seb128: 1000th of Sgig? :-)
<Amaranth> seb128: my menu editor, the one that was called "Menu Editor"
<seb128> Amaranth: there is a gnome-menu-editor on the GNOME CVS, and gnome-menus 2.11 has a pygtk menu editor
<seb128> k
* lamont really sleeps
<seb128> lamont: maybe :p 
<Amaranth> the one in gnome-menus is just an example of using the python interface
<seb128> no
* jsgotangco feels sleepy too
<Amaranth> they've done more with it?
<seb128> that's the menu editor for GNOME 2.12 I think
<seb128> they are working on it 
<lamont> jsgotangco: 0330 here
<Amaranth> g-m-e was supposed to be the one for 2.12...
<seb128> no
<elmo> seb128: ?
<seb128> where do you read that?
<fabbione> hunger: it's a bug in udev/hotplug
<fabbione> hunger: check bugzilla
<Amaranth> well, I don't want to run GNOME from CVS (don't even know how) so i dunno what i can do there
<jsgotangco> ackk
<Amaranth> seb128: Well, that's what Manny seemed to be saying.
<seb128> elmo: 
<hunger> fabbione: Thanks!
<seb128> Executing shell in 'breezy' chroot.
<seb128> Unknown id: seb128
<seb128> elmo: on concordia
<seb128> elmo: if you can make that working, would be nice :)
<seb128> Amaranth: right, but that's what this guy think, he's not a maintainer for gnome-panel or gnome-menus ...
<elmo> seb128: fixed
<seb128> Amaranth: the gnome-menus maintainer is working on gnome-menus, read the desktop list
<seb128> elmo: thanks
<Amaranth> seb128: got a link to the d-d-l archive of this?
<Amaranth> i've only been subscribed for a week
<seb128> Amaranth: mail "Simple menu editor"
<seb128> that's an april mail
<Amaranth> ack, my name :/
<seb128> "Build gnome-menus HEAD and run "gmenu-simple-editor" to try it out."
<seb128> "This is pretty much the same as Christian's gnome-menu-editor, but with
<seb128> less features. I thought it might good idea to try and explain why I
<seb128> went with a new editor with less features :-"
<seb128> etc
<hunger> fabbione: Do you have a bug#? I do not see anything like my problem in the bugzilla.
<fabbione> hunger: no, but i remember reassigning it to udev
<seb128> elmo: can you update the package list for the concordia breezy chroot and install the build-dep for epiphany-browser ?
<elmo> seb128: done
<dholbach> hey elmo, did you have luck with brandon hale (tseng)'s key? (universe keyring)
<elmo> dholbach: not yet, piece-of-string and all that, I'll get it done today tho
<dholbach> elmo: ROCK, he will love you for that :-)
<seb128> elmo: thanks
<ogra> yeah
<ajmitch> elmo: thanks
<fabbione> hey elmo
<fabbione> thanks for the sync
<Kamion> hm, this ubuntu-meta update will suck without getting ia64 into sync with the changes
<Kamion> elmo: any ETA on ports.ubuntu.com?
<Lathiat> ports.ubuntu.com ?
<hunger> fabbione: Ah, found the bug!
<fabbione> Lathiat: ia64/sparc/hppa
<Kamion> Lathiat: unofficial architectures
<Lathiat> ah right
<fabbione> Kamion: elmo had an ETA of a week more or less
* fabbione has been bitching elmo a lot @ UDU :)
<Lathiat> hahaha
* ogra whispers mips
<Lathiat> ubuntu on my indy would rock. :)
<Lathiat> altho i think its mipsel isnt it?
<ogra> yep
<Amaranth> "multiple menu editors
<Amaranth> are being developed (gnome-menu-editor, the pyxdg one etc.)" <--cool, he knows i exist ;)
<seb128> I'm not sure that's a good idea though
<seb128> better to get 2 menus editor, a simple and a featured one
<Kamion> hmm
<ogra> even better, have only oe that can be run with a --advanced commandline option
<Lathiat> i think you should have one nicely done one
<ogra> s/oe/one
<Amaranth> well, for mine "simple" decribes ease of use (i hope) not functionalilty
<Kamion> I think I might temporarily mirror the ia64 Packages files to people so that ubuntu-meta can be updated properly
<Lathiat> and smeg seems to be going pretty well
<Amaranth> Lathiat: Thanks. :)
<ogra> jdub around ?
<dholbach> away for 4 hours now
<ogra> ah, ok
<dholbach> wanted to get us a ubuntu-motu--list earlier
<jsgotangco> i feel so sleepy already and its only 6pm
<jdub> ogra: back
<ogra> http://www.arcad.de
<ogra> jdub ^^
<ogra> just translating their request for you
<trukulo> jdub: congratulations for your wedding
<jdub> ogra: thanks
<jdub> trukulo: thanks
<trukulo> jdub: you have to tell me where to find blind girls to get married too ;)
<jsgotangco> trukulo, there are loads in sydney
<hunger> udev does not log anything anymore:-(
* ogra still wonders about https://www.ixsoft.de/cgi-bin/web_store.cgi?page=Products/de/OFUB0504BX.html&cart_id=2677340_11915
<trukulo> jsgotangco: i note it
<mdke> jdub, quick word in PM?
<jdub> ok
<mdke> thanks
<hunger> ogra: It does have a fancy box... Maybe it is gold-plated or so?
<ogra> hunger, dunno, just wondering if it needs canonical approval for the logo usage....
<jdub> is that the boxed set?
<ogra> yep
<jdub> ogra: yeah, almost certain that's the company we've approved
<ogra> jdub, where does the handbook come from ?
<hunger> ogra: Maybe they rely on "humanity to others", hoping they will not get sued? ;-)
<ogra> hmm, there is also a typo in the description....
<jdub> ogra: not sure - silbs knows
<ogra> GNOME 2.9.4
<jsgotangco> whoa!
<ogra> heh
<jsgotangco> heh
<ogra> jdub, ok
<jsgotangco> the box looks like something that came out from Lotus
<ogra> bah... debian for the desktop :-P
<trukulo> umm, it's legal to sell it ?
<ogra> debian is the core of this distribution and thus is the "rock on which ubuntu is built".
<trukulo> i mean, selling that way
<trukulo> does it have rights to sell with a t-shirt?
<seb128> is libstdc++5-3.3-dev supposed to have a /usr/lib/libstdc++.so?
<dholbach> jdub: could we have ubuntu-motu or something?
<jdub> dholbach: mailing list?
<dholbach> jdub: yes! :-)
<seb128> and ubuntu-desktop for the bugs ? :)
<seb128> ubuntu-desktop-bugs or something
<mdke> we need to segregate these motu dudes
* mdke sniffs dholbach 
<dholbach> seb128: dunno, if malone teams can have their own "preferred mail adress" *hrm*
<jsgotangco> ahem
<seb128> dholbach: I want that for bugzilla atm
<dholbach> mdke: do you want to tell me something?
<dholbach> seb128: i see
<mdke> dholbach, no...
<dholbach> mdke: ok :-)
<dholbach> seb128: i will put the idea on http://wiki.ubuntu.com/MaloneUniverseWishList 
<seb128> k
<jsgotangco> "A Guide to Open Source Software" by the Australian Government Information Management Office
<jsgotangco> hmmm
<ogra> mdke, how did it smell ?
* ogra suspects axe :)
<Kamion> mdke: btw, reading scrollback, ubuntu.com is the domain we'd prefer people to use; there's a website bug that makes that awkward at the moment though
<mdke> Kamion, yeah
<mdke> ogra, it was ok...
<ogra> heh
<mdke> Kamion, i think i posted that bug during the chat with that guy
<jdub> dholbach: hrm, can you email ubuntu-devel about creating ubuntu-motu?
<mdke> ogra, i might not do it again tho
<jdub> seb128: ok, i will think about that tomorrow morning ;)
<ogra> mdke, lol
<hunger> udev is seriously broken in breezy from what I understand. I do not get anything with udev in the logs.
<dholbach> jdub: ok
<jsgotangco> thats it i am going home and sleep
<jsgotangco> bye bye
<hunger> und that with udev logging its version as the first thing it does.
<dholbach> jsgotangco: sleep tight
<ajmitch> night jsgotangco 
<mdke> Kamion, while we're on the subject, it would be nice to assign a few website bugs: at the moment is seems a lot of them go to lu@canonical, and henrik is not assigned bugs
<jdub> lamont: does the new postfix include tls foo?
<Kamion> jdub: can you fix mdke's comment about default assignees?
<mdke> jsgotangco, sleep well
<jdub> ok
<jdub> heh
<koke> mvo: are you around
<koke> ??
<koke> I want to patch gksu, the ("Child terminated with %d status") message is not "usable" at all
<koke> any suggestions?
<Kamion> ok, I think I have a reasonably working new ubuntu-meta now
* Kamion uploads
<Amaranth> is bazaar-ng supposed to be svn-like commands but with arch?
<hunger> fabbione: Is someone working on #9913 (the one about udev)? I just updated the report with some more information. Tell me when you think I can help.
<fabbione> hunger: somebody will work on it pretty soon.
<mdke> https://bugzilla.ubuntu.com/buglist.cgi?query_format=specific&order=bugs.resolution%2C+relevance+desc&bug_status=__open__&product=Websites&content= <-- these are the website bugs, almost all unassigned, even the early ones
<ogra> koke, it would also be cool if it could use the app name form the .desktop file instead of the comandline in the dialog...
<ogra> koke, currently it talks about /usr/bin/blah .... instead of Blah
<hunger> fabbione: Good to have a trusty old debian box around... no devfs or anything, but at least I can get to the data I need on that box:-)
<fabbione> hunger: running breezy is not something you do, if you expect things to work.
<fabbione> hunger: run breezy and it will work
<hunger> fabbione: Yeah, I know... but I am a new-package junky...
<fabbione> or downgrade udev
<hunger> fabbione: I got bored on hoary;-)
<hunger> fabbione: I won't downgrade... better to figure out what goes wrong and fix it.
<hunger> fabbione: I'll look some more tonight after work.
<Lathiat> hunger: Just if it breaks, keep both pieces and don't hassle the devs too much. :)
<hunger> Lathiat: Yeah, I shouldn't have brought this up here. Actually I shouldn't be here at all.
<hunger> Lathiat: But the "how do I mount ntfs" got on my nerves in #ubuntu;-)
<Lathiat> heh
<trukulo> we need an #fukcking-ubuntu-gurus channel
<trukulo> lol
<koke> ogra: yeah, that would be the next step
<ogra> koke, http://udu.wiki.ubuntu.com/UsingSudo
<ogra> koke, alsden wants to extend the spec a bit and its not approved yet, but already shows the direction to go...
<ogra> s/alsden/sladen
<JaneW> Riddel: ping
<koke> ouch, I missed that one
<seb128> doko: is libstdc++5-3.3-dev supposed to have a /usr/lib/libstdc++.so? 
<seb128> doko: easytag FTBFS with a "/usr/bin/ld: cannot find -lstdc++", not sure of why
<doko> seb128: No, it's in g++-3.3
<seb128> hum
<doko> just wait with recompiling C++ code ...
<seb128> wait for what? that's a package bug or a buildchain issue?
<doko> looks like a package bug
<seb128> hum, k
<seb128> it builds fine on Debian and not on Ubuntu, I guess that's a gcc4 issue ... it gets a -lstdc++ but dunno why it doesn't on deb
<dholbach> Riddell: JaneW pinged you, but forgot an 'l' ;-)
<seb128> <tab> is nice :p
<ogra> hrm
<fabbione> seb128: lamont was mentioning something about gcc-defaults not being alligned yet
<doko> seb128: does it link with gcc or g++?
<fabbione> seb128: due to c++ crap
<seb128> doko: http://people.ubuntu.com/~lamont/buildLogs/e/easytag/1.99.4-1/easytag_1.99.4-1_20050503-1056-i386-failed
<fabbione> elmo: when and if you time, can you give me a sparc pulse please?
<seb128> fabbione: that causes some build breakages?
<fabbione> seb128: yes.
<fabbione> seb128: i have seen it here on sparc too
<seb128> k, thanks
<Kamion> you could work around it in the package by forcing gcc-3.3, I guess, if it builds both C and C++ code
<Kamion> grotty, though
<fabbione> Kamion: i think it's better to just wait for the transition :)
<seb128> I don't want to bother, that's an universe package and it can wait
<fabbione> adding workarounds now, will make the transition more painful later
<fabbione> plus we must drop gcc-3.3
<doko> Mithrandir: around?
<Mithrandir> yes
* fabbione -> food
<doko> please could you fix #9211?
<Kamion> fabbione: true
<doko> mithrandir: please could you fix #9211?
<seb128> doko: apparently it uses gcc
<doko> seb128: yes, and it doesn't find cc1plus from g++-4.0. that's package bug, should use g++ to link.
<seb128> doko: k, I'll have a look, thanks
<Mithrandir> doko: ask jbailey; he said he would fix it
<doko> Mithrandir: he's in vacation for a week ...
<Mithrandir> doko: just upload a new amd64-libs-dev, then
<doko> Mithrandir: thanks
<fabio> hello people
<mdke> hi
<fabio> hello mdke
<fabio> r u a developer?
<mdke> nope
<mdke> but ask in here
<fabio> eheh same, well I am studying, but I was going to ask, which could be the best IDE for C/C++ programming in Gnome?
<JaneW> dholbach: thanks
<JaneW> Riddell: ping
<ogra> fabio, anjuta probably
<tseng> hi all.
<ogra> hey tseng :)
<fabio> oh thanks Ogra, well something like KDevelop in KDE
<dholbach> i tried to use anjuta, but it wasn't helpful at all
<trukulo> fabio: kdevelop :) heh
<dholbach> fabio: just try to use it and see if it fits for you
<fabio> will, do because I program in C, so Gnome is C oriented isn't it?
<tseng> sortof
<tseng> it uses glib
<trukulo> fabio: if you want my advice, you can try anjuta+glade/gazpacho
<fabio> trukulp, that's great thanks
<fabio> trukulo sorry
<trukulo> fabio: you can call me trukulp if you want, silly
<trukulo> heh
<fabio> eheh, np
<fabio> I wanted also to ask, is it possible to di GUI programming with Shell scripts?
<doko> fabbione, elmo: please could you build a ppc64 kernel in davis's breezy-ppc64 chroot using gcc-3.4? we need it then installed to run the gcc ppc testsuite with -m64. This kernel should then be installed on davis
<dholbach> fabio: for absolutely primitive things, zenity exists, but you may want to have a look at python-gtk at some stage
<fabio> I saw something called GTk Server
<trukulo> fabio: i just read an article about it today
<fabio> oh right dholbch
<trukulo> it's very similar to zenity, but with more things
<fabio> trukulo, yes, seems interesting cos u can program GUI's via PHP too
<trukulo> exactly
<trukulo> i started reading it, but i have to stop (it's printed press)
<fabio> I did contact the programmer, I will go to translate in my language too, so I am waiting for his reply
<trukulo> i think he is poland, and that gtk-server is very recent
<trukulo> in fact, the article is written by the programmer
<fabio> yep, oh I thought he was German ;?
<fabio> nevermind, yes, well I am a web-designer, I thought to give him a help with the website style
<trukulo> i'm not sure fabio, don't believe me so much
<trukulo> publication is polish, that's for sure
<fabio> right, won't able to understand though!! ;)
<trukulo> fabio: article is translated to spanish
<fabio> trukulo, sorry only English or Italian here
<trukulo> anyway, i suposse you can find it in english in his website
<fabio> yes, I think I found it too
<fabio> trukulo, what u do in Ubuntu about dev?
<trukulo> me? nothing
<fabio> oh right, I thought u were a developer? ;)
<trukulo> no i'm not
<fabio> oh I see np
<trukulo> i'm just interested in development
<fabio> yes, what language?
<trukulo> no language in particular, just system
<fabio> oh right, cool, I am learning PHP, C and Shell Scripting
<fabbione> doko: no i can't build ppc64 kernels atm
<fabbione> doko: not a standard deb at least
<fabbione> doko: i think elmo is a better person to do it, since he will need to install it and reboot davis
<fabio> bye guys
<amnesia> hi
<fabio> bye guys
<chmj> doko, ping 
<doko> chmj: pong
<mdke> jdub, still here by any chance?
<mdke> mako, how about yourself?
<Kamion> oh, damn
<dholbach> Kamion: what's wrong?
<Kamion> fabbione: please 'echo common/ext2-modules > d-i/amd64/modules/amd64/ext2-modules.lnk; baz add d-i/amd64/modules/amd64/ext2-modules.lnk'
<trulux> heya
<Kamion> hoary/amd64 is unable to do anything with ext2 filesystems in the installer :(
<Lathiat> heh
<Mithrandir> Kamion: in hoary too?  That's quite bad.
<Kamion> ext3's fine
<dholbach> oh :-/
<Lathiat> ewps
<mdke> ok in the absence of those two guys, is anyone able to give me some advice about how mailing lists should be moderated?
<Lathiat> fascistly?
<HrdwrBoB> mdke: generally.. more 
<Kamion> it was fine in warty, since that had CONFIG_EXT2_FS=y
<mdke> Lathiat, ;)
<Lathiat> mdke: :)
<mdke> HrdwrBoB, you've touched on the problem i'm having. essentially the list is not too bad, but the occasional flame springs up. Now, I am currently the only moderator, and naturally I am unable to be always checking it. so i'm adding a person. the question is, whether to add a person to try and ensure that the list is ALWAYS covered, come what may (difficult to do, may require several people), or just be a bit more laissez faire and not worry about the occasion
<mdke> al weekend when neither moderator is present
<mdke> whoa, that was bigger than i expected
<mdke> anyway, any thoughts welcome
<HrdwrBoB> it's not the end of the world
<HrdwrBoB> maybe have another person as well
<mdke> 3?
<HrdwrBoB> who doesn't usually moderate
<zyga> hello
<pitti> Hi zyga 
<HrdwrBoB> but can be called upon when others are busy/unavailable
<mdke> hmm
<mdke> i was thinking of encouraging the whole list to act as moderators, i.e. try and calm things down when they get out of hand
<HrdwrBoB> yeah
<HrdwrBoB> that will also help
<zyga> ubuntu devel is back to normal :-)
<HrdwrBoB> some people though are trouble causers
<mdke> ahh, this list doesn't have that problem
<HrdwrBoB> ah well that's ok
<mdke> its more tempers getting frayed
<mdke> i think 3 people might be a bit much, HrdwrBoB, i can't see any ubuntu lists with that many admins
<HrdwrBoB> heh yeah
<mdke> dunno about moderators
<mdke> come to think of it, i'm not absolutely clear on the difference
<seb128> elmo: orbit2 sync please
<mdke> seb128, do you have that problem with ubuntu-fr?
<seb128> which one?
<mdke> ^^
<seb128> ?
<zyga> will gcj be unavailable until we actually use g++ 4.0 ?
<mdke> seb128, a problem with moderating the mailing list with just one person
<seb128> I'm not going to spend 10 min to get the point with 50 questions
<seb128> I'm not aware of any issue with the -fr list
<seb128> if you have specific questions feel free to ask
<mdke> seb128, sorry i'll make myself clearer.
<mdke> seb128, i'm sure there is no problem with the -fr list, i'm just asking for advice with a different list: do you find that it is necessary that the list has moderators always available, or is one moderator enough?
<seb128> depending
<seb128> I think that the message from people not subscribed at the list can wait one week or two
<mdke> yes
<seb128> but getting a second moderator if you have somebody you trust for the job doesn't hurt
<mdke> seb128, ok i appreciate the advice
<seb128> np
<mdke> seb128, do your moderators check the list every day?
<mdke> in case of flaming etc
<seb128> dunno for the others, I just approve new messages and reject spam on the -fr list
<mdke> seb128, oh right I guess you don't have those problems :)
<seb128> no
<mdke> cool
<mdke> ok thanks again
<doko> zyga: yes
<pitti> Riddell: here?
<Riddell> pitti: hi
<seb128> grumpf
<ogra> seb128, ??
<seb128> Mithrandir: your new pkgconfig breaks builds
<pitti> lamont: ping
<lamont> pitti: acl
<lamont> ack, even
<seb128> lamont: epiphany-browser builds fine on concordia ....
<seb128> lamont: maybe you could try to kick the build again just to see?
<lamont> seb128: will do
<lamont> doko: fetchmail hates you
<elmo> seb128: done
<seb128> thanks
<doko> lamont: bison hates _you_
<doko> (or maybe the buildd)
<seb128> jamesh: around ?
<lamont> doko: heh
<lamont> seb128: libgnomeprintui_2.10.2-1 has many undefined references during linking
<seb128> k
<Simira> *getting breezy*
<ogra> shudder
<Simira> :D
* mdke hands Simira a horseshoe
<seb128> lamont: I blame Mithrandir 
<Treenaks> I think Mithrandir made her upgrade ;)
<Simira> thanks mdke: Guess I'll need it
<seb128> lamont: the new pkgconfig breaks stuff
<Simira> Treenaks: actually he's out just now
<jdub> i love breezy
<seb128> he has just broken pkgconfig and runs away :p
<jdub> having stuff not working again makes me feel more comfortable
<Treenaks> jdub: does it love you back? :)
<ogra> heh
* Lathiat grins at jdub, Treenaks 
<seb128> jdub: you say that because you don't have to fix these stuff, right ? :p
<jdub> seb128: i have always enjoyed the company of competent hackers :-)
<seb128> rofl
<Lathiat> heheh
<chmj> hahaha
<Simira> jdub: then I know who I'll be whining to next time something doesn't work like I want it to...
* jdub wonders why flickr shows images with flash
<jdub> that's so bong
<ogra> hmm, isnt flash a quasi standard for images, like MS word is for .txt files ?
<bob2> no
<ogra> *g*
<trulux> tseng: seems that you replied too fast, or you were reading too deep
* Lathiat jumps ship to breezy
<mdke> everyone is jumping ship huh
<mdke> when do cd images start coming out?
<Lathiat> tseng: beagle probably wont be much good until we get kernels with inotify no? 
<jdub> Lathiat: boot with 'inotify'
<jdub> night all
<Lathiat> jdub: and it does bad things with my machine. :)
<Lathiat> doesnt with the newer patches
<Simira> night jdub
<jdub> Lathiat: ask fabbione when we'll get new kernels with 0.22 :)
<Lathiat> yeh i already was using it before, works fine except it screwed with gamin so i went back to 2.6.10. :)
<Mithrandir> seb128: which one?
<Mithrandir> seb128: that is, which package breaks?
<zul> jdub: im already running 0.22 :)
<seb128> Mithrandir: libgnome breaks, I think that's due to the --libs not listing everything
<seb128> -LIBGNOME_LIBS = -Wl,--export-dynamic -pthread -lglib-2.0 -lgmodule-2.0 -ldl -lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lesd -laudiofile -lm  
<seb128> +LIBGNOME_LIBS = -Wl,--export-dynamic -pthread -lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lbonobo-activation -lgconf-2 -lORBit-2 -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 -lesd -laudiofile -lm  
<seb128> 
<seb128> pkgconfig 0.15
<seb128> pkgconfig 0.17.2
<seb128> ups, other way rather
<seb128> ie: it needs -lbonobo-activation and -lgthread-2.0 which has not listed with the new version
<lexhider> what's the protocol with a non-devel confirming a bug that has an assignee? is it cool to do? [bug in question is trivial typo but nice to know in general] 
<Mithrandir> seb128: sounds like some libraries aren't linked correctly.
<Mithrandir> seb128: but yes, 0.17.2 is a bit broken, I'm going to find some time to fix it soonish.
<seb128> Mithrandir: where is the bug for you ? Ie: who should set the 
<seb128> "-lgthread-2.0"
<Mithrandir> seb128: which library needs libgthread-2.0 but isn't linked with it?
<seb128> Mithrandir: I guess libgtk-x11-2.0
<Lathiat> seb128: wasnt there some recent pkgconfig issue
<Lathiat> seb128: where it no longer pulls in libs that th libs your askign depends on?
<Lathiat> where issue may be a "feature"
<seb128> Lathiat: that's what we are just discussing
<Lathiat> right
<Mithrandir> Lathiat: I'm pkg-config upstream. :)
<Lathiat> blah
* Lathiat shuts up. :)
<Mithrandir> seb128: I should write a tool to verify that libraries are linked correctly, I think.
<seb128> Mithrandir: libgnome use bonobo-activation, what is the correct way to say it to pkg-config ? the configure.in ?
<Mithrandir> seb128: it should include a PKG_CHECK_MODULES with bonobo-activation-2.0 in configure.in, yes.
<Mithrandir> seb128: but only if it uses it directly itself.
<seb128> atm PKG_CHECK_MODULES looks for libbonobo-2.0, I guess it should look for activation too ?
<seb128> right
<Mithrandir> seb128: no, you shouldn't need that:
<Mithrandir> ldd /usr/lib/libbonobo-2.so | grep bonobo-act libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0xb7e27000)
<seb128> I get -lbonobo-2 but no -lbonobo-activation
<Mithrandir> you shouldn't need that; bonobo-2 is linked with bonobo-activation.
<seb128> so that's /usr/lib/pkgconfig/libbonobo-2.0.pc bugged ?
<seb128> hum, no
<seb128> hum
<seb128> /usr/lib/pkgconfig/libbonobo-2.0.pc:
<Mithrandir> this is weird; you shouldn't be seeing those errors at all
<seb128> Libs: -L${libdir} -lbonobo-2
<seb128> it should list activation here ?
<Mithrandir> no. :)
<Mithrandir> the libgnome in the archive FTBFS?
<seb128> so that's pkg-config bug, it should pick it correctly ?
<seb128> right
<seb128> builds fine with pkgconfig 0.15, ftbfs with the current version
<Mithrandir> I think it's some bug in some library which is masked by the old version
<seb128> ups
<seb128> libgnome/gnome-gconf.c      2005-03-11 21:11:36.000000000 +0100
<seb128> @@ -26,6 +26,7 @@
<seb128> 
<seb128>  #include <config.h>
<seb128>  #include <stdlib.h>
<seb128> +#include <popt.h>
<seb128> 
<seb128> you need this patch for gcc4 in fact
<seb128> then you get the bug
<Mithrandir> ok
<Mithrandir> give me a few minutes to check why it fails
<seb128> thanks
<SlackShrike> hi
<SlackShrike> do you have any repository with the chagens of debian-installer ?
<Mithrandir> seb128: to me, it looks like libgnome is using functions from bonobo-activation and gthread without asking for them.  It shouldn't. :)
<Mithrandir> seb128: but I'll need to investigate a bit further.
<seb128> Mithrandir: how should it ask ? 
<Mithrandir> seb128: in configure.in
<seb128> it PKG_CHECK_MODULES on libbonobo-2.0
<Kamion> mdke: CD images will start coming out when all the pieces are ready. This is my primary task at the moment.
<seb128> you said that should be enough
<Mithrandir> seb128: actually, it's using -Wl,-z,defs which breaks ATM.
<seb128> oh, that's due to that ?
<seb128> binutils bug ?
<Mithrandir> seb128: I think so; that's known to cause issues atm.
<Mithrandir> seb128: no, just bad interaction
<Kamion> there's no point building CD images yet because I can guarantee that they'll be broken :-)
<seb128> Mithrandir: what would you change for the package ? Not using -Wl,-z,defs for the moment ?
<Mithrandir> seb128: yes
<Mithrandir> seb128: I'm on my way out now; I'll need to sit down and fix it later today or tomorrow or so.
<seb128> k, thanks
<Mithrandir> since it causes breakage.
<mdke> Kamion, cool thanks
<mdke> Kamion, i'm not in a rush at all
<seb128> Mithrandir: k, let me know when you have fixed it
<seb128> thanks
<Mithrandir> seb128: np, sorry for the problems caused :/
<Lathiat> hrm, vmware... "Defragment: 484818900% done"
<Lathiat> i wonder if its eating my data :\
<wasabi> is your data tasty?
<Lathiat> nah its just a windows install
<wasabi> I wouldn't eat windows.
<Lathiat> neither would i
<Lathiat> but well, this is vmware.
<seb128> Mithrandir: np, that's a working branch after all :)
<SlackShrike> where I find documentation on casper ?
<SlackShrike> where I find documentation on casper ?
<SlackShrike> where I find documentation on casper ?
<Kamion> not by asking three times in one minute.
<Kamion> as far as users are concerned, it's generally self-documenting. other than that the only documentation I know of is in source code comments.
* lamont boots 2.6.12
<Lathiat> my machien is in the middle upgrading to breezy mmmmm
<SlackShrike> where I find documentation on casper ?
<Lathiat> will i regret this. :)
<Lathiat> SlackShrike: It is rude to constantyl ask the same question over and over and peopel will jut ignor eyou. Kamion has already kindly answered your question, please pay attention to what he said.
<SlackShrike> Excuses, tou with problem in my machine and are very slow.  I find that it is problem in the gnome-kerboard-layout
<mvo> ping mdz
* Nafallo will soon lack out on his poor laptop
<Nafallo> damn wireless keeps switching ap to my neighboors.
<lamont> Nafallo: so hardwire the AP... ?
<Nafallo> lamont, the problem seems to be in the driver. it's an rt2500 chipset.
<Lathiat> Nafallo: just iwconfig eth1 essid <blah>, if its the same essid or something, try ap <bssid of ap>
<Lathiat> Nafallo: ah, heh
<Nafallo> I am connected to my own ap, but then the damn thing likes my neighboors better right of a sudden ;-).
<Lathiat> maybe the ndiswrapper drivers will suck less ?
<Nafallo> should be better when the rewrite of the driver is made. hopefully we can have that out-of-the-box on ubuntu to :-).
<lamont> Nafallo: the simplest solution is to use something other than the default SSID, and then hardwire that with iwconfig
<Nafallo> lamont, I already do that :-)
<lamont>  /lib/modules/2.6.12-1-686/kernel/drivers/net/wireless/rt2500/rt2500.ko
<lamont> Nafallo: I was hoping you did... :-)
<Lathiat> Nafallo: try seeign 'ap <bssid>'
<Lathiat> iwconfig, read what the MAC of the ap is and set that
<Lathiat> might work
<Nafallo> lamont, is that the rewrite or the derivate from ralinks own?
<Nafallo> Lathiat, tried that to :-). there is a bug open upstream...
<lamont> Nafallo: no clue
<Lathiat> Nafallo: ah ok, sucky.
<Nafallo> lamont, that kernel is in breezy? I might aswell switch early in that case ;-)
<lamont> Nafallo: isn't uploaded yet - that's my most recent test-build
<Amaranth> does anyone here use jhbuild to build GNOME on breezy?
<zul> lamont: sorry about the config stuff :)
<doko> hmm, ia64 isn't installable at the moment?
<doko> Err http://archive.ubuntu.com hoary/main Packages
<doko>   404 Not Found [IP: 82.211.81.138 80] 
<lamont> zul: grumble. heh
<Lathiat> the 2.6.12 test kernesl worked great here except that it screwed with gamin
<lamont> doko: no
<zul> lamont: my bad
<Nafallo> lamont, ahh. well. I check mailinglist and mirrorlogs for the upload then :-).
<Kamion> doko: it'll be on ports.ubuntu.com eventually
<doko> lamont: so don't care about ia64 for breezy at the moment?
<lamont> doko: it's installable in the data center, and making the mirror visible again is on elmo's list for the week, but there are things ahead of that task...
<lamont> is there an sftp method for apt?
* elmo just looks at lamont
<lamont> nm
<pitti> lamont: I tried this once, it works; it just sucks if you need to type a password
<Lathiat> hrmm, ubuntu blacklits snd_intel8x0m because it "doesn't support much hardware on its own" but it drives modems attached to i810 audio chipsets, hrmm.
* Lathiat looks up the bug report
<lamont> pitti: I wasn't serious.  seriously
<pitti> lamont: I was serious, too. It indeed works
<pitti> ;-)
<lamont> neato.
<SlackShrike> sorry
<Lathiat> ah, fabbione disabled the inotify backend in gamin, so the 2.6.12 kernels should work ok now
<Treenaks>  what's wrong with the backend?
<Lathiat> Treenaks: no idea, but fabbione says its 'utterly broken' and it certainly breaks for me when i have inotify on (stops seeing file updates and stuff)
<zyga> did anyone notice increased memory and CPU usage of gnome-panel when updating/removing/adding packages?
<zyga> mine just hogged over 500MB of memory (and 95% CPU) for a moment so I've killed it 
<zyga> killing it seems to fix the problem
<zyga> I guess it keeps trying to update the menu after being constantly notified about updates to various .application and .desktop files
<zyga> but it also seems that it leaks memory somewhere along the way
<mvo> does anyone knows if python distutils support runing a testsuit for a pkg?
<lifeless> mvo: not built in, but you could hack it easily enough I htink
<jabra_> should I add my name as the new maintainer of radmind in the new package list as it looks like it was already review
<jabra_> /s/review/reviewed
<mvo> lifeless: ok, thanks
<mdke> http://ubuntuforums.org/showthread.php?t=22860 <-- stuff like this worrys me
<Lathiat> heh
<Treenaks> mdke: it's SCRIPTED
<Treenaks> *shudder*
<mdke> scripted evil
<Treenaks> instead of just fixing what needs fixing (i.e. licenses mostly)
<elmo> Treenaks: eh, fixing those licenses isn't exactly trivial
<elmo> (to be fair.  OTOH, I'm not encouraging that horrow show thing either)
<mdke> i use proprietary software as happily as the next man, but really, a script which doesn't even tell you what is going on and introduces backports into your sources.list... its enough to give you nightmares
<Treenaks> elmo: no, but a /shell script/.. 
<Treenaks> elmo: what's wrong with good old apt?
<elmo> eh?
<dilinger_> elmo: yea, why do you hate apt?
* dilinger_ smirks
<elmo> Treenaks: "instead of just fixing what needs fixing (i.e. licenses mostly)" <- I was responding to that
<Treenaks> ah
<Treenaks> anywat, the "script" should be a list of things to add to sources.list + a list of package names, imho
* mvo hates apt ... sometimes
<dilinger_> what's the default hoary compiler, gcc-3.3 or 3.4?
<elmo> 3.3
<dilinger_> thanks
<lamont> Mithrandir: amd64 libtool/gcc chain is randomly SEGVing sometimes.  fix that. kthxbye
* pitti just experienced that in wild life with a hoary-security upload
<elmo> eww
<elmo> _hoary_?
<elmo> how did we not notice this before?
<Lathiat> elmo: the ext2 stuff?
<lamont> elmo: just lucky I guess.
<lamont> elmo: then again, the kernel is fairly new, no?
<elmo> lamont: not really, they were running the same version for at least a couple of months before release
<elmo> it's had security updates, sure, but I doubt that's the cause
<virus84|> hi can any one tell me how mutch space i need to set up a ubuntu mirror?
<Nafallo> virus84|, a full one?
<virus84|> yes maybe
<virus84|> how mutch should what take?
<virus84|> more then 100GB?
<virus84|> or more then 1TB?
<zyga> virus84|: about 54GB for i386 AFAIR but I may be very wrong
<stratus> < 1TB of course.
<elmo> a full mirror is 63Gb ATM
<elmo> that's all arches, all suites
<Nafallo> elmo, that means ppc takes 12GB approx ;-)
<virus84|> elmo: okey all architecturs is included in that 63GB?
<virus84|> elmo: okey
<virus84|> elmo: are all the packages included to?
<Lathiat> zyga: i386 with no sources was ~10GB (including universe, multiverse)
<virus84|> im planing to put up a .se ubunto mirror 
<zyga> Lathiat: then I must have remembered something wrong
<virus84|> we have at the moment a debian mirror and kernel.org mirror
<stratus> virus84|, are you planning setup a ubuntU mirror too?
* stratus runs
<virus84|> stratus: yes
<Lathiat> heheh
<virus84|> stratus: we are a computer club www.ds.hj.se
<virus84|> ftp.ds.hj.se
<trulux> those interested in the new spec. for Ubuntu Hardened, that is, a RFC, could you join #ubuntu-hardened, please?
<Nafallo> ahh :-)
<stratus> hmm, ok.
<virus84|> stratus: somthing wrong
<virus84|> ?
<trulux> note; the RFC concerns both userland and kernelland related packages, maintainers of kernel packages and toolchain packages are highly encouraged to join
<stratus> no.
<zyga> trulux: will generic users benefit from listening to the discussion?
<zyga> s/users/developers/
<trulux> zyga: of course, and I would like to hear the opinion of as much people as possible
<fabbione> trulux: can't you just kindly do a call for a meeting with some notice in advance?
<fabbione> trulux: i would like to partecipate but 5 minutes notice in my life isn't an option
<trulux> fabbione: yes, I'm about to send an email to ubuntu-hardened and -devel
<fabbione> trulux: do a normal call with a week in advance
<Mithrandir> lamont: oh yay. :/
<fabbione> trulux: at least a week.. given the timezone differences
<trulux> fabbione: I apologize, I've been taking care of some stuff, like repairing my CRT early in the morning
<trulux> fabbione: I will discuss the date at the channel
<fabbione> and time....
<fabbione> remember of TZ
<trulux> tseng: feel free to join, but no flames there, please (and DON'T read too deeply, it's not my desire to waste my or others time with such senseless stuff).
<trulux> fabbione: sure
<ogra> wasnt that discussed and speced in a BOF in sydney already ?
<Mithrandir> jbailey: what mount is used in an initramfs?
* ogra tries to remember how it was called...
<lamont> Mithrandir: what would really help is if we had a /proc/sys/kernel entry that would let us say 'never use a virtual address < 4GB for user data'
<jbailey> g'm all
<lamont> then then >4GB issues would be solid.
<jbailey> Mithrandir: klibc stuff
<jbailey> I don't know the upstream of it, I can check.
<seb128> hey jbailey 
<Mithrandir> jbailey: yes please
<Mithrandir> lamont: that should be doable?
<lamont> Mithrandir: it should be... ia64 does ...
<lamont> well, doesn't have the switch, just does it....
<Mithrandir> but the ia64 people never test the binaries and nobody uses ia64; that's the reason why we're still seeing 64 bit issues on amd64. ;)
<lamont> heh
<jbailey> Mithrandir:  * mount_opts.c, by rmk
<jbailey> Mithrandir: Is about the only hit I get, I'll keep looking.
<Mithrandir> jbailey: ok.  I'm probably going to rewrite mount(8) completely and it would be nice to be able to actually generate the initramfs mount from the same sources
<jbailey> Mithrandir: This code is just a wrapper around the mount syscall AFAICT.  It may be original code.
<jbailey> That and some comand line parsing.
<Mithrandir> jbailey: ok, so there isn't any real need for a mostly full-featured mount there?
<jbailey> Mithrandir: I'm all about using a common mount, it would save some suckage, but that assumes that I can actually compile your mount rewrite with klibc.  Keep in mind that it's not a posix C library.
<jbailey> Mithrandir: Enlighten me as to what mount provides beyond this? =)
<Mithrandir> jbailey: file system autodetection?  Handling of loop devices?  Handling of crypted devices?
<jbailey> Ah, right.  Hmmhmm.  I haven't thought into the realm of crypt'd devices and such yet at all.  
<jbailey>         eval $(fstype < ${ROOT})
<jbailey>         # Mount root
<jbailey>         mount ${ro} -t ${FSTYPE} ${ROOT} ${rootmnt}
<Mithrandir> jbailey: the new one will have a plugin system so adding support for a new file system will not mean you need to patch mount.
<jbailey> There's a binary called fstype
<jbailey> I'd really like to see fstype merged into util-linux
<lamont> doko: looks like gcc-3.4 might actually build on debian/hppa - sorry for screaming...
* lamont mutters about 20 hour builds 
<Nechushtan> how can I contribute a "bug" for the installer?
<Kamion> util-linux uses stuff from e2fsprogs for that at the moment, doesn't it?
<Kamion> Nechushtan: bugzilla.ubuntu.com
* Mithrandir leaves for dinner
<jbailey> Kamion: Well, the fsck wrapper is provided by e2fsprogs
<Kamion> Nechushtan: if you don't know the package, choose "debian-installer" as a default
<Nechushtan> Kamion: thanks
<Kamion> jbailey: no, for figuring out filesystem types
<Kamion> libblkid
<jbailey> Hmm, dunno for sure.
<jbailey> Ah, cool.
<Nechushtan> Kamion: if i know the step in the install process does that help or still use debian-installer ?
<Kamion> Nechushtan: what step?
<Nechushtan> bootloader install
<Kamion> Nechushtan: architecture?
<Nechushtan> amd64
<Kamion> Nechushtan: probably grub-installer then
<Nechushtan> though it happened with my Athlon XP too
<Kamion> Nechushtan: it gets to me either way ;)
<Nechushtan> haha
<Nechushtan> ok
* mvo is away to play some hockey, bbl
<doko> lamont: as long as you don't cry as loud as fabbione about sparc ... ;-)
<doko> jbailey: Mithrandir told me that you did want to make an amd64-libs-dev update to remove the conflicting headers
<jbailey> doko: Yeah.
<jbailey> doko: I want to do an l-k-h update that makes all of the headers biarch properly so that they're all available.
<jbailey> doko: Then it'll just get treated the same as sparc, s390, and powerpc.
<doko> jbailey: when? it's needed as a build-dep.
<jbailey> doko: I'm tracing devmapper breakage, so I'll update lkh with that fix, and after that do the amd64-libs-dev.
<lamont> jbailey/doko: for biarch, probably the best thing to do is leave the signed _source.changes for the stuff that needs to be built somewhere I can fetch it (preferrably in-LAN...), and give me steps
<jbailey> lamont: It should literally be just installing the glibc, I think and then letting doko upload the new package.
<doko> lamont: ppc64 biarch gcc doesn't build without a ppc64 kernel. fabbione doesn't want to build it, elmo probably doesn't have the time to do so
<jbailey> doko: Really?  Hmm
<Kamion> elmo: could you lisa the ubuntu-meta changes? I'd like to upload a matching debootstrap
<Lathiat> hmm, bugger. tomboy crashes with the new mono
<doko> jbailey: tries to run some 64bit binaries for building the runtime libs to see, if the 64bit support is there.
<jbailey> doko: Hmm.  Isn't it possible to set it up so that it does the biarch bits like a cross compiler?
<doko> jbailey: I didn't try. At least s390 and sparc didn't try that either
<seb128> pitti: where is your page about informations to submit for utopia bugs?
<pitti> seb128: http://wiki.ubuntu.com/DebuggingRemovableDevices
<seb128> oh, wiki page
<elmo> doko: why are you uploading expect-tcl8.3 by hand?
<seb128> I was looking on p.u.o
<seb128> thanks
<doko> elmo: stuck in Debian NEW, needed for gcc-4.0 on hppa
<elmo> expect-tcl8.3           | 5.43.0-1                                              | source hppa        | 3 hours old
<elmo> wow, that's _really_ stuck.  those evil crappy debian ftp folk
<elmo> :P
<Nafallo> hehe
<doko> elmo: don't blame the poor ftp folk, but the ftp-master ;-)
<Lathiat> elmo: haha
<jordi> the ftp-masters are busy attending my NEW requests. Leave them alone!
<Nafallo> lol
<lamont> yeah - how dare they take more than 3 hours to push something through NEW. :-)
<trukulo> jordi: promise them a beer
<doko> elmo: is it now possible to sync from experimental?
<elmo> doko: has been for eons
<jordi> I need to tell mvo to do the magic required to get nano/experimental in breezy then
<jordi> it won't be long before I upload it to unstable though
<doko> elmo: eons must be < 3 months
<jordi> that is eons in free software speak :)
<elmo> hmm, why has trashapplet come back?
<elmo> seb128: I assume we don't want it?
<jordi> elmo: yeah, you don't
<jordi> it was uploaded to Debian because Sarge won't have it in gnme-applets
<jordi> it lacks conflicts, etc though
<elmo> meh
<elmo> do we not want 'suede' either?
<jbailey> Wah, why doesn't i386 glibc have /usr/include/gnu/stubs.h?
<seb128> elmo: no we don't
<seb128> elmo: they have backported that for sarge since that's a GNOME 2.10 stuff
<elmo> seb128: which? 
<elmo> suede or trashapplet?
<seb128> trashapplet
<elmo> ok
* seb128 looks on suede
<trukulo> suede is icon artwork
<trukulo> i mean, it shouldn't be official gnome stuff
<elmo> so hang on.  we can fit a new arch into sarge, but not a new gnome?  ROCK ON.
<jordi> elmo: hmm, funny thing is that trashapplet is only 4d old. I guess it won't make it in :)
<elmo> </bitter and off-topic>
<jbailey> elmo: </ >  Really?  Is it over that easily? =)
<Nechushtan> whats /.dev ?
<seb128> elmo: suede looks ok to me ... any issue with it?
<jbailey> Nechushtan: It's the /dev directory that would be there if udev weren't running.
<Nechushtan> ahh
<jbailey> Nechushtan: Safe to ignore, unsafe to delete.
<Nechushtan> yea
<trukulo> Nechushtan: old entry for udev if it failed
<Nechushtan> just never saw that in my other distros
<elmo> seb128: I thought we had suede in ubuntu-artwork already or something.  but then I don't really notice/track all the icons and artwork and similar stuff, so I may be 12 months out-of-date
<elmo> lamont: dude, is it really necessary to do all this postfix stuff?  it seems like a lot of delta for little gain
<trukulo> elmo: not in hoary
<seb128> elmo: I thought so, but I don't have any /usr/share/icons/Suede/ on my system, I think that was before having Human
<trukulo> seb128: you're right, suede it's not in hoary
<cartman> any ETA on a gcc update?
<jbailey> lamont: Around?
<jbailey> cartman: What's the rush?
<cartman> jbailey: KDE blacklisted 4.0.0 :(
<cartman> need 4.0.1 :/
<cartman> aka 4.0 branch
<jbailey> I think doko said the patch for that might already be in our setup, I don't recall for sure, though.
<jbailey> There's alot of toolchain work over the next couple of weeks, though.  Have yous een the spec for the toolchain work that we wrote at UDU?
<cartman> jbailey: its just version thing our g++ is 3.3 anyway :)
<elmo> hey, how do I get mvo's update-crack in the panel?
<Riddell> not yet but should be soon
<doko> jbailey: the patch, that broke it, was not yet in the branch
<elmo> it doesn't appear in the add to panel options
<cartman> KDE only checks gcc :/
<cartman> jbailey: yep ABI transition will be hairy...
<elmo> Need to get 72.7MB of archives.
<cartman> jbailey: I won't report c++ bugs for a month or so ;)
<elmo> yay for security updates in inhumanly large packages
<cartman> elmo: tetex security updates always rocks
<cartman> ~45mb updates
* jbailey snivles and asks lamont to gzip the build logs. =)
<elmo> jbailey: you're lucky, you can always log into rookery and look at them directly
<elmo> and really, they should be bzip'ed.. they bzip _so damn well_ it's not funny
<jbailey> Will browsers and such automatically unpack bzips?
<elmo> dunno, but buildd.d.o does it, so I imagine so
<jbailey> My thought was basically that every browser out there now unpacks .gz files without a problem, so at least do that.
<seb128> grrrr, malone is b0rked
<seb128> you can't even put a comment on a put
<seb128> it eats it with an error on the first time
<jordi> gtk bug?
<seb128> then you get a window where you can enter the bug again
<seb128> and you need to click again after that to get the comment on the bug
<seb128> jordi: no way
<seb128> and you can't put a comment when you close a bug ...
<seb128> you need to change it to close
<jordi> it's always gtk bug :)
<jordi> I gotta leave.
<seb128> then click on the link to get the bug page
<seb128> and then put a comment ...
<seb128> jordi: later
<jordi> seb128: upload to experimental!
<jordi> err, unstable
<seb128> what ?
<jordi> gnome!
<jordi> gone now
<seb128> ah ah
<jbailey> Something is officially screwed.
<jbailey> dpkg -x shows that libc6-dev has /usr/include/gnu/stubs.h, but when I dpkg -i it, it's not there.
<elmo> jbailey: multi-arch diversion crack? :P
<seb128> dpkg-divert ?
<jbailey> Might be, checking all that.
<jbailey> Yar.
<jbailey> Yeah,
<jbailey> Looks like amd64-libs-dev
<jbailey> hmm
<jbailey> which isn't installed. =(
<jbailey> So I'm guessing the postinst fails to remove the divert.
<jbailey> Well, maybe I'll do the lkh/amd64-libs-dev upload *before* I fix devmapper then.
<mdz> morning
<Nafallo> goodmorning mdz :-)
<ogra> morning mdz 
<trukulo> afteroon matt :)
<zul> hey mdz 
<ghetek1> im sorry to bother with a support question but nobody knows in any other irc room. I'm on an imac, i dont know what type but i know its a slot loader.  i put in the live cd but it doesnt give me a gui. it says it has problems finding my display. any help would be much appreciated
<seb128> mdz: do you know what is wrong with aspell? Building the package on my box fixes the issue, but the version from the buildd doesn't work
<mdz> seb128: I thought mako said that he fixed it with rebuilds in the archive
<Kamion> ghetek1: try booting with the 'video=ofonly' kernel argument?
<seb128> mdz: I've uploaded a new aspell this afternoon but the result is still b0rked
<seb128> mdz: and rebuilding on my box works as said
<seb128> mdz: that puzzles me a bit, so if you have an idea ... :)
<mdz> seb128: b0rked == unresolved symbols?
<seb128> right
<seb128> ** (gedit:7780): WARNING **: Error, unable to open module file '/usr/lib/libaspell.so.15: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE'
<seb128> by example
<mdz> is aspell written in C++?
<cartman> mdz: yes
<cartman> and its not linking to libstdc++ for some reason
<seb128> mdz: right
<mdz> cartman: yep
<mdz> seb128: is it being linked by libtool?
<seb128> yes
<mdz>  g++ -DHAVE_CONFIG_H -I. -I. -I./gen -I./gen -I./common -I./interfaces/cc/ -I./modules/speller/default/ -DLOCALEDIR=\"/usr/share/locale\" -g -Wall -O2 -fno-exceptions -MT modules/filter/url.lo -MD -MP -MF modules/filter/.deps/url.Tpo -c modules/filter/url.cpp  -fPIC -DPIC -o modules/filter/.libs/url.o
<mdz> /bin/sh ./libtool --tag=CXX --mode=link g++  -g -Wall -O2 -fno-exceptions   -o libaspell.la -rpath /usr/lib -version-info 16:2:1 -no-undefined common/cache.lo common/string.lo common/getdata.lo common/itemize.lo common/file_util.lo common/string_map.lo common/string_list.lo common/config.lo common/posib_err.lo common/errors.lo common/error.lo common/fstream.lo common/iostream.lo common/info.lo common/can_have_error.lo common/conver
<mdz> t.lo common/tokenizer.lo common/speller.lo common/document_checker.lo common/filter.lo common/objstack.lo common/strtonum.lo common/gettext_init.lo common/file_data_util.lo modules/speller/default/readonly_ws.lo modules/speller/default/suggest.lo modules/speller/default/data.lo modules/speller/default/multi_ws.lo modules/speller/default/phonetic.lo modules/speller/default/writable.lo modules/speller/default/speller_impl.lo modules/
<mdz> speller/default/phonet.lo modules/speller/default/typo_editdist.lo modules/speller/default/editdist.lo modules/speller/default/primes.lo modules/speller/default/language.lo modules/speller/default/leditdist.lo modules/speller/default/affix.lo modules/tokenizer/basic.lo lib/filter-c.lo lib/word_list-c.lo lib/info-c.lo lib/mutable_container-c.lo lib/error-c.lo lib/document_checker-c.lo lib/string_map-c.lo lib/new_config.lo lib/config
<mdz> -c.lo lib/string_enumeration-c.lo lib/can_have_error-c.lo lib/dummy.lo lib/new_filter.lo lib/new_fmode.lo lib/string_list-c.lo lib/find_speller.lo lib/speller-c.lo lib/string_pair_enumeration-c.lo lib/new_checker.lo modules/filter/url.lo    -ldl -ldl 
<mdz> libtool: ignoring unknown tag CXX
<mdz> mkdir .libs
<mdz> eek, sorry
<mdz> doko: is it kosher to link using 'gcc' rather than 'g++'?
<seb128> $ grep unknown *.build
<seb128> $
<seb128> don't get such error with my local build
<mdz> seb128: yes, that's very odd
<mdz> the libtool in /usr/bin/libtool has CXX
<elmo> mdz: no
<doko> mdz: no, if you link g++ code.
<mdz> that'll be the problem, then
<elmo> (didn't we have this discussion already?)
<mdz> if test "" = "post" ; then \
<mdz> 	if test -e ./libtool ; then cp -f /usr/bin/libtool ./libtool ; fi ; \
<mdz> fi
<mdz> elmo: yes, but I couldn't remember if it was ld vs. g{cc,++} or gcc vs. g++
<trulux> mdz: hi?
<mdz> trulux: hi
<mdz> seb128: where does the top-level libtool come from?
<mdz> is it just shipped with the source package?
<elmo> gar, that's so satanic
<seb128> mdz: the source package has no libtool
<seb128> the configure does that here:
<seb128> configure: creating libtool
<seb128> appending configuration tag "CXX" to libtool
<mdz> yeah, just saw that
<mdz> seb128: does the libtool in your build have 'CXX' in it?
<seb128> $ grep CXX libtool 
<seb128> available_tags=" CXX"
<seb128> as said by the configure output "appending configuration tag "CXX" to libtool"
<mdz> seb128: it looks like it is running libtoolize during the build
<mdz> it shouldn't do that
<mdz> oh, no it isn't
<mdz> are those "pre" and "post" things cdbs hooks?
<seb128> jbailey: ? :)
<elmo> it doesn't build-depend on libtool
<elmo> so it must be creating it from the source pkg
<elmo> bah, why isn't there a breezy-i386-chroot on concordia
<astharot> ciao
<mdz> lamont: ping
<Kamion> elmo: hmm, moving ubuntu-minimal and ubuntu-standard to main would be good, too :)
<tseng|work> lame ass irc-cgi
<tseng|work> heya mako
<jbailey> seb128: here.
<elmo> Kamion: picky picky
<Kamion> elmo: details, y'know
<Kamion> (thanks)
<tseng|work> that -minimal stuff is pretty rad
<Nechushtan> I know, wrong channel, but kinda depserate: can someone help me get my amd64 kernel setup to see my IDE drives?
<cartman> Nechushtan: select AMD xxx thing in IDE driver section
<cartman> compile them in and it works
<Nechushtan> IDE driver section?
<Nechushtan> oh, recompile the kernel
<Nechushtan> so the packaged amd64 kernel doesn't support ide?
<cartman> errr?
<cartman> default kernel works fine
<Nechushtan> then I'm confused
<cartman> I thought you were recompiling your own kernel
<Nechushtan> ah, no
<Nechushtan> just trying to get ubuntu installed and running
<cartman> it works fine with an nforce4 mobo here
<Nechushtan> is there a special module I have to install?
<cartman> nope afaik
<Nechushtan> argg
<jbailey> Nechushtan: initrd-tools should go through all the chipset modules.  If it's missing one, please let me know.
<Nechushtan> jbailey: little more detail please
<Nechushtan> jbailey: the install cd found the drives fine, but I had to unplug all my ATA drives to get ubuntu to install, now I'm trying to reconnect them
<Nechushtan> ugh
<jbailey> You had to unplug the drives?
<jbailey> Like the harddrive from the chain, as opposed to the controller right?
<Nechushtan> jbailey: yea, I just unplugged the drive cable from the mobo and the pci ATA100 card so that grub would install on my scsi drive
<Nechushtan> which, when i did it with the i386 installer worked fine after i plugged them back in
<jbailey> Otherwise how was it failing?
<seb128> jbailey: nm, that was just about the <mdz> are those "pre" and "post" things cdbs hooks?
<jbailey> seb128: Ah, okay.  All sorted out?
<Nechushtan> from the installer grub only installs on the first bios drive (ie no worky for scsi) and lilo is just fubar in the installer
<seb128> not really, but that's not a cdbs issue
<Nechushtan> the weird thing is it won't even see the drive i have plugged into the onboard ATA controller
<Nechushtan> weird, "PCI: cannot allocate resource region 3 of device 0000:00:01.1" when i boot with the Ultra100 pci card plugged in...
<seb128> elmo: is serpentine (new package) somewhere? I've not received a NEW mail apparently
<Nechushtan> the kernel seems to not be able to allocate resources for my ATA card
<Nechushtan> ok, what do I need to do to get udev to create /dev/hd?
<mdz> seb128: perhaps when lamont emerges, he can help us find out what is happening differently on the buildd
<seb128> would be nice
<seb128> hum, I'm reading ubuntu-user, there is a new thread about cdparanoia/sound-juicer beeing slow on ubuntu 
<seb128> any chance that would be a kernel issue?
<mdz> seb128: does your configure say 'appending configuration tag "CXX"' also?
<mdz> seb128: probably it is due to the fact that we disable DMA on CD-ROMs by default
<seb128> we have 2-3x speed, according to user Suse does 15x 
<seb128> according to user hdparm doesn't change a lot 
<mdz> seb128: #3672
<mdz> oh
<bluefoxicy> cups broke in breezy.
<mdz> if hdparm doesn't fix it, I don't know
<bluefoxicy> my printer doesn't work.
<seb128> mdz: 
<seb128> <seb128> configure: creating libtool
<seb128> <seb128> appending configuration tag "CXX" to libtool
<mdz> bluefoxicy: mine either; have you tried to find out why?
<bluefoxicy> I print, it pauses the printer, i resume it, it pauses it again.
<mdz> seb128: I wasn't sure if you were pasting from the buildd log or yours
<bluefoxicy> I deleted the printer, recreated, printed, it did it again.
<seb128> mdz: according to the thread this seems to work better with ide-scsi ... I'll give a try
<bluefoxicy> mdz:  I tried reinstalling cups and restarting it and flushing and all
<ogra> mdz, the mail talks about (upstream) known issues with te kernel module
<seb128> mdz: from my box
<bluefoxicy> mdz:  no luck.
<seb128> bluefoxicy: same here
<mdz> bluefoxicy: but did you do some investigation to try to find the source of the problem?
<mdz> I would like to, but I don't have time
<bluefoxicy> mdz:  no, that's as far as I kno how to do.
<bluefoxicy> I don't have a debugger on cupsd
<mdz> for one thing, /dev/usb/lp0 on my system has the wrong permissions, but that is not the only problem
<seb128> right, root.root here
<seb128> udev issue?
<mdz> that allows me to print a test page, but the PDF document I want to print still doesn't go
<mdz> udev has changed the way that it deals with these permissions
<mdz> it used to use: usb/lp[0-9] *:root:lp:0660
<mdz> now it does: SUBSYSTEM="printer",    GROUP="lp"
<bluefoxicy> that fixes it
<mdz> hmm, in fact it is doing both
<jbailey> Mithrandir: Around?
<mdz> never mind
<mdz> /etc/udev/permissions.d seems to be ignored now
<mdz> so I was right the first time; it is using SUBSYSTEM instead of pathnames
<mdz> does anyone know how SUBSYSTEM works?
<Nechushtan> screw it. time to try Kanotix...
<mdz> Nechushtan: I understand that you're frustrated, but that isn't a good way to get help.  See http://www.ubuntu.com/support/
<sjoerd> mdz: /sys/class/<subsystemname>/<name>/dev mostly except for block..
<mdz> sjoerd: so udev probably unfers SUBSYSTEM from the sysfs pathname?
<mdz> s/unfers/infers/
<jbailey> It would pretty much have to, I'd guess.
<jbailey> Can tell you in a sec.
<sjoerd> maybe it's passed in the hotplug event too, not sure
<Nechushtan> mdz: well, it works with the i586 install but i can't for the life of me figure out why the amd64 kernel won't see any IDE drives and I'm just not familiar enough with /dev to figure it out
<mdz> Nechushtan: this channel is intended for developer discussion, not for getting help with problems.  that's what #ubuntu is for.
<jbailey> mdz: "udev" expectes SUBSYSTEM as an environment variable, udevstart sets it for inital start.
<Echylo> damn, need to set encoding options, this channel looks all chinese for me :|
<Echylo> so much too learn, so little time
<mdz> jbailey: so udevstart gets it from the sysfs path, otherwise the kernel provides it?
<jbailey> mdz: Looks like that, yeah.
<jbailey> Trying to confirm the gets-it-from-the-sysfs path bit,
<bluefoxicy> mdz:  steal another distro's udev config and tweak it :P
<bluefoxicy> why do the work twice :)
<mdz> bluefoxicy: do I need to explain the charter of this channel again?
<bluefoxicy> mdz:  after I look up the definition of charter in the dictionary as pertaining to anything other than catching a bus?
<mdz> bluefoxicy: are you being deliberately obtuse?
<GheRivero> res
<bluefoxicy> mdz:  um.  Eh, I kinda get what you're saying, you're just using words in ways I haven't encountered before.
<mdz> jbailey: is there some way to get udevsend to dump the environment, or do I need to wrap it?
<jbailey> mdz: I haven't played with udevsend at all, sorry.
<jbailey> mdz: There's no command line parsing or debug stuff in the code.
<jbailey> mm, dbg(), not debug.
<mdz> yes, seems ot end up syslogging with LOG_DEBUG
<mdz> but it doesn't come through; perhaps it isn't compiled in
<jbailey> mdz: Needs a rebuild with -DDEBUG
<mdz> bah, easier to wrap it
<mdz> it's coming through with SUBSYSTEM=usb, not SUBSYSTEM=printer
<mdz> or rather, I see SUBSYSTEM=usb events come through, but no SUBSYSTEM=printer event
<mdz> udevsend.env.7600:DEVPATH=/class/usb/lp0
<mdz> SUBSYSTEM=usb
<jbailey> mdz: Do you want that double checked?  I don't have a usb printer handy at the moment, but I can arrange one in 10-15 minutes.  Where I'm staying has one in a pile in the next room apparently.
<mdz> jbailey: seb128 confirmed
<mdz> I'm just not sure how to fix i tyet
<mdz> it yet
<mdz> this is https://bugzilla.ubuntu.com/show_bug.cgi?id=10004
<jbailey> FWIW, I think scanner devices are wrong too, so that whole bit might be off in the new udev.
<jbailey> mdz: Shall I take this bug?
<mdz> jbailey: please
<mdz> I noticed a bug report about scanners, but I don't recall whether it was breezy or hoary
<mdz> or even warty
<seb128> hum, not faster with ide-scsi here 
<mdz> seb128: SuSE's kernel is very different from ours; it could be anything really
<seb128> right
<mdz> they are probably also using a different cdparanoia
<jbailey> mdz: I'm pretty certain my scanner only stopped when I upgraded to breezy, and not with my glibc testing.
<Treenaks> suse has scary automount-ish stuff in the kernel
<glyph> If I need to build drivers that live in the kernel source tree normally (in my case, fs/cifs), how can I convince make-kpkg to build a kernel that looks *exactly* like the running one, i.e. will have compatible modules?  I did make-kpkg kernel-image --append-to-version -5-k7 but modprobe complains that my new cifs.ko 'disagrees about version of symbol struct_module'
<glyph> (after copying /boot/config-2.6.10-5-k7 to .config, of course)
<mdz> glyph: #ubuntu, please
<glyph> mdz: Already been there.  With 500+ people on the channel, many of whom are clueless, there is not much hope of getting help there on anything detailed anymore :-).  I figured that this was a sufficiently esoteric question it might warrant discussing here - sorry for using an inappropriate venue.  I am also curious though, whether ubuntu's kernel uses a non-standard cifs subsystem, because it's been badly broken enough for me that I 
<lamont> mdz: ack
* lamont delunches
<lamont> mdz: which package?
<mdz> lamont: aspell
<lamont> 0.60.2+20050121-2ubuntu1 built successfully *4
<mdz> lamont: I know; read scrollback please
<mdz> it builds, but doesn't work
<lamont> k
<mdz> fabbione: what remains to be done for 2.6.12rc?
<mdz> lamont: seb128's local build works, though
<lamont> mdz: in a pristene chroot? or just on his machine full of packages?
<seb128> machine full of packages :p
* seb128 chroots
<seb128> pbuilder even
* lamont tests in an sbuild chroot, just to see if he can reproduce it
* lamont scratches his head
<seb128> lamont: the pbuilder version works fine too
<lamont> yeah.  and rebuilding in a fresh chroot on the buildd fails.  chroot on my machine works.
* lamont does another build on both, preserving the directory
<seb128> elmo: poppler sync from Debian please
<jblack> Do you guys have something smart planned for device enumaration? 
<jblack> My usb key and printer both have usb filesystems and they swap sda sdb depending upon which one is plugged in first.
<jbailey> jbailey: ISTR that hotplug is supposed to have some sort of magic that can be used for that, but I don't know anything about it.
<jbailey> jbailey: Do you just drop .ps files in the filesystem for the printer?
<seb128> jbailey: stop talking to yourself, big freak :)
<jbailey> seb128: Perhaps I'm still jetlagged.
<seb128> ah ah
<jbailey> seb128: Or given that occasionally the folks doing the scheduling couldn't tell jblack and I appart, I've simply caught whatever they had ;)
<seb128> :p
<mdz> jblack: if it's important that they have useful names, label them
<mdz> jblack: then they'll be mounted according to the label
* jblack googles
<mdz> we're not currently planning to do anything about sda vs. sdb, but rather provide another layer of naming on top of that
<jblack> will that work with things like autofs? 
<mdz> autofs is a different beast
<mdz> I don't recommend using it for removable media
<jblack> Perhaps I'm using the wrong tools then. 
<jblack> This is how I've got things setup. I keep all of my important stuff on a usb key -- gpg key, ssh key, baz archives, etc, all symlinked to the appropriate places on my filesystems. When I want to ssh somewhere, if my key is inserted, autofs mounts the usb key, ssh grabs the key. then, about 60 seconds later, its unmounted. 
<jnc> and when your flash drive goes kaput
<jblack> (that ended with "60 later, its unmounted" 
<jblack> jnc: pardon? 
<jnc> jblack: flash block devices are not the most reliable things
<jblack> jnc: I occasionally make an encrypted backup. 
<Nafallo> jnc: that's why you keep backups of stuff :-)
<jnc> i've seen more than 5 go bad in the course of a few years
<jblack> jnc: anyways, they're good for 10k mounts. I don't mind if the key is going to be good for a year or so, because by then, I can buy a device with twice the flash at 1/2 the cost. Even now, I could superceed my $90 256mb key with a $60 512mb one. 
#ubuntu-devel 2005-05-12
<jblack> I rarely write to the device anyways. Usually its just reads. 
<jnc> i'm just asserting whether or not you rely on it to be the only copy of your data
<jblack> So, if autofs isn't the recommended method for what I'm doing, what is? 
<HrdwrBoB> jnc: if you want to do that, replace it semi regularly
<HrdwrBoB> in any case, I wouldn't trust anything to be the only copy of data
<jblack> I think we've wandered from the original question.
<tseng> wth, that aspell rebuild is still broken
<jblack> The problem I have is that I'm getting into a mess because my printer has a filesystem too. so, depending on whether my key is in during boot or not, it changes devices. 
<HrdwrBoB> ah
<jnc> jblack: that info is in /sys
<HrdwrBoB> the easiest way to deal with that is to put a volume name on your key
<seb128> tseng: read the chan log
<HrdwrBoB> that way it'll be mounted under /media/name
<jnc> that too
<tseng> seb128: ok
<tseng> seb128: ew
<jblack> I think I've succeeded in disabling the daemon that does /media/name
<jblack> I had problems with it not automatically unmounting fast enough.
<tseng> that would be hal, pmount and gnome-volume-manager on top
<jblack> kde here. :) 
<tseng> unmounting fast enough to do what?
<jblack> To minimize the risk from yanking the key out while in a rush. :)
<tseng> yeah um :)
<tseng> it unmounts it after it relized you yanked it
<tseng> heh.
<jblack> its a little late then. :) 
<tseng> yeah it should include a mind reading module
<Nafallo> hehe
<jblack> that's why I've got automount doing a 60 second auto-unmount.
<tseng> or just look into the future.
<jblack> autofs, that is
* lamont follows the breadcrumbs
<mdz> jblack: this is really a #ubuntu sort of conversation
<jblack> sorry. I'm used to working the baz way. 
<lamont> mdz: issue isolated, pondering clean solutions
<seb128> lamont: about aspell ?
<eruin> is n-c-b 2.11 making its way into breezy anytime soonish?
<seb128> when it's ready
<mdz> eruin: we have a lot of higher-priority work to do at the moment
<eruin> mdz: yup, just curious ;)
<seb128> I tend to think than ubuntu has the new GNOME package quickly usually
<seb128> there is no real point to ask for non-tarballed version here though ...
<seb128> ie: there is no n-c-b 2.11 atm
<lamont> seb128: yes. aspell. and others
<seb128> lamont: what is b0rked for aspell ?
<eruin> seb128: yeah, I was just wondering since I'm tracking rhythmbox--merge which just upped its req. to 2.11 ;) - whether or not to build it myself
<lamont> gcc invocation, but not aspell's doing.  (g++ -v != g++ -pipe -v)
<lamont> rather, g++ invocation.
<seb128> hum, k
<seb128> GNOME 2.11.0 is planned for soon anyway
<seb128> BTW time for sleep now, 'night
<eruin> nn
<mdz> daniels: for building thin clients, it'd be nice to have a way to tell xserver-xorg "don't even bother"
<mdz> would be useful for the livefs builds as well, really
<Kamion> yay, joeyh is rattling through the initramfs d-i hacking
<Kamion> hooray for synchronicity
<mdz> Kamion: how close is a debootstrappable breezy?
<mdz> I don't need it right away, but down the road it will be necessary for thin client testing
<Kamion> mdz: coincidentally I was just finishing off the debootstrap upload to reduce to the minimal seed
<mdz> yay
<Kamion> elmo: I don't believe http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html for one second; is that really working properly?
<Kamion> mdz: (I uploaded it before I looked back at this window, so it's on its way)
<Kamion> elmo: does breezy need to be added to the MERGE section of /srv/ftp.no-name-yet.com/testing/britney?
<Amaranth> sarge froze?
<Kamion> yes
<Amaranth> err, wrong channel :0
<Amaranth> err, :)
<Amaranth> I'll try trying now
<Amaranth> ack
* Amaranth dies
<ajmitch_> btw, where's the MoM results for universe?
<lamont> mdz/elmo: did we decide on 'build' as the auto-syncable upload word?  3.1.3-1build1?
<lamont> new aspell uploaded
<lamont> fabbione: you around?
<mdz> lamont: yes
<lamont> mdz: ok. lftp needs a little love as well
* lamont uploads lft_3.1.3-1build1
<mdz> lamont: please close #9906 if aspell turns out OK
<toresbe> The Ubuntu installer is a version of debian-installer, right?
<tseng> yes.
<toresbe> night, and ganbatte
<zul> fabbione: i added hostap support this afternoon
<zul> good chelsea lost :)
<cc> say, is ubuntu hoary using EVMS or LVM2?
<jdub> cc: both
<cc> jdub: is EVMS going away (w/LVM2 being the preferred method)?
<cc> btw, hi jdub. well rested?
* lamont heads to his fire dept meeting
<mdke> jdub, sorry to be pinging you again
<jdub> cc: don't think so, evms seems to be the better set of tools
<jdub> cc: not sure if i'm well rested yet ;)
<cc> jdub: hmm, i was under the impression that upstream evms was dead
<cc> jdub: well, go out, party, enjoy the marriage and stuff
<jdub> cc: best to ask mdz about this
<cc> ok, will do when mdz is next around
<mdz> cc: evms upstream is manifestly alive and very responsive
<cc> mdz: ah, you're around. so the installer should be preferring evms over lvm2 in the next release (breezy)?
<mdz> cc: there is currently no defined plan for adding EVMS support to the installer, though I am interested in seeing it happen
<jsgotangco> good morning
<tseng> hi
<ajmitch_> hi jsgotangco 
<jsgotangco> hi tseng, ajmitch_ how's it going
<tseng> its lame user night
<jsgotangco> hehe
<ajmitch_> breaking things like usual
<tseng> yeah how do we unbreak my uploads
<jdub> tseng: did aspell go in?
<tseng> jdub: yes
<jdub> cool
<mdz> has anyone seen thom since UDU?
<tseng> only idle 7 hours
<dilinger> meh, i have to take infinity abuse here now?
<infinity> dilinger : infinity abuse?
<infinity> mdz : He's VAC, isn't he?
<infinity> (Which I should have done too... I'm developing a seriously nasty flu since I got back)
<jsgotangco> ouch
<dilinger> <dilinger> joshk: i upgraded apache2.  i blame infinity for the breakage
<dilinger> infinity: how's the wife and kids?
<infinity> The wife is good.  The kids are nonexistant, and we're keeping it that way.
<infinity> Unless, by "kids", you mean "daniels", and I assume he's fine, but I haven't seen him since getting back.
* infinity wonders what he broke in apache2.
<dilinger> heh
<dilinger> i dunno
<dilinger> all i see in error.log is a SIGTERM
<tseng> ugh libgda transition
<tseng> is that already planned?
<mdz> infinity: that was before UDU, not after, unless you know something I (and StaffCalendar) don't
<infinity> No, I'm probably just fuzzy in the head.
<HrdwrBoB> how big is universe?
<zul> pretty big...lots and lots of planets :)
<mdz> daniels: ping
<Amaranth> tseng: the libgda stuff didn't hurt anything before (could be ignored) but now python2.4-gnome2-extras needs the new one
<Unfrgiven> hey all ive got a friend trying to install ubuntu on a thinkpad R31. he said that he has screen corruption as soon as the install starts and hence can't install. is there any tricks i can ask him to try? i have him on instant messenger right now so i could prolly try stuff
<z3k3> ask in #ubuntu
<z3k3> you'll get better response
<Unfrgiven> z3k3: k thanks.
<z3k3> there should be a "text" option
<z3k3> when he's sitting at the prompt tell him to go through the help stuff
<z3k3> good luck.
<womble> Unfrgiven: The "F1 at boot: prompt" gave me the right option to use on my R31 a month or so ago
<Unfrgiven> womble: ok thanks. my friend is a bit of a newbie and says that he cant see anything for this option... ill boot off the cd and have a look myself.
<womble> Don't have to boot, the option screens are browsable on the CD
<womble> vga=771 (via F5)
<womble> So "linux vga=771" is what needs to be entered
<womble> Unfrgiven:  I recall that worked for me
<fabbione> morning
<Unfrgiven> womble: ok thanks. i found something that aloows you to turn off the framebuffer
<Unfrgiven> womble: so it seems we have a solution for my friend... he's out for lunch. so ill have to wait till he returns
<Unfrgiven> womble: thanks for your help though
<womble> Unfrgiven: no probs
<womble> Be warned that Hoary on the R31 is likely to cause some occasional mouse spastics.  
<womble> Turning off the battery monitor helps a bit, but it'll still happen occasionally
<blahrus> wondering if it was a bug with breezy and nothing having aspell working?
<jdub> blahrus: upgrade
<lamont-away> blahrus: #9906
<lamont-away> and fixed
<lamont> hrm... should have changed that a while ago...
* blahrus update && upgrade
<blahrus> thanks guys
<blahrus> jdub: still not spell checking
<jdub> lamont: is postfix-tls now rolled in to postfix?
<jdub> lamont: or just momentarily incompatible?
<lamont> jdub: builtin
<jdub> lovely, thanks :)
<lamont> jdub: mind you, it may be broken... feel free to bitch...
<jdub> heh
<blahrus> i how your not reffering to me bitching
<blahrus> hope not how
<infinity> lamont : Did you figure out what went wrong with your keysigning?
<jdub> lamont: is the tls stuff simpler now?
<Unfrgiven> infinity: all this time i thought i was doing something wrong with lamont's keys... im happy to hear it wasn't me :)
<jsgotangco> yeah something's wrong eheh
<lamont> infinity: haven't looked yet
<lamont> figured I'd let the dust settle this week
<jsgotangco> lamont, no rush :) take your time
<lamont> a bunch of them worked, though.  that's the annoying part
<infinity> Well, I blame Kinnison.
<lamont> infinity: to be fair - I ignored an error...
<infinity> Oh.  In that case, I blame you. :)
<jsgotangco> whiprush, ping?
<pitti> good mor*yawn*ing
<fabbione> hey pitti
<dilinger> pitti: yawn indeed
* dilinger is ready for bed
<infinity> pitti : A quick glance of the php3 stuff looks like he just pulled my changes directly from Debian, so it should be fine.  Want me to actually compare for paranoia's sake?
<pitti> infinity: no, I don't think that he actually changed anything
<pitti> infinity: btw, do you think we should go into the warty-ffox test phase soon?
<pitti> Morning ogra!
<infinity> pitti : Yes, just let me fix console-tools to stop sucking first.
<pitti> infinity: ah, that keymap error on boot?
<infinity> pitti : If you can find some suckers^Wvolunteers who are willing to test, that'd be cool.
<pitti> infinity: we mail the internal ML about this and require everybody to do so :-)
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
<lamont> hrm... /me bets Kamion isn't awake yet.
<pitti> mdz: still up?
<mdz> pitti: yes
<fabbione> hey mdz
<bob2> what's up with http://archive.ubuntu.com/ubuntu/pool/multiverse/t/transcode/?  it doesn't seem to be built on any architecture.
<fabbione> bob2: check people.u.c/~lamont/buildLogs/
<infinity> bob2 : FTBFS on all arches.
<bob2> ah, right
<bob2> needs non-existent build-deps
<lamont> yeah - missing build-deps
<lamont> bob2: libavcodec-dev should do the trick... or ffmpeg
* lamont makes it an early night
<pitti> daniels: here?
<fabbione> good night lamont 
<Mithrandir> hm; how was the selection for the minimal seed done?
<infinity> Meh, where's jbailey when you need him?
<Mithrandir> asleep, most likely
<infinity> I wonder if he'd do painful things to me if I uploaded a new linux-kernel-headers.
<crimsun> transcode is dying on i386 because of a missing libdivxencore0 (no divx4linux source package)
<crimsun> among many others. Hmm, troublesome.
<bob2> yeah
<mdz> a lot of that zany stuff is gcc-4.0-unfriendly
<infinity> mdz : Any objections to a new linux-kernel-headers with a 1-line change to include/linux/keyboard.h (to match 2.6.12-rc3)?
<fabbione> infinity: i do object :)
<infinity> I'd wait for jbailey to come back, but this is what's breaking the console-tools build. :)
<fabbione> infinity: i think jb has other changes pending for l-k-h
<infinity> fabbione : Most likely, yes, but I doubt his intersect with mine (unless he's updating the whole thing to a newer upstream)
<mdz> jbailey should be around within ~6 hours, I expect
<fabbione> infinity: i would be much more happy to wait for jb
<infinity> Mmkay.
<infinity> I'll wait.
<fabbione> since even a line change in l-k-h has been killing sparc/hppa/ia64
<infinity> I could hack around it in console-tools, but that feels less correct.
<fabbione> can't console-tool just wait 6 hours?
<infinity> Yup. :)
<fabbione> than sit down and take a very loooong smoke :)
* fabbione hands a cig to infinity 
<infinity> I'll mail him, mind you, since I may not be here in 6 hours.  But no big deal.
<fabbione> thom, elmo: piiiing???
<Treenaks> edd: you're my new hero
<lifeless> edd: oh, if you have baz questions. .. just ping me ;)
<fabbione> elmo: davis breezy chroot is borked.. i think it's the usual udev -> /dev/null problem, and i noticed that the load was pretty high due to cron daily overllaping
<fabbione> elmo: it would also be very nice if you can give me a sparc pulse....
<fabbione> (and sorry for 349394 REJECT mails.. there was a problem with a local disk and it was trying to upload & reupload all the packages for a few hours. fixed now)
<elmo> meh, it's the silly cron.daily scripts getting entirely confused by the bazillion bind mounts
<elmo> sparc pulsed
<elmo> and don't worry, I don't get the REJECT mails directly, they queue locally on jackass, so it's no biggie
<fabbione> elmo: ok.. you can just flush them
<fabbione> ok guys...
<fabbione> who has an amd64 and feels VERY lucky today???
* Treenaks points at Mithrandir 
<jsgotangco> brb
<Mithrandir> fabbione: hm?
<fabbione> Mithrandir: people.u.c/~fabbione/
<fabbione> Mithrandir: grab a kernel and let me know :)
<Mithrandir> does it work on hoary?
<fabbione> nope
<fabbione> breezy only
<Mithrandir> well, I don't have any amd64 breezy boxes yet.  Waiting for the smoke to rise first.
<fabbione> Mithrandir: tsk... time to upgrade and test my kernel
<fabbione> you have no excuses ;)
<fabbione> well you can actually run that kernel, upgrading only 3 packages from breezy
<fabbione> you don't need the full breezy
* jdub sends smoke signals to Mithrandir over the horizon
<seb128> morning
<Treenaks> hi seb
<jdub> yo seb128 
<seb128> hey hey jdub 
<seb128> elmo: can you sync poppler from Debian please? And do you know if serpentine (new package) is somewhere, apparently I've not received a NEW mail
<JaneW> elmo: ping 
<elmo> seb128: done.  new where?  ubuntu or debian?
<seb128> elmo: ubuntu
<seb128> thanks
<elmo> JaneW: ?
<elmo> seb128: it's in NEW - you didn't get mail because you used seb128@d.o rather than @u.c
<crimsun> elmo: please sync xmms from sid
<seb128> elmo: oh, I thought than both were working ... thanks :)
<elmo> seb128: I de-whitelisted all non-ubuntu addresses for employees a while ago, as mdz told us all to switch to u.c
<elmo> crimsun: ubuntu changes ok to override?
<seb128> k
<crimsun> elmo: yes
<elmo> crimsun: oh.  xmms is in main.  can you get a main uploader to ACK?  sorry to have to ask
<crimsun> elmo: np, mvo's the last to resync with sid. Thanks.
<jdub> can we shove xmms out of main?
<elmo> jdub: any particular reason why?
* jdub checks colin's dep foo
<seb128> why main has xmms to start with ? :)
<Treenaks> elmo: mp3
<elmo> because rhythmbox is the suck?
<jdub> elmo: crackrock muck and inbuilt mp3 (yes, i actually still use xmms too)
<jdub> http://people.ubuntu.com/~cjwatson/germinate-output/breezy/rdepends/xmms/xmms-dev
<jdub> ^ bong
<Treenaks> flac build-deps on xmms?
<Treenaks> WTF?
<jdub> for the flac xmms module, i'd imagine
<Treenaks> hm, good point
<p0m> People use flac still?
<Treenaks> p0m: in the form of oggflac, yes
<p0m> Ohh.
<p0m> Duh.
* p0m goes back to arguing with optocouplers and serial ports
<GheRivero> res
<seb128> lamont: around?
<Kamion> cc: it makes very little difference which the installer uses; the on-disk format is (I'm told) the same. The installer will use whatever set of tools makes it easiest to do stuff automatically, but that has very little bearing on whether they're generally suitable or not.
<Kamion> cc: (of LVM2/EVMS)
<Kamion> Mithrandir: the minimal seed was done by mdz and I sitting down in Sydney and going "need that", "don't need that", etc.
<Kamion> Mithrandir: we tried to keep only stuff needed for the system to come up and install packages, plus a few things we couldn't quite bear to get rid of (wanted an editor, couldn't quite part with less, strace is "terribly useful", etc.)
<cartman> morning
<Kamion> Mithrandir: but there was lots of stuff from base that fell into the "comfortable Unix system" category, and we pushed that out to standard)
<Kamion> -)
<Mithrandir> Kamion: I would say stuff like memtest has nothing to do on a minimal system, but that might just be me.  I'll spend some time making a list of stuff I'd like to chuck out.
<Mithrandir> Kamion: the idea is we want minimal to be as small as possible for HTPCs and such.
<Nafallo> morning all
<jsgotangco> Mithrandir, any nice UDU pics wif u?
<jdub> Kamion: strace? pfft. ;-)
<ogra> morning
<jsgotangco> ogra, hey
<Mithrandir> jsgotangco: in a little while, yes.
<ogra> jdub, want to answer this ? http://lists.ubuntu.com/archives/ubuntu-users/2005-May/033833.html
<Nafallo> jdub: not to me rushing you or anything, but when can we see the next ubuntu-calendar? :-)
<jdub> ogra: thanks :)
<jdub> Nafallo: soon, soon
<jsgotangco> the fridge
<jsgotangco> heh
<ogra> :)
<hunger> Anyone working on the udev bug that stops usb sticks to work?
<mvo> crimsun: xmms needs to be merged by hand because it build-depends on "type-handling"
<crimsun> mvo: danke
<fabbione> mvo: is xmms in main?
<crimsun> (yes, xmms is in main)
<fabbione> yeah than it needs manual love
<Treenaks> "manual love"
<p0m> Treenaks: Copulation in the bitbucket?
* ogra yays for serpenine
<Treenaks> ogra: for the sarge freeze?
<ogra> Treenaks, nope, for seb128's new package of it
<Treenaks> ogra: ah :)
<Kamion> Mithrandir: memtest86+ is there because the installer adds a bootloader entry for it, and it's good for that to be there at the first boot.
<Kamion> Mithrandir: but it's flexible - we were being fairly conservative at first and in cases of doubt we left stuff in base (renamed to minimal)
<Kamion> mdz: please edit breezy.template as well as breezy when making debootstrap script changes, otherwise I'm liable to overwrite them at the next upload
<seb128_> elmo: gnome-media sync with debian please
<elmo> seb128: debian is << than us?  or do you mean experimental?
<seb128_> experimental
<Kamion> mdz: ('./required-base.py breezy' regenerates the script from the template)
<GheRivero> res
<jsgotangco> bye bye
<Mithrandir> Kamion: I would go the other way -- minimal should really resemble debian's base, or even thinner, IMO.
<Mithrandir> Kamion: if not, it'll be too big to be useful for buntu/mini-ubuntu
<elmo> any sane base is going to be, surely?
<elmo> if moobuntu is aimed at the embedded world you want more debian-installer minimalness than a "minimal" normal debian system
<Kamion> Mithrandir: it was a start, mkay
<Kamion> Mithrandir: and we already removed some stuff that's in Debian's base
<Kamion> e.g. man-db (though I put up token resistance)
<Mithrandir> Kamion: ok. :)
<Kamion> it's easier to remove stuff from Debian's base though 'cos they don't have the metapackage crack
<Mithrandir> elmo: we thought a mini-ubuntu might be useful for small systems like home theatre boxes and such
<Mithrandir> Kamion: I wasn't trying to pick on you, sorry.
<Kamion> Mithrandir: just noting that what we have now is anything but final. :)
<Mithrandir> Kamion: then I'm happy. :)
<p0m> To be honest, I think Familiar and OpenEmbedded might be better than a ubuntu based system :)
<Kamion> would be worthwhile somebody figuring out how to get libreadline4 out of minimal, btw (we have libreadline5)
<Kamion> p0m: improving Ubuntu for those purposes and others is a continual goal, though ...
* edd wonders if any launchpad guys around
<jdub> hey edd
<Kamion> edd: try #launchpad?
<p0m> Maybe you should talk to the familiar developers then, familiar is semi debian based.
<Amaranth> Kamion: Good luck with that. It looks like Python, GNOME, and KDE all depend on it.
<p0m> And they might be able to give you some good tips/guides.
<Kamion> Amaranth: GNOME and KDE don't impact minimal
<edd> Kamion: ah, thanks.
<edd> jdub: hey dude
<Amaranth> #launchpad? it's open source?
<Kamion> no
<Amaranth> I thought freenode didn't allow channels for things that weren't open source.
<Kamion> not as far as I can tell from the network policy (http://freenode.net/policy.shtml)
<Kamion> er, "not" = "I don't think that's true"
<Amaranth> hmm
<p0m> Launchpad isn't open source?
<Kamion> "including those of free and open source software (FOSS)"
<Amaranth> They might have changed it. I had a channel shutdown because it wasn't for open source stuff.
<Kamion> p0m: no - personally I hope it will be one day, but at the moment the code isn't distributed
<Amaranth> #launchpad might fit in as corporate
<p0m> Kamion: Fair enough/
<Amaranth> "Corporate.  Contact channels for registered corporate or business entities or consortia with an interest in our target communities are considered to be on-topic."
<Kamion> pitti: the security advisory format for warty+hoary advisories is a bit odd. Could there be some indication of which archive URLs are for warty and which for hoary?
<pitti> Kamion: yeah, I can ceartainly add that
<pitti> elmo: ^  is it possible to integrate that into the templates?
<Kamion> pitti: it works well for single-suite advisories, but maybe "Source archives (Ubuntu 4.10)" or something would work
<elmo> pitti: adapt one of the existing advisories as to how you think it should look, and send it to me and I'll fix amber
<mvirkkil> Is there any way to check if doing a fopen on a fifo would block? (ie, can you check if someone is trying to open the other end)
<Mithrandir> it wouldn't block until you tried to read, would it?
<Kamion> coo, breezy is debootstrappable now, I didn't actually check last night. excellent.
<Kamion> 180508  /chroot/breezy
<mvirkkil> Mithrandir: It would.
<mvirkkil> But I figured it out. Doing a non-blocking open and then a fdopen will work.
<Kamion> so bigger than Debian but not quite so outrageously much bigger as it used to be
<Kamion> jdub: http://lists.debian.org/debian-release/2005/05/msg00118.html # ?
<jdub> Kamion: sjoerd (new maintainer) knows about our patches - his call
<Kamion> jdub: oh, I thought you were still maintainer
<seb128> Kamion, jdub: the version waiting in Debian/NEW has the hoary patch but we according to the discussion on #gnome-debian we don't need gamin for sarge
<Kamion> so does the BTS, for that matter :)
<seb128> nothing uses it atm and that's not tested on Debian
<Kamion> ok, thanks
<seb128> np
<jdub> seb128: why hasn't sjoerd changed the maintainer yet? :)
<seb128> I think he has, but as said the package is NEW
<seb128> due to the python bindings I think
<Kamion> scheduled for removal
<seb128> jdub: any objection to have only evolution 2.3 for breezy? I'm thinking about make different packages like the Debian maintainer does, or keeping one package ... I think than I prefer the second option, but opinions are welcome 
<pitti> seb128: as long as the data format stays compatible, supporting only one version is definitively preferrable
<seb128> pitti: right, I think that too, thanks :)
<astharot> ciao
<jdub> seb128: if we have two versions, no one will test the development version :-)
<pitti> Hey astharot 
<astharot> hi Martin
<seb128> jdub: right, let's get some fun :)
<astharot> I just sent what you requested yesterday :)
<pitti> neat
<pitti> astharot: will take a look at it ASAP, but I still have a psql security update which will keep me busy for some hours
<astharot> ok, there are other pending patches
<astharot> for main
<Kamion> 236352  /chroot/hoary-base
<Kamion> so minimal has saved 56MB, which is a start; could go further
<jdub> fabbione: around?
<Kamion> mdz: meh - can we remove reiser4progs from minimal? given that our kernel doesn't support it, I think we should kick it out as far as supported at least
<elmo> I don't think we should even support it, TBH
<jdub> *cough* universe *cough*
<ogra> hrm
<trukulo> has sense
<Kamion> elmo: tend to agree, hence "at least"
<Kamion> wonder how it snuck in there; I think it dates back to London
<fabbione> jdub: yes
<jdub> fabbione: have you looked at the fedora core kernels to see what they do about the SATA/PATA mess?
<jdub> fabbione: just hearing that they work fine
<fabbione> jdub: so does our kernel...
<fabbione> we fixed that problem a long while ago
<jdub> fabbione: http://www.gnome.org/~gman/blog/04052005
<fabbione> jdub: ahha that's the same problem i fixed for benno at the university
<fabbione> he had a gx280
<fabbione> it's the bios setting...
<jdub> i'm told that fedora does not require the PATA compat BIOS setting change
<Robot101> heh
<fabbione> jdub: that's SATA
<Robot101> took me a while to realise he was talking about solaris :)
<jdub> fabbione: SATA with PATA compat
<jdub> regardless of what you call it, fedora doesn't require the BIOS change
<fabbione> jdub: ENOTENOUGHRESOURCES to track fedora too
<jdub> hrm
<fabbione> also... fedora is running 2.6.11.something
<fabbione> that might have been fixed upstream...
* Kamion -> lunch
* pitti lunches
<jiyuu0> i've done this "sudo update-rc.d nessusd defaults", but on the next reboot... nessusd doesn't start unless manully start it... any idea how to make it auto start?
<Treenaks> jiyuu0: read /etc/defaults/nessusd? maybe you need to config it?
<ogra> bah, breezy update takesalready 444 packages
<tseng> Amaranth: its a bit more than that
<jiyuu0> Treenaks, nessud is not in /etc/rc3.d
<jiyuu0> is that the prob?
<ogra> nope
<ogra> rather look in rc2.d ;)
<Treenaks> jiyuu0: that's not what I said.
<jiyuu0> Treenaks, /etc/defaults/nessusd looks normal
<jiyuu0> ogra, ok... i'll check that out
<ogra> update-rc.d is not a adimnistartors tool...
<Amaranth> tseng: ?
<jiyuu0> ogra, it's also not in rc2.d 
<ogra> probably it gets started by inetd ? dunno
<tseng> Amaranth: libgda
<Amaranth> tseng: yeah, that was just fron a user POV
<Amaranth> iirc libgnomedb is the one that needs updated for the rest of the stuff to stay, at least on my machine
<tseng> I guess
<tseng> gtk-sharp* too
<Alessio> next community council?
<Alessio> any suggesting date?
<astharot> ciao
<AndyFitz> Alessio,  the 8th ?
<Alessio> where is this date?
<AndyFitz> that was a suggestion
<AndyFitz> :)  I don't know when the next meeting date is
<ogra> i'd guess the 11th since that would be the normal 2 week schedule (one left out because UdU)
<zul> hey
<Amaranth> how can something that ubuntu-desktop depends on be in universe?
<pitti> it can't
<ogra> it cant...
<ogra> hey pitti
<Amaranth> oh, the new version is in universe
<Nafallo> Amaranth: what package?
<pitti> Hey ogra
<Amaranth> python2.4-gnome2-extras
<ogra> mihght be caused by the autoimport...
<Amaranth> yeah
<Amaranth> well, it says seb128 is the maintainer but that probably means he put it in sid :)
<ogra> he maintains both afaik....just hasnt touched the ubuntu package yet i guess
<seb128> Amaranth: I don't understand your issue
<seb128> what wrong?
<Kamion> Amaranth: universe->main propagation is only semi-automatic, not fully automatic
<Amaranth> seb128: nothing :)
<seb128> Amaranth: grrrrr
<Amaranth> hey, while you're around... :)
<seb128> Amaranth: if you have something to say, say it, doesn't start speaking about an issue on a package to say nothing
<Amaranth> could you look into a pyxdg 0.10 package
<seb128> no
<seb128> what about python-gnome2 ?
<Amaranth> just saying it's in universe and ubuntu-desktop depends on it
<seb128> breezy?
<SlackShrike> hi
<Amaranth> yeah
<Amaranth> Kamion already explained why
<Kamion> Amaranth: that can happen transiently. don't worry about it, it'll get fixed up.
<seb128> no need to start to point every change for breezy
<SlackShrike> i am installing  breezy now !
* Amaranth goes to do something else
<Kamion> SlackShrike: I imagine you're upgrading, not installing
<JaneW> any idea why I can not hear sounds on my Ubuntu installation, apart from event beeps etc...
<SlackShrike> Yes
<SlackShrike> I am upgrading
<JaneW> web sites with sound, and audio files = no sound
<SlackShrike> I am lick build a cd-install with the breezy packages
<JaneW> I checked volume control and it's pretty much maxed out
<ogra> any errormeaages ? 
<ogra> messages even
<Kamion> SlackShrike: don't bother, it won't work yet
<mvo> Kamion: do you use the "--allow-unauthenticated" switch in aptitude in the installer?
<JaneW> ogra: no there's nothing, except silence ;)
<Kamion> mvo: no, I use the -o APT::whatever
<Kamion> mvo: actually, no, not to aptitude
<JaneW> Ogra: I tried loading the badger song as a test, I had to install flash 7, which I did, and it;s playing now, the visuals are fine but it's silent.
<mvo> Kamion: ok, thanks (I'm merging the aptitude code with our patches right now)
<Treenaks> JaneW: it's a bit of a hack, but killing esd fixes flash for me
<Kamion> mvo: (I prefer -o because that's more tolerant of old versions of apt)
<JaneW> Treenaks: I am a bit of a newbie on Ubuntu , should wma sound files be able to play?
<ogra> JaneW, ah, ok.... Treenaks is right, if you installed flash for macromedia it wont work while esd is running, our flashplayer in multiverse is fixed afaik, but not version 7
<JaneW> hmmm..
<ogra> JaneW, nope, you'll need the microsoft codec for that....
<JaneW> ok, I did try to play a wma file earlier before the flash installation (but that may be windows specific?)
<JaneW> oic, ok
<Treenaks> JaneW: wma sound should be able to play if you follow the RestrictedFormats page from the wiki
<JaneW> *nod*
<Treenaks> JaneW: +instructions on the 
<JaneW> should I use the multiverse flash player then?
<ogra> JaneW, w32codecs is what youre looking for
<JaneW> or fiddle with esd?
<ogra> yep
<ogra> one of these, your choice
* Treenaks shakes his fist at software monopolies
<JaneW> ogra: which is easier ;)
* JaneW choses the path of least resistance
<ogra> using multiverse is "cleaner" :)
<Nafallo> I can't even see flash, gladly ;-)
<JaneW> ogra clean sounds good, thanks.
<Nafallo> if people tell me to install I it, I just have to tell them to tell Macromedia to let me ;-)
<ogra> Nafallo, amd64 ?
<Nafallo> ogra: oui :-)
<ogra> heh, same here
<ogra> no badger song for me.... :(
<Nafallo> hehe
<ogra> but 2 mins to breezy....
<JaneW> ogra: should I select the mozilla plugin - since I intend it to run in firefox?
<ogra> JaneW, yep....its just a generic name.... 
<Nafallo> ogra: huh? "but 2 mins to breezy"?
* Treenaks guesses he's upgrafding
<ogra> Nafallo, upgrading
<Treenaks> -f
<Treenaks> ogra: tell me if/when it works ;)
<Nafallo> ogra: ahh :-)
<Nafallo> I down-graded to hoary again since my flash-drive and usbkey didn't automount ;-).
* ogra is a bit worried about >64000 mails in his local inbox....a major evo breakage would be no fun....
<pitti> Nafallo: oh, same for me :-/
<Nafallo> ubuntu have made me lazy :-P
<Nafallo> from debian/fluxbox to this ;-)
<pitti> Nafallo: no worries, we will update the complete Utopia stack soon (and the kernel), after that we can make it work again :)
<Nafallo> pitti: I know. I'm holding of to the 2.6.12 hits the archive now. that will stop me from having to compile my wlandriver from cvs ;-)
<ogra> gah, lots of locale errors
<Nafallo> hmm, I hold of a bit longer probably ;-)
<JaneW> ogra: ok I installed, biut now I have to get rid of flash 7 (I think)
<ogra> JaneW, depending on how you installed the plugin you have to delete it in the right plugin directory...
<ogra> (with or without sudo/root)
<JaneW> erk.
* JaneW must dash out, I'll try that shortly
<pitti> Riddell: will you fix the kdewebdev vuln in Breezy, too?
<Riddell> pitti: good point, will do
<stockhol1> mdz: ?
<pitti> Riddell: thanks
<stockhol1> can anyone help me with edubuntu?
<stockhol1> is anyone here working on edubuntu?
<stockhol1> is there a special mailinglist or so?
<Nafallo> hmm, debootstrap needs sudo, or will fakeroot suffice?
<stockhol1> Nafallo: i dont think fakeroot cuts it
<stockhol1> Nafallo: it needs to chroot, which fakeroot cant do
<Nafallo> stockhol1: right. just got the error :-)
<zul> Nafallo: which wlamdriver?
<Nafallo> zul: rt2500 :-)
<zul> ah..
<zul> ok
<Nafallo> zul: you don't happen to know if it's the rewrite or the branched ralink driver that's in there?
<zul> Nafallo: its the one from sourceforge the gpl one
<Nafallo> zul: yepp, that project has two versions. the rewrite will be better, but I don't know in what state it is atm. haven't tried it myself yet...
<zul> Nafallo: well when 2.6.12 for breezy is released you will get to try it out ;)
<Nafallo> zul: I know. I follow my mirrorlogs closely ;-).
<Nafallo> zul: I guess it's the rewrite then :-)
<ogra> fabbione, 2.6.12 boots fine here....
<ogra> fabbione, (amd64 on breezy)
<SlackShrike> how the casper work. sorry, i not speak english very well.
<seb128> pitti, carlos: what is the standard way to get something translated/using rosetta? ie: ubuntu-artwork
<carlos> seb128: if it has a .pot file inside, you don't need to do anything
<seb128> no there is no
<carlos> seb128: put it into the archive and it will be imported into Rosetta
<carlos> seb128: then you need to create it on build time
<seb128> k
<carlos> seb128: and name the .po files as LOCALE.po (es.po, fr.po, pt_BR.po) instead of using WHATEVER-LOCALE.po like ubuntu-artwork-es.po
<seb128> there is some apps doing that ?
<seb128> all the I was going to do fr.po as usual for GNOME stuff
<carlos> seb128: ubuntu-docs was doing it
<carlos> seb128: ok, perfect
<seb128> carlos: k
<pitti> Hey dilinger 
<dilinger> pitti: good morning.  how's it going?
<pitti> dilinger: fine, I'm catching up
<ogra> hmm, my console keymap in breezy seems broken....
<pitti> ogra: yeah, infinity is going to fix that
<ogra> ah, fine
<ogra> i can reconfigure it though... it works until next reboot
<cartman> ogra: keymap thing is https://bugzilla.ubuntu.com/show_bug.cgi?id=10063 btw
<ogra> cartman, thanks
<cartman> np
<seb128> lamont: around?
<lamont> seb128: yo
<zyga> which package could contain update-mozilla-chrome?
<seb128> lamont: can you kick the gtkspell build? it ftbfs according to the build-log, and you have open #9998 , but it builds fine with pbuilder here !?
<zyga> I'm trying to remove locale stuff I've installed some time ago but uninstallation script ivoked by dpkg fails on this, missing, program
<seb128> zyga: #ubuntu question
<zyga> seb128: right
<seb128> and that's mozilla-browser
<zyga> hmm that smells like a bug to me :-)
<zyga> anyway thanks
<seb128> np
<stockhol1> is anyone here working on edubuntu?
<lamont> seb128: is g++?
<seb128> lamont: no, is aspell weird error
<seb128> "checking for new_aspell_speller in -laspell... no
<seb128> checking for new_pspell_manager in -lpspell... no
<seb128> configure: error: You must have the aspell or pspell dev libraries to build
<seb128> gtkspell."
<seb128> 
<seb128> but the same package builds fine on debian and on my hoary pbuilder ...
<lamont> seb128: let me kick it once for giggles, and then I'll look at it if it fails again
<seb128> on #9998 you wrote "aspell-bin is not in the build-dep list.", but I don't think it's needed, my pbuilder builds the package fine without it
<seb128> k, thanks
<seb128> and same gnome-spell if you can kick this one too
<stockhol1> does anyone know the nicks of the people working on debian-edu, so i can /notify myself when they come online?
<stockhol1> bah
<stockhol1> does anyone know the nicks of the people working on edubuntu, so i can /notify myself when they come online?
<Mithrandir> stockhol1: you might want to look at the list of participants on the edubuntu spec.
<Kamion> (http://udu.wiki.ubuntu.com/Edubuntu)
<Kamion> I don't know if either Jeff Elkner or Colin Applegate IRC, though.
<Kamion> I think Matt was largely there as facilitator/liaison, but I could be wrong
<stockhol1> i mailed the people in question allready about cooperation and got mails in reply, but now it has been a long time (6 days) without answers 
<stockhol1> so i was trying to escalate to irc.
<Kamion> for several of those days those people would have been busy at the conference, then on plane flights, then jetlagged
<stockhol1> yes.
<Kamion> if they're anything like me they're still catching up
<stockhol1> lol
<stockhol1> mjg59 is half dead, still. 
<stockhol1> right.
<Lathiat> poor matthew
* lamont makes another pass through the office-crap migration process
<stockhol1> mako went to bed with wisky.
<stockhol1> so it must be bad
<stockhol1> Kamion: what do you think, when will people be half-alive again? (c:
<stockhol1> these are the people on the cc: 
<stockhol1> Cc: Kevin Cole <kjcole@gri.gallaudet.edu>, Eric Howard <ehoward@fissg.com>,
<stockhol1>         Paul Flint <flint@flint.com>, Colin Applegate <colin.a@gmail.com>,
<Kamion> stockhol1: I don't know their schedules - was just keeping you informed in case you didn't know they had been travelling
<stockhol1>         Colin McDermott <colmcd@optusnet.com.au>,
<stockhol1>         Colin Charles <byte@aeon.com.my>
<stockhol1> anone of these online?
<Kamion> stockhol1: Colin Charles was very likely just editing that specification
<Kamion> since he was one of the people editing *all* the specifications
<Kamion> I have no idea about the others
<stockhol1> ok
<stockhol1> thanks
<Kamion> I only met two of those people knowingly, and one of those only in passing
<Kamion> (the ones other than cc, that is)
<Mithrandir> stockhol1: just wait a few days and see if they answer your mails; they are, as Kamion says, most likely jetlagged and overworked ATM.  Connectivity wasn't too good at the conf.
<stockhol1> sure.
* Kamion glares at kickseed
<seb128> lamont: gtkspell builds fine now, can you kick gnome-spell too ?
<stockhol1> a general question regarding the config file handling of preconfigured systems (like edubuntu most likely will be): are you guys working on integrating better local configuration management like multilevel configuration or configfile rewriting/parsing for some key applications?
<Kamion> stockhol1: I'm not aware of any work on that in Ubuntu in general; dunno about Edubuntu
<lamont> seb128: done.
<lamont> firecall
<fabbione> there...
<fabbione> lamont: later...
<Nafallo> pitti: postgresql updated fine, but I was waiting for a the "Starting PostgreSQL" line :-)
<Nafallo> s/the//
<pitti> Nafallo: right, I recently got a Debian bug about that
<pitti> Nafallo: however, it should have started up fine, did it?
<fabbione> Kamion, pitti: ppc question:
<Nafallo> pitti: it did. I supplied status to the init-script to be sure :-).
<fabbione> *** Warning: "isa_memcpy_fromio" [drivers/net/hp100.ko]  undefined!
<fabbione> this is building ppc kernels....
* pitti newer saw that
<fabbione> now.. does ppc have anything related to isa?
<Kamion> no
<pitti> not my iBook at least
<fabbione> ook... another question:
<Kamion> not 100% sure about some of the IBM kit, but I doubt it
<Mithrandir> Kamion: the IBM PPCs I've seen at least have all been PCI-only.
<Kamion> that or MCA
<Kamion> (for the older ones)
<fabbione> hp100, com90xx and arc-rimi are somekind of net card available on any ppc?
<Mithrandir> well, yeah.
<Kamion> fabbione: I wouldn't be prepared to venture an opinion on any of those
<Kamion> hp100 is a PCI card, so you could fit it to a powerpc system
<fabbione> Kamion: we actually build them.. but they can't load.. i am trying to figure out if they are broken or we can safely remove them :)
<fabbione> but i don't believe they are the only drivers that use those functions...
<fabbione> it's probably easier to find the missing include
<Kamion> isa_memcpy_fromio and friends are not defined in asm-ppc
<Kamion> they are available in asm-{alpha,arm,i386,mips,parisc,sh,x86_64} here
<fabbione> that's what i am checking....
<fabbione> Kamion: the drivers are broken.. very easy fix anyway
<fabbione> they just renamed the function...
<fabbione> i can either add the define or fix the driver (better)
<Kamion> elmo: is ports.ubuntu.com deliberately missing the source? it would make germinate's life easier if the source were accessible in the usual place there, if possible ...
<fabbione> there... fixed...
<Kamion> fabbione: I think fixing the driver is definitely better, yeah
<fabbione> Kamion: i am not 100% sure...
<fabbione> there is a specific reason why that stuff is defined the way it is
<Kamion> isa_* doesn't make sense on all architectures
<fabbione> but ppc has all the bits required to create the definitions
<fabbione> except that it's missing them
<fabbione> Kamion: i fully agree...
<fabbione> check for ex asm-i386/io.h
<fabbione> #define __ISA_IO_base ((char __iomem *)(PAGE_OFFSET))
<fabbione> bofh __iomem and PAGE_OFFSET exists on ppc
<fabbione> and as a consequence you can see that the following isa_ definitions are extremely simple..
<fabbione> probably the name space is wrong....
<fabbione> in both cases, nobody has been complaining about these missing drivers.....
<fabbione> this kernel is going to rock hard...
<fabbione> modulo OOPS
<fabbione> and crashes
<fabbione> :P
<Nafallo> hehe
<GheRivero> res
<Kamion> "rocking, except when it sucks"
<Nafallo> don't forget wlan drivers that can't do managed stuff ;-)
<fabbione> Nafallo: if you are talking about hostap is already in
<fabbione> atm there are only 2 OOPS'es we are aware of...
<fabbione> nothing too fancy
<Nafallo> fabbione: rt2500 experimental seems to lack the code for managed mode.
<fabbione> Nafallo: well... that's not my problem.. we imported the driver.. upstream will have to take care of the rest
<Nafallo> fabbione: hopefully it will be their in time for release :-)
<Nafallo> fabbione: yea, I know :-). just added a "sucking" reason ;-)
<fabbione> also because all these neat external drivers will land in non-supported-external-modules.deb
<fabbione> so basically.. we will ship them to make users happy
<fabbione> but it will a ENOCARE line :)
<Lathiat> fabbione, all in one deb or separate debs?
<Lathiat> heh
<fabbione> Lathiat: all in one deb
<fabbione> i am not going to create a million debs
<Lathiat> right. :)
<fabbione> otherwise i could split each single module in one deb
<fabbione> and let somebody figure out the dependencies
<fabbione> :)
<Lathiat> heh
<Nafallo> lol
* Lathiat takes his hand down and closes his mouth
* Lathiat grin
<sjmorgan> should i be worried that running "free -m" in a terminal on my machine says it's using 268MB -/+ buffers/cache? (this is without X running)
<fabbione> sjmorgan: no
<fabbione> not at alll
<Lathiat> someone needs to write a memory usage program that takes real usage
<Lathiat> and then divides it by 10
<Kamion> caching is good
<sjmorgan> can you explain why it'd use or at least say it's using so much?
<Lathiat> so peope stop warrying
<Kamion> sjmorgan: there's no point having memory unused. it might as well be used to cache stuff.
<sjmorgan> my friend is running hoary and his says its using 70meg even with gdm running
<clee> so, launchd.
<fabbione> sjmorgan: if that value is higher, it is better
<sjmorgan> he's using hoary
<sjmorgan> why is mine caching so much?
<Kamion> the cached stuff will be thrown out if anything actually needs it
<clee> have you guys looked at it yet?
<Nafallo> sjmorgan: does your friend count cache in?
<sjmorgan> yeah
<Kamion> sjmorgan: because caching is *good*
<sjmorgan> i ran free -m on his machine
<Kamion> it improves performance because you don't have to go to disk
<sjmorgan> i don't understand though, we have the same kernels
<Nafallo> sjmorgan: bad for him then :-)
<Kamion> sjmorgan: depends what the machine's been doing. don't worry about it.
<fabbione> sjmorgan: also the same amount of ram? do you also run exactly the same applications in the same order, loading the same data?
<sjmorgan> ok cool, thanks for clearing it up. i was worried there was a memory leak or something.
<fabbione> sjmorgan: trust us.. if that value is high, it is only good :)
<sjmorgan> fabbione: he has 512, i have a gig
<fabbione> so you can cache more
<fabbione> he can't
<sjmorgan> and they were both booted today and havent been doing anything really
<Kamion> memory leaks would show up in other columns, not buffers/cache
<fabbione> it doesn't matter
<sjmorgan> actually they've probably had exactly the same load
<fabbione> even running cron.daily in background would change that value
<fabbione> sjmorgan: not after a cron.daily
<sjmorgan> i thought maybe the leak might be in the kernel or something
<Kamion> this is a FAQ
<Kamion> http://info-x.co.uk/docview.asp?id=117
* fabbione goes and washes dishes while davis flies over a brand new patch
<Kamion> (just the first hit for "buffers/cache linux", there are probably better explanations)
<sjmorgan> cool thanks
<Kamion> http://alphalinux.org/archives/axp-list/February2000/0307.shtml <- short-'n'-sweet explanation
<Nafallo> hmm, now when we're talking about cache... can we please have an easy way for setting up the READAHEAD variabel in /usr/sbin/laptop-mode? :-)
<elmo> Kamion: meh, I guess.  i was trying to avoid the duplicate 20Gb
<Kamion> elmo: oh, it's a different box?
* Nafallo guess the answer will include 'patch' and 'willing to take' :-)
<stockhol1> is there a breezy release goal overview, btw?
<elmo> Kamion: yes, at the moment, and even if it wasn't, it's implemented super-naievely (i.e. --include/--exclude rsync), so the two trees wouldn't automatically share source
<elmo> so I'd have to dsync after each pulse or something
<elmo> hmm, and I never did get dsync working with post-bo g++
<Nafallo> well, I have to switch nic in my server/router/firewall/everything. brb (hopefully).
<fabbione> Kamion: but do you need all the orig.tar.gz or just the Source.gz files?
<fabbione> i don't really see why we need all the sources on ports...
<`anthony> So I've bitten the bullet and switched the laptop to Ubuntu. Do you guys want bug reports for stuff that's not working (that was working in Fedora) ?
<ogra> `anthony, nah, these are likely user errors ;)
<elmo> `anthony: sure
<ogra> `anthony, so you use gnome now ?
<`anthony> ogra: so exactly how does user error make /sys/devices/system/cpu/cpu0/cpufreq/ not be there?
<`anthony> ogra: Only until kubuntu-desktop finishes downloading.
<mjg59> `anthony: Is it a Pentium 4?
<`anthony> mjg59: P4M
<ogra> `anthony, you know i'm kidding :)
<mjg59> `anthony: Are you really sure it's a P4M, not a desktop P4?
<`anthony> Yep
<mjg59> Ok. Try doing sudo modprobe speedstep-centrino and see what output you get.
<`anthony> model name      : Mobile Intel(R) Pentium(R) 4     CPU 3.06GHz
<`anthony> no such device
<`anthony> it's a different beast to the pentium-M
<mjg59> Yes, but P4Ms use speedstep-centrino anyway (IIRC)
<mjg59> What output does dmesg have?
<`anthony> CPU: Intel Mobile Intel(R) Pentium(R) 4     CPU 3.06GHz stepping 09
<mjg59> `anthony: When you load speedstep-centrino?
<`anthony> nada
<`anthony> FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.10-5-386/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device -- is what the shell sez.
<mjg59> Ok. Sounds oddly like your processor doesn't have frequency scaling, which is odd
<mjg59> Fedora was probably using p4-clockmod
<`anthony> It definitely does - worked on Fedora. It's kinda necessary, because at full power this CPU drains the battery in about 1h15m ;)
<mjg59> Are you sure it wasn't using p4-clockmod on Fedora?
<`anthony> dunno. is that a kernel module, or a patch?
<jbailey> infinity: There?
<jbailey> doko: ping?
<mjg59> It's a kernel module
<mjg59> It allows throttling, but doesn't alter the core voltage
<mjg59> It's not enabled by default because it has really poor performance characteristics on a lot of hardware
<Kamion> fabbione: just the Sources I guess
<`anthony> mjg59: Well, the module's definitely there.
<`anthony> (I've still got the FC install sitting on disk)
<Kamion> stockhol1: we've got a load of stuff written down, but we haven't had the kickoff meeting to decide exactly what's going to end up as goals yet; that's early next week
<mjg59> `anthony: Ok. My suspicion is that Fedora was using p4-clockmod and (for some reason) your chip doesn't do proper frequency scaling
<mjg59> What make of laptop is this?
<`anthony> Dell Inspiron 5150
<mjg59> Weird
<mjg59> If it supports frequency scaling, speedstep-centrino should load
<`anthony> submitted hardware db as e9247dd452b15d6d04aab7366aa5fc80
<Kamion> 18:09 < joeyh> actually, the syslinux is experimental will probably change all this for x86
<Kamion> 18:10 < joeyh> it has a widget toolkit, so we can present a menu of 2.4, 2.6, with buttons for rescue mode, expert mode
<Kamion> 18:10 < joeyh> check boxes for framebuffer disable, etc
<Kamion> 18:10  * joeyh is quite looking forward to it
<Kamion> ooh
<Kamion> mdz: who needs gfxboot, eh?
<`anthony> mjg59: Well, I'm happy to help make it work. 
<doko> jbailey: pong
<fabbione> hey jbailey 
<stockhol1> Kamion: ok, thx
<stockhol1> jbailey: you live!
<fabbione> jbailey: confirmed that devicemap changes did unbreak also lvm :)
<Mithrandir>  Kamion shiny!
<Nafallo> damn I love hoary :-)
<Nafallo> best server I've even had :-)
<Nafallo> hi again btw
<hunger> fabbione: Any news on the udev issue yet?
<hunger> fabbione: I attached straces, env and commandline info from my system to the bugreport this morning.
<fabbione> hunger: i am not handling that bug.
<hunger> fabbione: I couldn't make sense of it... but I am sure you got someone better at udev then me;-)
<fabbione> and i didn't check the status
<fabbione> hunger: the person to ask is probably pitti
<hunger> fabbione: You made the mistake of replying to me yesterday;-)
<pitti> hunger: whassup?
<hunger> pitti: fabbione said I should bug you about that udev bug;-)
<pitti> hunger: udev works fine for me
<fabbione> pitti: in breezy?
<pitti> hunger: your USB devices don't work in breezy?
<hunger> pitti: Nope.
<pitti> hunger: yeah, tha's a hotplug bug
<hunger> pitti: They did work in hoary.
<pitti> hunger: right, that's why it is a stable release :-)
<pitti> hunger: hotplug is broken for me too
<fabbione> ah
<pitti> hunger: we'll sort that out in the next time
<fabbione> hunger: what was the bugnumber?
<fabbione> pitti: we might want to reassing it, if you know what the problem is
<hunger> pitti: Yes I know. But I got bored on hoary:-)
<pitti> fabbione: hotplug does not load sg or sd_mod
<pitti> fabbione: but I didn't yet figure out why
<fabbione> pitti: ah ok
<pitti> fabbione: I did not debug this, just noticed that my device worked as soon as I typed modprobe sd_mod
<fabbione> pitti: ok...
<fabbione> i think i did the hotplug merge...
<fabbione> i really can't remember...
<pitti> fabbione: hehe, you broke it :-)
<hunger> pitti: I added lots of strace info to bug#9913
<pitti> fabbione: no worries, let the Breezy users suffer for a while :-)
<hunger> pitti: I should have thought of sd_mod myself:-(
<fabbione> pitti: i want to have a working userland before uploading a new kernel
<fabbione> i actually did the merge....
<fabbione> well i guess i will have to debug it on monday
<jon1012> hello :)
<fabbione> pitti: if you get a flash and want to fix it.. go ahead :)
<jon1012> a developer interested in doing an ubuntu package for my app, appliworks ?
<jon1012> (http://appliworks.jondesign.net)
<pitti> fabbione: sure, but first I want to get rid of my vuln backlog
<fabbione> pitti: is there anything for me in the queue?
<pitti> fabbione: yeah, we have some pending issues
<pitti> fabbione: the real unfortunate thing is that Linus doesn't use BK any more
<jon1012> (I can't do one since I don't use ubuntu... I'm a member of the foresight team)
<pitti> fabbione: i. e. there are no fancy patch URLs any more
<fabbione> pitti: yeah
<pitti> fabbione: basically we need to port the patches from 2.6.11.{7,8}
<fabbione> amen
<pitti> fabbione: I will collect some more data and bug you about this friday
<fabbione> pitti: i won't be around before monday, but send me the mails anyway
<fabbione> pitti: afaik some stuff in .7 and .8 did change quite a lot of things
<fabbione> doko: did you also include the security fix in OOO 1.3 upload?
<fabbione> doko: or did you just upload it?
<jon1012> nobody interested in making ubuntu package for Appliworks ? :(
<fabbione> jon1012: this isn't the right forum to ask
<fabbione> you might want to see in #ubuntu-moty
<fabbione> meh
<fabbione> you might want to see in #ubuntu-motu
<jon1012> fabbione: oh sorry
<jon1012> what is #ubuntu-motu ?
<fabbione> jon1012: Master of the Universe
<jon1012> lool I see ;)
<fabbione> basically all the developers that take care of universe
<Nafallo> jon1012: masters of the universe; the developers that handle the big unsupported archive.
<mdke> jon1012, its a development channel for people making Ubuntu packages in the universe archive
<hunger> Does anybody have some docu on the lsb init-script functions? when to use which log_*, etc.?
<mdke> jon1012, not to mention battling against the evil skeletor
<jon1012> ok thanks :)
<jon1012> mdke: loool
<mdke> skeletor is no laughing matter
<mdke> he will have you
<jon1012> what is he ?
<hunger> jon1012: skeletor is the minion in the master of the universe comics/toys.
<mdke> http://www.he-man.org/cartoon/cmotu/index.shtml
<jon1012> ok lol :)
<jon1012> thx ;)
<jon1012> loool
<jon1012> hehe we should need a channel like this in foresight
<mdz> Kamion: will syslinux be able to display localized text as well?
<doko> fabbione: yes, daddy, the security fix is included as well ;-)
<mdz> Kamion: reiser4progs has an air of sabdfl about it
<Kamion> mdz: syslinux> no idea
<fabbione> doko: ok dude...
<fabbione> hey mdz
<Kamion> mdz: sabdfl has distinctly failed to make it appear in the kernel
<fabbione> Kamion: and please do not remind him.
<fabbione> reiserfs4 is crack
<Kamion> I have no intention of doing so; it's sick evil badness
<fabbione> exactly
<fabbione> later
* fabbione -> hospital
<Nafallo> fabbione: see you later :-)
<mako> stockhol1: hey there. i managed to drag myself awake (at 2PM!)
<stockhol1> mako: uff.
<dilinger> mako: if the sun's still up, it counts as getting up early in my book.
<tseng|work> dilinger++
<Mithrandir> dilinger: so UDU was middle of the night for you?
<dilinger> Mithrandir: yep.  which worked out suprisingly well, since i tend to gravitate towards waking up between 2 and 6 pm EST
<ogra> heh
<mvo> mdz: is there a cvs/svn repository for apt-listchanges? 
<ogra> tseng|work, do we have a ubuntized dbus-sharp source pkg anywhere ?
<tseng|work> dbus-sharp is part of dbus
<tseng|work> but, since mono was in universe..
<ogra> hmm...yeah, i c
<tseng|work> we have a dbus-sharp source package that only installs the binding
<tseng|work> it will be merged during breezy
<ogra> ah, fine...
<tseng|work> i need to talk to seb128 about libgda sometime
<tseng|work> and go one pushing the bindings in
<mdz> mvo: I have a local cvs, yes
<mdz> mvo: I would like to have it imported into baz
<mvo> mdz: that would be nice
<mdz> Kamion: can you add a README to debootstrap about the template stuff?  I had no idea
<Kamion> mdz: ok, will do
<mdz> jbailey: what's your timeline for EarlyUserspace?
<mdz> jbailey: it's a dependency of ThinClientIntegration
<jbailey> mdz: klibc and udev uploads by the end of the week, kernel packaging changes to let us use it by mid to end of next week (since it may require coordinating with Debian maintainers to get it right)
<jbailey> Upload of the mkinitramfs that I have now in that same timeframe.
<jbailey> hotplug-ng in the week after, I'm guessing - have to talk to md to find out if he's packaging it for Debian already, I want to make sure that we can sync it.
<mdz> jbailey: why, is Debian planning to transition to initramfs at the same time?
<dilinger> sarge is frozen, why not? :)
<jbailey> mdz: Fabio told me that he'd prefer our make-kpkg not diverge from Debian.
<jbailey> It's mostly a matter of making sure that kernel-img.conf can be told to call something other than mkinitrd to build the initrd.
<jbailey> So it makes sense to have the hooks be something that Debian is willing to sync.
<mdz> have you, er, talked with the debian release team about this? :-P
<jbailey> No =)  But since they're frozen it shouldn't be that big of a deal.   But that's why it's a week and a half out. =)
<Kamion> the release team officially doesn't care about etch yet
<Kamion> and it already looks like d-i will be moving to initramfs
<Kamion> it's probably more relevant whether Manoj likes it :)
<mdz> my reading of the release status update did not imply that it was no longer important to be able to (manually) propagate individual packages from sid->sarge if found to be necessary
<mdz> we should probably have this discussion over on #d-d?
<mdz> or #d-r
<Kamion> it may be useful, but since t-p-u is now operational it is no longer a big deal to restrict use of unstable
<Kamion> with the exception of libraries
<mdz> so you're saying that I can upload apt 0.6.x to sid now? ;-)
<Kamion> apt is a library ...
<mdz> details
<jbailey> mdz: This change should be safe even in that respect: I'm proposing add an option to kernel-img.conf.  If it's unset, it would still default to mkinitrd.
<Kamion> as the announcement said, we're still asking people to use common sense to avoid making life difficult for others; I suppose kernel-package could affect new kernel builds
<Kamion> anyhow, as you say, slightly more on-topic: the upshot is that lots of scary d-i hacking is happening in unstable, so we'll get to see that pretty much straight away
<wasabi> http://www.eweek.com/article2/0,1759,1791653,00.asp
<mcquaid> hello all
<mcquaid> i want to try making some deb packages for ubuntu
<GheRivero> res
<mcquaid> i'm just going over the debian maintainers guide and it talks about starting from the source
<mcquaid> i'm wondering can one grab debian's src debs and start from there to save some time?
<crimsun> sure
<mcquaid> i guess i would grab testing?
<crimsun> probably better to choose sid
<mcquaid> i thought sid at first, but someone menitoned to use testing as sid is still a moving target and some depends might have changed since ubuntus snap shot
<mcquaid> but ok ill try sid
<mcquaid> is there a good guide on this if one is starting with deb src packages?
<crimsun> the new maintainer's guide, the debian developer's manual, the policy documentation, cdbs documentation
<Kamion> if there's a Debian source package it will be (semi-)automatically synced/merged into Ubuntu and built
<Kamion> if you're tweaking or just curious, install the devscripts and fakeroot packages and use debuild
<mcquaid> i was going to start with the actual source but the first thing i was going to try is actually a python program and there isn't a make file to edit 
<mcquaid> so i got kinda lost from there ;)
<trulux> anyone going to attend to LSM?
<ogra> mcquaid, just grab the sourcepackage of a existing python package and inspect ;)
<dholbach> hey
<JaneW> night all
<ogra> night JaneW 
<dholbach> good night janew
<JaneW> *wave*
<mcquaid> anyway to search debians ftp?
<Kamion> mcquaid: I guess packages.debian.org is what you mean
<uniq> mcquaid: like a package search? 
<mcquaid> yes
<uniq> as kamion said.. packages.debian.org
<mcquaid> hmm, i'm going through the packages but can't find it, i know i have it in deb sid
<mcquaid> it's a front end to visualboyadvance called gnomeboyadvance
<Kamion> well, there's definitely no package called 'gnomeboyadvance' in Debian
<mcquaid> eh? i know i have it in sid, don't want to reboot to find it 
<ogra> probably from apt-get.org
<Kamion> nor anything matching 'boyadvance' in the distribution apart from visualboyadvance and a kdevelop frontend for it
<mcquaid> no i checked apt-get.org
<Kamion> mcquaid: mount your sid partition and chroot to it
<mcquaid> i have it mounted already, but how will that help me determine where i got it
<ogra> http://developer.berlios.de/project/showfiles.php?group_id=1650&release_id=3263
<ogra> mcquaid, ^^
<mcquaid> yes thats its home page
<mcquaid> but i recall getting it through apt
<ogra> nope, the download page for the deb
<Kamion> mcquaid: try 'apt-cache policy gnomeboyadvance', then
<mcquaid> brb
<tseng|work> http://tseng.ath.cx/photos/index.php?galerie=udu
<dholbach> pictures!!!
<tseng|work> yes.
<ogra> whee
<ogra> tseng, btw, i have a working mono environment here now (played a bit today) but dh_netdeps and dh_makenetlibs seem to be missing in the package source...
<tseng|work> those are in cli-common
<ogra> ahhh....
<dholbach> are there any plans when the next TB meeting will be?
<tseng|work> which should be installable now also
<ogra> silly me... i thought in mono-utils
<tseng|work> it used to be there
<ogra> ah, ok
<tseng|work> now that is just upstream stuff
<tseng|work> see dh_net* is used for pnet also
<tseng|work> not just mono
<ogra> ah
<mcquaid> ok i'm a stoner, i must have installed it manually
<mcquaid> ill pick something else to learn making packages
<mcquaid> btw, i notice that if i right click on a menu item there is no longer a properties option, i have to add it to the panel to get properties
<mcquaid> is that a gnome 2.10 thing or did ubuntu simply the gnome menu?
<mcquaid> i assume it's a 2.10 thing but just curious
<tseng|work> 2.8 iirc
<mcquaid> in 2.8 i do have properties when i r click
<mcquaid> just not in 2.10
<tseng|work> ok, 2.10
<mcquaid> ok just curious
<Sharpyy> hello
<Sharpyy> does someone know a free alternative to SourceForge Enterprise ?
<dholbach> tseng|work: nice pictures :-)
<Nafallo> the namecards should be larger though :-)
<luis_> Sharpyy: gforge
<luis_> hrm, does anyone know why (w/ breezy) compiles would not be picking up my system libc symbols?
<Sharpyy> luis_: thanks
<ogra> tseng|work, you really got atalent for catching unintentional funny faces ;)
<tseng|work> ogra yep
<ogra> heh
<ogra> hehe, luis_ in other spheres http://tseng.ath.cx/photos/index.php?galerie=udu&snimek=54
<luis_> man
<luis_> classic
<tseng|work> luis_++
<tseng|work> thats my favorite pic
<tseng|work> time to go home
<luis_> heh
<fabbione> bah
<ogra> ??
<fabbione> 7 hours to get 2 X-rays 
<ogra> bah
<dholbach> oh?
<Riddell> A
<dholbach> hey Riddell 
<ogra> fabbione, but at least your amd64 kernel from today works really fine .... (testing the k8) thumbs up so far
<fabbione> ogra: rocking
<ogra> yeah
<fabbione> i think monday i will be able to upload
<fabbione> i have a few things left on the todo list
<ogra> i can finally see my pcmcia devices 
* dholbach is still upgrading
<fabbione> given that hotplug gets fixed first
<Nafallo> is there a http://www.ubuntulinux.org/wiki/ConferenceGalleries for udu?
<ogra> not yet i fear
* mvo goes to bed now
<luis_> ogra: http://phy.duke.edu/~icon/misc/serialluis.jpg <- friend did that from that pic
<ogra> hehe
<tseng> back
<ogra> luis_, and thats how they look like if they come out again after 5 years ;) http://tseng.ath.cx/photos/index.php?galerie=udu&snimek=31
<tseng> hah
<tseng> yes i definately have some winners
#ubuntu-devel 2005-05-13
<ogra> heh
* lamont goes to take his wife out for her birthday
<ogra> lamont, have fun
<tseng> cya lamont.
<tseng> i going to break the buildd's while youre away
<dholbach> brb
<mdz> fabbione: what is wrong with hotplug?
<ogra> dholbach, badger badger badger badger badger badger badger !
<dholbach> re
<dholbach> YES! :-)
<Nafallo> lol
<ogra> *g*
<dholbach> now a breezy pbuilder and i can upload some fixes soon
<dholbach> CONGRATULATIONS, tseng!
<tseng> yay
<ogra> hooray !
<ogra> !
<ogra> !!
<mdz> mako: awake?
<tseng> mdz: my pictures are up if you missed them
<tseng> tseng.ath.cx/photos
<toresbe> hmm
<mdz> tseng: I see it now, thanks
<tseng> rock on.
<toresbe> is there any safeguard against replacing the GDM sccreen with a keygrabber
<tseng> toresbe: erm, users cant normally overwrite gdm for starters
<tseng> if they can, you have bigger problems
<toresbe> nono
<tseng> than protecting against a keygrabber
<toresbe> logging on as a normal user in perhaps safemode then presenting a fake GDM screen
<tseng> uh
<tseng> safemode?
<toresbe> xterm failsafe or whatever it's called
<toresbe> perkele, cyberix :P
<cyberix> :-)
<tseng> if you walked away from your pc, and someone else was on your account, they could theoretically make a mockup of gdm to steal your password
<Nafallo> toresbe: you're still screwed if they get as far as to place it on the system IMO.
<mdz> toresbe: the best defense is probably the fact that when the "real" gdm starts up, there is a noticeable video mode switch :-)
<toresbe> mdz: can be faked
<tseng> they bypassed a good bit of commonsense to get there
<toresbe> nono
<toresbe> Authenticated User B wants A's sudo rights
<mdz> toresbe: you misunderstand
<mdz> toresbe: fake gdm steals the password, then it needs to hand off to the "real" gdm
<toresbe> B logs on and makes a program that looks like GDM.
<toresbe> mdz: not really
<mdz> after an incorrect password, real gdm just prompts again, while with the fake gdm there would be an unexpected mode change
<tseng> if you are doing trusted things on system 1 with untrusted user B with local access
<tseng> you are unwise.
<toresbe> the program remaps backspace to something else and maps ctrl-alt-(x) to a quick XRandR call to switch the resolution
<toresbe> the program runs an su user -c gnome-session or whatever.
<cyberix> An university is a good example environment.
<tseng> why would you trust a university pc to begin with
<mdz> toresbe: a trojan which doesn't cover its tracks by allowing the user to log in the second time is easily discovered
<tseng> you dont, for exactly this reason
<toresbe> mdz: what do you mean?
<toresbe> tseng: Windows has ctrl-alt-del
<tseng> toresbe: because you only enter one password into windows during a normal session..
<mdz> and the X server has control+alt+backspace
<toresbe> mdz: that can be unmapped
<mdz> but like any SAK-ish solution, it only works if every user uses it
<mdz> toresbe: not by an unprivileged user
<tseng> there are just alot of problems with your use case
<toresbe> mdz: sure 
<mdz> toresbe: try it
<toresbe> mdz: I've done it
<zul> tseng: your photos need descriptions 
<tseng> zul: leave comments
<mdz> toresbe: show me
<tseng> for luis.. BUH.
<toresbe> mdz: paying the ticket? :P
<toresbe> mdz: ISTR it anyway
<toresbe> mdz: Right now I've got no ctrl-alt-f* 
<toresbe> and I don't wanna kill me X
<mdz> toresbe: that is not the same thing
<cyberix> Windows has a screen where you can't login before you press ctrl + alt + delete. But this is not irght because the user should understand she must secure the machine even, if the login mode is already open.
<mdz> you don't need to; just show me the command sequence you use to disable it
<zul> tseng: good pictures though
<dholbach> zul: especially all the plugs ;-)
<zul> yeah
<cyberix> Anyway ctrl + alt + backspace takes more time than the Windows thingie. So normal users will be likely to not do so.
<zul> dholbach: you plug fetish
<dholbach> zul: ME? i didnt take those pictures! :-)
<zul> hehe
<cyberix> I'd like to see a Windows user who presses ctrl + alt + delete before logging in, even when the computer is showing the login(g) mode while he sits by it.
<cyberix> How can we do better.
<cyberix> Atleast we can teach the user that he isn't doing it because he can't type in his login and password before pressing such combination.
<cyberix> Maybe letting him type in his login and password, but showing a big red sign and not letting him in, if he didn't press the securing combination.C
<darwinist> UbUnTu rocks
<HrdwrBoB> indeed
<ydelaware> ubuntu rock
<ydelaware> is that a new kind of music?
<mdke> candy
<clee> so, is upgrading from warty to breezy supposed to work?
<mdke> *grins*
<infinity> clee : You mean right now, or by the time we release?
<mdke> give it a try!
<Nafallo> clee: that would be a question for #ubuntu, but no. you should upgrade to hoary first.
<clee> Nafallo: fair enough
<dholbach> good night everyone
<Nafallo> dholbach: nightie :-)
<ogra> night dholbach 
<clee> so, then, a more devel-related topic. anybody here looked at launchd?
<dholbach> bye ogra, Nafallo 
<ogra> night all
<Nafallo> ogra: nightie. see you tomorrow :-).
<Nafallo> ogra: ehm, later today :-P.
<mdke> nite
<ajmitch_> hi
* dilinger waves
<infinity> Hey Andy.
<AndyFitz> g'day infinity
<AndyFitz> how goes being back home ?
<infinity> Sick. :/
<infinity> Not sure if it was the long week in Sydney, or coming home to a drier climate, or just bad luck.
<AndyFitz> bugger mate.   you shouldnt have spent those late nights in kings cross
<mako> mdz: yeah yeah, i'm around
<AndyFitz> evening mako
<mdz> mako: was wondering if you'd thought about when to hold the next CC meeting
<clee> heya, mako 
<mako> mdz: do you ahve one planned for next tuesday?
<mako> mdz: i'd like to get back on a every-other week schedule not conflicting with the TB
<mako> if either of us is willing to do two weeks in a row, we can do that
<mdz> mako: according to the old alternating schedule, TB would have been this week, and CC next
<mako> mdz: you ok waiting two weeks or holding one sooner?
<mako> i'd love to take next tuesday
<mdz> mako: that's fine with me
<mako> rad
<mdke> you have a loooot of member candidates to get through ;)
<Nafallo> hehe, 21 :-)
<mdke> the member candidate criteria needs to be spelled out a little...
<dilinger> mako: what'cha up to?
<mako> dilinger: not too much
<mako> dilinger: i talked to greg.. he said to plan something for sunday. but i would like to hang out before
<mako> Clint: with you too
<Clint> not tonight
<dilinger> mako: well, i'm heading up north for the weekend to pick stuff up..
<mako> dilinger: ah, ok
<mako> Clint: that's fine
<jba> hey guys
<jba> don't know how to say this, so gonna come straight out with it. Appologies in advance if it upsets anyone
<jba> I'm looking at coming into the job market in sept/oct this year, and wanted to know what the odds of working for canonical would belike
<jba> and who to speak to about it
<jba> cool, tseng got me on the right track. thanks guys
<tseng> anyone here with an amd64 and breezy?
<jdub>   tomboy: Depends: libgnome-cil (>= 1.0) but it is not going to be installed
<jdub> tseng: hrm ;)
<tseng> jdub: libgnomedb rebuild
<jba> hey jdub, congrats on wedding
<tseng> jdub: i mailed seb to pretty please do it tommorow
<jba> am a bit dissapointed I didn't get to meet you at udu, but my timing seemed a little off
<jdub> thanks jba
<jdub> tseng: ahr
<tseng> jba: i met him, you didnt miss much
<tseng> :P
<jdub> ha ha
<jba> tseng, hehe
<jba> actually so far the only oss hacker I've met in real life that I knew from online world is james henstridge
<jba> and that's cause i went to the wrong BOF
<jba> was still interesting
<jba> maybe it's better that way ?? ;)
<tseng> jdub: so the word is, within the next few months we will have a non-xattr fallback for beagle
<tseng> jdub: so it doesnt smoke crack on nfs and tmpfs
<tseng> jdub: im still not sure what the effect would be if we put beagle in -desktop and it wound up on a livecd
<tseng> jdub: http://lists.debian.org/debian-wnpp/2005/04/msg00550.html btw
<|QuaD-> tseng: i noticed all of mono is in the repos, how come we can't install it yet? whats missing
<tseng> |QuaD-: cant install what?
<tseng> gtk-sharp is broken, libgnomedb needs built with new libgda, then maybe gtk-sharp built again
<tseng> do you have an amd64 by chance?
<|QuaD-> oh
<toresbe> a lot of Ubuntu devs going to debconf?
<|QuaD-> nope, not yet, in june i am building a dual opteron
<tseng> then could you please just be patient and let me sort things out
<|QuaD-> tseng: hahah, yeah, i was just curious :)
* jba thinks of request to ask of tseng, just to tick him off ;)
<jdub> tseng: elite!
<tseng> jdub: BUT WAIT, THERES MORE
<jdub> tseng: i wonder if they're going to use ._blah like apple did for tiger? :)
<tseng> jdub: http://www.go-mono.com/archive/1.1.7/ < beagle x3
<jdub> tseng: september... gar.
<tseng> it doesnt matter, we can track it same as gnome
<jdub> whoa
<tseng> yes?
<jdub> if we get it approved as a feature goal and are allowed to track it
<tseng> my spec was approved
<tseng> which involved moving the whole stack to main
<Lathiat> wow, the new i/o layer sounds sweet
<ajmitch_> lots of new crack in main
<jdub> tseng: but doesn't necessarily cover post-UVF updates
<tseng> when is uvh
<jabra> I am wondering what the differnce for packages build for ubuntu compared to those built for debian
<tseng> august?
<tseng> jabra: the version string?
<jabra> that it?
<tseng> yes
<jdub> http://udu.wiki.ubuntu.com/ReleaseCycle
<jba> tseng, actually using multiverse/mallirat and tring to install gstreamer0.8-lame i had issues with dependencies on libc
<tseng> and we stab people who dont put patches in debian/ and use diff.gz
<jba> synaptic said it deped on a version of libc that wasn't any of repos at all
<tseng> jba: whats that have to do with anything? its assumed you dont have binary compatibility between dists guaranteed
<tseng> or it should be
<tseng> gstreamer-lame would be nice to have in multiverse
<tseng> do we get jail time for that?
<jba> tseng, yeah i assumed that the gstreamer08-lame that was referenced by the haory mp3 howto on the wiki would be installable as the howto said
<jba> but it wasn't
<jba> i'll find the howto
<tseng> I dont much care, its a wiki
<tseng> the interested party (you) is meant to maintain it
<jba> tseng, not bitching, just syaing that there is a little diff
<jba> in response to jabra
<tseng> the question was about packaging, not binary compatibility
<tseng> pulling things built against debian and expecting them to work is silly
<jabra> I am asking in #debian-devel too
<jabra> it is the issue of building one deb 
<tseng> um
<jabra> and I am wondering if I build it for ubuntu if that could be accepted into debian
<jabra> rather than having to make changes
<tseng> youd have to change the changelog
<jabra> and making  a different deb
<jabra> ok
<jabra> other than that?
<tseng> youd have to test building it on both
<tseng> naturally
<Lathiat> hmm, g-v-m has borked, bugger
<jabra> right
<tseng> I do this for f-spot
<Nafallo> tseng: you want me to test more tonight? :-)
<tseng> Nafallo: no nice work
<tseng> thanks alot
<Nafallo> tseng: I will implement a real testing environment after I get some sleep :-).
<tseng> ok rock on
<tseng> *hopefully* the rest will wrap up tommorow
<tseng> ill fix mono now before sleep
<Nafallo> goodnight people :-)
<tseng> bye
<Nafallo> bye
<Lathiat> ooh, tomboy stopped crashing, woo
<tseng> it did.
<Burgundavia> jdub, did you see this? http://steelgryphon.com/blog/?p=46
<tseng> dude he totally stole my boogs
<tseng> or i stole his.
<jdub> Burgundavia: please make sure thom sees it :)
* dilinger looks at openafs and considers patchbombing hartmans and upstream
<Burgundavia> jdub, saw it on planet.moz, I imagine he will see it
<Burgundavia> jdub, thom@ ?
<bluefoxicy> tseng:  got any zar-like utils that are GPL and work on FAT/NTFS/ext23/xfs?
<jdub> thom@ubuntu.com - thanks :)
<tseng> bluefoxicy: i have a pillow like tool, i think im going to sleep on it.
<bluefoxicy> tseng:  need something I can point at a drive that's been mkfs'd and get the files back
<bluefoxicy> dammit.  Everything I'm finding (even the cool shit on the Helix livecd) is closed source
<Lathiat> bluefoxicy: what file system?
<Burgundavia> jdub, done
<bluefoxicy> Lathiat: ?  Target or what does what support?
<Lathiat> reiserfs is good for gettin data back when you do stupid shit like that, i learn that the other day. :)
<bluefoxicy> Lathiat:  I'm just wondering about GPL recovery utils.  Have you tried Helix' windows programs?
<Lathiat> bl	no i mean, what filesytem di dyou screw up
<bluefoxicy> Lathiat:  I dunno, once in a while a customer comes in missing files :D
<Lathiat> if you lose data on reiser, you can run a reiserfsck --rebuild-tree -S and it finds all the files it can and relinks them, but you dont really want to do it on a filesystem you want to keep. :)
<Lathiat> cus it may eat your other data, and probably will. :)
<bluefoxicy> heh
<bluefoxicy> mainly after fat and ntfs
<bluefoxicy> though a wide, wide range is good always.
<Lathiat> i recommend a backup solution. :)
<bluefoxicy> it's too late when people come into a best buy asking for data recovery due to windows eating itself :S
<bluefoxicy> http://z-a-recovery.com/  <-- these fools can do it, and there's another tool that comes on Helix that can do it with FAT/NTFS/EXT2/EXT3/ReiserFS
<Lathiat> woo, avahi is shaping up
<Lathiat> jdub: :)
<jsgotangco> hello
<dilinger> here's some mako poetry
<dilinger> http://www.acm.rpi.edu/~dilinger/sloth/pics/2005_udu/IMG_0266.JPG
<jsgotangco> hehehehe i saw that
<dilinger> (i wouldn't waste your time on the rest of the pics, i suck at taking pictures)
<cc> is there a way to capture the installation? like pass an option so that a Hoary install can be sent to a vnc listner?
<jsgotangco> i like the "we create a synergistic system" piece
<jsgotangco> dude you took pics of your hotel bathroom heh
<jsgotangco> ok got it thanks
<dilinger> i was all giddy
<bob2> haha
<dilinger> it took so long to get access to the damned room.. :P
<jsgotangco> tell me about it i got my room after lunch
<bob2> spiv: those magnets were the best idea, ever
<dilinger> jsgotangco: so did i.  and i got faked out w/ the wrong room/card before lunch..
<spiv> bob2: Thanks :)
<spiv> bob2: I'll try to remember to bring them to the next conf too.
<dilinger> http://www.acm.rpi.edu/~dilinger/sloth/pics/2005_udu/IMG_0318.JPG
<dilinger> that was a good one.  you don't see that in the US
<HrdwrBoB> dilinger: they're all over the place here
<dilinger> if someone tried to do that in the US, people would get up in arms about encouraging drug use or something equally as stupid
<jsgotangco> AndyFitz, hey
<dilinger> http://www.acm.rpi.edu/~dilinger/sloth/pics/2005_udu/IMG_0289.JPG
<dilinger> and that is a great name
<AndyFitz> g;day jsgotangco
<ajmitch_> afternoon andy
<ajmitch_> heh, the pants sign
<AndyFitz> afternoon ajmitch.
<bluefoxicy> So before I sleep, this one's not for the bugzilla right?
<bluefoxicy> After much googling i discover that there are no tools similar to PC Inspector File recovery or Zero Assumption Recovery (wow, descriptive name) that fall under GPL
<mako> dilinger: oh man. i love magnetic poetry
<bluefoxicy> so someone should make one, so I need to find people interested and I need to find docs about FAT, NTFS, and EXT2/3 to start with
<jsgotangco> heh
<jsgotangco> mako, hi
<bluefoxicy> basically my options are find docs and write code myself, aren't they?
<bluefoxicy> 'cause there's no bugzilla for programs that don't exist
<mako> "mission a r y" thing was brillance
<jsgotangco> i guess you can't separate sex with the office then thats why it had that word
<jsgotangco> brb lunch
<jsgotangco> man my opera house pic suck
<mako> jsgotangco: dude, you give me ANY set of magnetic poetry and i guarentee i can make a dirty poem out of it :)
<jsgotangco> haha
<crimsun> I thought that's the whole purpose of alphabet magnets
<AndyFitz> I'm sure the makers are well aware of that
<AndyFitz> hehe where else would the fun be
<tseng> dholbach: !
<dholbach> hey
<tseng> up for testing?
<Burgundavia> If I want to get a font into Ubuntu/Debian, what licence must it be under?
<Lathiat> tseng: im up for testing 
<tseng> Lathiat: do you have an amd64?
<Lathiat> oh, no
<Lathiat> i could boot a qemu runnign x86-64 but
<Lathiat> and i have access to an opteron
<Lathiat> so i could
<Lathiat> testing what?
<tseng> a build
<Lathiat> of?
<tseng> of mono
<dholbach> tseng: did you get a pbuilder set up?
<calc> Burgundavia: email debian-devel or debian-legal to ask wrt debian
<tseng> dholbach: on x86 I do
* calc bbl
<dholbach> tseng: for breezy?
<tseng> yes
<dholbach> hrm
<tseng> i upgraded a hoary one
<Burgundavia> I am about to start talks regarding a new font for inuktitut and I am wondering what the minimum is
<tseng> anyway, im getting tired of testing amd64 stuff right on the buildd
<dholbach> mine tries to set up {gcc,g++,cpp}-4.0 and dies with problems in there
<dholbach> if i get the pbuilder working, i, i'm happy to test-build it here
<tseng> well, there is a bit of logic that sets different confflags for amd
<tseng> it worked before, now it doesnt
<tseng> only difference is a bit of whitespace
<tseng> a tab at the end of a line
<Lathiat> is this in autoconf? whitespace in autoconf fucks everything
<tseng> its make
<Lathiat> ah
<tseng> debian/rules
<tseng> dholbach: basically, get the latest mono source in breezy, remove the whitespace in ifeq statement in rules, and see if it ftbfs still
<dholbach> when i get the pbuilder working, yes
<tseng> ok
<tseng> thanks
<dholbach> tseng: ok... starting all over, trying to set up a hoary one first
<tseng> ok
<tseng> then --override-configs update to breezy
<dholbach> mako: ping
<mako> dholbach: hey dude
<mako> whats up
<dholbach> when is the next CC meeting? :-)
<mako> dholbach: tuesday
<mako> dholbach: not sure of the time
<dholbach> tritium just needs CC approval for MOTUness
* mako nods
<dholbach> and there are a lot of other guys who want to join the member crew :-)
<tritium> thanks for remembering, dholbach :)
<mako> i know
<mako> it's gonna be a long meeting
<mako> mdz and i talked about it today
* dholbach nods
<mako> tuesday is the day
<mako> i'll figure out the time and announce i tomorrow
<dholbach> i can give you the list of guys, i absolutely vouch for... member-wise
<dholbach> (if that helps)
<infinity> dholbach : Ooo, oo, vouch for me!
<tseng> me next, me next
<dholbach> hrm, pbuilder is fine now
<dholbach> but 'debuild -S' keeps hanging at   fakeroot debian/rules clean
* dholbach wonders, what's going wrong
* lamont sleeps
<fabbione> morning
<tseng> hi fabbione.
<dholbach> hey fabbione 
<jsgotangco> hmmm
<Amaranth> d'oh
<Amaranth> breezy gets mono 1.1.6 and 1.1.7 comes out
<tseng> breezy doesnt have anything yet, everyone chill out
<Amaranth> heh
<Amaranth> well, breezy got it from sid
<tseng> uh
<tseng> not at all
<Amaranth> oh, those are still in experimental for debian?
<tseng> some are
<tseng> some are in ~
<dholbach> Amaranth: don't tell the MONO MASTER what he has done ;-)
<tseng> ive decided to start posting status on the blog to avoid repeated questioning
<jsgotangco> hey dholbach
<jsgotangco> hey tseng
<tseng> about "zomg mono is built why isnt app XYZ here yet"
<dholbach> jsgotangco: jerome, how are you?
<tseng> jsgotangco: sup dude?
<Amaranth> tseng: heh, you must get that a lot :)
<tseng> Amaranth: only in 3 or 4 channels
<Amaranth> i'm happy with 1.1.6, i don't plan on using beagle
<Amaranth> btw, thank you
<jsgotangco> dholbach, tseng, I just came from lunch at KFC, its nice to eat junk food after our weeklong stint with real food
<tseng> jsgotangco: hah, yes!
<dholbach> ;-)
<tseng> jsgotangco: ive had burritos 3 days in a row now
<tseng> to make up
<jsgotangco> haha i wont eat salad for a while
<tseng> that green leafy stuff was bogus
<dholbach> :-)
<tseng> i wouldnt go so far as to call it salad
<jsgotangco> i reckon we could have been more productive if we had pizza at least
<tseng> we had pizza at work today, i ate too much
<aj> the salt and pepper calamari at the place next to UDU was yummy
<tseng> hm the cafe on the corner?
<aj> the pub right next door, i think
<tseng> i got a strange burger from there, it was on flat bread
<jsgotangco> i got some good stuff from the cafe at the center of the park
<tseng> hm they were always busy when i went by
* ajmitch_ never went there, sadly
<dholbach> did anyone run into "fakeroot debian/rules clean" hanging (when using debuild), after an upgrade to breezy?
<ajmitch_> nope
* jsgotangco will upgrade to breezy in a few days after finishing kubuntu docs
<crimsun> Kamion: just a heads-up, with debootstrap_0.2.45ubuntu33 (built on Hoary) and pbuilder_0.127 (installed on Hoary), a Breezy pbuilder can't be created yet on amd64
<crimsun> Kamion: it loops trying to configure cpp > cpp-4.0 > gcc > gcc-4.0,cpp-4.0 ; g++ > gcc ...
<Burgundavia> for legal stuff, is mako the best person to ask?
<dholbach> elmo could help you as well
<Burgundavia> ok
<Burgundavia> where does elmo live?
<Burgundavia> he likely to be awake right now?
<dholbach> but there are lots of opinions in here, just go ahead and ask the question :-)
<jba> nemo ?
<Burgundavia> I want to get an inuktitut font into main
<Burgundavia> to be distributed as part of ubuntu
<Burgundavia> as part of the larger project involving translation
<Burgundavia> what are the legal requirements of said font
<Burgundavia> s/legal/licencing
<dholbach> does it have a license?
<dholbach> (distributed with it)
<Burgundavia> negatory
<Burgundavia> currently freely downloadable
<Burgundavia> but unknown on redistribution
<Burgundavia> before I ask, I want to know what I should be asking for
<dholbach> couldn't you propose any of the licenses of other font-packages in main to upstream?
<Burgundavia> sure
<tseng> look at bistream vera maybe
<tseng> http://www.gnome.org/fonts/#Final_Bitstream_Vera_Fonts
<Burgundavia> cool;
<Burgundavia> ok
<Burgundavia> thanks
<tseng> that might not be the most open
<tseng> but its distributed by everyone these days
<Burgundavia> I am looking for minimum level right now
<Burgundavia> as I am expecting the maker (a gov) not to understand our requirement
<Burgundavia> thanks
<dholbac1> GRR, my box just cracked and 'rebooted'
<dholbac1> mvo: good morning
<mvo> hey dholbac1 
<mvo> morning all
<mvirkkil> morning
<Kamion> crimsun: ok, doesn't really surprise me though, breezy only became debootstrappable *at all* a day or two ago
<Kamion> Burgundavia: both the Debian and Ubuntu web sites have pages on their licensing policies
<Burgundavia> Kamion, cheers, thanks
<Kamion> http://www.debian.org/social_contract#guidelines
<Kamion> if you meet that, you'll satisfy Ubuntu requirements too
<Burgundavia> ok
<Burgundavia> by the DFSG, is the gnome font licence for bitstream vera really free?
<mjg59> Yes
<mjg59> There's no DFSG requirement for something to be distributable on its own
<Burgundavia> ah
<Burgundavia> ok
<mjg59> (This was needed to make the Artistic license free)
<Burgundavia> as I reread, I see it now
<jsgotangco> JaneW: hello
<JaneW> hi jsg
<JaneW> (forgive the contraction - you have a long nick)
<jsgotangco> i don't mind
<Mithrandir> JaneW: tabcompletion is nice, though
<jsg> i own jsg as well anyway
<jsg> :)
* JaneW smiles at jsgotangco
<jsg> how have you been
<JaneW> (I like to be contrary)
<JaneW> Mithrandir: I don;t seem to have tab completion (using x-chat)
<JaneW> jsg: well thanks, finally waking up again, I have been in a daze since UDU
<Burgundavia> JaneW, what are you using? xchat as always had so for me
* JaneW tries again ... Mithrandir 
<JaneW> ok, it works when you know how ;)
<jsg> I've just recovered...i don't understand myself I've always been sleeping a lot lately i guess i've been pretty busy
<Burgundavia> indeed
<JaneW> jsg: I cant get enough sleep, and I am having the WEIRDEST dreams
<jsg> hmm
<jsg> Mentos mutants perhaps?
<Simira> hehe
<JaneW> jsg: don;t joke I actaully brought a handful back - for the kids, but they are scaring me ;)
<JaneW> scaring/scarring whatever both work
<jsg> *grin*
<infinity> Oh, no wonder I'm feeling a bit flat/sick this week.
<infinity> Mentos whitdrawal.  It all makes sense.
<infinity> s/whit/with/
<jsg> i feel the same way
<Lathiat> heh
* JaneW tosses one in the general direction of Melborne
<mjg59> Last night I dreamt I was a wireless router
<infinity> I've been incredibly unproductive since getting back... Which just means working twice as long (or twice as smart!) next week.  Oh well.
<mjg59> I feel better this morning
<infinity> JaneW : I'm trying to kick the habit, thanks.  I think it's for the best.  One morning at UDU, I think I had 3 or 4 bowls to myself in the space of 2 BoFs.
<JaneW> infinity: aaarrrgh!
<mdz> mako: I didn't realize ututo-e was based on gentoo
<Amaranth> 3 or 4 bowls of Mentos? Either we're talking about different things or your breath was mighty fresh.
<jsg> i wasn't able to get a decent photo of the opera house
<jsg> we had a crappy tour guide
<JaneW> jsg: it didn't help that the windows were tinted
<mjg59> Amaranth: There were fruit-flavoured ones as well
<JaneW> jsg: we weren't going to get to see it at all - until I begged that they do a detour on the way to the movie...
<infinity> Amaranth : Mentos fruit flavour.
<jsg> if we were two weeks in sydney, we're all doomed with the mentos, redbull and pepsi max
<mjg59> I'm now entirely unused to the idea of having to make my own food
<mjg59> I keep expecting there to be trays of it around the place
<jsg> lol
<Amaranth> red bull is killer
<jsg> Amaranth: yeah, the can had this warning not to take more than 2 cans a day
<Amaranth> it's even worse mixed with beer or liquor
<JaneW> btw cvd arranged that red bull 
<Amaranth> heh, i used to drink a 6-pack a day
<dholbach> aaargh
<jsg> when you pour redbull in a glass it looks so much like beer
<Amaranth> couldn't see straight if drank too fast
<Amaranth> everything started wobbling
<mjg59> It was banned in France
<mjg59> No idea if that's still the case
<dholbach> redbull is evil stuff... jellygums resolved in weird chemicals
* Simira regrets missing UDU
<Simira> JaneW: so, how did you manage to get yourself into this mess?
<dholbach> are there any pictures up yet? i know of galleries of jblack and tseng
<Simira> dholbach: Mithrandir's are up... let's see
<jsg> i haven't checked tseng's gallery yet
<dholbach> where where where? :-)
<Simira> http://www.err.no/pictures/2005-04-30/
<Simira> and http://www.err.no/pictures/2005-05-03/
<jsg> oooo
<mdz> Simira: oh god, what an awful picture of me
* Amaranth looks
<Lathiat> haha
<Simira> mdz: Yes, I made that comment too when I saw it ;p
<Simira> I mean - awful, like in a Ubuntu way.
<jsg> hehee
<mdz> it's like I'm blinking, talking and swallowing all at the same time
<Lathiat> heh crazy photos of daniels as usual
<jsg> pia looks pissed
<Simira> all in all - Ubuntu crowd pics. :p
<dholbach> wow there are pictures of jdub where he looks kind of normal, cool :-)
<Lathiat> i met a few really cool pics
<Lathiat> dh	hahaha yeh
<Simira> huh? Where?
<Lathiat> pics? oh man
<Simira> gotta take them away!
<Lathiat> my brain need to be rpeplaced
<Lathiat> *met a few really cool people
<Simira> Lathiat: yes. You're a community person? What do you do in Ubuntu?
<Treenaks> any people here who know upstream HAL a bit?
<Lathiat> Simira: im not a community person
<Lathiat> i dont really do anythign for ubuntu at the moment
<Lathiat> apart from convince lots of people ot use it. :)
<Lathiat> ive done bits and peices for gome in the past and am working on network service discovery stuff at the moment (mdns-sd/rendezvous)
<Simira> Lathiat: Ok. Gnome/Debian stuff?
<dholbach> Treenaks: pitti and ogra will
<Simira> Lathiat: hangaround, eh? Almost like me ;p
<Lathiat> heh
<Treenaks> dholbach: ok, and I guess they're not up yet :)
<Simira> Lathiat: you're from .au?
<Amaranth> http://www.err.no/pictures/2005-04-30/medium/dsc00770.jpg <--who is that?
<Lathiat> Simira: yep, perth
<Lathiat> Amaranth: anthony towns (aj)
<Treenaks> Amaranth: going by the hackergotchi, I'd say AJ
* Lathiat nods at Treenaks 
* Amaranth giggles
<JaneW> Simira: I don;t know...
<Treenaks> hackergotchis are useful!
<Treenaks> (though I didn't recognise jdub the first time around ;))
* JaneW is still trying to get pictures up... resorting to webshots now
<Lathiat> robert loves hackrgotchi looks very different to hi
<Lathiat> m, at least i think so
<Amaranth> yeah, jdub looks nothing like his hackergotchi
<jsg> its becausehe doesn't have any hair back then
<JaneW> beanbag! :)
<Simira> JaneW: poor you ;) What do you do in the distroteam? Anything fun,or just holding back the guys by their ears?
<jsg> she's the slave driver
<Simira> :D Sounds good
<JaneW> Simira: I like the ears idea...
<chmj> hey, don't give her ideas 
<JaneW> where were the balloons
<jsg> chmj: hehe
<JaneW> chmj: why cos yours are closest?
<Simira> JaneW: I know they might need it sometimes. I was in Matar....
<Simira> JaneW: where are you located? UK?
<chmj> JaneW: yes
<mdz> I've been spoiled by the UDU wiki; I no longer have patience for www.ubuntu.com/wiki
<dholbach> WikiTransition! now! :-)
<Mithrandir> JaneW: the balloons were from LCA.
<Mithrandir> JaneW: we used them to send glasses of wine around.  Mucho fun.
<bob2> and to help colin
<Mithrandir> yeah.  His hair was heavy.
<JaneW> Mithrandir, cool
<Mithrandir> almost as heavy as a wine glass, iirc.
<JaneW> Simira: no, Cape Town, SA
<bob2> haha
<JaneW> can I put a link to those pics on the wiki?
<dholbach> JaneW: which wiki? the canonical internal one?
<JaneW> mdz: I also preferred the UDU wiki 
<JaneW> dholbach: yes, the photos - pretty page
<jsg> *groan*
* dholbach wants to have access as well :-)
* Simira too
* jsg too wants to see pretty pics
<Mithrandir> just put the links to the galleries somewhere on either one of the public ones.
<Simira> #ubuntu-devel is fine with me :)
<bob2> hah
<Simira> talking of wiki... have/can/will you fix the ubuntu.no-wiki for me, Mithrandir?
<Simira> bob2: nice pic of you by Tollef :)
<Mithrandir> Simira: sure; this evening?
<Simira> Mithrandir: mmokey, then
<Simira> oops
* Simira pushed a lot of buttons, and got a lot of emails
<bob2> Simira: hah, it's terrible
<bob2> Simira: make tollef take the "make everyone look ugly" filter off his camera before he goes away next time
<JaneW> hehe
<Mithrandir> bob2: http://err.no/pictures/2005-04-30/slides/dsc00800.html is nice, though
<Mithrandir> bob2: helix liked it too. ;)
<Simira> bob2: I don't think it's his camera... It might have something to do with those people... I don't know for sure
<bob2> Simira: BAH
<Simira> ;p
<jsg> nice shot
<bob2> Mithrandir: you were lucky to take a photo during the five seconds I was smiling all week
<Simira> bob2: I'll take the pictures nect time :)
<bob2> Simira: yay
<mjg59> bob2: I'm almost feeling well again!
<Mithrandir> mjg59: you whipped yourself with a few cat5 cables to get rid of the wireless feeling?
<Simira> Mithrandir!!!
<Simira> Wash your thoughts!
<Mithrandir> Simira: I'm considering getting a digital SLR.
<Mithrandir> Simira: hey, he said he did dream of being a wlan router
<Simira> Mithrandir: yes, and nothing of cable whipping. What do you need an SLR for?
<bob2> mjg59: yay!
<Robot101> mjg59: wahey, to the pub-mobile! :)
<Mithrandir> Simira: well, whipping oneself with cables should rid one of the wireless feeling, at least.
<Mithrandir> Simira: SLR?  Take pictures, of course.
<mjg59> Robot101: Not until you've finished your PROJECT
<Robot101> mjg59: HNNRGGGHHHHH
<mjg59> Haha
<bob2> Simira: it's not about "need", it's about "shiny"
<JaneW> those photos are really good
<Simira> bob2: he's got me
<Robot101> mjg59: I made it almost work yesterday, all I need to do now is add another 8 or 9 syscalls and then write the other half of it, which should be easy
<Simira> JaneW: hey, where are yours?
<Robot101> mjg59: it's tempting to write it in perl, but I think my supervisor would... kill me :D
<mjg59> Robot101: Excellent, you'll be finished by Sunday and we can go to the pub!
<Lathiat> Robot101: what project is this?
<bob2> Simira: exactly
<Simira> Mithrandir: you have a digicam
<Mithrandir> Simira: yes, a compact one.  It sucks in little light and such.
<Robot101> mjg59: oh, no. then I have to write the dissertation, which is what I get the marks for.
<Robot101> mjg59: rowenio suggests I stop coding and just lie in the dissertation
<infinity> Mithrandir : Get a 20D, so I'll have one more person to consider stealing from at the next conference.
<Simira> Mithrandir: that's because you got a lousy cam :p Besides, you wouldn't bring a SLR anywhere, either
<Robot101> Lathiat: filesystem modification monitoring crack - ned.ucam.org/~robot101/proposal.pdf
* infinity looks sadly at his now obsolete 300D.
<Mithrandir> Simira: I would.
<JaneW> Simira: still trying to upload them, but they are awful compared to those... old useless camera, old useless operator
<Simira> JaneW: aww
<Mithrandir> infinity: I'm more of a nikon person.
<Simira> JaneW: I'd need a pic of you. Tollef got Claire(right spelled?) but no Jane.
<JaneW> nod *grin*
<jsg> i only have one group photo the one from jblack
<Simira> Mithrandir: well, if you want that for your birthday, you have to put some more money on my account.
<Mithrandir> Simira: I didn't say I wanted you to buy me one, I said I considered getting one. :)
<Mithrandir> Simira: and besides, if I took pictures of all the gals, I figured you'd be jealous or something. ;)
* Mithrandir hides
<Simira> Mithrandir: bah. You just want to use the money yourself, instead of giving them to me.
<jsg> i haven't seen any pics of adi
<Simira> Mithrandir: you mean I should have a reason to?
<Mithrandir> Simira: nah, just teasing you
<JaneW> jsg: I dodn;t get one either
<JaneW> didn't
<Simira> Mithrandir: shouldn't you work on your assignment now?
<jsg> :(
<Mithrandir> Simira: I should
* Simira considers if she should eat some chocolate
<infinity> Mithrandir : I was more of a Pentax person until I got the 300D.  The value at the time was hard to pass up.
<Treenaks> I'm getting the 350D
<Mithrandir> the 300D is dirt cheap, though
<Treenaks> Mithrandir: because the 350D has succeeded it
<infinity> I got it for 700 USD almost a year and a half ago now.
<infinity> It was a pretty decent value at the time, given the price of everything else.
<Treenaks> also, the 300D is crippled, the 350D isn't (or less)
<Mithrandir> I'm just a bit wary of buying Nikon ATM due to their _silly_ policy wrt documentation of the RAW format.
<infinity> Adobe's been trying to push manufacturers toward an open RAW format, but I dunno how well they're doing with that.
<infinity> I think they're just sick of adding new formats to their RAW plugin every three days.
<Treenaks> infinity: understandable, really
<Mithrandir> there's no reason for it to be proprietary in any way, as long as the manufacturers can extend it in well-defined ways.
<ogra> mornin
<jsg> ogra: mornin' to you1
<dholbach> hey ogra!
<Mithrandir> hi ogra
<lifeless> debian/rules question
<lifeless> I need to add -Wno-pointer-sign to CFLAGS but only for gcc-4.0 builds
<Lathiat> pff, fix your software not to need it. :)
<lifeless> Lathiat: nice. now the real answer please.
<lifeless> Lathiat: I'm not fixing 68K LOC with mixed pointer types tomorrow
<Mithrandir> ifeq $(,$(shell gcc --version | grep 4\\.0))\nCFLAGS += -Wno-pointer-sign\nendif
<Mithrandir> I'd guess.
<lifeless> Mithrandir: thanks!
* lifeless shall see 
<Mithrandir> lifeless: or build-dep on gcc (>= 4.0) and add it unconditionally.
<lifeless> Mithrandir: I'm so not breaking backports.org
<Mithrandir> lifeless: fair enough
<lifeless> ;)
<ogra> badger badger badger badger badger badger badger http://www.grawert.net/udu-gallery/img049.jpeg
<ogra> http://www.grawert.net/udu-gallery/
<jdub> heh
<Lathiat> haha wtf was that
<ogra> the breezy dance....
* ogra wants a new cam ...
<jdub> http://www.grawert.net/udu-gallery/img045.jpeg.html
<Lathiat> i so missed out
<Mithrandir> hm, what's the easiest to get a patch showing all the differences between two branches in baz?
<Mithrandir> hm, baz delta, it seems.
* Lathiat notes that down
<Lathiat> :)
<ogra> sightseeing with tainted windows at night :) http://www.grawert.net/udu-gallery/img046.jpeg
<ogra> s/tainted/tinted
<astharot> ciao
<Mithrandir> ogra: why are your thumbnails so thumby?  (That is, so small?)
<ogra> to small ? 
* ogra blames gthumb
<Lathiat> they see fine sized to me...
<Mithrandir> on the overview page, they are tiny
<Mithrandir> like, 100x80px or so
<Mithrandir> (ok, 120x90 then)
<ogra> heh, yep....
<ogra> think of the poor aussies that want to view them....
<ogra> its bandwidth friendly....
* Mithrandir sighs.
<Mithrandir> I have 50k lines of patches for multiarch stuff
<ogra> uff
<dholbach> after hours of hard work: http://www.grawert.net/udu-gallery/img046.jpeg
<Lathiat> dholbach: more hour sof hard work?
<ogra> dholbach, sightseeing with imagination of the outside due to lack of sight .... ;) 
<dholbach> ogra: yeah... exactly... i just tried hard to remember how it looked in daylight :-)
<ogra> heh
<JaneW> FWIW here are my pics http://community.webshots.com/scripts/editPhotos.fcgi?action=viewall&albumID=338849189
<dholbach> hrm
<dholbach> "You do not appear to be the owner of this album. Make sure you are logged in."
<jsg> yeah
<jsg> brb
<JaneW> erk, but I made it public...
<jdub> Mithrandir: 50k! hfsnw!
<astharot> ciao enrico
<JaneW> http://community.webshots.com/album/338849189afiQFQ?824 <- that should work
<enrico> hi
<dholbach> yeah... better :-)
<jsg> top posting :(
<JaneW> jsg: ?
<JaneW> orga: I love the difference between your before and after conference pictures . you can see how TIRED we all got
<ogra> jsg, whats wrong there.... people are still polite
<ogra> JaneW, yeah :)
<jsg> what's so weird about key signing JaneW :)
<JaneW> jsg: from an outdside perspective it *looks* very weird, of course by next conference/developer sumit or whatevere I am sure I'll be right in there ;)
<jsg> heh
<ogra> JaneW, so we can finally trust you then ? ;)
<JaneW> ogra: yes ;)
<jsg> haha
<jsg> ogra, i meant the top posting thread has gone quite OT but then you're right if people are still polite its not an issue
<ogra> jsg, yeah, i love this community, in other lists i read this would have turned into a flamewar days ago :)
<ogra> the sad thing is that you cant come to a conclusion in such threads....
<seb128> hi carlos 
<carlos> morning
<seb128> tseng: libgnomedb2-4 is built with libgda2-3
<tseng> hm I only see -3
<Lathiat> Does synaptic have the ability to ask it to do a package update from the command line?
<tseng> seb128: yep i dont have libgnomedb2-4 on breezy
<seb128> hum
<seb128> it probably ftbfs 
* seb128 looks on the build logs
<Lathiat> whats fs stand for?
<tseng> fails to build from source.
<thom> fail to build from source
<tseng> thom!
<thom> hola
<jsg> tseng, you got some pics from UDU?
<tseng> jsg: tseng.ath.cx/photos
<jsg> thanks
<JaneW> jsg: are there more, I have seen ogra's and tollef's so far...
<ogra> JaneW, jblack http://gallery.linuxguru.net/UbuntuDownUnder-4-2005
<jsg> i have some few i will upload them later
<JaneW> ta
<thom> tseng: your flights back were ok?
<tseng> thom: "ok" yes :)
<bob2> tseng: nice stylesheet
<thom> i love the MAGIC whiteboard
<tseng> bob2: its jimmac's script
<bob2> ah
<bob2> the thumbnails seem a bit stretched
<tseng> possibly
<tseng> seb128: maybe it just needs kicked again?
<jsg> ogra, whats the url of your gallery?
<ogra> http://www.grawert.net/udu-gallery/
<bob2> jsg: grawert.net/udu-gallery/
<seb128> tseng: I've uploaded a package sync on Debian 10 min ago
<tseng> yay
<seb128> tseng: if it doesn't build that's because libgda2-3 is universe and should probably be main, I'll ping elmo if that ftbfs again
<Mithrandir> hmm, why does baz delta -n --diffs include all the diffs three times or so?
<tseng> seb128: great sorry to be a bother
<seb128> np
<thom> i need to upload my photos; most are from jdub's wedding though
<thom> by the way, has anyone played with picasa? (google's photo app) -  it looks and feels very much like a polished fsport
<thom> f-spot, even
<Lathiat> and i thought f-spot was polished
<jsg> i always compared f-spot with picassa
<lifeless> fabbione: baz 1.4 should build with gcc-4.0 in ~ 45 minutes - 3 commits have to make check.
<lifeless> fabbione: to get 1.3.2 building, you can backport (should be trivial) or not fix it ;)
<dholbach> JaneW: this isnt me: http://community.webshots.com/photo/338849189/338861060HQDuQx# - or i looked odd the other day and don't remember :-)
<ogra> its tseng i guess
<tseng> yes.
<tseng> and andy
<tseng> where is the index for that?
<tseng> oh.
<JaneW> dholbach: yes sorry I think I got one or 2 names confussed, I'll go fix..
<bob2> uh-oh
<dholbach> JaneW: dont worry :-)
<bob2> man that site is slow
<ogra> the site is ok... the banners are slow....
<JaneW> bob2: if I could get into people.ubuntu.com I would have put them there...
<bob2> hm
<dholbach> yeah p.u.c for everyone!
<tseng> "bob2 cheers up"
<bob2> oh, your password is encrypted with a key you don't have?
<tseng> dholbach: yeah!
<dholbach> <name>@ubuntu.com for everyone!
<bob2> tseng: never.
<dholbach> :-)
<jsg> i love you bob2
<jsg> hehe
<JaneW> dholbach: do you know who that is?
<dholbach> JaneW: i think it's tseng
<Mithrandir> looks like AndyFitz and tseng
<tseng> < ogra> its tseng i guess
<tseng> < tseng> yes.
<tseng> < tseng> and andy
<ajmitch_> such a shame I'm not in any of those :)
<tseng> ajmitch_: you share a silver moment with luis
<AndyFitz> janeW thats me on the left and tseng on the right
<ajmitch_> yeah, that one is funny
<JaneW> ajmitch: I avoided names I wasn;t sure of
<JaneW> and even them I got some wrong
<JaneW> so sorry ;)
<JaneW> ok, thanks
<tseng> http://tseng.ath.cx/photos/index.php?galerie=udu&snimek=54 wee
<jsg> you can just name them the way jblack did: some ubuntu hackers hehehe
<jsg> ok im out see you guys later
<ajmitch_> bye jsg 
<JaneW> better now?
<JaneW> ajmitch: which pic are you in?
<JaneW> oic got it
<ajmitch_> JaneW: none of yours except the group shot
<ajmitch_> hi chmj 
<chmj> hi ajmitch_  
<JaneW> ajmithc: don't feel bad, no one took photos of me either ;)
<bob2> so
<bob2> can I plug a ata-100 drive into a ata-33 controller using a 40 pin cable?
<bob2> and have it work at ata-33.
<Lathiat> yeh
<ogra> ajmitch_, http://www.grawert.net/udu-gallery/img027.jpeg.html 
<Lathiat> they only use ata-100 if you have an 80pin cable (even on an ata100 bus)
<bob2> is this a "it might work, but watch those backups" or a "'tis fine, ata falls back" thing?
<ajmitch_> ogra: thanks :)
<Lathiat> nah its fin
<Lathiat> *fine
<Lathiat> its designed to work like that. :)
<bob2> Lathiat: excellent, thanks
<bob2> jesus christ it's hard to get into this hp
<AndyFitz> janeW  : http://bytebot.net/shots/dsc03162.jpg   colin charles took this 
<bob2> this machine apparently consumed all the metal they wanted to use in their shitty plastic printers
* ajmitch_ sees some mao photos
<Lathiat> bob2: heh
<Lathiat> old hardware is fun
<Lathiat> you end up dropping it to open it, then realise it was really much easier to get it open
<bob2> I'm kinda worried it will topple and destroy my x40
<bob2> it must weight 20 kilos
<JaneW> AndyFitz,: oh yes, that was when I was evangelising that guy in the elevator!
<AndyFitz> good work.  10 points
<mjg59> bob2: Silly. The X40 has an aura of magic protection.
<JaneW> AndyFitz: thanks - I didn;t realise I had an audience though ;)
<AndyFitz> JaneW,  its been posted on his blog and on  planet.linuxaustralia  http://www.bytebot.net/blog/archives/2005/05/02/ole-ole-ole-ubuntu-boleh
<Lathiat> tseng: qemu 0.7.0 has support to run x86-64, might be usefull?
<Nafallo> morning all
<bob2> jesus this hp likes to beep a lot during boot
<bob2> beep for missing case
<bob2> beep for missing keyboard
<bob2> beep because it's a thursday
* Lathiat grins at bob2
<Nafallo> hehe
<bob2> "buffer i/o error on device hdc"
<bob2> that sounds bad
<Nafallo> bob2: it didn't beep for that?
<bob2> Nafallo: a beep is an unfair description
<bob2> it was more like a rising crescendo of beeps
<bob2> a symphony of annoyingness
<bob2> an aria of irritation
<Nafallo> *s* that's why I haven't that cable plugged in ;-)
<bob2> oh, it has a flashing red DANGER DANGER WILL ROBINSON led on the front, too
<bob2> hp kayak: the server for people who can't read textual errors
<Nafallo> lol
<bob2> wow, it even booted ok
<bob2> and let me format the disk and everything
<seb128> elmo_: around? libgnomedb ftbfs because libgda2-3 is not-installable ... is that because that's an universe package? Any way to move it to main?
<robtaylor_> anyone know anything about the status of using LVM for root?
<robtaylor_> (partition)
<ajmitch_> works fine for me since at least mid-way through the hoary cycle
<ajmitch_> the warty installer didn't support lvm2, but hoary does
<robtaylor_> ooh
* Kamion doesn't remember the change that added lvm2 support
<Kamion> could've been a sync from Debian I guess - I thought warty supported lvm2 though
<Kamion> but anyway, LVM for root is usually more a matter of careful bootloader configuration than anything else
<ajmitch_> ah yes, I do have a separate small /boot, iirc
<cc> AndyFitz, JaneW : of course, it was on planet fedora. that makes it all hte more fun :)
<JaneW> hi cc
<cc> hey, hey JaneW 
<JaneW> cc: thanks for including me in your - post on every web page on the web campaign ;)
<JaneW> cc: btw do any more specs need editting?
<JaneW> I am pretty busy but could still help out
<JaneW> or editing even
<JaneW> of course spelling/typing is not my personal strong point, but I can spot other's errors...
<dholbach> ok... i'm out... see you later
<robtaylor_> Kamion: ah, that makes sense
<JaneW> who moderates the ubuntu-devel mailing list?
<Simira> Isn't that Jeff? Waugh, I mean
<Mithrandir> yeah, jdub does that
<cc> JaneW: do i have more that need editing, no. but i'd gladly look at more i'm sure
<JaneW> ok thankis, cos I sent a msg earlier and it's been detained...
<JaneW> says I am not subscribed...
* JaneW is still feeling slightly anxious after migrating to Ubuntu... like I don;t have everything taken care of and buttoned down, and like I am not completely in control
<JaneW> was there a 'psychological effects of a w32 to Ubuntu migration' BOF?
<Mithrandir> JaneW: no, since most people have migrated from Debian or similar to Ubuntu. ;)
<Simira> :D
<Zomb> I think you should care more about upgrade path from Woody, btw.
<Mithrandir> Zomb: bugs and patches accepted. :)
<ogra> Zomb, whats wrong with the upgradepath from woody ?
<JaneW> Mithrandir,: I gather that is easier and less like flinging yourself off a clifff then?
<Zomb> it failes on some places, I remember 3-5 file overwrite problems and the lilo bug from Sid
* ogra grins about a redhat mail.... they want to build a hardware database....
<Mithrandir> JaneW: I think so, yes.
<Mithrandir> JaneW: what's scary ATM?
<ogra> Zomb, after following the upgrde notes ?
<ogra> Zomb, remember, we only support woody->warty
<Zomb> there only notes for woody-warty
<ogra> Zomb, yep
<Zomb> that sucks
<ogra> Zomb, because you shouldnt do woody->hoary... do woody->warty->hoary if you want a sane upgrade
<Zomb> as said, that sucks. You expect people to install gigabytes of data just to reinstall it again.
<ogra> Zomb, woody is simply to old for a direct woody->hoary upgrade, to many changes
<Zomb> maybe. I don't remember the details but every time I have hit a file overwrite error it was clear: this one can have been fixed easily. Woody->Sarge upgrades are also supported (less or more).
<Kamion> Zomb: we went through a fair bit of effort for both woody->warty and warty->hoary; but you start hitting diminishing returns after a point
<cc> JaneW: if it helps, i've held of my migration as well. i'm still being a little cautious
<JaneW> cc: thanks ! now you tell me
<ogra> yeah kickoff, thanks JaneW 
<JaneW> ogra: I sent that hours ago - was stuck in the moderator queue, but I managed to bypass now ;)
<ogra> ah :)
<lamont> moo
<ogra> morning lamont 
<JaneW> mooning
<Simira> JaneW: What did you use before Ubuntu?
<tseng|work> hey does anyone know an rss feed for ubuntu-security?
<tseng|work> the gmane one seems broken
<mvirkkil> jdub: Does planetplanet use plain pickle for caching?
<tseng|work> hi lamont
<dilinger> good morning all
<lamont> morning dilinger 
<lamont> kids->school
<JaneW> Simira: windows (XP most recently)
<JaneW> Simira: did you see my pics? I am in there...
<Simira> JaneW: ok. No, I didn't see your pics. Where?
<Simira> JaneW: I still use XP, on my desktop computer
<Simira> (don't tell anyone)
<tseng|work> :'(
<Simira> ah
<Simira> JaneW: are you working with Charles?
<JaneW> http://community.webshots.com/album/338849189afiQFQ
<Simira> hey, chmj and Charles are the same!
<JaneW> Simira: yes I am, though I have been working from home this week
<chmj> O.o
<Simira> JaneW: I found it
<Simira> ok
<JaneW> Simira: yes he changed from d3vic3 at UDU
<Simira> chmj: you probably don't remember me. We barely met in MAtaro
<chmj> Simira: yeah, I don't
<Simira> JaneW: I'm looking forward to meet you on the next conf
<JaneW> Simira: ditto
<ogra> ubuntu women power :)
<JaneW> Simira: you also in Norway?
<JaneW> Simira: I hope your real name isn't Jane though ;)
<Simira> JaneW: yes, I'm kind of Tollef's fianc, and my name is Karianne :)
<JaneW> else if it is, we'll have to make it a policy to only hire females with the name Jane
<Simira> hehe
<ogra> Simira, kind of ???
* JaneW was also wondering
<JaneW> nice name ;)
<Simira> ogra: oh, it's just a way of speaking
<ogra> heh
<Simira> JaneW: yes, please just call me Simira irl if you can't pronounce it ;p
<Mithrandir> she wore her ring this morning at least, so unless there's somehting she hasn't told me.. :P
<ogra> lol
<JaneW> I think Karianne is easier to say IMHO
<Simira> JaneW: I'm one of those not-getting-paid to work on Ubuntu. I'm the head of LoCo and Translation team in Norway. :-)
<JaneW> cool
<Simira> JaneW: Ok, some have problems with it. It's almost like Marianne, though.
<JaneW> pronounced carry anne right?
<Simira> yes
<JaneW> k
<Simira> JaneW: I'm primarily a XP user (daily), but my web/file/mailserver are hoary and my laptop is dualbooting with breezy/xp
<Simira> which reminds me I have to find a decent windows pgp client
* JaneW still has an XP partition to escape to if it all gets too much ;)
<Simira> JaneW: nothing to be ashamed of. I still turn to XP when I get stuck in Ubuntu and want things done nice and easy. ;p
<Simira> rather than getting help from Tollef :p
<Lathiat> i must be lucky or something
<Simira> Lathiat: what have you done? Or haven't?
<cc> Mithrandir: hey, any leads to your masters project on multiarch stuff and how its being correctly implemented?
<Lathiat> (i have never needed windows for anything of late)
<Simira> cc: ah, I saw your mail, yes. Nice :)
<Mithrandir> cc: http://err.no/debian/amd64-multiarch-3 is the latest proposal with some links; http://err.no/ntnu/thesis/report-multiarch/doc/report.pdf is the current state of my thesis
<cc> Simira: this being the sounder one? 
<cc> Mithrandir: thanks, a lot
<Simira> cc: yup
<Lathiat> i see a use for having x86 and x86-64 co-instaleld
<Lathiat> btu why would you want more co-installed?
<Simira> JaneW: But you have a pgp key, right?
<Mithrandir> Lathiat: some architectures support more, and you might want to have linux and netbsd, x86-64 and i386 at the same time, for instance.
<Simira> gpg, even
<Lathiat> linux and netbsd?
<mjg59> Lathiat: Imagine ppc64, ppc and x86
<Mithrandir> Lathiat: or you might want ia64, i386 and x86_64 once ia64 gets the ability to run x86_64, which I think it will
<Lathiat> mjg59: but i dont get why you would want x86 stuff installed on a ppc machine?
<mjg59> Lathiat: Because it's not available for ppc?
<Mithrandir> or sparc64, sparc32 for both linux and sunos
* Lathiat is confused
<Lathiat> why do i need x86 libraries on a ppc machine that can't exuecute them, why do i want sunos stuff installed and why do i want netbsd stuf finstalled?
<mjg59> Lathiat: qemu lets you run x86 linux stuff on ppc quite happily
<mjg59> And there's lots of x86 linux stuff that you can't get for ppc
<Lathiat> mjg59: right, but doesnt that then handle the libraries too?
<bob2> like valgrind
<mjg59> Lathiat: The libraries need to be on your filesystem somewhere
<svenl> Kamion: i did a build of the chrp kernel using mkvmlinuz on a installed ubuntu/hoary image and getting the hoary install CD initrd.gz.
<Mithrandir> Lathiat: not all people like Linux; mjg59 is working on Debian NetBSD for instance, where an idea is to just port the base stuff and use the emulation layer for everything else.
<Lathiat> mjg59: so qemu does emulate the 32bitness for the 32 libraries and uses 64bit libraries?
<mjg59> Lathiat: ? Uh, no.
<svenl> Kamion: but it tells me that it is not finding the kernel modules, due to version difference, which seems strange.
<Lathiat> mjg59: when why do you need 32bit libraries installed?
<Lathiat> sorry, im not getting something here, and i cant figure out what it is. :)
<svenl> Kamion: /proc/version has 2.6.10-5.
<JaneW> Simira: no I don't
<mjg59> Lathiat: qemu lets you run x86 binaries on ppc. This requires x86 libraries.
<Lathiat> mjg59: oh right, duh
<Lathiat> how did i miss that
* Lathiat smacks his head on the desk
<Simira> JaneW: It's not so weird when you get used to it :)
<Simira> Mithrandir: how did you avoid all those cameras?
<Mithrandir> Simira: no idea.
<Mithrandir> I probably vibe out.
<Lathiat> mjg59: thanks. :)
<Mithrandir> uhm, vibed out
<bob2> Simira: he beat potential photographers!
<Simira> bob2: he wouldn't
<Mithrandir> bob2: I beat photographers who flashed me in the eye.
<svenl> Kamion: mmm, ubuntu-installer got confused by the rc3 dvd i had in the player :)
<Kamion> svenl: could you give me the exact error message rather than a paraphrase of it? I don't know this process off by heart.
<svenl> Kamion: well, i was french localized :)
<svenl> Kamion: i guess i used the cdrom initrd, which caused that.
<svenl> Mmm, gigabit ethernet is not yet working.
<seb128> elmo_: around?
<cc> svenl: really? i thought i saw benh pass the patch on to akpm/linus already
<svenl> cc: hoary has only 2.6.10, and the backport in ubuntu was broken.
<cc> svenl: ah yes, of course. 
* cc keeps on forgetting about stable kernel releases
<svenl> cc: you are in the ubuntu boat too then ? 
<Lathiat> whats scott remnants irc nick?
<tseng|work> keybuk
<thom> keybuk
<Lathiat> ah
<cc> svenl: well, not quite, no. lets just say its something i'm finding really interesting at the moment, and i do plan on loading up and using at some stage soon
<Kamion> svenl: what mkvmlinuz command did you use, so that I can try it out and track it down myself?
* JaneW needs to go
<JaneW> bbl
<Simira> bye, Kane
<Simira> uhm
<Simira> Jane
<Simira> 0_o
<Kamion> +shadow (1:4.0.3-31sarge3ubuntu1) breezy; urgency=low
<Kamion> these version numbers are getting SILLY
<Lathiat> you havent seen the ubuntu backports ones then
<ogra> argh....
<ogra> he said IT
<Lathiat> it?
<ogra> the bad B word
<Lathiat> oh, that
<Kamion> Lathiat: I restrict myself to non-totally-broken distributions
<Lathiat> Kamion: you mean sources
<Kamion> backports are effectively a distribution
<Lathiat> i guess
<Kamion> albeit an overlay one
<Kamion> certainly to the extent that those using them take on responsibility for supporting themselves
<Lathiat> hrm new powernowds thread detection is borked
<thom> Lathiat: howso?
<Lathiat> thom: comes up on my cpu as 0
<Lathiat> so it fails to start without -c
<Lathiat> as threads < ncpus
<Lathiat> trying to figure out why atm
<svenl> Kamion: mkvmlinuz -o /path/to/file -i /path/to/initrd.gz -a chrp -z -v
<Lathiat> also, returning an uninitialized num if (edx & 0x8000000) isnt true probably isnt good either
<svenl> Kamion: hoary doesn't call mkvmlinuz or install it though, since it is assuming yaboot worked, which i didn't quite do in time.
<svenl> Kamion: and the page telling about the OF variables doesn't seem to handle the OF aliases as debian's nobootloader did.
<thom> Lathiat: can you file a bug, please
<Lathiat> thom: ya, trying to see if i can figure it out first
<Kamion> svenl: indeed, I didn't attempt to reimplement that part in yaboot-installer
<svenl> Kamion: please do in the future, typing /pci/ide@.../disk@0,0:0 is a lot more complicated than just hd:0 :)
<Lathiat> anyone here with a p4 with hyperthreading?
<Kamion> svenl: enhancement bug please?
<svenl> Mmm, actually, i should be able to boot it using yaboto directly here, will try that.
<svenl> Kamion: i should file a bug you mean ? 
<svenl> will do.
<Kamion> I was just trying to get it done at all; since it wasn't something that was on my official list of things to do, I had to cut some corners
<Kamion> svenl: yes, please
<Lathiat> if so, can they grab http://bur.st/~lathiat/threading.c and paste me the output?
<svenl> against yaboot-installer.
<Kamion> yes
<svenl> Kamion: do you need a patch or something ? Or can you handle from nobootloader ?
<Kamion> svenl: the nobootloader code looks reasonably straightforward
<Kamion> so I can probably handle it
<svenl> I can just copy the code from nobootloader into the bug report for documentation purpose.
<svenl> Kamion: if i had installed as expert, i would have had to chose nobootloader instead of yaboot-installer ? 
<svenl> Kamion: in that case, maybe we should modify nobootloader to do the mkvmlinuz call thingy ? 
<Kamion> I don't like mkvmlinuz; I'd much rather have a sane bootloader :)
<Kamion> (well, sane-ish)
<Kamion> I'm tempted to switch Pegasos to grub2
<svenl> Kamion: mkvmlinuz is sane.
<Kamion> not by comparison. :)
<svenl> Kamion: it is real kernel code, and is the default on real ppc hardware for netbooting.
<Kamion> it's 2005, damnit, bootloaders should be able to assemble stuff
<svenl> real ppc hardware meaning IBM stuff i guess :)
<svenl> Kamion: for netbooting, it bears no comparison to the way yaboot works. you have only to put a single file in your tftp served dir, and boot it.
<Kamion> I'm happy to make it work but I don't think it should be the installation default
<Kamion> if it's at all possible to have any other solution
<svenl> Kamion: well, nobootloader is not the default.
<svenl> yaboot-installer is.
<Kamion> true
<svenl> so it would only be a fallback for expert mode or whatever.
<svenl> but it would sound strange to fall back to expert mode, chose nobootloader, have it tell you to boot boot/vmlinuz-2.6.10-5-powerpc or whatever, and this kernel not being present :)
<balor> I'm getting some strange agpgart errors with today's Breezy "[drm:drm_fill_in_dev]  *ERROR* Cannot initialize the agpgart module.".  Thus I can't get DRI working.
<Kamion> seems reasonable for it to make sure that file exists, yes
<svenl> Kamion: will fill another bug report about this.
<Kamion> I have an incredibly large number of breezy goals though - if anyone else can do it, I'm happy to help
<balor> I'm running an Intel 865G with the latest BIOS patches.  Can anyone speculate as to why it can't ceate the dev entries?
<thom> balor: support questions in #ubuntu, please
<svenl> Kamion: well. I may do it, but filling a bug report makes sure it doesn't get forgotten.
<balor> thom: It's not really a support question.  I think there's a bug in the module loading.
<Kamion> svenl: yeah, absolutely
<balor> thom: But I'll try there anyway...sorry
<Lathiat> anyone here with a pentium-m cpu? 
<Kamion> svenl: this cycle is probably going to be me realising that I can't write all the code myself any more, that's all :(
<tseng|work> Lathiat: yes?
<Lathiat> tseng|work: can you compile/run/paste results of http://bur.st/~lathiat/threading.c
<Lathiat> tseng|work: need to run as root
<tseng|work> its at home
<Lathiat> actually, you dont
<Lathiat> tseng|work: oh, ok
<svenl> Kamion: hehe.
<Kamion> svenl: mkvmlinuz worked fine for me when I added '-r 2.6.10-5-powerpc' to the arguments
<Kamion> (I was running it in a chroot so the default was bound to fail anyway)
<svenl> Kamion: anyway, we should have an OF with yaboot/grub2 support and nvram editing from linux well before breezy anyway.
<svenl> Kamion: ok.
<Kamion> svenl: using -k /path/to/kernel works too
<Kamion> nvram editing> woohoo#
<svenl> Kamion: i think you should do -k /path/to/kernel instead of -r.
<svenl> That was what Jens said anyway.
<svenl> Kamion: nobootloader does get called after the kernel has been installed, so we would need to dpkg-reconfigure linux-image, or call mkvmlinuz by hand, right ? 
<svenl> Arg.
<svenl> ubuntu/hoary's X doesn't respect me chosing french language but us keyboard, and it probably did chose macintosh and not pc105 too.
<Kamion> svenl: calling mkvmlinuz by hand would seem straightforward/reasonable enough
<svenl> Kamion: indeed.
<svenl> Kamion: you need only to call it the same way kernel-package's postinst call it.
<svenl> Kamion: i wonder how the mkvmlinuz debconf question would be called though, maybe nobootloader could preseed it to mkvmlinuz.
<Kamion> it shouldn't be running at a priority high enough to be seen anyway
<Kamion> if it is, we'll have to clobber it in Ubuntu
<Kamion> one way or another
<svenl> Kamion: it is running in priority medium i think, but you will see it in expert mode i guess.
<svenl> Kamion: the thing is that it should default to yaboot on pegasos once the firmware is released, but if you chose nobootloader over yaboot-installer, you want it to default to mkvmlinuz and not yaboot.
<Kamion> it's not rocket science to tweak :)
<svenl> Mmm, trying to boot yaboot directly gets me :
<svenl> Amiga partition table corrupted at block 0
<Lathiat> thom: bug filed, with possible patch
<svenl> block type is not partition but 00000000
<thom> k, thanks
<svenl> I wonder if this is our OF or yaboot, let me check ...
<svenl> It is yaboot.
* svenl wonders why.
<svenl> This used to work :/
<Lathiat> thom: the patch cant hurt at the worst, and seems to fix all situations of return values I've seen
<doko> chmj: pan is already fixed and uploaded
<chmj> doko: so i have noticed 
<bluefoxicy> ok
<bluefoxicy> why the HELL don't +, =, -, and _ work in synaptic?!
* bluefoxicy is right-clicking one of like 19 packages at a time to remove residual configs.
<Lathiat> bluefoxicy: eh?
<ogra> bluefoxicy, synaptic can do multiple select ....
* bluefoxicy selects all, right click. . . mark for installation?
<bluefoxicy> no.
<bluefoxicy> oh geeze if it selects one that's marked it'll grey the option x.x
<bluefoxicy> ogra:  I still have to use this annoying pointing device.
<ogra> bluefoxicy, its a gui tool.... use aptitude if you dont like mice
<bluefoxicy> ogra:  press ctrl+t :)
<doko> elmo_: please import perl from unstable, the security patches are applied in the Debian version
<doko> elmo_: please import libunwind from experimental
<jani> seb128 ping
<seb128> pong
<jani> seb128, evince does not built, in case you missed it :)
<jani> missing poppler-glib something
<seb128> thanks but there is a lot to do, I'll do a second pass on ftbfs soon
<jani> ok :)
<seb128> bah, not an evince bug
<Lathiat> heh
<seb128> jani: archive issue
<jani> build infrastructure you mean?
<seb128> jani: it'll be solved when the appropriate package are moved to main
<jani> ok thanks
<seb128> jani: no, 'archive', like archive.ubuntu.com
<seb128> evince is main and the new poppler part universe (that's by default)
<seb128> need to be moved to main
<jani> got it
<seb128> there is some similar issues, that will be solved soon, but not by me
<seb128> you just have to wait, sorry for the delay
<jani> np
<Burgundavia> where should I file synaptic bugs? ours or some upstream?
<Lathiat> bugzilla.ubuntu.com
* hunger_ hates ubuntu's start/stop scripts. Their output is rather erratic...
<hunger> powernowd is NOT started, but the start/stop script thinks that is OK:-(
<Kamion> elmo_: could you arrange for restricted/debian-installer/* to show up in dists/*/Release, please?
<Kamion> elmo_: it looks like ziyi has main rather hardcoded when looking for */debian-installer sections at the moment
<Simira> pancakes!
<mjg59> hunger: Why is it not started?
<hunger> mjg59: Dunno... worked till today.
<thom> hunger: are you on breezy, and did you update recently?
<hunger> mjg59: But I figured out why this sucky mix oy lsb/debian style start/stop script won't work.
<hunger> thom: I did and I updated today.
<thom> you're probably seeing 10446
<hunger> thom: Looks like bug10446 is biting me:-)
<hunger> thom: Yeah, just saw you had that reported.
<hunger> thom: Does /etc/init.d/powernowd start claim that it works for you?
<wasabi> anybody familiar with programming against synaptic (such as how update-manager does)
<hunger> thom: Aka. do you get an [ ok ] ?
<Lathiat> hunger: http://bugzilla.ubuntu.com/show_bug.cgi?id=10446
<thom> hunger: the only box i have atm (laptop's in for servicing) doesn't support powernow (old amd64)
<Lathiat> hunger: (known bug)
<Lathiat> thom: what cpu is your laptop?
<Lathiat> it only sems to show up on pentium-m
<Lathiat> altho some other cpus get -ve values
<Lathiat> which are not handled either
<thom> Lathiat: p-m (but like i say, it's at ibm)
* Lathiat nods
<thom> Lathiat: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306896
<hunger> Lathiat: P4.
<hunger> Lathiat: Have a look at #10457 as well: the [ ok ]  issue (incl. patch).
<Lathiat> thom: righto
<zyga> wasabi: what do you want to do?
<wasabi> zyga, append a new source in a somewhat safe manner. Only if the same source doesnt' already exist, etc.
<wasabi> And then invoke synaptic to a) update the sources and b) install some packages
<zyga> wasabi: if you want to do that in python it's not that complicated and you could just use update manager's source 
<Lathiat> heh intel not following their own spec, theres a surprise.
* hunger is away.
<wasabi> good idea.
<zyga> wasabi: by install do you mean - gui allowing people to choose stuff?
<wasabi> no.
<wasabi> I am implementing a test file hanlder for .apt files
<zyga> wasabi: automated?
<wasabi> Yes.
<wasabi> The file, when double clicked, will add some sources then install some packages.
<zyga> wasabi: then update manager already has everything you need
<wasabi> super
<zyga> wasabi: take a look at current source, I may help you if you're lost or don't want to read everything
<zyga> wasabi: one moment
<wasabi> im in it now
<wasabi> I hope for this to make it somewhat easy for third partities to distribute packages targetting debian-based distros to end users.
<zyga> wasabi: aptsources.py.in is interesting for you
<zyga> wasabi: oh great, different approach to autopackage :)
<wasabi> Basically just provide a link to SuperCoolProgram.apt on their web site, and have it offer to install it.
<wasabi> Yeah.
<wasabi> Just WAY SIMPLIER
<thom> hunger: that's a broken patch, and anyway the way it works currently is by design. also, please use diff -u when submitting patches
<Burgundavia> and a huge security nightmare
<Burgundavia> wasabi, there is some discussion is making installing easier
<wasabi> No more a security nightmare than every other OS ever.
<Burgundavia> see the UDU wiki
<Burgundavia> wasabi, we need to be better than the others, not the same
<wasabi> There really is no other possible means to the end really.
<wasabi> Users want to install software from the internet. That's it.
<zyga> wasabi: and update-manager.in
<wasabi> Either we let them, or we don't.
<zyga> wasabi: of course you don't need 80% of it
<wasabi> The only way to make it "secure" is to wrap it in SELinux or something similar.
<wasabi> Or try to do what MS wanted to do, sign everything with a central authority.
<wasabi> which obviously isn't going to work.
<zyga> wasabi: if the installer gets root and asks internally for every permission then selinux is not going to help, trusted sources are but that's a different story
<wasabi> exactly.
<wasabi> I hope to have the .apt file contain a number of sections in traditional dpkg tag file format. Each section has a Distro and/or Arch section, Binary-Archives, source-archives, then a list of packages to install.
<wasabi> And probably a public key too for apt-secure.
<wasabi> Thing just runs thru it, adds the sources, adds the keys, and tells synaptic to go for it.
<zyga> wasabi: okay if you need anything else make sure irssi will hilight your line for me, I'm reading a book a few meters away
<wasabi> ok. thanks. ;0
<wasabi> I see, that's pretty easy.
<zyga> wasabi: re... I just had a cool idea
<zyga> wasabi: instead of doing extra meta packages why not do something compleatly different 
<wasabi> extra meta packages?
<zyga> wasabi: .pakackage in mind (autopackage)
<wasabi> Oh. It's not a meta pacakge.
<wasabi> At all.
<zyga> wasabi: I know ;-)
<zyga> wasabi: anyway just listen for a moment
<wasabi> k
<zyga> two possible scenarios - open source stuff and close source stuff
<wasabi> ok.
<zyga> oss first
<zyga> let's say I want to get latest and gratest gaim 
<wasabi> ok.
<zyga> greatest even 
<zyga> (assuming .desktop compatible environment)
<wasabi> ok.
<zyga> I click 'start-or-something' -> internet -> gaim 
<zyga> it's there already even though it's not installed
<wasabi> I get it, that's neat, I like the idea.
<wasabi> But I think it's seperate to this idea. ;)
<zyga> a little
<zyga> it becomes complicated more for close source stuff
<wasabi> The idea is to make apt decentralized.
<wasabi> Right now it isn't, mostly because people aren't proficcient at using it.
<wasabi> And they shouldn't be.
<zyga> because you still need the package installer and .desktop file that will ivoke it somehow
<wasabi> Yup.
<wasabi> I think a button on a web page
<wasabi> "Install Software Now!"
<wasabi> Is pretty rad.
<zyga> but imagine .desktop and .png files as only two things needed for custom app installation :-)
<Burgundavia> the advantage of a centralized system is that you can say "here is all the games on offer"
<Burgundavia> your system cannot do that
<wasabi> For open source software, like, gaim could publish CVS snapshots On Ever Checkin, if they wanted to.
<wasabi> Burgundavia, my system isn't designed to.
<zyga> run = install-magic http://www.vendor.com/your-game-or-something
<wasabi> The use case of "my system" is pretty damned simple.
<Burgundavia> wasabi, have you read www.ubuntu.com/wiki/WinningTheDesktop ?
<wasabi> It's just about making it easy for users to install stuff using apt without editing text files.
<zyga> Burgundavia: the problem is non free stuff as 99% games are are not going to be in any repository
<Burgundavia> wasabi, see http://udu.wiki.ubuntu.com/PackageManagementRoadmap
* zyga wonders if anyone bough doom3 for linux
<Burgundavia> and http://udu.wiki.ubuntu.com/FindingPackages
<zyga> how did they manage the installer and such?
<wasabi>  mime-type of packages should be used: find a application to work with that mime type and install it (see also FindingPackages).
<wasabi> That is potentially awesome.
<Burgundavia> I have a copied windows install
<zyga> Burgundavia: so you need a windows box to install it first?
<Burgundavia> zyga, I don't think so
<jnc> hey um... is Breezy usable?
<jnc> i understand it might break now and then
<Burgundavia> I have a pirate version that a friend copied to me
<zyga> jnc: hey, that depends but generally yes :-)
<Burgundavia> I noticed it installs the linux binaries along with, so I can run it
<zyga> jnc: and that answers both questions really :-)
<jnc> okay.   so like you don't forsee any changes that would totally fubar the system and render apt unworkable?
<Burgundavia> jnc, no
<jnc> a'right.
<Burgundavia> jnc, I see not having X work
<jnc> thanks
<zyga> jnc: hoary once broke network stuff for an hour
<jnc> X not working is not the end of the world
<zyga> jnc: but it's usable IMHO :-)
<jnc> that'd be like using Microsoft or the old Apple OSes
<jnc> !@#t happens.
<zyga> jnc: windows has virtual terminals that help when X crashes, cool..
<zyga> ;-)
<jnc> zyga: what, you never ran win32s on top of DOS to virtualize two copies of doom I running at the same time ?
<jnc> tsk tsk
* jnc ;)
<zyga> jnc: doom doesn't run on sparc - sorry
<jnc> touche!
<zyga> ah but I'm silly
<zyga> doom3 does not ;-)
<jnc> going from Hoary -> breezy, are there any special procautions when making the switch (have there been changes not covered by dpkg?)
<zyga> jnc: some things don't work - if you need one of them - wait
<Burgundavia> does anyone have a list of stuff still borked?
<jnc> i dig it.
<zyga> Burgundavia: gcj, ooo  (or ooo2, cannot remember ATM)
<zyga> Burgundavia: gcj needs g++ 4.0 which AFAIK it will not get untill abi change
<wasabi> Okay here's another question.
<wasabi> I am looking for something that identifies the distro.
<wasabi> in an apt based system.
<wasabi> the word "hoary" for instance.
<Lathiat> wasabi: /etc/lsb-release
<wasabi> or "sid".
<Lathiat> well, on ubuntu
<wasabi> Ahh hah!
<Lathiat> debian has /etc/debian_verson
<Lathiat> debian has /etc/debian_version
<Lathiat> debian doesnt have lsb-release tho
<wasabi> Hmm.
<wasabi> I can mandate lsb-release.
<Burgundavia> /etc/issue
<wasabi> Since *I* use ubuntu. :0
<zyga> standards - so many to choose from ;-)
<Lathiat> actually ubuntu has /etc/debian_version
<Lathiat> assumedly for compatibilty
<Lathiat> (but it says the debian version)
<wasabi> Okay the two words Ubuntu and hoary. What would they be called. The distro and the ?
<Kamion> don't look at /etc/lsb-release
<jnc> release name
<zyga> wasabi: release name?
<Kamion> use the lsb_release command
<Lathiat> release name
<jnc> zyga: bwahaha.
<wasabi> Oooh.
<Kamion> wasabi: formally "suite"
<Lathiat> Kamion: ahh, didnt know about that
<wasabi> I like tha tcommand
<Kamion> though that's basically internal archive terminology
<Kamion> release name or release codename would be usual
<zyga> Kamion: N/A 
<wasabi> Kamion, did you hear what I was working on? If you knew the context you might have an idea.
<Lathiat> zyga: lsb_release -a
<Kamion> zyga: so read --help
<Kamion> wasabi: I heard, I don't want to be involved
<wasabi> =)
<Kamion> wasabi: I've argued against it in the past; I consider I've said my piece
<wasabi> What would you argue for?
<wasabi> Or are you one of those "i don't carers"
<Kamion> "I consider I've said my piece"
* zyga is enlightened
<Kamion> I'm not having the same argument every week
<Kamion> however we specced out a less bad solution at UDU
<ogra> http://udu.wiki.ubuntu.com/FindingPackages
<wasabi> Hmm. That doesn't really cover the same use cases.
<wasabi> Oh I see it does.
<wasabi> goal 2!
<Kamion> right, FindingPackages is much better than teaching people that a web browser is a good thing to use to install software
<wasabi> I don't see the difference.
<wasabi> from the page
<wasabi> file with some meta-information needs to be provided by launchpad when the user clicks on a "Install" button with his web browser.
<Kamion> that slipped by me; I would have argued against that if I'd heard it
<wasabi> Well I think the main idea is that users should be able to install stuff *we* haven't vetted.
<Kamion> as long as the means is *not* a web browser
<wasabi> How do they find the people without that?
<Burgundavia> Kamion, I think goal 2 is within a web browser
<wasabi> That's the only means of decentralized navigation we have.
<Kamion> Burgundavia: yeah, I think goal 2 is misdesigned
<wasabi> Maybe we should use gopher!
<Burgundavia> Kamion, there is another goal for gnome-app-install
<Burgundavia> Kamion, I happen to agree with you there
<Lathiat> perhasp some sort signing
<wasabi> The idea of gnome-app-install is good... but how do the apps get into it!
<Lathiat> so that you guys have a database and a name and it tells them who the package being installed is from
<Burgundavia> wasabi, they get drawn out of launchpad
<wasabi> Burgundavia, and launchpad is what?
<Kamion> sigh, I said I wouldn't get drawn into this again. gone.
<Burgundavia> wasabi, canonicals new web based do everything thing
<wasabi> Kamion, nobody would argue it over and over again if a solution for this most obvious usecase was presented. ;)
<Burgundavia> there is one coming
<Kamion> wasabi: I have many other problems to solve
<wasabi> That's fine.
<Burgundavia> gnome-app-install, being driven off of launchpad
<wasabi> Burgundavia, and I can add my own stuff to launchpad?
<wasabi> As an ISV.
<thom> Kamion: world hunger, jetlag? ;-)
<zyga> wasabi: I'm interested in the answer as well :-)
<Burgundavia> wasabi, ask sabdfl/mdz
* zyga was living under a rock lately and almost never heard of launchpad
<wasabi> Well, I'm actually almost done with what I'm working on, so I'm going to give it a go.
<wasabi> Since it's *so simple*
* zyga thinks that pseudo-dir in menu that enables people to install common apps would be way better than gnome-app-installer though
<Kamion> thom: :-)
<Kamion> more like "kbd-chooser is broken and nobody noticed for two months)
<Kamion> "
<thom> Kamion: huh.
<zyga> any .desktop and .menu (or whatever it's called) gurus here?
<Kamion> wasabi: sorry to snap; debugging broken stuff makes me cranky. :)
<wasabi> that's ok.
<wasabi> i didn't take it that way
<wasabi> Wish there was a suitable API to check if a source existed in sources.list
<wasabi> counting for odd spacing, etc.
<zyga> wasabi: linear find will do
<zyga> jbailey: hello
<jbailey> zyga: Hello!
<jbailey> (and everyone else too)
<wasabi> hi
<jbailey> Jerry!
<Kamion> morning jbailey
<jbailey> Colin!
<jbailey> It's a party. =)
<wasabi> zyga, the thing is if there is a line: deb http://site/dir suite dist1 dist2, and what needs to be added is only dist2.
<wasabi> It will add a second line for dist2, even though it is already included
<jbailey> doko: Around?
<doko> jbailey: yes
<jbailey> doko: Did the testsuite finish fine?
<doko> doko: yes, although I didn't test the 64bit binaries, running on a i386 machine
<jbailey> doko: I didn't touch any of the libraries at all, I just removed the lkh headers.  I'll do a quick compare between the two to make sure, though.
<jbailey> Assuming that's all good, I'll upload.
<jbailey> Thanks for testing that. =)
<jbailey> I do wonder if the whole amd64-libs package should just go away and we should setup biarch i386 stuff the same was sparc and s390 are done.
<jbailey> (and presumably ppc64 will be done, too)
<doko> nice, preparing the gcc upload orgy
<zyga> wasabi: re
<zyga> wasabi: hmm?
<jbailey> doko: Do you want the ppc64 glibc for that too?
<Kamion> wasabi: isn't that in libapt_pkg?
<Kamion> libapt-pkg, sorry
<Kamion> it certainly knows how to parse the file
<Kamion> and that's exposed through python-apt (GetPkgSourceList)
<doko> jbailey: can't really hurt ... so you do a glibc upload as well?
* Kamion goes to help out with election stuff
<Kamion> probably not around for the rest of the evening
<thom> Kamion: hope it goes well
<doko> thom: is he getting married? ;-)
<thom> doko: no, he's doing general elections stuffs 
<azeem_> this r0ml guy Ian is so fascinated about has blogged on installing Ubuntu: http://r0ml.net/blog/2005/04/20/new-laptop
<Lathiat> huzaah
<Lathiat> his resolution only worked cus i got that bug fixed for those dell screens. :)
<Lathiat> glad i did that before hoary released :)
<Burgundavia> now he is going to tell his friends how great Ubuntu is
<Lathiat> i wish i could email him and point out that turning off the tapping feature is as easy as commenting out one line in xorg.conf (well, thats not exactly easy, but fairly trivial)
<Lathiat> except he has no contact details on his page
* Lathiat mumbles something about people misinforming people, notably the kind who dont know what they are talking about
<Burgundavia> right
<Burgundavia> he shouldn't have to comment out that line
<Lathiat> yeh but it beats him trying to recompile his kernel
<Burgundavia> what I am saying is that there should be a gui for it
<azeem_> Lathiat: http://r0ml.blogs.com/about.html
<thom> Burgundavia: daniels has some ideas as to how that should work
<Lathiat> azeem_: cool
<mjg59> Burgundavia: It's not actually easy to do
<Burgundavia> thom, cool. did you get the url I sent you?
<thom> yes, thanks
<Burgundavia> cheers
<mjg59> There's all sorts of nasty security issues
<Burgundavia> oh?
<mjg59> Well, if you want to control the pad directly
<mjg59> Otherwise it's something that needs to hack xorg.conf and then restart X
<Burgundavia> hmm
<thom> (daniel wants to move the thing into an X config extension)
<MasterYoda> do ubuntu and debian actively work together?
<Burgundavia> yes
<mdz> morning
<MasterYoda> what do they do together?
<MasterYoda> will ubuntu's xorg go into debian? are the packages compatiable?
<MasterYoda> do they work to keep the packages compatiable?
<mdz> MasterYoda: yes, it is likely that Debian will adopt Ubuntu's xorg packages when they are ready to upgrade
<MasterYoda> what about gnome 10?
<MasterYoda> gnome 2.10....
<mdz> gnome 2.10 is already in Debian experimental
<ogra> morning
<thom> mdz: hey, morning
<MasterYoda> mdz: well yeah, but it's not the same as ubuntu's right?
<mdz> thom: feeling better?
<thom> mdz: much, thank you. i can walk again ;-)
<dholbach> thom: what did you do?
<mdz> MasterYoda: why would you say that?
<MasterYoda> mdz: cause gnome on ubuntu looks different than on debian
<mdz> MasterYoda: Debian has GNOME 2.8 in unstable (which is probably what you are running) and GNOME 2.10 in experimental
<thom> dholbach: major sinus headaches
<MasterYoda> mdz: right...
<dholbach> thom: oh :-((((
<MasterYoda> mdz: but the packages are not the same...
<MasterYoda> nevermind
<thom> dholbach: gone now, so it's all good
<seb128> elmo_: around now? :)
<elmo_> seb128: kind of - I was planning on coming back later unless it's urgent?
<elmo_> [I've just done the gda thing, if it was that] 
* jbailey stands in line for the "when elmo's back" queue.
<jnc> hey....
<jnc> no openoffice.org-evolution
<jnc> what's gives?
<seb128> elmo_: doing the same for poppler new binaries would rock but there is no hurry, thanks :)
<seb128> jnc: I don't understand the question
<jnc> it's missing from amd64
<jnc> there's builds for powerpc and i386, but not amd64
<jnc> seb128: the question might be, what prevents openoffice.org-evolution from being built for amd64 target arch?
<jnc> http://packages.ubuntu.com/breezy/gnome/openoffice.org-evolution
<seb128> jnc: no idea
<jnc> okay going from those files (dsc, tarball, diffball)  what would i do to try building a package here
<jnc> debmaker or something?   i don't build dpkgs all that often
<seb128> ask Mithrandir, he probably knows
<jnc> Mithrandir: hail!    how to attempt building 'openoffice.org-evolution' on amd64?
<seb128> lamont: around?
<jnc> it looks like no one attempted amd64
<seb128> there is an openoffice.org-amd64
<jnc> hmm
<jnc> i don't see it
<Mithrandir> jnc: not, since it's an universe package, iirc
<wasabi> an apt archive needs a place to put an image
<Amaranth> what?
<wasabi> http://archive.ubuntu.com/ubuntu/dists/hoary/image.png or something similar.
<wasabi> pondering third party repositories.
<Amaranth> what use is that?
<wasabi> Would be interesting to install third party software from apt, and have the repository show up in synaptic in a way that made it obvious what it was.
<wasabi> Like, if commercial software distributors made their own apt repositories.
<Amaranth> wasabi: I don't see commercial software makers setting up apt repositories any time soon
<wasabi> Well let's fix that.
<Amaranth> They'd probably move to autopackage before they'd do that.
<Amaranth> Which imho is a better option, or at least will be.
<wasabi> disagreed.
<Amaranth> Why not?
<wasabi> So complicated.
<Amaranth> err
<Amaranth> double clicking a file is complicated?
<wasabi> the implementation behind it is.
<Amaranth> but it's a lot simpler for users (double click vs editting sources.list)
<wasabi> That's why im working on a very simple program to double click and edit sources.list. ;)
<wasabi> I think I'm nearly done at 98 lines.
<Amaranth> it edits sources.list automatically, gets the package, and then restores sources.list to it's original state?
<wasabi> No need to restore it.
<Amaranth> this has a GUI?
<wasabi> No... we already have GUIs
<Amaranth> not as good as the one for autopackage :)
<wasabi> Synaptic can be (and should be made better) for other reasons.
<Amaranth> *shrug*
<Amaranth> You're fighting an uphill battle though. Once autopackage gets rpm and dpkg integration it'll be that much better than your tool.
<Amaranth> Because rpms for 4 different distros and 1-3 debs won't be needed anymore.
<Mithrandir> Amaranth: that's reinventing the wheel; if you want something like that, use LSB packages.
<mdz> let's not have the autopackage argument (again) here; we've been over it in depth on the mailing list
<Amaranth> LSB only does so much
<mdz> wasabi: you should talk to mvo about the repository icon idea
<jnc> Mithrandir: it's in the list of things to look into adding to the supported Ubuntu mix
<jnc> not that it matters
<Mithrandir> jnc: I'll veto it for amd64, since it would mean doing lots of more ia32-libs-style packaging.
<Mithrandir> it's not really scalable to do that in the long run.
<mako> mdz: ututo-e is theoretically bsd/gentoo based + some stuff from suse
<wasabi> mdz, i will be, mostly im in Code Mode right now. ;0
<lamont> seb128: was hiding from you... whats up?
<Mithrandir> azeem_: hi, any thoughts on getting a CVS snapshot of multisync with the gnokii support into breezy?
<dholbach> lamont: some rebuilds i guess :-)
<lamont> dholbach: sounds about right...
<seb128> lamont: please kick gnomedb planner builds
<dholbach> yes! planner! :-)
<seb128> lamont: libgda2-3 has been moved from universe to main by elmo, now they should build
<lamont> and gnumeric, of course./
<lamont> given back
<azeem_> Mithrandir: I'd prefer to kick the devs to release a new version, but they seem to be focused on opensync
<Mithrandir> azeem_: what's opensync? :)
<azeem_> the fd.o replacement
<seb128> lamont: cool, thanks
<Mithrandir> azeem_: what's the current state of that?
<azeem_> I am not sure, I think it is not on level with multisync yet, but catching up fast
<Mithrandir> azeem_: do you think it's breezy material?
<azeem_> I wouldn't count on it
<Mithrandir> hm, ok.
<mdz> `anthony: what up, dawg
<jnc> Mithrandir: are you looking for native compilation before incl. Ooo?
<jbailey> Ugh.  dpkg-divert and Replaces: don't seem to interact well.
<Mithrandir> jnc: ooo2 is rumored to be vaguely 64-bit clean.  I might find time to help out with that so we can get rid of the whole ia32-libs mess
<jnc> Mithrandir: that's what i'd like to see also
<Burgundavia> anybody get through to b.g.o ?
<jnc> bugs.gentoo.org ? 
<jnc> i'm a dev.  what do you need
<jnc> (gentoo dev)
<Burgundavia> gnome
<Burgundavia> ok, thats odd
<Burgundavia> now I got through
* Burgundavia determines that it was user error
* jbailey gives up and goes for lunch.
<Burgundavia> seb128, ping
<seb128> pong?
<Burgundavia> seb128, I am digging throught b.g.o, looking for a similar bug, before I file dup. Regarding the copy dialog, when you already have a file at the dest. An option for showing the timestamp on each file
<seb128> what is a timestamp?
<seb128> why doing this?
<Burgundavia> basically, say "file1" in folder1 was last editing yesterday. "file1" in folder2 was editing today. Do you want overwrite?
<Treenaks> seb128: who are you and what did you do to seb128? ;)
<seb128> Treenaks: asking for an user, not for me
<seb128> Treenaks: "timestamp" doesn't really speak to lusers
<seb128> Burgundavia: that's clutter for nothing imho
<Burgundavia> seb128, timestamp saying when each file was last edited is clutter?
<seb128> yep
* Burgundavia wonders about seb128 and his sanity
<seb128> if I copy a file over an another one that's on purpose
<Burgundavia> what if I don't know?
<Treenaks> seb128: how about it being in the "more info" arrow-opener
<seb128> Burgundavia: why not the size of the file rather?
<dholbach> lamont: could it be the buildlogs are on another place or something?
<Burgundavia> date is often a better indicator than size
<seb128> dholbach: about?
<Treenaks> seb128: sometimes you know you worked on a file yesterday or "last week"
<dholbach> seb128: i tried some links on http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
<Treenaks> seb128: but not how large it is
<Burgundavia> and sometimes files shrink
<Treenaks> seb128: saves you from opening both files and comparing
<seb128> because you work this way
<seb128> I know rather on the file properties than the date
<lamont> dholbach: works for me....
<seb128> BTW feel free to open a bug upstream
<dholbach> lamont: hrm, now it works for me too
<Burgundavia> seb128, I was wondering if a bug already existed
<seb128> maybe
<seb128> look on the closed bug too
<seb128> maybe that's closed :)
<Burgundavia> i doubt it
<seb128> why?
<seb128> I would close it I think :p
<Burgundavia> because it is useful
<seb128> that clutters the UI
<Burgundavia> here is my use case: I have 2 presentations, one on a disk and one on a harddrive. If i just copy over, I have no idea which is newer
<Burgundavia> unless I actually look at each
<seb128> yeah, I understand the usecase
<seb128> but that's not that common imho
<seb128> ie: you don't want that displayed all the time
<Burgundavia> this would only come up when a conflict occurs
<Burgundavia> only in the "conflict while copying" dialog
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=47893
<Burgundavia> open since 2001!!!
<lamont> jbailey: you around?
<Burgundavia> seb128, I might even have to learn how to code to fix it myself
<seb128> coding is easy
<seb128> coming with a good UI for that is what need the work
<Burgundavia> ok
<Burgundavia> I will do some hacking right now on that
<seb128> tseng: gnomedb fixed
* lamont is reminded of just how much he _HATES_ things like cdbs
<dholbach> lamont: he went out for lunch
* dholbach is quite fond of cdbs :-)
* lamont is weaving through a maze of cdbs trying to figure out why it's deciding to not build anything
<lamont>  debian/rules build
<lamont> make: Nothing to be done for `build'.
<lamont>  /usr/bin/fakeroot debian/rules binary
<lamont> make: Nothing to be done for `binary'.
<dholbach> which package is it?
<lamont> e2tools, after you remove the build-dep on type-handling evilness
<seb128> lamont: you don't like "just work" things ? :)
<lamont> seb128: not when they don't work, and debian/rules is all of 15 lines
<crb> mako: ping
<lamont> seb128: I like "just work" things just fine... It's "just doesn't work" that I don't like
<seb128> doesn't happen a lot with cdbs which is nice
<seb128> dunno what you have do to break it this way
<lamont> s/nice/why I'm cdbs illiterate/
<dholbach> lamont: maybe because of this:
<dholbach> edd: e2tools source: no-architecture-field
<dholbach> wasabi: e2tools source: build-depends-without-arch-dep
<lamont> dholbach: doh
* lamont finishes ripping type-handling out 
<lamont> edd?
<dholbach> oops  E :  became edd: and  W :  became wasabi:
<lamont> from  lintian?
<dholbach> yes, after pasting
<dholbach> L:
<dholbach> hrm
<lamont> dholbach: auto-nick-completion is evil, you know...
<dholbach> seems to be...
<lamont> fixed e2tools uploaded, and the other byDate polluters promotion needs requested
<wasabi> Hmm. gksudo is weird. It's putting '''s around my arguments.
<wasabi> i wonder how you work with that from a .desktop file
<jbailey> lamont: I'm here now.
<lamont> jbailey: is ok.
<lamont> we figured it out...
<jbailey> lamont: Get my hopes up and throw my love away then.  See if I care. ;)
<jbailey> lamont: While I've got you here, can you give-back lvm2?
<jbailey> retry, it rather.
<wasabi> gksudo is putting '''s around all my args. =(
* wasabi beats it
<lamont> done
<jbailey> lamont: jbailey^^ ?
<lamont> jbailey: yes
<jbailey> lamont: Thanks. =)
<jnc> oh geeze
<jnc> printing not working in breezy
<jnc> silly me
* lamont tells printing to take a number. :-)
<jnc> well... 
<jnc> should i try downgrading
<Burgundavia> how do I center text in glade?
<jnc> or wait a day or two
<thom> or just don't run breezy if you need everything to work
<jnc> well, not everything works anyways
<opi> at least you can whine then :-)
<Burgundavia> seb128, http://img161.echo.cx/img161/6384/filecopydialogtest5yx.png
<jnc> opi: *sigh*
<opi> you can not whine with Breezy :)
<jnc> amd64 hoary has a lot of... trouble patches
<jnc> like meteorite holes
<thom> i've had no problems with hoary/amd64
<jnc> hmm.. no printing from openoffice
<jnc> no openoffice.org-evolution
<opi> jnc: I know, I know. But what can yo do except for helping with Breezy
<jnc> opi: eh.   i'd sure like to start
<jnc> it's like, whining and downgrading doesn't do much to help you guys
<jnc> having breezy and not understanding OOo doesn't do much for y'all either :/
<seb128> Burgundavia: that's quite ugly but that gives the idea :)
<Burgundavia> seb128, there are some serious spacing and text issues
<Burgundavia> seb128, is there a default arrow icon in gtk?
<seb128> yep
<Burgundavia> hmm
<Mithrandir> jnc: printing to a file then running lp on that afterwards work fine for me.  The other printing bug is known, I just haven't gotten around to fixing it.
<Burgundavia> I didn't find it
<Burgundavia> I just did
<Burgundavia> but it won't let me select it
<JanC> hm, someone (a linux newbie) tried to use FAT32 partition as /home when he was installing hoary
<Mithrandir> JanC: that breaks horribly.
<JanC> resulting in the installer not being able to create a user directory etc.
<JanC> can't the installer detect something like that ?
<Mithrandir> JanC: known issue; too late to fix.  A bug has been filed already and it'll be fixed for breezy.
<JanC> ah, okay
<Mithrandir> so for now the fix is "don't do that, then"
<lamont> jbailey: lvm2 will build better once libdevmapper1.01 is in main. :-(  (requested)
<JanC> that's what I said ;-)
<jbailey> lamont: Oh, I hadn't noticed that.  I saw it failing to build because of missing libraries, and then noticed that devmapper was FTBFS, so I fixed that.
<lamont> jbailey: np
<lamont>   gcj: Depends: g++ (>= 4:4.0-0) but 4:3.3.5-4 is to be installed
* lamont nudges doko
<jbailey> lamont: Probably asleep, since he was sick.
<jbailey> lamont: I confirmed the upload a couple hours ago for him of amd64-libs, though, which makes gcc actually buildable again.
<jbailey> His plan I think was to upload gcc and check on it in the morning.
<Burgundavia> seb128, I committed the screenshot to the bug
<lamont> jbailey: yeah - I talked with him about the time amd64-libs made it into the archive
<seb128> Burgundavia: k
<doko> half asleep, will be fixed, when we make g++-4.0 the default
<jbailey> doko: That's about 2 weeks out, yes?
<lamont> doko: and then db4.2, libtool, and several others will be buildable.
<doko> jbailey: heh, no, next week ...
<doko> lamont: db4.2 needs to be rebuilt anyway, because it builds a C++ library. I think, we should stop the automatic sync from unstable, until we rebuilt all our C++ libs
<Burgundavia> seb128, sorry, you just spammed with 4 emails from the one bug
<jnc> oh man
<jnc> printing != working for me...  != cool
<jnc> where do i start to fix it?
<jnc> it looks like the locale is confusing perl
<jnc> on some kind of back-end to cups
<jnc> the alternative is to downgrade but i'm not exactly sure how one goes about doing that
<seb128> ?
<mako> crb: hey ddue
<wasabi> gksudo is giving me headaches.
#ubuntu-devel 2005-05-14
<wasabi> Hmmm.
<wasabi> So I was thinking that apt needs a way to track which packages were installed from which repositories, and only update them from the right repository.
<wasabi> done.
<mdz> jbailey: any luck with the printing issue?
<tseng> hi.
<mako> mdz: i want to write up a little news article about the conference for the website
<mdz> mako: that'd be rad
<mako> i figured it might be good to sort of say something about how we want people to interact with teh specs
<mdz> agreed
<mako> what do you think?
<mdz> they should feel free to add comments at the bottom, but should not modify the text of the spec without contacting the lead or second
<mako> ok, sounds good
<mdz> unfortunately, that's extremely non-trivial in the current format
<mdz> unless you happen to know everyone's email address off the top of your head
<mako> hmm
<mako> yeah
<mdz> I tried to argue that we should use "Lead: SomePerson" rather than "SomePersonLead"
<jammcq> hey mako
<mako> jammcq: hey dude
<mdz> thom: ping?
<HiddenWolf> Will there be a posting to -devel once breezy would be somewhat stable-ish?
<tseng> there will be a post when there is an array release
<tseng> or whatever it is called this time
<HiddenWolf> It's just with all that toolchain stuff, I'd like to have a heads up that it's probably ok before I try and wreck my system. :)
<tseng> its going to get worse before it gets better
<HiddenWolf> Was afraid you'd say that.
<HiddenWolf> I just made the mistake of getting myself worked up and exited over the wiki plans. :P
<tseng> theres nothing excitingly new to be had in breezy anyway
<tseng> so far
<HiddenWolf> nohar, but then at least I can blame something that doesn't work on running a devel distro, and bug people about it. :)
<HiddenWolf> -har
<tseng> ugh
<HiddenWolf> there are one or two things in hoary I find really annoying, so i'll switch as soon as possible. :)
<dilinger> waah
<dilinger> i found a nice index of a bunch of (music) shows happening around nyc
<dilinger> then the site broke
<jordi> mako: I hope this will teach you a lesson.
<mako> jordi: ?
<jordi> mako: oskuro.net :)
<mako> what bout it?
<jordi> latest blog entry
<mako> BASTARD
<jordi> ha ha
<mako> how do i say bastard in catalan?
<mako> sorry, VALENCIAN?
<jordi> Bastard!
<mako> Bastard!
<jordi> you pronounced  that like english
<jordi> you need to say it fast, remember
<jordi> "M'agrada el caf"
<mako> Bstrd!
<jordi> better!
<jordi> anyway, heading to ebed
<mako> jordi: how is the conference?
<jordi> it's going well
<jordi> people are actually not bashing LliureX that much
<dilinger> s
<mako> always a plus, i guess :)
<sto> jordi: go to sleep
<tseng> oh man
<tseng> http://osnews.com/comment.php?news_id=10515
<tseng> "ubuntu backports!!!ONE"
<mako> oh man
<tseng> im afraid to even try to clear that up
<zul> heh...redirect backports.ubuntuforums.org to 127.0.0.1
<zul> or that could be a bit extreme
<jordi> sto: totally
* lamont back in a while
<jammcq> hmm, anybody craving Mentos ?
<tseng> not at all
<zul> hell no
<dilinger> i was tempted to stuff my suitcase full of 'em
* infinity has the shakes from Mentos withdrawal still.
<dilinger> but i probably would've had to declare them or something
<jbailey> "crack"
<infinity> "I declare that these are faaaantastic!"
<jbailey> "weapons of mass destruction"
<dilinger> and who knows what customs would do to a guy packing aussie mentos.  i mean, they're even vegan.  if that doesn't scream out "terrorist"..
<jbailey> "dangerous projectiles"
<dilinger> :)
<ajmitch_> as long as you don't carry them on the plane
<jdub> you wouldn't get them past customs
<tseng> jdub: hah-hah
<tseng> jdub: customs are a bunch of softies
<tseng> i still had some food in my bag i forgot to throw out
<jdub> with a small amount of dishwasher glass cleansing fluid, you can turn a pile of mentos into a substantial explosive
<infinity> <blink>
<jbailey> mdz: No, although I have the test system all setup and am reproducing the problem.  md looks like he fixed the problem once a rev or two ago, and it's broken again.  I expect to have it nailed tomorrow.
* jbailey runs off for the night.
<mdz> why do people randomly add the 'branding' keyword to bug reports?
<stuNNed> what's it mean?
* stuNNed is lost with this developer euphanisms
<tseng> the most obvious form of branding is adding an ubuntu logo to something
<tseng> less obvious is changing a config file to point to our mirror instead of debians
<mdz> stuNNed: it is meant to be used for issues with Ubuntu branding of the distribution (e.g., the boot logo on the CD being Ubuntu's rather than Debian's)
<mdz> a very small proportion of bugs have to do with branding, but many bug submitters seem to add the keyword, perhaps unintentionally somehow
<jiyuu0> how to check whether installed ubuntu is x86?
<tseng> in a package, or in general?
<jiyuu0> in general
<tseng> cat /proc/cpuinfo
<jdub> tseng: 1.1.7!
<tseng> jdub: yes!
<jdub> ha ha ha
<jdub>    * I/O Layer rewrite for ludicrous speed
<jdub> ha ha ha
<tseng> its so true
<tseng> muine loaded my albums at warp speed
<jiyuu0> cat /proc/cpuinfo a lot of things... nearest to get uname -m
<tseng> that works.
<tseng> jdub: also, tomboy now writes notes via telepathy
<jiyuu0> then maybe have to write if statement... if i686 or i586 or i386 = x86
<infinity> jiyuu0 : Erk, no.
<infinity> jiyuu0 : Check out dpkg-architecture
<jiyuu0> infinity, thank
<sladen>   * Engaging Warp Drive
<mdz> jiyuu0: if this is for a script, you want dpkg --print-architecture rather than dpkg-architecture
<jiyuu0> mdz, does it will return i386 on my i686 machine
<tseng> yes.
<jiyuu0> ok... thanks :)
<infinity> dpkg --print-architecture is the same as dpkg-architecture -qDEB_BUILD_GNU_TYPE
<infinity> If you want the dpkg arch (just i386, not i386-linux), 'dpkg-architecture -qDEB_BUILD_ARCH' gives you that.
<infinity> Oh, I lie.
<infinity> That was fixed. :)
<infinity> (That's true in woody... Not in sarge/warty/hoary/breezy, apparently)
<Keybuk> infinity: it isn't
<Keybuk> dpkg --print-architecture is the same as DEB_BUILD_ARCH though
<infinity> Keybuk : Right, but it used to be DEB_BUILD_GNU_TYPE
<infinity> Keybuk : At least, it is on the woody box I was just sitting at.
<Keybuk> that was probably broken :)
<Keybuk> syndicate scott% dpkg-architecture -qDEB_BUILD_GNU_TYPE
<Keybuk> i386-linux-gnu
<infinity> Yes, it was definitely broken in the past.
<infinity> And had I not been typing in a horribly thinking-out-loudish fashion up there, I probably would have been more clear about that. :)
<jsg> good morning
<mdz> Keybuk: a lot of people seem to use your signkey script to send out keys that they have already signed
<Keybuk> heh, those people are stupid
<jdub> lots of people i've never shown my passport to have signed my key
<jdub> that said
<jdub> i think we should put some better gpg tools in ubuntu
<mdz> people who don't even know what I look like have signed my key
<tseng> jdub: seahorse now has keyserver support
<jdub> supposedly seahorse is getting better
<tseng> we just need an update
<jdub> thinking more about workflow tho
<tseng> yes
<tseng> alot of people were very confused
<tseng> its hardly obvious
* infinity golfclaps for Eric Harrison, who signed my key with a key that expired in 2003.
<dholbach> good night
<Unfrgiven> dholbach: hey
<Unfrgiven> hi all :)
<Unfrgiven> im just holidaying in new zealand and thought I'd say hi
<Unfrgiven> :)
<ajmitch_> Unfrgiven: enjoying it?
<Unfrgiven> ajmitch_: yeah very much so
<Unfrgiven> ajmitch_: just heading out now...
<ajmitch_> where in NZ are you?
<Unfrgiven> auckland
<ajmitch_> ok
<Unfrgiven> will catch up with you all when i return on sunday
<Unfrgiven> cyas
<ajmitch_> call in if you're visiting dunedin
<dholbach> bye Unfrgiven 
<Unfrgiven> ajmitch_: unfortunately not this time.. :(
<ajmitch_> alright
<crb> Unfrgiven: we're having an Ubuntu installfest in Hamilton tomorrow
<jnc> hey gang
<jdub> hrm, how do you tell irssi to stop trying to connect to a server, when you can /disconnect from it?
<jnc> jdub: i figured out how once, but irssi doesn't listen
<jdub> aha!
<jdub> rmreconns
<jdub> that is a silly command name
* jdub smites silly command name
<jnc> i'm in a bit of a bind, i gave 'breezy' a try and now stuff i need to have functioning is now;  it wasn't much of a issue during the hoary preview but now i absolutely must have printing...  how do i go about downgrading?
<jdub> reinstall :)
<jnc> you gotta be joking, no?
<jdub> nup
<jsgotangco> hey
<jdub> you could downgrade a single package
<jnc> it's dpkg.   can't i do a downgrade?
<jdub> but attempting to downgrade the entire system is a total waste of time
<jnc> oh geeze
<schweeb> it's not very fun
<schweeb> not at all
<jdub> does printing not work in breezy?
<jnc> i think there are perl locale issues on the backend filters that are freaking out
<schweeb> lots of manual comparison of versions and dpkg -i'ing packages
<jnc> amongst other things
<jnc> basically the two things i didn't realize i absolutely needed, i now realize i need them
<jnc> printing, and gnucash
<jnc> gnucash is obviously not supported (though it *should be!!!*)
<jsg> awww
<jnc> i can always move my gnucash files to another box and do it that way
<jnc> the printing...  i'd really like to resolve what is breaking
<jnc> any devs w/ breezy confirm one way or the other if printing works for them?
<jsg> i haven't upgraded to breezy yet
<jnc> since the backend filters being broken, there's not much hope of me printing remotely to a cups server that works
<jsg> after i finish some stuff with kubuntu
<jnc> ah
<jdub> i should turn on my printer or something
<calc> how come the hwdb site hasn't generated daily stats since apr 12?
<jnc> well, on a positive note 
<jnc> the new kernel in breezy fixes a longstanding bug with my usb keyboard not being picked up on boot time when plugged into a hub
<jnc> i might end up reinstalling :/
<jsg> brb lunch
* jsg is away: Away at the moment
<ajmitch_> crb: sounds good, how many are you expecting to turn up?
* calc assumes someone is fixing the hwdb site since it is now down
<calc> doesn't resolve dns either oddly enough
<calc> hmm perhaps its just me that is hosed
<calc> seems i can't resolve anything gar
* calc kicks his modem
<calc> ah it works now
<calc> kicking works good :)
<calc> hwdb still isn't updating but it shows the old out of date pages
<schweeb> calc: yell at ogra
<calc> ogra: yelling at you now
<calc> ogra: fix the hwdb.u.c cron jobs/scripts they have been broken since Apr 12
* jsgAway is back.
<mako> someone should send information on ubuntu to editors@linux.com
<jsg> ok i noticed we're not on the distributions page of their site
<mako> jsg: cut and paste some text from the website or something.. i dunno
<jsg> mako: ok i'll do it you lazy bones
<mako> i just got an email from info@ and would love to mark it as done? you want to take it?
<jsg> sure
<mako> :)
<jsg> dude, do we have hi-res images of the logo and stuff
<jdub> jsg: svg versions on the artwork page
<mako> as hi-REZ As you want em baby
<jsg> jdub: was wondering about the artwork from the hoary pressed discs
<Lathiat> svg rocks
<jdub> jsg: oh. no.
<jsg> jdub: to be used for conference flyers hopefully...we got some on draft atm
<mako> jdub: do you have that at all?
<mako> jdub: i don't
<mako> someone asked about artwork for people who are burning their own DVDs/etc
<jdub> i don't have that artwork
<jdub> we were going to do alternative artwork for that
<jdub> i will ping jane about it
<mako> cool
<jdub> i said 'that' a lot up there
<jdub> mako: dude!
<jdub> mako: did you see? i posted to ubuntu-news!
<mako> who should i sent OOo stuff to?
<mako> jdub: AWESOME
<jsg> nice poll
<jdub> i was very excited to post to -news
<mako> i'm very excited that SOMEONE ELSE posted to news
<mako> not the ALL MAKO ALL THE TIME channel
<jsg> HEHE
<ajmitch_> hey, I did see a dholbach post there once..
<dilinger> makoTV
<mako> dilinger: unrated
<mako> rated U for UTILIKILT
<dilinger> wholly unsuitable for minors and pregnant women
<dilinger> haha
<jdub> wholly unsuitable for minors, miners and mynahs
<jsg> mynah the bird?
<jdub> as demonstrated at the recent UbuntuDownUnder conference
<jdub> yeah
<jdub> they flew away pretty fast when mako turned up without pants
<jsg> haha
<Lathiat> jdub: http://www.nopantsday.com
<HrdwrBoB> I thought it was everyday?
<jdub> it is today
<dilinger> jdub: should've gone to
<dilinger> http://www.acm.rpi.edu/~dilinger/sloth/pics/2005_udu/IMG_0289.JPG
<jdub> HrdwrBoB: dude, it's like christmas
<mako> today was nopantsday
<jdub> HrdwrBoB: some people are christians all the time, some people are christians on one day a year
<mako> damn
<HrdwrBoB> ahhhh :)
<mpt> jdub: s/Christians/Irish/ also works
<crb> I'd like to see jdub and/or mako on Talk Like A Pirate Day
<jdub> dilinger: so the weird thing is
<ajmitch_> crb: they're bad enough every other day
<jdub> dilinger: pretty much all my friends from overseas take a picture of that and say "ha ha, pants!"
<jsg> Talk Like a Pirate day..hehehe i've seen that
<jdub> dilinger: but it's just a regular chain store here ;)
<dilinger> jdub: dude, i saw it and thought "jdub"
<HrdwrBoB> yeah.. it's the .. pants .. store
<jsg> general pants?
<jdub> mmm
<jdub> pants in general
<HrdwrBoB> yeah if you want specific pants you need to go to a different store
<HrdwrBoB> eg: for jeans, you go to Just Jeans
<dilinger> spatula city
<jdub> heh
<jdub> "we make spatulas, and that's all!"
<jsg> mako: SENT
<mako> jsg: you rock dude
* mako hugs jsg 
* jsg wonders who pays for ubuntu technical support at the momemt
<fabbione> morning
<mattcamp> Where can I learn about the tools that are used to build the Ubuntu ISO's?  Are these tools available to developers outside the Ubuntu team?
<crb> I believe the debian 'cd-image' package is the base mattcamp
<crb> and Colin Watson has patches on top of that, I forget where
<mattcamp> And for the Live CD?  Mounting the file system from the official Live CD, chrooting, making changes, and cleaning up seems rather error-prone.
<TheMuso> mattcamp: What part seems error prone? It is not that hard to work on the cloop filesystem, if that is the only one you intend to change. You simply need to ensure you don't leave unnecessary data lying around. Have you read the live CD customization howto on the wiki?
<TheMuso> mattcamp: Or have I missed the point entirely?
<mattcamp> Yes, I have looked at that howto.  But if there's a tool that can build a fresh file system for the live CD, given a collection of packages (or better yet, a list of package names and an APT sources list), then I'd think that would be better.
<mattcamp> Is debootstrap used for that?
<TheMuso> mattcamp: Perhaps you could send a mesage to the Ubuntu development list?
<fabbione> doko: what is the reason of disabling gpc on sparc?
<doko> fabbione: http://buildd.debian.org/fetch.php?&pkg=gcc-3.3&ver=1%3A3.3.6-2&arch=sparc&stamp=1115240262&file=log&as=raw
<fabbione> doko: meh...
<pitti> Morning
<ajmitch_> hi pitti 
<mdz> fabbione: you're sick too??
<fabbione> mdz: yes.. :/
<fabbione> i am just catching up on emails and i will head to bed pretty soon
<fabbione> the last week is something to forget and whipe away from my history
<fabbione> busted by the tax minister, wife at the hospital, me sick + jetlag
<fabbione> see.. i was right to say we need 15 days conferences...
<Mithrandir> fabbione: ew; wish her well from Karianne and me.
<fabbione> Mithrandir: she is fine.. she just falled down a couple of steps...
<fabbione> and she needed xrays and rest 
<Mithrandir> wish her well anyhow. :)
<fabbione> nothing serious....
<fabbione> i will
<fabbione> :)
<fabbione> next time she will learn to look wth she is walking, instead of thinking to flowers and earrings
<fabbione> or whatever she had in her mind
<jsg> mvo: hi there
<HrdwrBoB> hrm.. if anyone with #ubuntu access is about
<mvo> hey jsg, morning all
<HrdwrBoB> it's required
<thoreauputic> anyone in here with ops for #ubuntu? There's a racist troll in there who needs some attention...
<Mithrandir> fabbione: 08:44 < thoreauputic> anyone in here with ops for #ubuntu? There's a racist troll in there who needs some attention...
<Mithrandir> fabbione: could you handle that before heading for bed?
<thoreauputic> Mithrandir, done, thanks
<Mithrandir> thoreauputic: ok, great
<thoreauputic> fabbione, jdub thanks
<fabbione> sorry.. i had to restart my session
<pitti> Hi ogra 
<Mithrandir> pitti: you might want to look at your #debian-devel window. :)
<ogra> hey pitti
<fabbione> hmmm i386 buildd bustage
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/g/gcc-3.3/3.3.4-5ubuntu1/gcc-3.3_3.3.4-5ubuntu1_20040729-0758-i386-failed
<fabbione> doko: your gcc-3.{3,4} look busted
<fabbione> doko: 3.4 is FTBFS on i386
<fabbione> 3.3 is a chroot problem.. but hey...
<cartman> hmm gcc-4.0 update will come soon I guess
<doko> fabbione: nah, 3.4 is buildd crack, builds fine here. 3.3 is currently building
<doko> lamont: ^^^
<fabbione> doko: with the latest l-k-h?
<mdz> fabbione: you're sick as well?
<fabbione> mdz: yes... i think you missed my reply before
<fabbione> i am heading to bed soon
<fabbione> just finished to catch up on emails
<mdz> fabbione: either you missed me or I missed you
<mdz> fabbione: is it the UDUFlu or something else?
<fabbione> mdz: the latter.. you pinged out...
<fabbione> mdz: it's flu... not sure about UDU
* sladen has just about recovered from it.   ...just in time for a few flights and the chance to pick up another one...
<mdz> doko: is there a newer oo.o2 milestone which can be packaged for breezy?
<Nafallo> morning all
<pitti> Hi Nafallo 
* Nafallo is stressed up today
<Nafallo> wanted to find my school and just typed in the equivalent of "adult education" :-P
<hunger_> Good morning
* fabbione heads to bed
<jsgotangco> jdub, ping?
<jdub> pong
<jsgotangco> jdub, PhilOSC, Sept. 27-29
<jdub> trade show or developer thing?
<jsgotangco> tradeshow target companies and enterprises with some tracks
<jdub> ok, cool
<jdub> thanks!
<jsgotangco> its probably suited for canonical instead of ubuntu community
<jdub> wanna add it to the list on the UbuntuAtConference spec?
<jsgotangco> ill add it but the organizer asked about canonical sponsoring? i can't answer
<jdub> hmm
<jdub> ask them to mail through a request to info@ubuntu.com
<jdub> (unlikely though)
<jsgotangco> ok thought of it as well
<doko> mdz: as soon as g++-4.0 is the default and a newer GCC snapshot is uploaded.
<doko> fabbione: yes, according to lamont, the buildd does have the latest l-k-h as well.
<mdz> doko: are there any remaining prerequisites for g++-4.0 as default?
<abelli> ciao everybody
<abelli> fabbione: dig
<abelli> ..ding
<jsgotangco> abelli, ciao
<doko> yes, an update, then I stop for automatic syncs from unstable, then we can start recompiling the C++ libs
<abelli> jsgotangco: ciao
<pitti> Hi astharot 
<astharot> hi Martin
<astharot> hello everybody
<abelli> astharot: sciao bello
<bob2> jdub: is glib gnome country, lp-wise?
<mvirkkil> sladen: I spammed you with a new version of blotch (bogl bootsplash),
<abelli> pitti: have you got a minut?
<abelli> ..e
<jdub> bob2: either GNOME or GTK+
<pitti> abelli: sure, what's up?
<bob2> jdub: ok!
<abelli> pitti: have you ever heard of tarzan? .. well let's do this in ubuntu-hardened ..
<astharot> ciao abelli :)
<abelli> astharot: ubuntu-hardened anche tu?
<astharot> abelli: nah
<jdub> hrm, the realplayer package doesn't do realplayer 10
<abelli> ogra: ciao
<thom> mdz: ack?
<jdub> yo thom
<mdz> thom: how are you feeling?
<thom> g'morning
<thom> mdz: great!
<ogra> morning
<pitti> Hi tho
<pitti> m
<jsgotangco> hello guys
<thom> hey pitti. how are you feeling about new utopia love? :-) (in other  news, firefox for hoary finished building overnight)
<pitti> thom: I'm still waiting for daniels, we need to sort out some upgrade issues
<pitti> thom: other than that: http://people.ubuntu.com/~pitti/utopia/
<pitti> Hey seb128 
<pitti> thom: I'll update to hal 0.5.1 soon
<seb128> hi pitti 
<seb128> utopia? 
<seb128> ROCK
<seb128> what about new dbus crack?
<thom> pitti: nod, cool
<seb128> (I've uploaded a fixed pyrex yesterday so dbus builds now)
<sladen> mvirkkil: ta
<mvirkkil> sladen: It now has something like usplash-notifier that's non-blocking, instead of using plain echo
<daniels> seb128: *cough*
<seb128> hey daniels :)
<daniels> seb128: next week, when I'm back at work
<seb128> I was not sure, I've not seen you around this week, you are on VAC ?
<Amaranth> hmm, looks like someone 'fixed' the libgda stuff
<pitti> Hey daniels 
<pitti> daniels: no worries, I still need to catch up with security anyway :-)
<seb128> Amaranth: yeah, that's not good?
<daniels> seb128: yeah, I'm on VAC all this week; was in Sydney still until yesterday
<daniels> pitti: hey dude
<pitti> daniels: we need to do a more more changes anyway (regarding proper SONAME-named libraries, etc)
<Amaranth> seb128: well, it's trying to remove libgnome-cil and glade
<seb128> pitti: on this topic, you have mail from this morning (sorry) :p
<daniels> seb128: i'm also going away for the weekend, tomorrow
<daniels> pitti: yeah
<seb128> daniels: k
<seb128> daniels: enjoy your VAC :)
<daniels> cheers :)
<seb128> Amaranth: nothing to do with gda, the transition need to be done
<seb128> Amaranth: don't use breezy if you don't want such changes
<Amaranth> seb128: i need new crack ;)
<Amaranth> i'll just pin the packages
<seb128> Amaranth: ...
<Amaranth> what?
<jsgotangco> brb
<seb128> Amaranth: nm
<hunger> thom: Turning off HT fixes powernowd for me.
<thom> hunger: yes, as you'd expect
<hunger> thom: Yeap, but isen't it nice, when a computer does what is expected for once? ;-)
<dholbach> morning
<aj> :q
<aj> sorry
<pitti> another vim user :-)
<dholbach> hey pitti 
<pitti> Hi dholbach 
<aj> pitti: nvi, technically
<mvo> morning dholbach 
<dholbach> hey mvo
<jsgotangco> hi dholbach, mvo
<seb128> elmo_: can you move libpoppler-glib-dev to main?
<seb128> somebody has an opinion on what is a good choice for a 19" LCD screen? :)
<pitti> seb128: I have an AOC LM919, and am very satisfied with it :-)
* seb128 looks
<jdub> seb128: definitely a desk. it will prefer a desk way more than, say, a window sill.
<Zomb> Err http://security.ubuntu.com hoary-security/main libapr0 2.0.53-5ubuntu5.1
<Zomb>   404 Not Found [IP: 82.211.81.151 80] 
<Zomb> ah, but now
<seb128> pitti: the french websites don't even know about AOC :p
<pitti> seb128: it's a noname brand
<jsgotangco> yeah
<thom> seb128: i have a hitachi
<jsgotangco> pretty good noname brand
<thom> it's great
<pitti> seb128: http://markt.golem.de/14-77e2.html
<pitti> (German, though)
<seb128> is that worth getting one with DVI?
<Mithrandir> samsung and NEC are nice too
<thom> seb128: yes! dvi-d is the only way to run a tft :-)
<seb128> jdub: I don't get what you said, sorry :p
<pitti> seb128: http://www.aoc-europe.com/monitors_lm929.html
<seb128> thanks guy
<pitti> seb128: mine has DVI (you should), but it doesn't make much of a difference with an 80cm VGA cable
<mvo> seb128: I have a benq FP992 and I'm pretty happy with it
<seb128> apparently everybody is happy with his screen, I guess than there is no big differences they are all fine
<dholbach> seb128: that's how it sounded to me as well ;-)
<seb128> I'll pick one with DVI and that should be fine
<Mithrandir> I'm using an acer al1721 at uni, very nice.
<mvo> that's probably because most of us have choosen carefull :)
<seb128> ah ah
<Zomb> hm
<pitti> yeah, it took me three weeks to find a good model
<Zomb> after trying to add Debian archive keys to apt's keyring, I get:
<Zomb> W: GPG error: http://archive.ubuntu.com hoary-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<jsgotangco> ive been using AOC for years its great
<seb128> pitti: it's taking me 3 weeks to decide between all the equivalent ones too :p
<Zomb> gpg -a --keyring `pwd`/trusted.gpg --list-keys | grep Ubuntu
<Zomb> pub  1024D/437D05B5 2004-09-12 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<pitti> seb128: you definitively want a function to tweak zooming (full screen, keep aspect ration, no interpolation)
<pitti> seb128: it's pretty hard to find a monitor that supports that
* netjoined: irc.freenode.net -> orwell.freenode.net
<seb128> oh
<pitti> seb128: if you can't switch off interpolation, then other video modes will look scary
<bob2> oh, cool
<Zomb> however, the sig checks fail only on hoary-updates and breezy files, not on hoary
<bob2> the gpg key thing is known-screwed
<Mithrandir> pitti: why on earth would you run an LCD with a non-native resolution?
<pitti> Mithrandir: to play video games or play videos
<Mithrandir> pitti: games can usually run in 1280x1024 and you can rescale videos just fine.
<pitti> Mithrandir: frozen bubble is a counterexample :-)
<Mithrandir> anyhow, videos should go on the wall. ;)
<pitti> Mithrandir: besides, my computer is not fast enough to play videos/games in 1280x1024
<Mithrandir> pitti: get an AMD64. ;)
<pitti> hehe
<cartman> imagemagick-dev not available on amd64 ?
<cartman> Mithrandir: there is no native amd64 game anyway :(
<cartman> commercially
<Mithrandir> cartman: so?  You can run it just fine in a chroot.
<cartman> too much work and its 32bit ;)
<jsgotangco> im going home bye people
<dholbach> jsgotangco: bye jerome
<pitti> bye jsgotangco 
<cartman> nm my imagemagick q.
<seb128> elmo: gtk-industrial-engine sync please
<elmo> seb128: whine
<elmo> this is one of the cases that makes the sync program cry
<seb128> elmo: what's wrong with it?
<elmo> gtk-engines-industrial | 0.2.36.4ubuntu1 | breezy/universe | amd64, i386, ia64, powerpc, sparc
<elmo> gtk2-engines-industrial | 1:2.6.2-0ubuntu2 |        breezy | amd64, i386, ia64, powerpc, sparc
<elmo> you're asking me to import a new source package called 'gtk-engines-industrial' which is in universe.  it's trying to build a package 'gtk2-enginges-industrial' which is in main
<elmo> that violates sync program's constraints
<seb128> elmo: hum
<seb128> gtk2-engines (1:2.6.3-1ubuntu1) breezy; urgency=low
<seb128>   * Sync with Debian.
<seb128>   * debian/control.in:
<seb128>     - gtk2-engines-dev is not useful, gtk2-engines-industrial 
<seb128>       and gtk2-engines-smooth have other source.
<seb128> elmo: this version should not build gtk2-engines-industrial, I've changed that yesterday
<elmo> err
<pitti> astharot: duh, just read your mail about fixing squid; I'm already at it (warty and hoary)
<seb128> elmo: hum, it's seeded somewhere?
<pitti> astharot: please ask me before fixing a main package, to avoid double work
<astharot> ok pitti :)
<elmo> seb128: dude, gtk2-engines-industrial in the archive has a version of 1:2.6.2-0ubuntu2
<elmo> you're asking me to sync 0.2.46.0
<seb128> hum rightr
<seb128> I need to figure what to do, thanks
<elmo> and I need to add a check for that to josie.  somehow.  hum.  not sure I even can
<seb128> elmo: BTW evince still crying and flooding build logs on libpoppler-glib-dev
<seb128> elmo: needs to be moved to main
<mirak> hi
<mirak> do you also have problems with usb in breezy ?
<tseng> mirak: try modprobe sd-mod
<mirak> tseng: this works for mass storage
<tseng> next time use #ubuntu
<mirak> tseng: I have find a fix on google
<mirak> ok
<mirak> my question was more if the usb is generally broken
<mirak> I will ask in ubuntu
<Mithrandir> mirak: it's a know issue, bugs have been filed.
<mirak> I have asked a more general question in #ubuntu, maybe you are on this channel too
* thom sobs at firefox
<elmo> seb128: done
<seb128> thanks
<p0m> Treenaks: I somehow just killed a 30gb drive :|
<Treenaks> p0m: stop throwing them aroudn the room
<p0m> But you have to break them in!
<p0m> How am I going to break them in if they aren't disciplined.
<p0m> At least it wasn't one of the Sata for the raid.
<p0m> I know you guys have probably heard this 9^nE times, but is there any eta on the Hoary CD's from shipit?>
* ogra guesses before breezy is stable....
<p0m> Heh.
<JaneW> Mithrandir: sorry to bother, but I have been unable to get GAIM Jabber to connect at all...
<JaneW> Mithrandir: so I thought I would try another package, I went to the package manager and wanted to select python-2.4-jabber
<JaneW> Mithrandir: but it indicates that it IS already installed. So how do I find it, I can;t see it obviously listed in any menu...
<seb128> JaneW: for jabber you can try gossip
<JaneW> ok...
<Mithrandir> JaneW: python2.4-jabber sounds like a library package to use jabber from python.
* JaneW installs gossip
<JaneW> oic...
<pitti> Riddell: ping
<Mithrandir> JaneW: do you get any kind of errors from gaim?
<JaneW> yes, unauthorised at times, unable to connect other times. But I can;t establish why. From windows I just d/led a package and connected...
<Mithrandir> JaneW: sounds weird. :/
<JaneW> brb trying something...
<Riddell> pitti: hi
<pitti> Riddell: is CAN-2005-0404 any issue for hoary/warty?
<pitti> (although we certainly don't need to support warty universe any more)
<SlackShrike> hi
<Kamion> urg, I can't even work around #10445
<Riddell> pitti: it seems to be considered not a serious problem http://bugs.kde.org/show_bug.cgi?id=96020
<Riddell> pitti: since HTML is off by default I tend to agree
<SlackShrike> I am have a 915P/G Combo A7058IMS, P4 HT and the ubuntu-live don't boot in this machine ?
<SlackShrike> sorry, i don't speak good english
<mvo> Riddell: \sh (in #synaptic) is interessted in working with pyqt and python-apt on some package-managment stuff (just FYI)
<Riddell> mvo: cool, I'll chat with him
<dholbach> see you later
<Kamion> SlackShrike: how far does it get?
<SlackShrike> Kamion: The live-cd don't found the cd-rom .
<Riddell> what's the process for uploading to hoary-updates?
<astharot> pitti: you are just dieing, isn't it? :)
<pitti> astharot: oh, am I? Why? :-)
<astharot> check the mailbox :P
<Kamion> SlackShrike: please file a bug against cdrom-detect, attaching /var/log/syslog and the output of 'lspci' and 'lspci -n'. (You'll need to figure out some way to get those files out of the installer; sorry, that may be difficult.)
<pitti> astharot:  argh, new crack... you are a robot, aren't you?
<astharot> yes sure
<mirak> pcitable is the file where you now wich module match wich device according to is vendor et device id. I am searching the same for usb devices
<pitti> astharot: dude, you really need to become a MOTU
<astharot> I really need to f*ck! :D
<Mithrandir> Kamion: around?
<Kamion> Mithrandir: yes
<Mithrandir> Kamion: do you have any idea what's needed for pterm to support dead keys?
<Mithrandir> it's annoying not being able to type accented characters. 
<Kamion> Mithrandir: I'd start in unix/gtkwin.c:key_event(), but I don't know the specifics.
<Kamion> I think the comment about "requires Unicode faff before even trying" is probably old - there should be enough Unicode infrastructure there now
<Mithrandir> Kamion: hmm, ok, thanks.
<Kamion> but that's about where it would need to go
<Mithrandir> I'll see what I can do, then.
<SlackShrike> Kamion: 1 minute 
<Lathiat> W: GPG error: http://security.ubuntu.com breezy-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
* Lathiat uh
<Lathiat> what causes that to happen?
<Kamion> SlackShrike: no hurry, I've got a bunch of bugs like that
<ogra> YAY
* ogra has a running beagle on amd64
<Mithrandir> ogra: sweet.
<ogra> yeah
<ogra> its still indexing....
<hunger> great, ubuntu-desktop is installable again in breezy. Good work guys!
<Amaranth> is it just me or are packages not actually getting uploaded?
<thom> Amaranth: eh?
<Amaranth> i've got a long list of things that have upgrades available and i get a 404 for all of them
<Amaranth> maybe the mirror is behind?
<thom> horked mirror most likely, yeah
<hunger> Amaranth: I had that too, the problem vanished when I tried again.
<Amaranth> 82.211.81.151
<Amaranth> that's the IP of the mirror, i guess
<Amaranth> heh, now i'm getting GPG errors
<Amaranth> must be in the middle of a mirror
<Lathiat> yeh i got one of those for security to
<Amaranth> i was told that happens when things are updating
<Kamion> hunger: it'll be randomly installable/uninstallable for some time to come; metapackages are like that
<hunger> Kamion: No problem with that for me... I got it installed now;-)
<ogra> :-/
<ogra> beagle doesnt like my 35000 ubuntu-users mails it seems
<Mithrandir> ogra: I wonder how it'll handle my ~600k mails, then.
<ogra> might be caused by the weird source i used... i'll just wait for tsengs package.... f-spot doesnt compile, but tomboy and muine run just great
<Kamion> is MOM running at the moment? I don't seem to have got merge bugs for the last few days, although the merges are there on rookery
<SlackShrike> Kamion: In the live-cd don't have lspci
<Kamion> SlackShrike: oh, it's not in the initrd, drat
<Kamion> never mind then
<Kamion> maybe I should add it to the initrd, although it's quite big when you take pci.lst into account ...
<Nafallo> hi all
<Kamion> MOM> ah, there she goes now
<Nafallo> hmm
<Nafallo> Kamion: care to explain what MOM is/stands for? :-)
<Kamion> Nafallo: merge-o-matic
<Kamion> it's the thing that tells us we need to merge new changes from Debian, and tries to do a lot of the grunt work for us
<Nafallo> Kamion: ahh, I thought it was Masters Of Multiverse first ;-)
<Kamion> in fact I was just confused 'cos many of the installer default bug assignments are incorrect
<Nafallo> Kamion: yepp, I knew about it. I just wasn't smart enough to figure out that it was m-o-m ;-)
<Kamion> elmo: please sync countrychooser from Debian; OK to throw away our branding changes since we aren't actually using it any more
<mvo> to what adress should kde bugs assinged? just to riddell :p ?
<Nafallo> hehe
<pitti> mvo: amu, too
<HrdwrBoB> erm
<HrdwrBoB> nm
<mvo> ping Riddell 
<JaneW> does anyone else have photo's from UDU on-line ?
<Nafallo> JaneW: you're making a wiki for the galleries? :-)
<dholbach> JaneW: i know tseng's, ogra's, Mithrandir's and jblack's apart from yours
<JaneW> dholbach: I have those - in warthogs wiki
<JaneW> do we need them in a public wiki too?
<dholbach> YES! :-)
* dholbach can't read warthogs wiki
<Nafallo> ofcourse :-)
<JaneW> oic
<Nafallo> wiki.ubuntu.com should have them :-)
<Nafallo> they got the mataro sessions :-)
<JaneW> well find me more links then ;)
<JaneW> Naf: ok
<JaneW> sorry about the contracted nick - amused me to do that ;)
<Nafallo> JaneW: *s*
* Nafallo feels he /have/ to get a job for next conference.
<Nafallo> is it decided where it will be yet? :-)
* Treenaks wants to know too, preferably ASAP :)
<Nafallo> ((sweden would be great)) ;-)
<Treenaks> (more "when" than "where" -> need to tell my boss)
<JaneW> Tree - October
<Treenaks> JaneW: cool
<ogra> Nafallo, is it warm in sweden in oct ?
<Nafallo> ogra: nope :-)
<ogra> hmm
<Nafallo> ogra: or... depends on where ;-)
<ogra> south sweden ?
<ogra> *g*
<ogra> far south.....
<Nafallo> ogra: probably warmer than north anyway :-)
<ajmitch_> at least in .se there'd be a better chance of a decent internet connection :)
<ogra> thats true
<dholbach> ajmitch_: haha, exactly :-)
<Nafallo> hmm, I would be willing to investigate sweden's southern part for that purpose :-)
<HrdwrBoB> hrm.. we need to find a way to heat sweden
* JaneW votes for Thailand
<Nafallo> if most "demo-parties" can get dual 1gb/s then we also should be able to ;-)
<Nafallo> JaneW: that isn't far from Australia, is it? ;-)
<srbaker> how do i turn off the "mouse keys" thing?
<JaneW> well it;s much further north
<srbaker> when i hit numbers on my keypad, the mouse cursor moves around
<JaneW> and a shorter flight from everywhere
<JaneW> was 9 hours for us compared to 14 to Sydney
<JaneW> and it's AMAZING
* Nafallo tries to dig up some facts about the weather in "skne" for october ;-)
<mvo> srbaker: system/preferences/keyboard/accessability IIRC
<seb128> elmo: glade-2 sync from debian exp please
<Riddell> mvo: to kubuntu
<Riddell> mvo: link on bugzilla.ubuntu.org front page
<Nafallo> hehe, rainy, windy and cold :-)
* thom also votes for thailand
* Nafallo investigates the weather in april instead ;-)
<Nafallo> hmm.
<Nafallo> the same ;-)
<Nafallo> *laughs*
<Nafallo> atleast we got good connections speeds ;-)
<Nafallo> but then again. all the wind cames of the flat landscape.
<Nafallo> maybe stockholm or gothenburg would be better...
<JaneW> ok I added the links I have.
<JaneW> UDU photos can be viewed at : https://www.ubuntulinux.org/wiki/UbuntuDownUnder
<dholbach> JaneW: you rock! :-)
<dilinger> nice
<Nafallo> JaneW: great! thanks :-)
<ogra> yeah
* JaneW takes a bow
<ajmitch_> thanks, JaneW :)
<srbaker> huh?
<srbaker> whoops
* pitti -> lunch
<seb128> pitti: that's not a time for lunch dude :)
<seb128> you should have a "take a lunch" like the "take a break" stuff :)
<pitti> seb128: any time I'm hungry is a good time for lunch :-)
<seb128> ah ah
<Nafallo> hehe
<Kamion> elmo: please sync rootskel 1.14 from incoming; OK to discard Ubuntu changes
<thom> pitti: do you have CVEs for our bugs 9926 through 9928
<zyga> hellol
<zyga> could dbus be used to notify other programs that network status has changed?
<thom> zyga: yes, networkmanager already has code to do it
<zyga> thom: networkmanager?
<zyga> thom: network-admin?
<thom> networkmanager
<thom> zyga: http://people.redhat.com/dcbw/NetworkManager/
<zyga> thom: many thanks
<thom> zyga: (http://verbum.org/blog/freesoftware/dialog-war)
* mvo needs to go to town for a bit, bbl 
<dholbach> bye mvo
<zyga> thom: am I right that ubuntu doesn't have this packaged?
<thom> zyga: people.ubuntu.com/~thom/netowrk-manager/
<Lathiat> looks like one of the security mirrors is out of date
<dholbach> bbl
<Lathiat> had to try about 5 time to get tcpdump last 3 times i tried
<zyga> thom: where can I find your gpg key?
<Lathiat> zyga: ubuntu keyring?
<zyga> thom: NetworkManagerNotification: error while loading shared libraries: libgnutls.so.10: cannot open shared object file: No such file or directory
<zyga> thom: I've got -11 though
<wasabi_> zyga, i have a test implementation that works done.
* wasabi_ will throw it at mvo today
<zyga> wasabi_: cool
<zul> heyu
<zyga> hmm
<zyga> does anyone uses powernowd on amd laptop?
<zyga> powernowd: PowerNow Daemon v0.95, (c) 2003-2005 John Clemens
<zyga> ncpus is not a multiple of threads_per_core!
<zyga> cd /sys/
<zyga> ls
<ogra> zyga, i do
<zyga> ogra: did you notice powernowd stopped working recently?
<ogra> nope
<ogra> else my laptop would burn
<ogra> be sure i'd recognize it :)
<Keybuk> powernowd works for me
<Keybuk> even if something's busticated in the kernel thermal department
<Keybuk> the latest kernel seems keen on decided my laptop is overheating, when it isn't
<zyga> strange
<zyga> it suddenly stopped working 
<zyga> powernowd doesn't start at all (message avove)
<Keybuk> May  6 01:02:02 localhost kernel: Critical temperature reached (112 C), shutting down.
<Keybuk> May  6 01:02:02 localhost kernel: Critical temperature reached (54 C), shutting
<Keybuk> down.
<Keybuk> 54 C _isn't_ a critical temperature (103 C is the critical point)
<Keybuk> and the temperature was never 112 C
<zyga> I've just installed cpufreq 
<zyga> if it can keep my laptop at lowest possible frequency at all times I'll use that instead ;-)
<zyga> cool it works ;-)
<zyga> my laptop is a very crappy model and is hot as hell even on 798Mhz 
<zyga> maybe the GPU has something to do with it (i believe it's right under my left hand)
<pitti> Keybuk: was that the reason for the sudden shutdown at UDU?
<Keybuk> pitti: yeah
<pitti> Keybuk: so at least you found the reason :-) 
<Keybuk> it seems to randomly get the temperature wrong
<zyga> BTW: does any gpu support 'power saving mode'?
<seb128> pffiou, this one iz not gtk bog
<seb128> ;)
<pitti> no, gnome this time
<Keybuk> so is
* pitti ducks
* seb128 *pan*
<jnc> please, take pity on me.  http://pastebin.com/280448
<jnc> what is broken?    is it perl?
<jnc> this is a breezy upgrade from hoary
<jnc> a few things have broken that work again once i reinstall the packages
<jnc> so i would like to know a 2nd opinion on what may be broken here
<jnc> then i may try to re-install it and see if that helps
<Keybuk> breezy is broken
<Lathiat> if you want stuff to work, don't run breezy.
<jnc> so...  you aren't interested in finding out what is broke and help make it work again?
<jnc> this is much different from gentoo :/
<jnc> i'm used to saying "here, something is broke, i don't know what it is" and at the very least there are people who would take a minute to tell me what's broke and where i might start to go about fixing it
<azeem_> jnc: this is for #ubuntu.  In #ubuntu-devel, you will have to come along with a patch in order for your bug to be discussed
<jnc> azeem_: how can i patch if i'm not sure what's broken?
<jnc> :/
<jnc> sorry to bother you all
<zul> jnc: you can open a bug in bugzillaq
<jnc> zul: i'm not sure it's even a bug
<SlackShrike> Kamion: Hi
<SlackShrike> Kamion: I am testing the new debian-installer and it detected the cd-rom
<thom> zyga: shrug, it needs recompiling
* zyga hates python indenting 
<wasabi> i like it
<wasabi> probably just because i got used to it
<zyga> wasabi: how do you deal with different indent settings for vim?
* zyga goes away
<pitti> zyga: I have "autocmd FileType python :set smartindent cinwords=if,elif,else,for,while,try,except,finally,def,class"
<jnc> uhh..   i figured out a way to make printing function sort of
<jnc> gs-gpl is fubar'd in amd64/breezy
<jnc> gs-esp will make things output to the printer, but it has that SetLineDash error i thought we'd fixed in hoary
<robtaylor_> are there any instructions on using casper from scratch anywhere?
<jnc> so i'm kind of confused now
<wasabi> I don't use vim
<Kamion> SlackShrike: thank you for amazingly usefully quitting
<Kamion> mutter. I imagine it's a hotplug thing.
<zyga> pitti: wow :-)
<zyga> pitti: many many thanks :)
<stockhol1> Kamion: lol
<zyga> wasabi: I'm addicted
<pitti> zyga: you're welcome :-)
<JaneW> bye all
<JaneW> have a great week-end
<thom> cya jane
* Mithrandir fixes the ooo-amd64-can't-print-la-la-la bug.
<JaneW> *wave*
<pitti> bye JaneW 
<Simira> Mithrandir: don't you have an assignment to fix?
<zul> heh..burn
<Mithrandir> Simira: I do, but I can't do that all the time. ;)
<Simira> Mithrandir: why not? Are you still building gcc?
<Mithrandir> Simira: no, I'm just trying to avoid doing it.
<Simira> Mithrandir: that won't get you far, right?
<Mithrandir> true
* Mithrandir hushes Simira back into her game again
* Simira pushes Mithrandir friendly into his assignment
<jnc> Mithrandir: O_O
<jnc> :)
<jnc> Mithrandir: btw i found out something in breezy for amd64 that might be interesting to you
<jnc> /dev/usb/lp0 defaults to root:root 660 perms
<Mithrandir> jnc: let me hear
<Mithrandir> probably just some udev sillyness; I doubt it's amd64 specific.
<jnc> aye
<jnc> also, gs-gpl is fubar.  i can't be more specific than that, as i am not able to concentrate on that sort of thing
<Mithrandir> I'm not sure what's going on with udev ATM, but it seems to need some love.
<jnc> gs-esp version from bug 8121
<jnc> works fine
<jnc> Mithrandir: the OOo amd64 thing is bug #6762  FYI (you probably already have it open though)
<Mithrandir> jnc: yup, I know
<Mithrandir> jnc: can you verify that the new package fixes the problem for you? http://err.no/tmp/ia32-libs-gtk_4_amd64.deb
<jnc> Mithrandir: i have to run, i'm late for a meeting.   i will verify later;  thank you very much,  but i really do have to run
<Mithrandir> ok
<Mithrandir> anybody else with an amd64 around who could verify?
<Amaranth> Mithrandir: /dev/usb/lp0 is like that on x86 too
<Mithrandir> Amaranth: yeah, as I said: probably udev bug.
<Amaranth> Mithrandir: Yeah, just confirming
<Mithrandir> ah, sure
<Riddell> lamont: what happens with packages uploaded to hoary-updates?  I see no build logs
<mdz> morning
<pitti> Hi mdz 
<thom> morning mdz
<Lathiat> Riddell: one would assume they have to be approved by someone
<mirak> when I compile a module, do I need to use the SAME compiler than the Kernel was compiled with ?
<Lathiat> mirak: yes
<Lathiat> mirak: if your running breezy, then temporarily replace /usr/bin/gcc with a symlink to gcc-3.3 (rather than gcc-4.0)
<doko> Mithrandir, mdz: do we have a policy for hoary-updates? ia32-libs-gtk to fix #6762 would be a candidate, local change, no other package affected
<mirak> Lathiat: I have done that, it's ok now
<Mithrandir> doko: I would be fine with pushing it in after it has stayed in breezy for a little while.
<mirak> I am proud I guessed it ;)
<Lathiat> )
<Lathiat> :), rather
<Mithrandir> doko: are you planning on doing any binutils uploads in the near future?  If so, I'd love to see http://sources.redhat.com/ml/binutils/2004-09/msg00299.html go in.
<elmo> please don't blindly apply h.j.lu patches
<elmo> (I realise that was ACKed, I mean in General)
<Taliesin`> hmmm
<Taliesin`> fresh updates to the debian mirrors
<Mithrandir> elmo: yes, you've said so before. :)  This one fixes a very, very confusing error and has been in for half a year so I guess it's mostly sane, though. :)
<Lathiat> h.j.lu?
<doko> elmo: will you fix #8970, or should I prepare an upload?
<mdz> doko: I agree with Mithrandir; let's allow it some time in Breezy first
<elmo> doko: I don't have time for maintenance of ubuntu packages, please don't wait for me on "my packages" (i.e. ones I maintain in Debian)
<doko> ok, any reason not to upload 2.16, did you contact drow about it?
<doko> elmo: ^^^
<elmo> to Ubuntu?  not particularly.  in Debian, binutils is very much frozen
<elmo> no need to contact drow, AFAICS
<Kamion> could probably go to experimental?
<Kamion> although a little risky given how people like to install newest crack of everything on development boxes
<elmo> right
<doko> heh, that's what experimental is for ... 
<elmo> I probably will upload it to experimental eventually, but AFAIC there's no great rush
<doko> elmo: ok, I'll package it, provide packages for review and testing first.
<elmo> there's a reason binutils is on a slow release schedule, it's changes aren't usually very interesting
<elmo> doko: k
<mirak> crap
<mirak> I can't insert it now !
<mirak> WARNING: Error inserting i2c_algo_usb (/lib/modules/2.6.10-5-386/kernel/drivers/usb/media/i2c-algo-usb.ko): Invalid module format
<mirak> FATAL: Error inserting usbvision (/lib/modules/2.6.10-5-386/kernel/drivers/usb/media/usbvision.ko): Invalid module format
<mirak> mm wrong cannel
<Kamion> elmo: did you catch my rootskel sync request?
<wasabi> So I was thinking. Is there support in apt-secure now for tracking package upgrades between keys? For instance, if a package is updated it should only be allowed to be updated by a package that is signed by the same key?
<elmo> wasabi: apt's authentication isn't that granular
<elmo> oh, well, I suppose it kind of is
<wasabi> Could it be made so? I'm thinking of a situation for ISVs
<wasabi> Where an ISV would provide a repository to track upgrades for their own software, which isn't allowed to replace, say, bash.
<Kamion> wasabi: it would probably be easier to think about it on a per-repository basis rather than per-package
<mirak> question, what compiler is used to compile ubuntu x86 kernels ?
<Lathiat> mirak: gcc-3.3 atm
<mirak> ok so I compiled with 3.4 and it failed
<mirak> can this be the cause ?
<Lathiat> yes
<Lathiat> you want to make it 3.3
<Kamion> that's why it's built with 3.3
<wasabi> Kamion, yeah, you see my point though.
<mirak> erf
<Lathiat> if you read dmesg, it will tell you that you need to build it with the same gcc version
<Kamion> wasabi: yeah. AFAIK there's no code at all for that kind of thing though.
<doko> elmo: fabbione wanted you to build a ppc64 kernel on davis. that one is needed to build and test the gcc biarch. that means, that we need the ppc buildd's run a 64bit kernel. how can we go on with this?
<elmo> Kamion: done
<Kamion> you'd have to remember the repository from which a package was installed, and have some mechanism for locking them
<Kamion> elmo: ta
<wasabi> Kamion, yeah, exactly.
<elmo> doko: is the hoary kernel source good enough for ppc64?
<wasabi> Kamion, I was thinking it might be easier to just remember which key a package was installed with.
<wasabi> Which is why I was thinking about it from that angle.
<wasabi> That allows smoother migration from like, ftp to http repositories, etc etc.
<wasabi> cdrom, etc.
<wasabi> An upgrade would only be allowed if the upgrading package was signed by the same key, or the key it was signed by was signed by the old key.
<wasabi> I'm thinking.
<doko> elmo: I don't know, that's a question to fabbione. I'm working on a machine, which runs a 2.6.5 kernel, so it should ...
<Kamion> wasabi: I think that's probably harder, especially for key rollovers
<Kamion> apt doesn't really handle rollovers particularly usefully at the moment AFAIK
<mdz> wasabi: there's even less code for that
<doko> is lamont around today?
<lamont> doko: yeah
<wasabi> Kamion, well, I put together my idea yesterday. User-wise, it works pretty well. Obviously it has to be secure to be useful though. Are your concerns written down anywhere I can read?
<bluefoxicy> Mem:    906660k total,   597720k used,   308940k free,   122648k buffers
<bluefoxicy> I have a gig and a quart of ram.  :(
<Kamion> wasabi: doubt it
<bluefoxicy> this is on the livecd though.
<bluefoxicy> Every time I cry kernel config error though the kernel team is like "we got that already" so I wanna make sure
<wasabi> Kamion, is it too long for you to outline here? :)
<bluefoxicy> the ubuntu kernel doesn't support large memory?  I was sure it did. . . . . .
<Kamion> the 386 kernel doesn't do highmem
<Kamion> the other configs do
<bluefoxicy> oh.  So my 686 kernel will.  :)
* bluefoxicy is copying to a new sata disk  :)
<Kamion> wasabi: maybe some other time
<koke> elmo: ping?
<elmo> koke: ?
<koke> do you know if I can already upload? :)
<elmo> koke: is your key signed?
<koke> yeah
<elmo> ok, I'll do it in the next batch then, I'll reply to your mail when it's done
<koke> ok, thanks
<Lathiat> ugh, who is jeff baily
<wasabi> haha
<Lathiat> linux-kernel-headers is broken due to the attempt at x86/x86-64 setup. :)
<thom> Lathiat: jbailey
<Lathiat> cheers
* Lathiat just files a bug
<zul> hey jbailey 
<Lathiat> speak of the devil
<Lathiat> oh well i filed it as a bug now.
<Nafallo> Lathiat: signed it to "the devil"? ;-)
* Lathiat grin
<jbailey> Heya Chuck (and everyone)
<seb128> what package is to blame for #8518: writing which seems to work on an usbkey with a readonly switch ... linux ?
<pitti> sounds like a missing kernel feature :-)
<seb128> k, I reassigning on linux :)
<zul> meh..
<zerokarmaleft> tseng, ping
<Kamion> hm, a simple incremental make in a glibc build tree takes quite a while ...
<elmo> glibc's the poster child for 'when makefiles go bad'
<Kamion> it's the enormous libc_nonshared.a. I suppose I could just ctrl-c it
<Kamion> but I'm building on amd64, it's never going to be *that* bad :)
* Kamion imagines a b-movie: "when makefiles attack"
<Kamion> jbailey: (if you're working on #10445, let me know, as otherwise I'm trying to pick my way through _nl_find_locale() now ...)
<jbailey> Kamion: I haven't started on that one yet.
<Kamion> ok, since it's blocking me I've started to try and understand it
<jbailey> I'd like to finish the udev permissions bug first - I can dive in after and look with you.
<Kamion> ok, sounds good; I'll see how far I get in the meantime
<pitti> bye folks, nice weekend for everybody!
<Nafallo> pitti: see ya!
<Nafallo> zul: you should probably update the rt2x00 driver ;-)
<zul> meh...its a first run
<Nafallo> zul: one of the developers cards stopped working and he removed everything eeprom and reduced the txpower choices :-P.
<zul> ah...well ill have a look at it this weekend if i have time
<Nafallo> zul: :-)
<Nafallo> the timespec for that driver was beta in january if I remember correctly.
<Nafallo> we might want to play safe and import rt2400 and rt2500 til rt2x00 is more mature.
<zul> send me the info
<zul> zulcss@gmail.com
<zul> im at work right now
<Nafallo> zul: k
<doko> elmo: please could you update / create a breezy-i386 chroot on concordia? I'd like to check for the gcc-3.4 build failure. the build suceeds on my local machine.
<elmo> Unpacking replacement linux-kernel-headers ...
<elmo> dpkg: error processing /var/cache/apt/archives/linux-kernel-headers_2.6.11.2-0ubuntu4_i386.deb (--unpack):
<elmo>  trying to overwrite `/usr/include/asm/bootsetup.h', which is also in package amd64-libs-dev
<elmo> ^-- doko/jbailey: someone
<jbailey> elmo: Yeah.  Scott gave me the hint for fixing that at the end of yesterday.  I haven't done the upload yet.
<doko> hmm, yes, there's an override missing. maybe install amd64-libs-dev first
<jbailey> elmo: Can work around it by uninstalling amd64-libs, updating linux-kernel-headers, and then installing the new amd64-libs
<jbailey> elmo: Evil stuff having to do with replaces, conflits and diverts.
<elmo> yeah
<elmo> thanks
<Lathiat> theres also some breakage in the new kernel headers wrt to __u64 and strict ansi mode
<Lathiat> (-std=c99)
<elmo> uh, WTF
<elmo> DOKO
<elmo> GOD DAMN IT, STOP BYHAND SYNCING
<doko> which package?
<elmo> bison
<elmo> which btw doesn't even bloody install
<doko> hmm, where's the problem? it did work fine for me.
<elmo> bison-doc is overwriting files in bison
<Kamion> jbailey: hmm. Appears that the LC_* files in rootskel-locale are triggering the "Bad data file" check in _nl_intern_locale_data() (nice of it to give a useful error message, NOT). I'm digging further.
<Lathiat> bison, bison-doc install fine here
<Kamion> it's all a bit WTF because those files were generated by localedef, I think from the same glibc
<doko> thanks, adding a Replaces: bison (<< 2.0)
<Kamion> ... oh. they changed the locale data file magic number. that might have something to do with it
<Kamion> and my data files were powerpc
<Kamion> (so different endianness on top of that)
<jbailey> Kamion: Ah.  I haven't looked at rootskel much before, does it fiddle with glibc's data files directly
<Kamion> lamont: please requeue debian-installer; now that rootskel's been built successfully on breezy, it should build fine
<Kamion> jbailey: it uses localedef, and the locale format's changed
<mako> jbailey: hey dude, there were a bunch of people wanting to be added to the marketplace that i didn't see answered.. you still gonna get to those?
<jbailey> mako: I was chewing through them yesterday.
<jbailey> mako: I'm about half done.
<mako> jbailey: cool
<mako> jbailey: are you replying to them as you do it?
<jbailey> mako: I'm batching the replies, I'm not home, and I don't currently have outbound SMTP access except through a series of ssh hops.
<thom> elmo: presumably, when katie says installing to main on a hoary-security upload it doesn't actually mean it
<jbailey> mako: So they'll all go out in one bunch today.
<mako> i just barely got caught up with role mail yesterday :)
<mako> and not including large order confirmation
<mako> which is another (very depressing) story
<mdz> thom: does firefox build with the current breezy toolchain?
<thom> mdz: yes; need to work out what the freeky ftbfs is
<elmo> thom: yes
<thom> elmo: the mail message is mildly terrifying
<lamont> Kamion: done
<doko> mdz: please can we move gnat-4.0 to main? gcc-4.0 uses it as a build dependency
<mdz> doko: ok
<jnc> jbailey: the udev perms bug affects /dev/usb/lp0 perms btw
<jnc> jbailey: that's more FYI in case you hadn't known about it, i'm sure you're on top of things
<jbailey> jnc: I've just uploaded the fix for it.
<jbailey> jnc: Thanks for the heads-up, though. =)
<jnc> jbailey: hooray :)
<Nafallo> jbailey: does that mean my usbkey will be mounted if I upgrade? or are we talking about another bug? :-)
<jbailey> Nafallo: No, the is very narrowly the group permssion applied to the device files for a usb printer created by udev.
<jbailey> #10004 if you want to play along. =)
<jnc> oh wow, i thought it was more broad than just usb printers
<tritium> Was spam filtering discussed at UdU?
<thom> yes
<jbailey> jnc: There may be other problems.  There used to be a file that would go through after and clean up permissions.
<jnc> jbailey: gotcha
<jbailey> jnc: That file isn't used anymore and a different one was created.  In this case, the rule for printers assumed a subsystem of printers.
<tritium> thom, could you point me to any info please?
<jnc> cups isn't too happy with "usb://HP/LaserJet%201012"  instead it likes "usb:/dev/usb/lp0" and had permission denied;  that's what tipped me off to it
<jbailey> jnc: The nice part is now that I understand the new way, fixing any others that come up will be easy.
<thom> tritium: there's a small amount of discussion on http://udu.wiki.ubuntu.com/MailRoadmap
<jnc> jbailey: that sounds useful
<jnc> jbailey: i mean, that the way they're doing it makes sense
<tritium> thom, thank you
<jbailey> tritium: The deal was basically that spam evolves too fast, and until we're prepared to do updates through the lifecycle of a release, there's very little we can usefully do.
<jbailey> tritium: With a side note that spam filtering should happen at smtp receive time, ideally, so that RBLs and whatnot can be applied.
<jnc> ah
<tritium> jbailey, ah, thanks.  Good info...
<Nafallo> jbailey: aha, oki :-).
<jbailey> jnc: Yeah, it's a better separation of permissions from pathnames, but there'll be a bit of work for them to do I think to catch all these cases.
<jnc> jbailey: if i run into any more i'll know how to address it and bring to your attention
<jbailey> jnc: Thanks.  bugzilla is best, I don't know if it assigns udev stuff to me by default or not.
<doko> mdz, Kamion: where should gnat-4.0 be added? it's a build dependency, which should not be listed, but it FTBFS currently, because it's still in universe. So add it temporarily to some seed (supported?), and then remove it again?
<dholbach> byeeeeee
<Nafallo> dholbach: see ya :-)
* hunger mentioned his wifi "roaming" script in InstallPool.
<jnc> uhh
<jnc> where'd mithander go?
<mdz> doko: it doesn't need to be added anywhere
<mdz> doko: elmo just needs to move it in the archive
<mako> has anyone here heard of the "global desktop project"?
<zyga> mako: what is it?
<mako> zyga: that's my question
<zyga> (don't ask me to google, please)
<zyga> ah :-)
<mako> googling isn't really helping
<mako> someone asked me if i know of it
<mako> i don't and google apparently doesn't either. but i wanted to check here first
<zyga> sounds like M$ global controll project ;-)
<zyga> switch to desktop at 53.251.24.18 and open 'finance' folder ;-)
<srbaker> yo
<srbaker> i just installed a new monitor,  program can i run to have it probed again?
<srbaker> the old one was probed perfectly when i installed
#ubuntu-devel 2005-05-15
<mike_douglas> any reason why gksu doesn't automatically default to using sudo-mode?
<Nafallo> mike_douglas: gksudo?
<mike_douglas> Nafallo: well there is gksudo and gksu, why have gksu default to su-mode if there is no default root password?
<Nafallo> mike_douglas: because you can enable root if you like?
<mike_douglas> ah right, duh :P
* robertj comes in particularly cheerful
<mattb> hi
<mattb> just at our local installfest and hacking up a quick package
<Burgundavia> ok
<mattb> wondering how I can add a menu entry to the Gnome Applications menu (or one of it's submenus)?
<zyga> mattb: entry? use .desktop files, menu? probably hack menu config
<zyga> mattb: .menu files ;-)
<Burgundavia> http://www.freedesktop.org/wiki/Standards_2fmenu_2dspec
<zyga> freedesktop.org has the standards, your drive has excelent examples 
<zyga> locate .menu
<zyga> locate .desktop
<mattb> cool
<mattb> lots of new ubuntu installations being created today :)
<zyga> mattb: anything large scale?
<mattb> zyga: we've got maybe 40 people here atm
<mattb> http://www.wlug.org.nz/InstallFest.2005-05-07
<mattb> unfortunately our nice hoary cd's didn't quite make it here in time
<|QuaD->  /join #epiphany
<zyga> mattb: you actually only need one you know ;] 
<zyga> mattb: who comes for such install fests?
<mattb> zyga: lots of weird people 
<mattb> we'll have photos soon
<mattb> we were wanting to send people away with CDs
<mattb> so they could evangelise it to their friends
<zyga> mattb: how weird? and how technicall?
<jdub> tseng: TOMBOY! MUINE!
<tseng> jdub: YES!
<tseng> jdub: NEW ICON
* Nafallo sees CAPS for the second time in this channel today ;-)
<Nafallo> or... today and yesterday :-)
<Nafallo> ...refreshing :-)
<tseng> Nafallo: we're moving the channel to EFNet
<tseng> gotta get in the spirit of things
<Nafallo> tseng: OMG!
<Nafallo> tseng: I hope you're kidding me?!?
<tseng> nope, we decided we werent reaching the 13-17 y/o computer user demographic
<tseng> so we are planning some outreach programs
<dilinger> mako: yea, so, looks like i'll be getting back down to nyc early on sunday
<tseng> Nafallo: yes, im joking.
<Nafallo> tseng: *s* last time I was on efnet was in... 2000 or something :-P.
<mattb> zyga: I'll put some photos up in a second
<Nafallo> mattb: where? :-)
<tseng> jdub: guess whats next?
<Nafallo> tseng: quakenet? ;-)
<tseng> no.. gamesnet
<Nafallo> lol
<tseng> but i actually meant beagle
<Nafallo> tseng: I know :-)
<Nafallo> tseng: want me to build something? ;-)
<tseng> no
<tseng> everything should be building when things on amd64 start clearing dep-wait
<Nafallo> hehe, damn. I'm bored ;-).
<tseng> thanks for your help though
<Nafallo> tseng: np. have been fun :-).
<tseng> jdub: oh jeez, you put a patch in diff.gz
* tseng shuns jdub
<Nafallo> tseng: btw, I've started looking into packages for real now :-).
<tseng> Nafallo: rock on
<tseng> Nafallo: im planning to write a more begininer quickstart doc soon
<Nafallo> tseng: going throw pitti's CVE-list for universe :-)
<tseng> sweet
<Nafallo> tseng: that will rock! :-)
<tseng> im planning to work on that also
<jdub> tseng: package?
<tseng> get on the mailing list
<Nafallo> tseng: that to :-)
<tseng> jdub: beagle
<tseng> jdub: gaim fix
<jdub> ahr
<tseng> hm its in patches/
<tseng> why'd uupdate try to apply it
<jdub> gtk-sharp is ready, etc?
<tseng> yes
<jdub> elite
<Nafallo> tseng: s-r@l.u.c? already there :-).
<Burgundavia> jdub, what is goining into main for breezy?
<tseng> Nafallo: wha?
<Nafallo> <tseng> get on the mailing list
<tseng> Nafallo: ah rock on
<Nafallo> tseng: security-review@l.u.c :-)
<tseng> i got it now
<tseng> just needed a hint
<Nafallo> tseng: *s* :-)
<mattb> Nafallo: the installfest? we're in Hamilton, New Zealand
<Nafallo> mattb: ohh, I thought you were to put the pictures on the web :-)
<dilinger> haha
<dilinger> http://lwn.net/Articles/134945/
<dilinger> what an unfortunate name for a daemon
<tseng> haha
<tseng> did you see the advisory for ethereal?
<Nafallo> lol
<tseng> it has like 30 vulns
<Nafallo> tseng: yay!
<zyga> hehehe
<zyga> :-)
<tseng> yeah we have like 10 sniffers with ethereal at work
* zyga -> sleep
<Nafallo> hmm, universe ;-)
<zyga> c'ya guys 'n' girls
<tseng> Nafallo: yeah dude, i want you to backport every fix in the next hour
<tseng> step on it
<Nafallo> tseng: lol
<Nafallo> tseng: I jump on it tomorrow after my haircut. I will be able to see the screen for once ;-)
<tseng> you have matthew garett disease?
<Nafallo> tseng: didn't follow that one. care to point me to a photo? :-)
* Nafallo curled most of mataro and udu pics ;-)
<eruin> Nafallo: don't cut it too short like I did
<eruin> you want to retain that sweet communist look :/
<tseng> Nafallo: he cut it now, his hackergotchi is pretty shaggy
<Nafallo> eruin: will be something like short on the sides and lot's in the middle ;-)
<Nafallo> tseng: yay! the before and after shoot! almost forgot :-P.
* Nafallo gets his camera
* Nafallo laughs
<Nafallo> hmm
<eruin> http://appelsinjuice.org/img_2620.jpg :i
<eruin> that's before... now it's ... SHORT. :/
* Nafallo admits. he's a psycho ;-).
<tseng> jdub: dude, we totally need to get in a working inotify/gamin combo
<tseng> jdub: there have been much better inotify patches in since hoary uvh
<jdub> yeah
<jdub> zul has been tracking them
<jdub> our first breezy kernel should have them
<jdub> ouch, new evince/poppler combo is slow
<jdub> hrm
<tseng> hm
<jdub> at least when images are used
<tseng> at least beagle is fast
<Nafallo> eruin: hehe, nice pic :-(
<tseng> beagle_0.0.9-0ubuntu1_source.changes is NEW
<jdub> THREE TIMES!
<Nafallo> s/\(/\)/
<jdub> tseng: bonus! :)
<tseng> elmo: beagle is safe to clear new now btw
<Nafallo> lol
<Nafallo> Mithrandir's pics are great! :-)
<jdub> dpkg: warning - unable to delete old file `/usr/share/dotnet/mono/gtk-sharp-2.0': Directory not empty
<jdub> ^ lots of these :)
<tseng> yuck
<tseng> crap
<jdub> http://www.winsupersite.com/reviews/longhorn_5048.asp
<tseng> yeah all the symlinks
<jdub> ^ btw, interesting reading
<tseng> are still in there
<Nafallo> hmm
<Nafallo> I need to get a new laptop :-P
<Nafallo> one our battery max on this one.
<Nafallo> sucks
<tseng> jdub: yep i still alot of crack in /usr/share/dotnet
<tseng> jdub: higher priority is making sure everything works on amd64 as expected atm
<tseng> Nafallo: your job ^ :)
<Nafallo> tseng: I was just about to tell you that :-)
<Nafallo> tseng: I'm going to a work interview the 17:th btw :-)
<tseng> rock on
<Burgundavia> jdub, we have a year and a half to make them look like fools. Not very hard
<Nafallo> tseng: things should turn out that I can go to the next conference in that case! :-)
<tseng> rock on
<tseng> jeez, longhorns photoviewer is a lightyear behind f-spot
<Burgundavia> I saw the some previous screenshots and was very underwelmed
<Burgundavia> "Microsoft says that it is moving away from the "My" naming convention in Explorer" <-- that is interested
<Burgundavia>  /ed/ing
<tseng> yeah, finally
<tseng> My Crackpipe
<Burgundavia> moved by brother from 98 to XP
<Burgundavia> should have heard him bitch
<Burgundavia> about the half-assed mutliuser stuff
* thom sobs. no tomboy amd64 love yet
<tseng> thom: :(
<tseng> thom: some stuff on amd hit build wait
<tseng> er depwait
<thom> yeah, not surprised
<tseng> when i fubared mono
* Nafallo builds gtk-sharp
<thom> i'll just wait impatiently (or go to bed, as a better option)
<Nafallo> tseng: what's next? :-)
<Nafallo> tseng: mono?
<tseng> Nafallo: gecko-sharp*, gtksourceview-sharp*, monodevelop
<tseng> is whats left
<Nafallo> wtf
<tseng> ?
<Nafallo>  -> Considering  libgtk-cil (>= 0.95)
<Nafallo>       Tried versions:
<Nafallo>    -> Does not satisfy version, not trying
<Nafallo> E: Could not satisfy build-dependency.
<Nafallo> E: pbuilder-satisfydepends failed.
<tseng> yeah?
<tseng> i just said
<tseng> its in depwait
<Nafallo> ahh, thought it was left to try and build ;-)
<tseng> gah tomboy ftbfs
<tseng> wth
<jdub> bbq!
<tseng> zomg
<tseng> yeah dave beckett built this source into a binary
<tseng> why cant I
<tseng> http://people.ubuntu.com/~lamont/buildLogs/t/tomboy/0.3.2-4ubuntu1/tomboy_0.3.2-4ubuntu1_20050507-0140-i386-failed
<tseng> jdub: putting beagled and best into my gnome-session startup adds a good whack to the startup time, very noticeable to the user
<jdub> yeah
<Burgundavia> it is beagled, as best alone doesn't seem to do it
<tseng> its certainly beagled
<tseng> but you cant have best w/o it
<Burgundavia> indeed
<bob2> is beagle in breezy yet
<tseng> bob2: in NEW
<tseng> i just uploaded
<bob2> queue/ROCK
<bob2> s'pose I need to find something else to whinge about when it gets approved
<tseng> yeah
<tseng> another shoulder to cry on
<ajmitch_> mattb_: installfest going well then?
<mattb_> yeah
<mattb_> reasonably
<mattb_> prob 30-40 people
<ajmitch_> good to hear
<mattb_> I'll get photos up sometime, too busy fixing other things atm :)
<jdub> GOOD MORNING NEW ZEALAND UBUNTU LOVERS!
<mattb_> afternoon actually :P
<jdub> it is always good morning
<ajmitch_> hey jdub 
<jdub> morning ajmitch_ 
<Nafallo> hehe
<Keybuk> it's always morning in jdubland
<ajmitch_> universal greeting time
<jdub> morning Keybuk 
<Keybuk> morning
<jdub> Keybuk: how's hacking?
<Keybuk> hacking was good, we did good stuff
<Keybuk> today is Saturday though, and we're going to go find kangaroos
<bytee> 11.45am seems morning enough for me
<Nafallo> so does 3:48pm :-)
<mattb_> bytee: we're always ahead of australia here in NZ :)
<bytee> mattb_: oh, thats right
<jdub> Keybuk: when do you fly out? have any time in sydney?
<Keybuk> fly form Canberra at 12:40 tomorrow
<Keybuk> flight from Sydney is at 3:15
<Keybuk> probably only enough time to check in and change flights and stuff :(
<bob2> are they connecting?
<Keybuk> not sure, one is a Qantas dash-8 and the other a British Airways 747
<bob2> you want to join them up
<bob2> or else you have < 1.75 hours to get your stuff to the international terminal
<tseng> that was no problem for me
<Keybuk> that's easy
<Keybuk> I've already confirmed the BA flight and picked my seat and stuff
<tseng> unless you look dodgey like bob2 
<tseng> and get a bunch of hassle from security
<bob2> hey
<bob2> only coming back into the country
<tseng> dude i threw out all my food for nothing coming into au
<tseng> they didnt even check
<tseng> i had some snacks and tea
<bob2> hah
<bob2> last time we cam back from england I brought tea
<bob2> which I declared
<bob2> and they told me was fine
<bob2> so I got through customs quicker than jdub and spiv who had nothing
<Keybuk> yeah, it's often quicker to declare and go through the red one than the green or blue if they're doing security checks
<mattb> Nafallo: photos as promised
<mattb> http://www.wlug.org.nz/~jrm/installfest-2005-05-07/
<mattb> mostly of the setup lsat night
<mattb> but we'll add some of the scary attendees soon :)
<crb> hey, it's mattb. :)
<Nafallo> mattb: :-)
<Nafallo> hmm, we have only two MOTUs? :-P
<tseng> ?
* Nafallo doesn't think he should trust launchpad ;-)
<tseng> what are you looking at
<tseng> im on launchpad
<Nafallo> tseng: you're not a member of team MOTU ;-)
<tseng> oh we;;
<tseng> srbaker:;;:ll:g
<tseng> wtfirssibbq
<Nafallo> ehm...
<tseng> hah sweet
<Burgundavia> archive.u.c just broke for me? can some else confirm this?
<tseng> no
<Burgundavia> gah
<Nafallo> Burgundavia: worksforme(tm)
<Burgundavia> hmm, must be my connection
<Burgundavia> I was getting 400k+, then it died
<Nafallo> hmm
<Nafallo> I should sleep :-P
<Nafallo> 4h or so :-P
<Nafallo> *yawns*
<bluefoxicy> this is going to work right?  I redid my drives, / is now on sata, /dev/sda8 but the kernel can't find it. . . . . (panic at mounting / vfs!)
<bluefoxicy> so I'm reinstalling my kernel?
<ska-fan> bluefoxicy: what's the boot command line?
<bluefoxicy> ska-fan: kernel          /boot/vmlinuz-2.6.10-5-686 root=/dev/sda8 ro quiet splash
<bluefoxicy> I reinstalled the kernel to get a new initrd
<ska-fan> no idea then
<bluefoxicy> well i'll hit it.
<bluefoxicy> if it breaks I'ma come back here and bitch while I google.
<fabbione> morning
<tritium> hi fabbione 
<cartman> gcc 4.0 fails on all arches :(
<Burgundavia> crap, need a #ubuntu op
<Burgundavia> tritium, crimsun, bob2 ?
<Burgundavia> help
<Burgundavia> jdub, mdz, mako ping
<Burgundavia> anybody?
<Burgundavia> fabbione, thnaks
<fabbione> np
<Burgundavia> gah, very frustrating
<dholbach> morning
<Nafallo> morning
<ogra> morning
<bob2> where are the hoary cdimages hiding?
<bob2> http://cdimage.ubuntu.com/releases/5.04/current/ only has dvds
<Nafallo> bob2: releases.ubuntu.com? :-)
<bob2> ah
<fabbione> sparc is installing now...
<fabbione> ops
<dholbach> hey mako: could we announce the cc meeting somewhere?
<dholbach> mako: i want the guys to know when they have to show up
<bob2> dholbach: when is it?
<dholbach> bob2: "tuesday is the day"
<dholbach> that's all i know :-/
<ajmitch_> day after kickoff?
<bob2> hah
<dholbach> morning Mithrandir 
<Mithrandir> hiya Daniel
<ogra> hey Mithrandir 
<Mithrandir> ogra :)
<ogra> :)
<dholbach> :-)
<ajmitch_> hi mvo 
<mvo> hey ajmitch_ 
<mvo> morning all
<ajmitch_> have a good night last night? :)
<dholbach> hey mvo
<mvo> hey dholbach, up so early :p
<dholbach> of course
<dholbach> :-D
<mvo> ajmitch_: yeah, it was fun (we went to a irish pub)
<ajmitch_> mvo: he's been online for at least an hour :)
<ajmitch_> sounds like fun
<zyga> mvo: hey, how's going?
<erich> The Ubuntu Live CD really should have more recovery/repair tools on it. Like dd_rescue, iostat and a few such things...
<thom> good morning
<dholbach> hellas thom!
<ajmitch_> morning thom 
* p0m sneezes
<mvo> morning thom
<mvo> zyga: hey. it goes pretty good, thanks!
<ogra> hey thom 
<dholbach> hey seb128!
<seb128> daniel !!!
<seb128> ;)
<dholbach> wooohooo! :-)
<seb128> wooloomoolooo ? :)
<dholbach> hahaahaa, woolloomooloo was great :-)
<bob2> did you guys get to wollongong?
<dholbach> no... i just smiled everytime i read the name :-)
<seb128> not than I know
<bob2> haha
<p0m> Heh.
<p0m> There's actually a "Whoop Whoop" in the NT.
<bob2> redistributing these disks will be interesting
<p0m> bob2?
<dholbach> hellas doko
<Treenaks> p0m: whoop whoop? home of teh l33t k1dd13z?
<p0m> Treenaks: Heh. Home of nowhere, officially.
<Kamion> woo, debian-installer finally built
<Burgundavia> where do I look for ftfbs source stuff?
<bob2> people.ubuntu.com/~lamont/buildLogs/ or so
<Burgundavia> ok, this is odd
<Burgundavia> devmapper builds http://people.ubuntu.com/~lamont/buildLogs/d/devmapper/2:1.01.00-4ubuntu2/devmapper_2:1.01.00-4ubuntu2_20050504-0111-i386-successful
<Burgundavia> but it is not in breezy
<Burgundavia> http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=libdevmapper1.00&searchon=names&subword=1&version=all&release=all
<bob2> better to check the archive server than that page
<bob2> it's probably only updated once a day or something
<Burgundavia> my machine is saying it is locally installed
<Burgundavia> and I just updated
<Burgundavia> that is what prompted me to check it out
<Burgundavia> well, it built and in archive.u.c
<bob2> there you go
<Burgundavia> and it has made it to my mirror (ca0
<Burgundavia> ah, I see the issue (I think)
<Burgundavia> currently a changeover to a new version 1.0.1
<lifeless> bob2: have we fixed that sparc problem yet ?
<bob2> no
<bob2> no one seems to have any idea
<bob2> aside from "alignment problem"
<bob2> and the code it seems to be in is horrendously hard to debug
<dholbach> grats Kamion! :-)
<Burgundavia> hmm, what to file the bug on
<lifeless> bob2: get me a login somewhere, I'll fix it
<Nafallo> morning all
<bob2> lifeless: the guy who owned the sparc machine I was using turns it off at night
<bob2> I've emailed him to ask him to turn it on in the morning
<lifeless> thanks
<bob2> and I'll email you the account details
<seb128> elmo: evince sync from debian incoming please
<sebest> hello, anyone tryed initng?
<sebest> I modified the script to make it work with ubuntu, and got it booting till gdm
<sebest> But i need to work on having good dependencies between scripts, any advice?
<Nafallo> thom: ping?
<sebest> initng anyone?
<trukulo> sebest: not here
<sebest> trukulo: why?
<trukulo> i don't use it
<sebest> oki
<jdub> tseng: ha ha ha ha
<jdub> tseng: "novelization" ha ha
<tseng> jdub: :)
<dholbach> hey jdub 
* Lathiat wonders how hard it is to write a network plugin in nautilus
<Nafallo> jdub: morning :-)
<jdub> hey everyone
<Nafallo> man... don't you guys hate it when you ssh to your server and then forgets what you should do with it?
<tfheen> get a faster setup?
<robertj> Nafallo: the prope thing then to do is either lsof or do uptime
<Nafallo> robertj: hehe, oki :-)
<robertj> Lathiat: for what?
<Lathiat> robertj: discovering servers
<Lathiat> via mdns-sd
<Nafallo> tfheen: naah, it's fast enough. or did you think about my brain? ;-)
<robertj> I thought mdns-sd was already in for some things
<Lathiat> yeh but it doesn't use the ultra cool fully free (LGPL) avahi mdns-sd library. :)
<robertj> Lathiat: make a chooser clone ;)
<Lathiat> it uses (used? i dunno if it was ripped out) the ugly apple licensed involved code
<robertj> Services on the left, hosts on the right
<Nafallo> firewall-rules...
<robertj> then you can both do everyone a favor and avoid writing a nautilus plugin (well in the short-term ;)
<Lathiat> hmm i wonder what the kernel does if a unix socket path string isnt null termianted
<Lathiat> robertj: oh well i could integrate it into the code rather than writing a plug-in
<Lathiat> schpose i should get the source and look around
<robertj> Lathiat: btw, do you know if there are python or  c# bindings packaged anywhere?
<Lathiat> robertj: to what?
<Lathiat> avahi?
<robertj> to ... forgetting the name...
* robertj smacks himself
<Lathiat> damn cat just refuses not to lie on top of my hand and half of my laptop
<robertj> howl!
<Lathiat> oh, howl
<Lathiat> howl has crappy licensing :)
<Lathiat> but no, i dont think there is
<Lathiat> there might be some c# ones
<robertj> oh, I thought it was clean
<Lathiat> nope
<robertj> what about avahi then
<Lathiat> avahi is clean. :)
<Lathiat> all LGPL
<robertj> in terms of bindings
<Lathiat> and theres no bindings yet, but there will be
<Lathiat> im just getting the C library working nice first
<Lathiat> then i'll tackle others
<jdub> Lathiat: oh, you're hooking up gnome-vfs and avahi?
<Lathiat> rather than write a binding i'll probably implement them natively
<Lathiat> jdub: will be this week i hope
<jdub> elite!
<Lathiat> jdub: so its gnome-vfs i want to tackle and not nautilus as such?
<jdub> yeah
<Lathiat> ah
<robertj> any thoughts on the Chooser UI though?
<Lathiat> robertj: well the idea is just to display http, ftp servers in the network dialog.
<Lathiat> no idea what a chooser ui is
<robertj> Lathiat: MacOS 9 had "Chooser"
<Lathiat> jdub: the engine is pretty much roaring to go
<jdub> Lathiat: mucking with the existing  howl support code shouldn't be too rough
<Lathiat> jdub: still working on the library/daemon 
<robertj> you launched it and on the left you clicked "Laserjet" "AppleShare" "Windows File Sharing" whatever and then on the right, all the hosts popped up
<Lathiat> robertj: oh, right
<robertj> then you double clicked the host and there you were. If it was a printer it added it, if it was a host it popped up a list of shares, etc.
<Lathiat> they should all just show up, you shouldnt nee dto care what protocol you want :)
<robertj> Lathiat: well suppose you are an end user and don't know where the file server is
<Lathiat> robertj: you open network and something called 'File server' should appear, whatever protocol it uses.....
<Nafallo> alternative, choose printer, fileshares and the like.
<robertj> Lathiat: there are like 40 machines serving out files here
<Lathiat> Nafallo: and printers dont show up in the network dialog
<robertj> but only 3 of them are serving out "Windows Files"
<Lathiat> right
<Lathiat> the network dialog actually has a separate 'windows network' section
<robertj> actually about 20 of those 40 machines are juts sharing printers
<Lathiat> (but shows current workgroup ones in the toplevel)
<Nafallo> Lathiat: I refered to the "Laserjet" stuff? those aren't fileshares I hope? :-)
<Lathiat> Nafallo: no, they wont be in the network dialog
<robertj> Nafallo: I think I've explained it poorly
<Lathiat> that would come under gnome-cups-admin
<Lathiat> robertj: i see what your getting at
<Lathiat> robertj: but i dont know any end users that know what protocol their corporate file server speaks :)
<Lathiat> that aside
<robertj> anyway, suffice it say that end users have alot of difficulty with that stuff. Especially considering there is a large chance that what they want IS going to be on the "Windows Network" section because the admin wants to run one file sharing service and that service is either DAV or CIFS
* Lathiat shrugs
<robertj> Lathiat: that's why it should show up "File Sharing" on the left
<robertj> or "Printers"
<Lathiat> right, but thats not as much of a service discovery problem
<Nafallo> if they do know what protocol the server speaks they should check the "expert" box ;-)
<Lathiat> as it is looking at each protocol and looking
<Lathiat> so youd need to say to samba
<Lathiat> "tell me if this machine is only sharing printers"
<Lathiat> which would take a long time to query 40 machines...
<Amaranth> that's how windows does it, isn't it?
<Amaranth> and it caches the results
<Lathiat> (altho that would suck less in samba4, where everythign is async, currently operations block others in nautilus samba support)
<Nafallo> pitti: hi! :-)
<robertj> Lathiat: windows does do that though and it works fairly well
<pitti> Hey folks
<Lathiat> robertj: yeh?
<Lathiat> i've never seen it personally
<robertj> When you add a printer it gives you the option to select a network printer
<Amaranth> when you are browsing the 'Entire Network'
<Lathiat> robertj: join/mail avahi@freedesktop.org with ideas?
<Amaranth> it caches the results
<dholbach> hey pitti 
<robertj> oddly enough if you want to add an IP only printer you select local printer, dont serach for my devices and then create a virtual "IP" port
<Lathiat> where as on linux i just hit network printer and put the ip in. :)
<robertj> Lathiat: That's not really an avahi-level idea is it though?
<Nafallo> robertj: that made sence, not ;-).
<Amaranth> too bad you have to put the IP in
<Lathiat> robertj: nah but i'd be interested :)
<Lathiat> i'm interested in getting service discovery stuff as a whole rocking
<robertj> Amaranth: but for SMB printers you get a little tree view with icons that show only printers
<robertj> Lathiat: which is cool. Another thing worth consdering is hardware advertising
<sebest> Lathiat: i used howl, when do you think that avahi will have the same functionnality to replace howl?
<Amaranth> you should get a nice combobox of printers with the format "network name (printer model)"
<Lathiat> sebest: coming weeks hopefully
<Lathiat> assuming i dont fall off the planet
<robertj> or I guess more precisely, "LOOK! I'm a gst sink!"
<Amaranth> network name is the printer was giving for the network
<Lathiat> last time i checked the world was a global so falling off would reqire effort
<Lathiat> *globe
<robertj> does avahi support any kind of mdns bridging?
<Lathiat> robertj: as in bridging between two subnets?
<sebest> Lathiat: is the Api available to check, or a little example.c showing how to browse/publish ?
<Amaranth> robertj: or "LOOK! I'm a daap share!"
<robertj> avahi: imagine you mix this in with galago
<`anthony> Bugger, bugger, bugger. Hoary has an old version of hal, so I can't use it to find the audio devices... crap!
<sebest> robertj: it could be mixed with evolution
<robertj> Whenever you friends come online with GAIM, there fileshares, gst-servers, etc also come online
<robertj> sebest: well the idea is to mix it with galago, not so much gnome
<sebest> robertj: to publish user presence and vcard
<fabbione> `anthony: my little red hair friend.. a release need to happen once in a while.. please complain with upstream. kthxbye
<robertj> Lathiat: but yeah, does it support any kind of subnet bridging?
<`anthony> fabbione: Yes, I know. It's just annoying. 
<Lathiat> robertj: not at the moment, its planned but
<Lathiat> robertj: there is a project that does that tho written by davyd and grahame, can be found on angrygoats.net
<Nafallo> damn I hate sneezing!
<Lathiat> fabbione: 'kthxbai'
<ogra> `anthony, http://people.ubuntu.com/~pitti/utopia/
<robertj> Lathiat: a GUI for adveritsing static mDNS "bookmarks" would also be nice
<ogra> `anthony, no warranty
<pitti> `anthony: the update is a bit rough since dbus does not yet have a clean transition, but in the end it should work
<robertj> like we have a university wide dav server here, and it would be good to advertise it
<robertj> and there are already tools to do that with howl
<robertj> but I don't know about avahi
<jdub> robertj: that's where unicast dns-sd comes in
<Lathiat> sebest: http://0pointer.de/cgi-bin/viewcvs.cgi/trunk/avahi-core/avahi-test.c?rev=57&root=flexmdns&view=markup
<sebest> Lathiat: thanx!
<robertj> jdub: what handles that?
<`anthony> For now, I'm gonna compile hald from source and run it from a separate location.
<`anthony> That way I can get the code working, but not break everything else.
<jdub> robertj: howl did, i assume avahi will
<pitti> `anthony: that won't work since you also need the newer dbus
<Lathiat> avahi will (but not yet)
<`anthony> pitti: Bugger.
<robertj> Lathiat: is avahi working building on windows and OS X yet?
<jdub> robertj: i just advertise stuff on my dns server, and add other dns servers to gnome-vfs's lookup list
<pitti> `anthony: and of course you will lose all USB automount magic
<Lathiat> robertj: i doubt it
<Lathiat> in fact, not at all
<Lathiat> it currently relies on netlink
<jdub> netlink... delicious evil.
<jdub> and with that
<jdub> i'm off to bed
<jdub> nacht alles!
<Lathiat> (which is a linux-specific API for getting interface information)
<Lathiat> jdub: :)
<`anthony> I guess for now I just get to parse output of aplay -l :-(
<Nafallo> jdub: nightie :-)
<robertj> Lathiat: hehe, I feel sorry for Tor Lillqvist, "First day on the job: Ok, we need you to port Orbit2, Bonobo, parts of gnomevfs, and a few other things so you can port Evolution"
<Nafallo> is there a roadmap for the networkstuff?
<Lathiat> robertj: ;)
<Lathiat> Nafallo: my stuff?
<Nafallo> Lathiat: I was thinking more in terms of NetworkMagic :-)
<Lathiat> oh, that stuff
<Nafallo> right now I use netapplet :-P
<robertj> Lathiat: are you going to be in #ubuntu-meeting monday?
<Nafallo> gaah, I'm slow today...
<Nafallo> robertj: what was that about again? :-)
<Nafallo> rock! my mirror is synced, only took 12h :-P
<tseng> do you really need the whole mirrror? thats wasteful
<Nafallo> tseng: nope. I only got amd64, i386 and source ;-)
<tseng> hm for hoary?
<Nafallo> tseng: warty*, hoary*, breezy* :-)
<robertj> Nafallo: i'm lookign for the post
<tseng> i see.
<Nafallo> tseng: only 52GB right now ;-)
<Nafallo> robertj: ahh, breezy kick-off? :-)
<robertj> http://lists.ubuntu.com/archives/ubuntu-devel/2005-May/007397.html
<robertj> yeah
<Nafallo> 21-23 CET, I'll leave early from my french class then :-)
<robertj> I'll be at work so I'll be here ;)
<Nafallo> robertj: lol :-)
<robertj> btw, are partitions in Linux still limited to 2.2tb?
<robertj> I'm placing an order for 3 LaCie firewire drives on Monday to give a bump to our departmental file server's storage ;)
<Lathiat> robertj: i dont think so....
<robertj> WIth out Educational discount 1 TB firewire 800 drives are like 823
<Lathiat> what times that breezy kickoff meeting?
<robertj> You can buy them a bit cheaper still if you buy refurbished.
<tfheen> Lathiat: monday 1900 utc.
<Lathiat> so thats uh
<Lathiat> 3am tuesday gmt+8 ?
<Nafallo> 19-21 UTC
<robertj> so if you buy 1000gb at once it's $.007/gig now
<Nafallo> Lathiat: should be :-)
<robertj> http://www.dxing.com/utcgmt.htm has the table
<dholbach> jdub: what do you think of the MOTU list now?
<robertj> btw, is evolution fixed in Breezy yet?
<dholbach> robertj: works fine for me
<ogra> works here
<robertj> that's good, I'd moved back to hoary because it was broken and I had a deadline
<robertj> but deadline is over so I'm pondernig the move
<Lathiat> its still a bit broken
<Lathiat> automounting stuff is borked
<Nafallo> pitti: ping?
<pitti> Nafallo: pong
<Nafallo> pitti: on MOTUSecurity it says Universe should have USNs. mistake?
<pitti> Nafallo: rather, it should have updates
<Nafallo> pitti: oki. there is an approved spec also, saying that we shouldn't care about warty. correct? :-)
<pitti> Nafallo: well, we should concentrate on Hoary first, and if there are still resources, we can fix Warty in addition (IMHO)
<Nafallo> pitti: oki. so now when we are three people we should clean up hoary and breezy first :-)
<Lathiat> '
<Lathiat> [[[[[[[[[[[[[[[[[[] 
<pitti> ^  ??
<Lathiat> ^^ cat
<Lathiat> decided to wander over my keyboard
<tfheen> hit the same key lots of times for wandering.
<ogra> iu88888888888888888888888
<Lathiat> i think it stretched halfway accross
<pitti> ogra: your dog?
<ogra> Lathiat, mine answered ;)
* Lathiat grins at ogra 
<ogra> pitti, i have a cat too
<Lathiat> they are speaking code!
<ogra> hehe
<Lathiat> quick, start a distributed project to deciper it!
<pitti> yeah, but another pet for a change... :-)
* ogra looks for the guinea pigs
<Nafallo> pitti: I have my rabbit on the keyboard sometimes ;-)
* pitti looks for some spiders
<robertj> I wonder if the hotline ever got "ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggghhhhhhhhhhhhg"
<pitti> ogra: cat pulled out your eth cable? :-)
<ogra> nope, dbus crashed while i was playing with beagle
<ogra> so i had to restart my session
<seb128> anybody has an idea of what could make udev not creating /dev/hda[n] ? seems than it wants to use devfs style names. That's for a friend crossgrading from Debian unstable to hoary.
<seb128> he has no devfsd installed
<ogra> uuuh sid->hoary ? evil
<seb128> and /etc/udev/rules.d/udev.rules points on ../udev.rules which seems correct
<seb128> why evil?
<ogra> sid is newer
<seb128> I've said crossgrading
<seb128> hoary 1050 for apt-preferences
<ogra> hmm
<seb128> the system works fine out of udev
<ogra> the right kernel ?
<seb128> the kernel should not matter
<seb128> he has tried with a debian and the hoary one
<ogra> is ide-disk loaded ? 
<seb128> no idea, the system doesn't boot
<ogra> hrm
<seb128> since there is no /dev/hdn
<seb128> /usr doesn't get mounted
<seb128> and without /usr, no boot
<seb128> he has chrooted and dpkg -r udev which fixes the issue for the moment
<User233> Can anyone provide me the URL for ordering free copies of Ubuntu?
<ogra> shipit.ubuntu.com
<User233> Thanks.   I actually ordered some disks a few months ago, but they never showed up.
<dholbach> bye
<dholbach> *wave*
<mirak> there is a module called usbvision but he is not in the modules, what to do to make it enter in the modules of ubuntu ?
<bob2> is it dfsg-free?
<mirak> what does this mean ?
<tseng> mirak: free as defined in the debian free software guidelines.
<mirak> bob2: ?
<mirak> it's on source forge
<tseng> that means nothing.
<mirak> wait a minute
<mirak> usbvision.sourceforge.net
<mirak> I guess it's totaly free yes
* Lathiat looks
<bob2> gpl
<Lathiat> beat me to it
<mirak> not good ?
<bob2> that's fine
<bob2> I guess you file a wishlist or enhancement level bug on the linux-source package on bugzilla.ubuntu.com
<mirak> ok
<mirak> should I ask on debian first ?
<tseng> bbl
<mirak> I mean if it's on debian it should be on ubuntu isn't it ?
<bob2> no
<bob2> presumably you want it added to the default ubuntu kernel 
<bob2> if it's in debian, then it would just happen to be in ubuntu, too, where you'd have to compile it yourself
<mirak> bob2: why ?
<mirak> would I have to compile it myself
<mirak> because it would be as package ok
<mirak> but why can't they put it also in the kernel ?
<Lathiat> mirak: the ubuntu kernels are differentto debian ones and maintained by the ubuntu kernel team
<bob2> that's not how it works, sorry
<Lathiat> mirak: if you wish these drivers to be included in the default ubuntu kernel, you will need to file a wishlist bug in ubuntus bugzilla against linux-source
<mirak> I guess ubuntu would more reactive
<mirak> Lathiat: thanks, bob2 said it
<bob2> no, it's not about being reactive
<mirak> I should ask on debian why they give it separately
<mirak> I am curious
<bob2> the debian kernel team don't add hardware support to their kernels
<mirak> I don't know the internals
<bob2> they encourage you to get upstream (ie linus) to include it
<bob2> so everyone benfits
<mirak> ah
<mirak> so I should ask linux
<mirak> linus
<mirak> lol
<mirak> ;)
<bob2> well
<bob2> you should ask the developers of 'usbvision' why it's not in the upstream kernel yeat
<mirak> ok, maybe it's not mature enough 
<mirak> it's a a part of linux that is a bit anoying
<bob2> well
<mirak> vendors would support maybe more the hardware
<mirak> with closed source drivers of course
<bob2> its a problem with driver authors not writing good enough code, usually
<mirak> the problem is more that they don't relase it open source
<mirak> mmm not really
<mirak> in fact since it can be linked
<Lathiat> i think you got halfway confused with two issues
<Lathiat> i think bob2 meant about usbvision not being upstream
<mirak> and me ?
<Lathiat> generally its because they are either not the right license, not willing to get it upstream, write bad code or use methods that linux disapproves of 
<bob2> right
<Lathiat> and yes the issue with binary drivers is closed sourceness and licensing
<mirak> yes but they volunteer
<mirak> and anybody not happy can change the code
<bob2> sure
<bob2> including you ;)
<mirak> yes
<mirak> lol
<mirak> but that's really to much work
<mirak> I really don't want to spent to much time coding outside of the job
<bob2> so, first step, ask the authors why it's not in the upstream kernel
<mirak> I don't know how they can code like that
<mirak> yep
<mirak> I think a media live cd use it
<mirak> I have downloaded it
<mirak> I will test it soon when I will burn it
<thully> hi - in the RestrictedFormats wiki, should the instructions which pertain to Warty be deprecated/removed soon?  It's hard to maintain working multimedia instructions (beyond what's in Universe) for Warty
<thully> Part of this is that I'm going to remove Marillat from that wiki, and replace it with the much-better Ubuntu Backports repo - which has what is needed from marillat for Hoary
<tseng> uh
<tseng> id prefer that we dont promote sites like that on our wiki
* Nafallo seconds tseng 
<thully> Well, the multimedia stuff is only in hoary-extras-staging over at backports currently, but it is all going into hoary-extras tomorrow
<tseng> oh great so you are going to have them add the entire repo and dist-upgrade?
<thully> Well, I'm actually only going to use their "hoary-extras" repo (which adds packages to Hoary) and not their "hoary-backports" repo (which upgrades packages)
<tseng> still not a fan
<thully> Think of hoary-extras as kind of similar to marillat, except for Ubuntu
<tseng> except not by a debian maintainer
<thully> Marillat is MUCH worse than hoary-extras, as the packages are designed for sid and break on Hoary (you need breezy to use them)
<Lathiat> the testing packages probably work
<tseng> we are defining quality in a different way I guess
<thully> The gstreamer-* plugins for AAC decode/encode and LAME aren't in marillat testing
<Nafallo> what packages does marillat have that universe and multiverse don't have?
<tseng> id like to see the source for those
<tseng> btw
<Nafallo> btw
<Nafallo> MOTU's care for multiverse to? or who does?
<tseng> thully: do you have the original aac sources before they start adding ~ to the version string and various other crackful backports things?
<Lathiat> Nafallo: yes, motu?
<Lathiat> no ? mark
<thully> they're in marillat - but the point is that they can't be added to Hoary now that it's released
<tseng> hoary is released, yes, end of story
<thully> And Marillat has been broken for these packages for a week - meaning nobody can rip  MP3 using sound juicer or listen to AACs in rhythmbox
<tseng> id like to see them for breezy please
<tseng> un-backport-crackified
<thully> These are already in UniverseCandidates for Breezy
<Nafallo> ehm. why do people always complain about missing stuff _after_ release?
<thully> I mentioned this a few months before
<tseng> Nafallo: he complained about it before, but I didnt appreciate his attitude at the time
<thully> and the marillat package was working at the time.....
<tseng> ill look on universecandidates, thanks
<thully> what should be done about this for Hoary - having a RestrictedFormats wiki which has non-working instructions isn't good
<tseng> hey dude i dont see a link
<cartman> gcc-4.0_4.0.0-5ubuntu1_20050507-1638-amd64-successful <--- YAY :)
<thully> yes - the source to the gstreamer stuff is actually all in Hoary - use what you use to build the other plugins...
<Nafallo> thanks cartman :-). I'll update my pbuilder then ;-)
<tseng> oh so we are back to that
<thully> The source for gst plugins is all in one file, in other words
<tseng> thully: it needs to be an entirely new package
<cartman> Nafallo: the long waited gcc update for me :)
<tseng> libfaac/faad are in multiverse
<cartman> hope its version number is 4.0.1
<tseng> we cant have gst-plugins in main building with libs from multiverse
<thully> They all build into separate debs - so can't they be built together and then separated?
<tseng> no
<tseng> it has to have two source packages
<tseng> dbus-mono is an example of this
<thully> OK - well, I don't know how to split the source - maybe somebody could take a look
<thully> Also, somebody could just do two builds of the same source - one with the gstreamer plugins formain, one for universe, and one for multiverse
<tseng> thats what im saying
<tseng> but they need different names
<tseng> gst-plugins-multiverse say
<thully> I wonder how gstreamer0.8-mad is packaged - as that's in universe
* Nafallo has a dejavu experience
<tseng> good question
<thully> these probably should be done the same way
<Nafallo> tseng: didn't you talk about that today or yesterday?
<tseng> Nafallo: yes
<tseng> it says -mad is from gst-plugins0.8 in main
<tseng> wth
<thully> So - OK - I'm more concerned about what should be done with the RestrictedFormats wiki - marillat has packages which break on Hoary, and that needs to be dealt with
<thully> It seems the best way would be to use hoary-extras from backports - they are based on the Marillat source, but actually work on hoary...
<Nafallo> thully: exactly which packages are we talking about? just the gst* stuff?
<tseng> maybe libdvdcss or w32codecs he means?
<thully> yes - plus gtkpod-aac (for iPods)
<Nafallo> tseng: isn't w32codecs in multiverse?
<thully> no
<tseng> Nafallo: buh!
<tseng> that would be a nightmare
<Nafallo> hehe, well. I run amd64 ;-)
<tseng> w32codecs = dlls ripped straight from a windows pc
<tseng> its soo illegal
<Nafallo> tseng: hehe. oki :-). only mplayerhq has the right to have them then ;-)
<Nafallo> and marillat :-P
<Lathiat> Nafallo: You misunderstand
<Lathiat> they a) are in random countries where these laws don't apply and could b) be breaking the law
<Lathiat> alot of people just disregard legality
<Nafallo> Lathiat: ahh, oki. the serverplacement issue again :/.
<cartman> Nafallo: there are no legal issues in hungary
<cartman> Nafallo: and mplayer is hosted @ hungary
<Lathiat> i mean, in australia, its illegal to convert your CD into digital form, so ripping my legally purcahsed cd and placing it on an ipod is illegal.
<Nafallo> cartman: yepp, oki.
<thully> OK - does anyone have any viable alternatives to directing people to hoary-extras from Ubuntu backports for gstreamer* stuff + gtkpod-aac
<tseng> how should we do gtkpod-aac in breezy
<tseng> if we statically link it is it still illegalish?
<thully> build a separate package against libmp4 and put it in multiverse
<tseng> id rather not have 2 packages of the same thing if it can have a better solution
<thully> I guess libmp4 isn't in multiverse - but I wonder what it actually does (since libfaad is in there)
<Lathiat> man, so tired, 2:17am and work to finish for tomorrow, blah
<Lathiat> php is bad for the soul
<thully> However, it is required for AAC in gtkpod
<tseng> libfaad is libmp4
<tseng>  /usr/lib/libmp4ff.so
<thully> OK - I know everybody's interested in what should be done for Breezy - but In my mind the bigger question is - what to do with the restrictedformats wiki?  
<tseng> its a wiki, you can do whatever you want
<tseng> this channel is about development, breezy
<thully> I brought this up in #ubuntu, and someone directed me here
<Lathiat> tseng: how goes the beagle love?
<tseng> Lathiat: its in new
<ogra> unstable here
<Lathiat> tseng: scweeeet
<tseng> ogra: its LOVE
<ogra> heh
<ogra> yeah
<Lathiat> now i just need inotify
<thully> OK - I guess I'll put hoary-extras in that wiki - better than broken packages and tons of apt pinning
<Lathiat> should build a 2.6.12 
<Nafallo> thully: for libdvdcss, tell people to run /usr/share/doc/libdvdread3/examples/install-css.sh
<Lathiat> the inotify in 2.6.10 does bad things on my machine
<Lathiat> and the prebuilt 2.6.12 i got doesnt have headers so i'll have to build one
<tseng> the next kernel will have sane inotify
<thully> libdvdcss is in hoary-extras...
<Lathiat> tseng: yeh it does, works nice here.
<ogra> thully, is it really necessary to promote backports
<Lathiat> thully: thats illegal too
<Lathiat> thully: at least, here, and in the U.S.A.
<ogra> thtas quite ugly...
<Lathiat> here being australia
<Lathiat> actually, it might not be illegal yet, but it will be soon
<Lathiat> stupid fucking free trade agreement and its DMCA shit
<Lathiat> </rant-mdoe>
<Lathiat> *mode
<tseng> dmca is abused
<Lathiat> yuhuh
<Nafallo> but if they build the stuff themselves we haven't given them the package. they should sue the user, or am I misunderstanding?
<Lathiat> thank god the courts ruled the FCC cant bring in that stupid broadcast bit
<Lathiat> Nafallo: the source is illegal
<Lathiat> Nafallo: its a copyright circumvention device
<Lathiat> (well, so they claim)
<tseng> im not sure thats been proven
<tseng> but its a sticky trap we dont want to get into
<Nafallo> Lathiat: so we can get sued for it?
<Lathiat> well
<tseng> Nafallo: potentially.
<Lathiat> they arrested that dude when he flew into the US for a conference
<Lathiat> so im not going there....
<Nafallo> that file is installed by ubuntu-desktop I believe ;-)
<wasabi> dvdcss is illegal.
<thully> It seems like 95% of the time you want to play multimedia on Linux, some legal issue comes up...
<wasabi> distributing it, etc.
<wasabi> in the US
<tseng> Nafallo: dvdcss? not at all
<Nafallo> s/file/script/
<Lathiat> thully: its true, its called software patents, they suck
<Nafallo> tseng: the script to build a package and install libdvdcss yes...
<Lathiat> altho multimedia is a little bigger than just software patents
<tseng> Nafallo: huh?
<Nafallo> tseng: it's in the docs of libdvdread3
<tseng> oh
<Lathiat> i dont think a reference is illegal
<Lathiat> because it might well be legal where you live
<Nafallo> hehe, probably. the file is grabbed from a swedish university server ;-)
<tseng> it sure is
<Lathiat> tseng: it is illegal?
<tseng> no, the script is installed
<tseng> gentoo leans heavily on the build-from-source loophole
<Lathiat> heh yeh
<tseng> they have unencumber xine and mplayer
<tseng> +ed
* Lathiat adds copyright loopholes to the list of weird reasons to run gentoo
<wasabi> what copyright ?
<wasabi> err, what copyright loophole?
<Nafallo> I'm sure that script can be legally distribed. debian does it ;-).
<Lathiat> ebuilds can pull the source to something
<Lathiat> and build it
<Lathiat> so the ebuild is legal
<wasabi> which script
<tseng> wasabi: gentoo doesnt technically distribute anything but shell scripts
<Lathiat> and pulling and compiling the source may be legal
<Lathiat> and poeple will do it anyway
<wasabi> You all forget that 2600.com was barred from LINKING TO the source of decss.
<tseng> well, it might be legal to distribute the script
<wasabi> And that was UPHELD
<Lathiat> i hear you can buy it on a t-shirt. :)
<Lathiat> the whole decss thing is stupid anyway
<wasabi> there is a difference between "technically illegal" and "i will get arrested for it"
<Lathiat> digital solutions to rip dvds existed long before
<Lathiat> its not like it brought anything new other than the ability to playa legal dvd on my legal dvd rom drive on my legal fucking laptop. law is ass.
<`anthony> wasabi: besides, it's jdub and mdz who go to jail, not us plebs.
<Nafallo> well, can we just have one less package to think about then ;-)
<Lathiat> be nice if fluendo get their dvd thing out
<Lathiat> i wonder if it will be a binary gstreamer plugin
<Nafallo> `anthony: hehe. and in debian it's who? ;-)
<Lathiat> welcome to the grey area
<Nafallo> hehe
<Lathiat> in part you could claim the maintainer
<Lathiat> but then yo ucould say
<Lathiat> all the mirror maintainers who host a copy...
<wasabi> that's why debian has non-us
<Lathiat> yurp
<Lathiat> i think that has screw all in it now tho
<Lathiat> most of the crypto stuff got sorted
<Nafallo> *sigh* politicans that aren't hackers shouldn't vote in those law questions :-P.
<Lathiat> bush didn't hack gstreamer last check
<Lathiat> unfortunately
<Nafallo> so... have we answered any questions about the question that made this discussion happen? :-)
<Nafallo> hmm, that's a meta-statement :-P
<thully> so - should decss info be replaced with a reference to the shell script that builds it from source?
* Nafallo votes for that
<thully> Also, should all the Warty info be removed (half the plugins don't work in Warty, and doing any more than MP3 playback on Warty would probably be a disaster at this point)
<thully> from RestrictedFormats
<Burgundavia> thully, your wiki to, I wouldn't remove it, just mention it
<thully> All the half-broken Warty info makes the Hoary info more confusing
<thully> What should be done about w32codecs - that is a questionable package as well... (maybe more so tha decss)
<Treenaks> at least copyright-wise
<tseng> its not questionable at all
<tseng> its straight illegal
<Nafallo> if amd64 can do without them, so can i386
<mjg59> There's no permission to redistribute those files at all
<Nafallo> ppl can jump though hoops and get it from mplayerhq if need to, but that's not something we should mention :-)
<thully> OK - take it off...
<thully> I'm doing that right now as I clean up this wiki...
<thully> BTW: mjg59 - have you had a further look at the ThinkPad suspend issues with Radeon cards?
<Nafallo> hmm, why do we want soundjuicer to rip mp3? which are the main reasons? mp3-players?
<thully> yes - I mean, only about 10% of devices out there play OGG, so OGG is useless for most
<Nafallo> thully: how many play MPEG-1 layer 2?
<thully> hm?  do you mean .mp2?
<thully> why - is .mp2 format non-patent-encumbered?
<Nafallo> thully: mais oui.
<thully> ?
<Nafallo> thully: I don't think so. toolame is in universe and debian main.
<Nafallo> would be nice to hook that into gstreamer and let people rip mp2.
<thully> If .mp2 is non-encumbered, maybe I'll try it on my iPod mini - since if it is unencumbered and works on iPods we should make that the default ripping format on breezy (or at least make it simple to use)
<Nafallo> thully: the default should be ogg, mp2 should be an option.
<tseng> so, lets promote lame stale codecs
<tseng> rock on.
<mjg59> mp2 is dreadful, in terms of quality
<thully> Is it a ton worse than MP3?
<tseng> yes
<ogra> yep
<Nafallo> mjg59: they should have bought ogg-players ;-)
<Lathiat> encode in wave format!
<thully> There aren't a whole lot of ogg players  - especially in the form factor of the iPod mini...
<ogra> Lathiat, punched tape !
<mjg59> Sucks. Not something we can do much about.
<Lathiat> ogra: like punch cards?
<ogra> yeah
<Lathiat> :)
<ogra> Lathiat, the one thats in mechanical pianos
<Lathiat> why dont you just carry your own personal band/orchestra around in your back pack
<Lathiat> do it the old fassioned way
<Nafallo> we could tell people to download the mp3 they want *jokes*
<ogra> yeah, that generates a lot of jobs !
<Nafallo> hmm
<Nafallo> we might be able to bring some packages in through hoary-updates for the aac stuff?
<Lathiat> a
<Lathiat> Nafallo: hoary-updates is for important updates and calendar
<Nafallo> true. we should make breezy rock instead :-).
<thully> OK - I think I'm wiping all the warty info from RestrictedFormats (makes maintenance easier) and I may put it in a new, "WartyRestrictedFormats", soon.
<thully> I'm in the process of making the changes - the Hoary-extras repo won't work until tomorrow, however (but the marillat repo in there before didn't work anyway)
<Burgundavia> thully, hoary-extras?
<thully> yes - marillat is broken...
<ogra> Burgundavia, he wants to advertise the backports repos instead of marillat :/
<Burgundavia> oh
<Burgundavia> trading crack for crack
<Burgundavia> hmm
<thully> well, what's the point in using broken repos?  I was fine with marillat until it broke on Hoary
<ogra> trading crack for bad crack
<thully> Well, marillat isn't an option anymore with their recent breakage...
<ogra> thully, broke in what way ? mplayer and friends are fine in multiverse, you nly need marillat for decss and w32codecs
<thully> and it is breakage that can't be resolved - building against sid packages not in Hoary
<Nafallo> ogra: not decss
<thully> gstreamer-* plugins are needed for quite a few things...
<thully> and the ones I want are broken on marillat by depending on a new glibc
<thully> Hoary-extras seems to work a lot better - no pinning necessary, and you don't have to replace Hoary's libfaad with Marillat's
<ogra> thully, will you go out and fix all the broken packaging systems of backport users ? 
<thully> This is a lot different from hoary-backports - this simply adds packages to Hoary, while hoary-backports upgrades packages already in Hoary
<svenl> Mmm, anyone knows why /dev/raw1394 is set to root.video mode 600, while /dev/video1394/0 is root.video mode 660 ?
<ogra> who is "this" ?
<thully> Nothing in hoary-extras is in main,restricted,universe,or multiverse
<svenl> It sure does stop gnomemeeting from working with firewire webcams and DV cameras.
<thully> this=hoary-extras from Ubuntu backports
<ogra> who made them ?
<thully> The Ubuntu backports team over at ubuntuforums
<ogra> so they are not better packaged then the other backports
<Burgundavia> ogra, http://backports.ubuntuforums.org/backports/dists/hoary-extras/restricted/binary-i386/
<Burgundavia> w32, dvd and jre
<thully> Most of these are simply rebuilds of marillat packages without bad deps
* ogra wonders how bad things will break for these users if gjc brings java in...
<thully> they don't have to install java from there...
<ogra> if they have it in their sources.list and the version number is broken as usual...
<thully> OK - if you don't like that repo, suggest a better alternative...
<ogra> marillat... use older packages from there...
<ogra> at least these are known to be packaged in a sane manner...
<Burgundavia> ogra, even more crack inbound http://backports.ubuntuforums.org/backports/dists/hoary-extras-staging/restricted/binary-i386/
<Nafallo> do we /have/ to have packages for w32codecs?
<ogra> Nafallo, not at all
<thully> I think it's nota good idea to point people to umpteen different links to old packages on FTP servers that may break at any second...
<trulux> Nafallo: I guess it's because the license stuff
<Nafallo> users could follow commands to get them from mplayerhq.hu if needed to.
<trulux> Nafallo: well, they have packages somwhere, I can't remember right now
<ogra> thully, and i think its not a good idea to point users to repos that break their packaging system and upgradeability
<trulux> btw, anyone here could point me to a HOWTO or reference for gnome applets development using python (or C, doesn't matter really)?
<Nafallo> trulux: mplayerhq?
* trulux is about to make an applet for Ubuntu Hardened stuff
<trulux> Nafallo: win32codecs
<ogra> trulux, an applet to hotswitch kernels ? :-P
<Lathiat> trulux: umm, no idea about docs, but angrygoats.net in svn has an applet called 'interapplet' (network interface cahanging applet) that uses python, might be a good example
<thully> OK - I didn't think hoary-extras would break anything the way hoary-backports might (since it only provides stuff not in Hoary)
<Nafallo> hehe, the frontpage was fun ;-)
<trulux> ogra: hah, no, SELinux enabling/disabling, to control the things that tseng commented/suggested on UDU and so on
<Burgundavia> thully, hoary-extras shouldn't
<trulux> Lathiat: danke sehr
<trulux> ogra: well, hot switching of kernels is not that tested but currenty is possible, just you need to have cold blood
<trulux> or be a brave soul
<ogra> heh
<ogra> or be the master of xul 
<trulux> (or a suicide, kamikaze, that kind of things)
<trulux> haha
<Nafallo> trulux: nope, know .deb for w32 on mplayerhq.hu as far as I can see.
<Nafallo> s/know/no/ ;-)
<trulux> well, I need also to upload the spec for Ubuntu Hardened, due the problems I had with my devel box I had to move to the laptop
<trulux> and I'm still fixing, setting working on general things
<Nafallo> how the hell did that happen :-P
<Burgundavia> gstreamer .9 is going to include a w32codecs-like functionality
<trulux> well, my CRT screen got fscked up, almost exploded...
<trulux> at least I could access the box for a few minutes to burn some backups
<trulux> Nafallo: no, .debs of win32codecs in other place, I can't remember, it's a well known unofficial repo
* trulux is eatingbelgian chocolate ice-cream from Hgen-Dazs
* Burgundavia hasn't had breakfast yet
<Lathiat> tru	woops
<Lathiat> trulux: rather
<trulux> Burgundavia: ouch
<Nafallo> trulux: marillat. however, it seems the issue is that marillat don't work with hoary as thully says...
<trulux> Lathiat: I'm checking the applet
<trulux> Nafallo: It did for me
<Lathiat> trulux: cool
<trulux> won't take too much time to finish
<Burgundavia> 2.6.12-rc4 is out
<trulux> Burgundavia: far away from 2.6.12 then
<trulux> :(
<Nafallo> trulux: and I'm for telling people to download from mplayerhq and unpack themselves if they really need it instead of any other repos :-).
* trulux needs 2.6.12 to get his couple of crack-of-the-day merged
<trulux> Nafallo: hah, let them learn ;)
<Nafallo> trulux: exactly. the issue with libdvdcss is covered in libdvdread3's doc/examples dir.
<trulux> ;)
<Nafallo> two less packages to do something about right of a sudden :-)
<trulux> I have NFC on why I spent almost half a day making the kernel doing weird stuff to recognize the USB mouse and not fsck my udev schema, and I'm still using the touchpad ;(
<trulux> oh, 'cos I have the ice-cream on the other hand
<trulux> ;P
<Lathiat> haha
<Nafallo> hehe
* Lathiat steals trulux's ice cream 
* trulux 's ice-cream is confined by SELinux
<Nafallo> lol
<trulux> avc: denied { steal } for pid=12345 exe=/home/lorenzo/ice-cream
<trulux> scontext=lorenzo:pleasing_r:eating_icecream
<trulux> after I've bene skimming on the package files relabeling for SELinux in Gentoo, I need to talk to...
<trulux> ajmitch_: ping :)
<trulux> btw, for Ubuntu I have another thing that might rock, a hack to the cpufreq applet to change from each governor to another
<Nafallo> trulux: is there a meaning with that when you have powernowd as a backend? :-)
<trulux> Nafallo: the meaning is my own fun and training ;)
<Nafallo> trulux: ooh, I see :-).
<trulux> among that I'm using Gentoo with a very few things installed
<trulux> and too much tweak ;)
<Nafallo> gentoo will never touch my computers again :-)
<trulux> Nafallo: why? too complex for you?
* trulux hides
<Nafallo> trulux: hehe, rather I don't like to compile my security updates. I want to install them :-).
<Nafallo> trulux: besides that, debian (and derivates) is my home ;-).
* Nafallo goes to find trulux again ;-) *
* trulux is back from his secret place
<trulux> Nafallo: I had to stay in front of the laptop while updating more than 200 ebuilds
<trulux> Nafallo: just to see if the new USE flags were correctly set and so on
<Nafallo> trulux: annoying :-P
<trulux> a bit :)
<trulux> openoffice still doesn't compile, need to fle a bug for it
<Nafallo> trulux: or apt-get install it ;-)
<trulux> dunruin lorenzo # apt-get install openoffice
<trulux> Use the box in the room near this one, moron!
<trulux> (Signed, the Gentoo wocked cow)
<trulux> dunruin lorenzo #
<Nafallo> hehe
<Nafallo> 3 x ubuntu hoary here :-)
<trulux> here, 1 x Hoary, 1 x Breezy, 1 x Gentoo with SELinux 2005.0 profile + Hardened profile bits
<Lathiat> 1x breezy here
<trulux> Lathiat: anything broken right now? :)
<Lathiat> well, and 4 hoary vms for routing simulations with quagga but i dont think they count. :)
<Lathiat> trulux: plenty
<Nafallo> I run breezy on my chroots and pbuilder :-)
<trulux> lamont: nice
<Lathiat> blam is fixed but !
<Lathiat> usb automounting is stil broke
<Lathiat> and i get some keymap error on boot
<tseng> Lathiat: modprobe sd-mod
<Lathiat> mono and evolution were fixed
<trulux> Nafallo: Hardened Debian started in Debian chrooted environments... no joke
<Lathiat> tseng: oh yeh i did that, but it still doesnt auto mount (but at leasti can mount it myself)
<Lathiat> and the gcc-4 stuff screws a few things
<Lathiat> like compiling kernel modules
<Nafallo> trulux: :-)
<tseng> hm because the kernel is built with 3.4?
<Lathiat> tseng: 3.3, but yeh
<tseng> yeah
<Lathiat> thatl be fixed when the new magic kernel goes in
<tseng> yes.
<Lathiat> which i was running a build of and works nice
<Lathiat> except i have no headers package for it 
<Nafallo> hehe, magic kernel for the magicalforest ;-)
<Lathiat> so i cant run vmware
<tseng> i only run vmware in windows
<Lathiat> i use it on linux to simulate some routing stuff for my network course
<Lathiat> cus you can set bandwidth and packet loss on virtual lan segments, totally rocks
<Lathiat> so i have 4 cut down hoary vms with quagga
<Lathiat> uses about 40% cpu idling tho :\
<Lathiat> of my 2ghz pentium-m
<trulux> Lathiat: well, my laptop is 3.07GHz
<Lathiat> and i have 5 hours of battery life. :)
<Nafallo> baah
<trulux> Lathiat: put userspace governor and turn it into a lovely old-times-like 383Mhz machine
<Lathiat> it only goese down to 600
<Lathiat> but!
<Nafallo> 1 hour battery max for me :-P
<Lathiat> if i then use acpi scaling on top
<trulux> you will be able to (almost) play ping-pong
<Lathiat> i can get it down to 75mhz
<Lathiat> last time i did that it took me about 5 minutes to get it ack up to 600mhz because i couldnt get much responsiveness to set it back up :)
<Lathiat> (i was running gnome at the time. :)
<Lathiat> tseng: mmm, new tomboy is much faster, woot.
* Lathiat sleep.
<Nafallo> Lathiat: sleep: to few arguments
<trulux> any Python hacker able to give some advice to someone who has been out of the Ptyhon business for too many time?
#ubuntu-devel 2006-05-08
<zyga> hey
<zyga> how can one debug hibernation issues?
<azeem> you ask mjg59 about them, AFAIK ;)
<zyga> I can hibernate okay with pure main system, but after poweron there is no sign of hibernation (regular boot)
<zyga> mjg59: awake?
<Lure> zyga: you may try #ubuntu-laptop...
<dholbach> good night everybody
<bddebian> How peoples
<tseng> hi bddebians
<bddebian> Hi tseng
<MrRio> hey
<bddebian> Hello MrRio
<dAndy_> is there a known issue with lots of printers crashing the printer dialog? I cant seem to find a bug, trying to pin down which bit is causing it so I can submit one
<mjg59> elmo: Hi
<dAndy_> I went ahead and filed a new bug, I wasnt sure what to file it against: #42676
<bddebian> Oh, elmo: I know you're busy but if you get a free second, could you plesae look at my @ubuntu.com e-mail?  cprov said you were the man to speak to..
<stub> Launchpad is going down in 15 mins for a regular code update. Estimated down time is 10 minutes. Wikis will be in read only mode during this period.
<LaserJock> stub: thanks for the heads up
<desrt> daniels is in pc magazine today
<mdz> infinity: how is that review of initramfs-tools bugs going?
<bddebian> OMG PC Magazine is still around?
<infinity> mdz: Getting some more stuff fixed and uploaded in initramfs-tools is next on my TODO after finishing up some security stuff for pitti.
<bddebian> Gnight folks
<pygi> Mithrandir: around?
<pitti> Good morning
<pygi> mornin' pitti
<pitti> hi pygi 
<dholbach> good morning
<highvoltage> morning mr holbach
<dholbach> highvoltage: how do you do?
<highvoltage> dholbach: fine thank you. how are you?
<dholbach> highvoltage: I'm just getting ready for the bug day - so I'm fine.
<highvoltage> :)
<kagou> infinity: around
<infinity> kagou: Vaguely.
<kagou> oh i need big attention :)
<infinity> ?
<kagou> :p
<kagou> infinity: we have many bugs for samba, concerning sharing/user security
<infinity> Yes, I know.
<kagou> we have to decide what is the default use for gnome-share. Is there a discussion anywhere on lists ?
<infinity> And switching to security=share breaks a whole host of other things, so I'd prefer if people stopped recommending it.
<G0SUB> infinity: hello :)
<kagou> infinity: so if security=user we have Bug #24184
<Ubugtu> Malone bug 24184 in samba "Samba and system passwords should be synchronized." [Wishlist,Unconfirmed]  http://launchpad.net/bugs/24184
<pitti> infinity: I had this problem with a friend of mine, too; either switching to share, or fiddling with smbbpasswd, either way there seems to be no way to get it working just OOTB or with GUI tools, right?
<infinity> kagou: As it stands, no massively amazing changes will go in before release anyway, so this is probably better specced out as "something we can improve on for Edgy", with people like G0SUB (hi!) who seem to be interested in better GUI toold for samba.
<G0SUB> yay!
<infinity> pitti: Yeah, the user needs a password.
<infinity> pitti: (switching to share breaks the world for a lot of other samba use cases, so it's a non-starter, IMO)
<G0SUB> infinity: I have written another spec ... this time for offline-updates
<G0SUB> https://wiki.ubuntu.com/OfflineUpdateSpec
<infinity> pitti: The easiest route to get the user a password would be to ask them for one when they create a share iff they don't already have a password set, but that means mangling the GNOME dialogs pretty late in the cycle.
<G0SUB> I would like to implement both of them for Edgy
<infinity> pitti: The dialog already needs root anyway (since it's fiddling with smb.conf), so tossing in an smbpasswd call isn't rocket science, I suspect.
<G0SUB> JaneW: Good Morning :)
<JaneW> hi G0SUB 
<G0SUB> JaneW: I am the one who mailed you about the Samba config gui idea
<JaneW> G0SUB: yes I just /whois'ed you :) G0SUB is somewhat easier to say :)
<G0SUB> JaneW: haha
<JaneW> infinity: did you check the spec?
<infinity> G0SUB: The service pack idea sounds rational, but when you start digging in, it gets a bit uglier.  When you say "it downloads its dependencies", you realise that you'll end up with half the archive in each "service pack", right?
<infinity> (Well, you'll end up with GTK, glib, a bunch of X libraries, glibc...)
<G0SUB> infinity: I agree. I must put in some sort of heuristics into it
<infinity> The only way to avoid that is to generate the package list on the target machine, so it knows what it already has installed.
<G0SUB> infinity: one idea might be to show ALL deps and let the user choose which deps to download
<infinity> That would be far too unfriendly to work for the target audience.
<infinity> Most don't even know (or want to know) what libc6 or libx11 is.
<G0SUB> infinity: the pack creator is not a newbie I assume :)
<G0SUB> infinity: or, we can download only first level deps?
<infinity> There's no way to know which are the "right" ones to download, honestly.
<G0SUB> or, we always remember what's there in the 1st CD and never download those?
<infinity> Not without running a "service pack diagnostic" on the machine you intend to install to.
<infinity> (Which would pretty much just be a "dpkg -l" output, but whatever)
<G0SUB> hmm
<infinity> Yes, culling dependencies that are on the install CD isn't a bad idea either.
<G0SUB> whatever the method, we must find out something. my friends who don't have internet are screaming at me
<infinity> But that's only part of the problem, since you're talking about doing "update" CDs, etc, which won't have a clue what updates the user may already have.
<G0SUB> infinity: the 1st CD idea is reasonable IMHO
<kagou> infinity: may be the script used to create users can be hacked to create smb password too ?!
<infinity> (For a while, dapper-security will be under 650MB, so you can just grab it all, but that won't last)
<G0SUB> infinity: it'd be date based
<G0SUB> it can be
<infinity> JaneW: I've not had time to give it a thorough check, no, though I'm now discussing his other spec. :)
<G0SUB> say all updates after this date
<kagou> infinity: may be we have not the time to hack gnome-user-share to ask for the samba password creation. So we may have to set security=share . Doing that we have to remove the default share of home directory in smb.conf
<JaneW> infinity: oic.
<infinity> kagou: I see no reason why we MUST do one or the other.
<infinity> kagou: This misfeature has been there forever.  It's not new in dapper.
<kagou> infinity: simply because without choosing, gnome-user-share don't work
<Mithrandir> pygi: yes
<infinity> kagou: I appreciate that it's annoying, but I don't want to break security= just to "fix" the desktop use case.
<pygi> Mithrandir: have you responded to that guy about n-a ?
<Mithrandir> pygi: no, sorry.
<Mithrandir> pygi: mdz did, though
<pygi> Mithrandir: I just saw he applied for SoC, but his presentation was ... huh, how do I put it :-/
<infinity> kagou: I'd be happy (as I've mentioned before), however, to audit a patch to gnome-user-share that does the smbpasswd invocation for the user.
<G0SUB> pygi: are you a mentor?
<infinity> It'll such that it may be a new untranslated string (unless I can cleverly pull a string from somewhere else and re-use it), but we may be able to make an argument for letting it in anyway.
<kagou> infinity: so we may  be can remove gnome-user-share installation by default, and add in README how to work with smb password. Of course i'd be happy too for this patch :)
<infinity> s/such/suck/
<pygi> GOSUB: for n-a thingy? nop
<G0SUB> pygi: for SoC
<pygi> GOSUB: yup
<infinity> G0SUB: Have you been following this conversation?
<Mithrandir> pygi: got an url to it?
<G0SUB> pygi: did you check my application? 
<pygi> Mithrandir: have you looked it over?
<G0SUB> infinity: yes, I am
<pygi> GOSUB: what is ur application?
<G0SUB> pygi: SAMBA GUI
<infinity> G0SUB: If you want to prove that you've got the m4d GUI sk1llz required for the SoC stuff you're proposing, maybe you could look at this gnome-user-share issue? :)
<infinity> G0SUB: I suspect that for someone with the right background (ie: not me, I don't touch GUIs), it may be a 10-minute hack.
<G0SUB> infinity: heh, I agree
<pygi> GOSUB: oki, I'll look into it
<Mithrandir> pygi: got an url?
<G0SUB> pygi: thanks a lot
<pygi> Mithrandir: I sent you to pm the url
<Mithrandir> oh, thank
<infinity> G0SUB: A patch would make me a very happy camper (and pretty keep on being your mentor for the actual SoC project)... <hint, hint>
<G0SUB> infinity: is there any bug report? I came in just now :)
<kagou> infinity: for Bug #27608 can i propose a simple patch to remove default home share in smb.conf
<Ubugtu> Malone bug 27608 in samba "Entire home dir is shared within another in samba!" [Normal,Needs info]  http://launchpad.net/bugs/27608
<Mithrandir> pygi: uh, aren't the students supposed to write something about themselves and their skill set?
<pygi> Mithrandir: indeed 
<infinity> G0SUB: There is a bug report or 12, but the jist of it is what's been said above.  When you create a new share with gnome-user-share, you can't actually ACCESS it, cause no one's ever run "smbpasswd -a <yourusername>"
<G0SUB> infinity: ah!
<G0SUB> infinity: now I got it the whole context
<pygi> Mithrandir: make a comment stating all your remarks about that application (a lot of them), and publish it to the student
<infinity> kagou: I don't really see that one as a bug, TBH.  Not after the followup comments, which seem to lead me to believe that he shared a directory with a sharename matching his username.
<infinity> kagou: But maybe you can convince me to comment out the user shares by default in Ubuntu.
<G0SUB> infinity: a patch will come soon
<pygi> Mithrandir: considering the complexity of that spec, we can't allow something like this :-/
<infinity> kagou: I'm still weighing the options between "being gratuitously different from most Samba installations" and "desktop user won't confuse themselves"
<pygi> GOSUB: seems nice on first sight
<G0SUB> pygi: thanks
<kagou> infinity: i must go away now. I will think at this and contact you later. It's a HUG DAY http://fridge.ubuntu.com/node/363 so i want to close samba bugs ;)
<G0SUB> infinity: I don't see any gnome-user-share, it's called shares-admin which comes under gnome-system-tools I guess
<pygi> infinity: will you be mentoring that samba thingy if it's accepted?
<infinity> G0SUB: Err, that thing.  Blame kagou for me naming it incorrectly. :)
<G0SUB> infinity: hehe :)
<infinity> pygi: If G0SUB's up to the task, and we add some polish to his spec, I'll likely mentor him, yes.
<jdub> (that said, samba integration for gnome-user-share might be interesting)
<pygi> infinity: nice
<infinity> jdub: What *is* gnome-user-share? :)
<infinity> jdub: Oh, webdav.
<Mithrandir> infinity: "share this folder on the network" clicky in nautilus.
<jdub> Mithrandir: not quite
<Mithrandir> jdub: oh?
<infinity> Mithrandir: No, that's shares-admin
<jdub> it runs apache for webdav serving ~/Public with avahi love
<pygi> Mithrandir: will you have enough time to comment?
<jdub> (i think ~/Public style serving is a better model than the windows-style 'randomly choose stuff to serve' model)
<Mithrandir> pygi: I've already done it.
<Mithrandir> pygi: basically saying "please provide more information or I can't evaluate your application"
<G0SUB> infinity: gnome-system-tools is in C ... I need more time to look at it
<ajmitch> when is edgy's feature freeze likely to be? around the time SoC work ends?
<G0SUB> ajmitch: lol
<Mithrandir> ajmitch: two days after UiP. ;-P
<ajmitch> G0SUB: generally any SoC project for ubuntu will have to be ready by feature freeze to make it in
<G0SUB> ajmitch: I agree. SoC will end on 23 August btw.
<pygi> Mithrandir: oki, nice
<holycow> hey guys
<holycow> hey, i want to deploy ubuntu for a few regular users, and would like to set it up so that if they screw up their box, they can powercycle, and from startup select a backup image to restore the to / partition
<holycow> how would one go about setting this up?
<HiddenWolf> holycow: if you can't trust them with administrator-rights, why give it to them?
<holycow> HiddenWolf, ultimately that is the answer, HOWEVER, i'm thinking useablity here
<holycow> there are certain functions non codemonkeys could use to make their computing environment nicer ... restore to base install is one
<holycow> snapshot +1 would be another 
<Kamion> you could use LVM snapshots
<Kamion> some assembly required, though
<lifeless> HiddenWolf: windows machines from vendors come with such a easy-restore option
<lifeless> HiddenWolf: it can be nice
<holycow> *hmmm* thats not a bad idea, my initial thought was partimage 
<HiddenWolf> lifeless: I know.
<Kamion> it was discussed at UDU in relation to the OEM installer, but never really made it as far as a design
<pygi> Kamion: there is a suggestion for doing app like that in SoC
<holycow> is lvm the right idea tho? i've read many an issue with dealing with lvm restores
<Kamion> oh, well, it sort of did
<Kamion> https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/OEMRescue
<holycow> my intuitition would say something like using partimage, and doing a diff restore/backup
<Kamion> but I think it would be necessary to rethink it anyway
<pygi> Kamion: https://wiki.ubuntu.com/GoogleSoC2006#head-6f1deddcffc4e286e0bbd987f3a424b4b3a82479
<Kamion> holycow: nothing wrong with using partimage, it just takes more disk space
<holycow> okay so i guess the idea has been brought up but not worked ona whole lot ... 
<Kamion> pygi: bit vague though
<leo> hi , I'am modifying a live cd - i changed my gdm.conf but i looks like a script is overwriting my gdm.conf with a default when the live session is prepared? Someone an idea which script is responsible for this?
<holycow> btw kamion, some of those ideas on that page are great
<HiddenWolf> holycow: and some are hilarious
<holycow> :)
<holycow> the oem rescue thing is a good idea
<HiddenWolf> holycow: there is a suggestion to make xgl work on S3 graphics solutions and such. ;)
<holycow> that i guess would be a step of last resort, would be also nice to setup something like allowing users to snapshot environment at will as per wiki suggestions
<holycow> HiddenWolf, ehehe :)
<holycow> classic
<HiddenWolf> Things like parental control however, seem like great things.
<HiddenWolf> specially considering edubuntu
<holycow> ah yes i would agree, that would be excellent
<holycow> my only question is what does parental control mean
<HiddenWolf> holycow: preventing kids from doing kid-unfriendly-stuff on their pc's
<holycow> its a hard thing to define, i would guess the most meaningfull aspect of pare ntal control would be total logging, including mouse movements and system use playback
<pygi> well, by looking at current applications for that, it seems people think parental control is only web filtering
<ogra> holycow, a (probably transparent) filtering proxy for web content 
<ogra> pygi, thats the main purpose
<holycow> call it heresy, i think that probably should be a paid for subscription service
<pygi> ogra: true, but not only one 
<ogra> you can indeed extend that by something like logging out the kid on schedule (after 1h for example) etc
<holycow> i would really say as well that it requires complete logging of environment use
<holycow> including ability of playback of kids useof system
<holycow> i have parents at the company ask me for that many many times
<tseng> pygi: false
<pygi> ogra: the suggestion is talking about Dansguardian + Squid, and considering we'll be using willow :-/
<tseng> pygi: http://spectresoft.com/
<tseng> pygi: commercial products cover alot more than web
<pygi> tseng: and what have I said ? :P
<pygi> that it's not the only purpose =P
<holycow> tseng, ah neat, thats cool, good bookmark.
<tseng> you claimed most products dont do anything else, or so
<pygi> tseng: I claimed SoC applications mostly claim that 
<tseng> oh.
<ogra> pygi, dansguardian is crap (as squidguard is) and indeed parental control is more than proxying, but a contentfilter is an essential bit 
<pygi> ogra: agreed...so please take your time to comment on that application, or should I?
<ogra> pygi, which application ? 
<pygi> ogra: Parental control, SoC
<pygi> want a url?
<siretart> Kamion: I normally don't beg for these kind of things, but could you please  NEW freealut? I already uploaded a couple of package build depending on freealut-dev, and I'd like to get the transition over quickly
<ogra> pygi, i dont see it on the official SoC wikipage
<Kamion> getting pretty late in the day for transitions, isn't it? :)
<pygi> ogra: the mentors part 
<pygi> ogra: want a link?
<Kamion> siretart: source accepted
<siretart> Kamion: thanks!
<pygi> ogra: or have you found it?
<ogra> pygi, commented it
<pygi> ogra: thanks, I'll look into it now
<ogra> i'll also update the willow description a bit now 
<ogra> (if Amaranth doesnt mind :) )
<pygi> ogra: have you commented on mentors page? cause I can't see the comment :P
<ogra> pygi, nope, in the SoC page
<pygi> ogra: bah, you need to comment on mentors page =P
<ogra> why ?
<pygi> and make it public so student can see it
<pygi> well, so student can improve application? 
<flurble> Kamion: riddell says, his internet is broken this morning and hell be on as soon as its fixed
<Kamion> flurble: thanks
<Kamion> flurble: passed on to the Canonical talk mailing list
<flurble> ok
<nags> when I try to build this source http://mutt.in/~nagappan/ldtp-tmp-source.tar.bz2 in SuSE / FC4 its working fine, But unable to build it in Ubuntu. I feel I miss something in configure.in, how could I fix it ?
<nags> some assistance will be of great help :)
<Kamion> that depends on what the failure is
<nags> Kamion: okay...
<nags> Kamion: G0SUB tried it building...
<Kamion> perhaps you could put the output in a pastebin
<nags> G0SUB: can you please ? and give the link to Kamion ?
<ogra> i test built it during breezy time ... shouldnt be impossible 
<Kamion> don't give the link to me personally, give it to the channel
<nags> Kamion: right :)
<G0SUB> nags: in a sec
<nags> G0SUB: okay
<nags> ogra: you tried building ldtp source ?
<G0SUB> nags: this is the special tmp code btw. not ldtp proper
<nags> G0SUB: right
<G0SUB> nags: and with all symlinks removed
<G0SUB> http://pastebin.com/695874
<nags> G0SUB: soon this will be checked in
<nags> G0SUB: right
<ogra> nags, yes, shortly after the stuttgard guadec
<nags> ogra: oh okay :)
<ogra> quite some time ago :)
<nags> ogra: lot of changes recently ;)
<nags> ogra: okay
<nags> Kamion: looks like the source files are not properly taken for compiling ?
<pitti> Diziet: yay new gs-esp; how many bugs does that close? :)
<Kamion> yum, a source tarball that requires you to run autoreconf
<soumyadip> ok it looks like the libtool package is required
<ivoks> how many opens? :)
<nags> soumyadip: do I need to mention the libtool some where ?
<pitti> Diziet: ah, just saw your bug mail
<soumyadip> nags: yes when you build the package, libtool should be in build-dependencies in the debian/control file
<nags> soumyadip: oh okay
<nags> soumyadip: is it required even if we do ./autogen.sh ?
<soumyadip> yes
<nags> soumyadip: hmmm
<soumyadip> because autogen.sh calls libtoolize, which is in the libtool package
<Kamion> especially if you do ./autogen.sh
<nags> kagou / soumyadip: okay
<nags> the issue comes on doing make
<nags> after this change things are not working http://webcvs.freedesktop.org/ldtp/ldtp/configure.in?r1=1.4&r2=1.5
<Kamion> that's extremely unlikely to matter
<Kamion> it's just a version number bump
<soumyadip> eh ? why does gcc complain of no input files when I run make after autogen.sh ?
<Mithrandir> infinity: care to disable the daily livefs builds?
<Kamion> investigate the Makefile and trace back the missing bits through Makefile.in and Makefile.am if necessary
<nags> Kamion: sorry one more... 
<nags> Kamion: I have modified this line
<nags> Kamion: enable_localization=yes
<nags> Kamion: to enable_localization=no
<Kamion> nags: I'm totally unfamiliar with this package; I'm trying to help *you* investigate rather than investigating myself
<Amaranth> ogra: cool, be nice to know what i'm getting myself into :)
<nags> Kamion: okay :)
<Kamion> there should be a something_OBJECTS that gets substituted into the gcc link line
<Mithrandir> Riddell: when you get around, please do start testing current install images for flight-7.
<Mithrandir> ogra: please test current install images for flight-7
<ogra> Mithrandir, this week ???
<Mithrandir> ogra: yes.
<ogra> when are we supposed to work on stuff ? 
<nags> Kamion: http://pastebin.com/695882
<ogra> i cant always loose 2 days of a week for iso tests
<Mithrandir> ogra: before FF. :-)
<Mithrandir> ogra: well, previous release was special because of the crazy beta bug.
<ogra> so we'll keep the 2 week schedule ? 
<Kamion> you shouldn't be spending two days on Flight testing
<ogra> (apart from the beta2 exception)
<Kamion> ogra: depends
<Mithrandir> ogra: two or three; depending.
<ogra> Kamion, if i discove a bug i need to change it takes me half the day to wait for LP
<Kamion> we need to get good installer testing, and that has been hampered by bugs that affected lots of people
<Mithrandir> ogra: if you don't want flight-7 for edubuntu, that's fine with me, though.
<Kamion> ogra: I have three weeks to get a working installer; I can't do that without occasional releases
<Kamion> ogra: do something else while you're waiting, then
<ogra> Kamion, fully understood, but iso testing means i need to postpone my artwork changes again etc
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | LP upgraded, report issues on #launchpad | Flight-7 preparations in progress, uploads must be approved by Mithrandir
<ogra> Kamion, all i need to do would affect the isos, thats my prob (artwork docs etc)
<Kamion> you shouldn't be losing days of work due to this. you might have to queue uploads for a while, but that's not losing days of work.
<Kamion> you can upload them all in a batch the next day
<ogra> i need to test the changes, probably need to build a test iso etc thats all blocked then ... but well, i'lll start my rsyncs
<ivoks> Kamion: am... rebuild of package with unmet deps is automatic or needs manual push? (now, when all deps are ok)
<Kamion> Mithrandir: I have two things in progress; one is a ubiquity upload to fix a few bugs and save /var/log/partman to the installed system for better debugging; the other is a partman-* change for bug 21655
<Ubugtu> Malone bug 21655 in partman-basicfilesystems "Installer doesn't change disk labels as appropriate" [Wishlist,Confirmed]  http://launchpad.net/bugs/21655
<Kamion> ivoks: depends on the circumstances, ask infinity
<ivoks> ok, tnx
<ivoks> bye all
<Mithrandir> Kamion: sure, I'll wait for those.
<Mithrandir> Kamion: (hence my "test install cds" not "test cds")
<Mithrandir> I should tell janimo too.
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | LP upgraded, report issues on #launchpad | Flight-7 preparations in progress, uploads to main must be approved by Mithrandir
<Kamion> the partman change would affect install CDs too
<Mithrandir> oh, true.
<Mithrandir> (topicdiff: add "to main"; I don't want to review uploads to universe. :-)
<ogra> so what made my install CDs explode ?
<ogra> *sigh*
<ogra> *sigh*
<Amaranth> who handles accepting/rejecting SoC applications?
<Kamion> I'd have liked to get in a fix for the problem that ubiquity doesn't handle partman exceptions, but I doubt I have time
<ogra> Amaranth, JaneW 
<ogra> Amaranth, i updated the featurelist for willow on the wiki, would you mind making a LP spec out of it ?
<Amaranth> i'll see what i can do
<Amaranth> it'd be nice to know if it's going to be accepted/rejected though so i can know if i should look at other projects
<ogra> Amaranth, the more work you put into it now, the more likely it will be *your* project ;)
<Amaranth> heh
<ogra> (according to JaneW writing the spec is a major step here)
<Amaranth> ok
<nags> Kamion: when doing autogen.sh, I get this error message
<nags> src/Makefile.am:16: ldtp_SOURCES defined both conditionally and unconditionally
<nags> src/Makefile.am:76: ldtp_LDADD defined both conditionally and unconditionally
<nags> what this means ?
<Kamion> I suggest you talk to upstream
<nags> Kamion: okay
<Kamion> you could also look at info automake and search for "conditional" if you are upstream :-)
<herzi> mvo: you wanted me to remind you of https://launchpad.net/bugs/36127
<Ubugtu> Malone bug 36127 in grub "ESC menu doesn't work" [Normal,Needs info]  
<mvo> herzi: right, thanks
<nags> Kamion: okay :)
<G0SUB> mvo: ping
<mvo> G0SUB: pong
<infinity> Mithrandir: Doing so.
<G0SUB> mvo: can I PM?
<Kamion> Mithrandir: it's also worth noting that we're half-way through a kernel ABI change at the moment
<mvo> G0SUB: sure
<pitti> fabbione: alright, current dapper doesn't crash any more with the test
<Kamion> the last kernel upload didn't build on sparc, and l-r-m/linux-meta/debian-installer haven't been uploaded to match yet
<Mithrandir> Kamion: argh. :-/  Any idea when that'll be fixed?
<Kamion> Mithrandir: no ...
<Kamion> BenC: around?
<BenC> Kamion: yeah
<Kamion> BenC: did you notice the kernel FTBFS on sparc?
<infinity> I pinged him about it, but I think he was asleep. :)
<BenC> yeah, fixing it for next upload
<Kamion> ok, thanks
<infinity> Kamion: Can you just go ahead without the ABI bump, or does the mismatched source offend you terribly? :)
<Kamion> Mithrandir might want to know roughly when to expect it :)
<Mithrandir> BenC: what's the ETA of that upload?
<BenC> later today
<Kamion> infinity: hmm, it rather annoys me for Flight releases - gets messy
<Mithrandir> BenC: 'k, thanks.
<Kamion> although it's probably technically possible to go ahead without, if the seeds haven't been changed yet
<infinity> BenC: As in, the end of your workday. Ish?
<BenC> nah, probably more like my lunch time ish
<pitti> hi BenC 
<BenC> hey pitti
<BenC> pitti: I have that upload ready too
* infinity was planning on some LRM bugfixes with the ABI upload, but that won't happen before I have a chance to sleep and clear my head.
<pitti> \o/
<infinity> So, if you need to just do the ABI bump in my absense, go nuts, I guess.
<Mithrandir> infinity: we can just postpone until tomorrow.
<BenC> infinity: ok, I will probably just do an abi bump upload with this upload, so I can get linux-meta done, and people can start testing this last upload
<BenC> I want some feedback on ipw3945
<Kamion> hmm. if I've got a bit of clearance, I'll start looking at the ubiquity/partman work again; would be nice to have all the top diagnosed crashers fixed
<infinity> Mithrandir: I'm cool with that too, since I plan to do some mad initramfs-tools bugfixing during *my* tomorrow, which would means they'd get in for flight-7 your tomorrow. :)
<BenC> brb, gotta walk to the bus stop
<Mithrandir> infinity: ok, let's build the images and stuff tomorrow then.
<infinity> s/means/mean/
<infinity> Mithrandir: It's a date.  You have me as a flunky after I polish up initrafms-tools and LRM tomorrow.
<ogra> yeah, it would be great to have some preparation time
<Mithrandir> I'll leave the topic as is so we don't get any gung-ho uploads, though.
<Lathiat> hrm
<Lathiat> anyoejn got a pointer to a discussion on moving removable media into a sub menu of places?
<infinity> pitti: In the name of having rebuildable flight releases (okay, just cause I'm a pedant), care to upload that fixed m-f-l-a package sometime between now and tomorrow? :)
<Riddell> Mithrandir: is flight 7 just text-install or text-install and desktop CD?
<pitti> infinity: oops, yes, will do right now if Mithrandir ack's
<Mithrandir> Riddell: we've decided to wait building the cd images until tomorrow.
<infinity> pitti: I ack. :P
<Mithrandir> Riddell: since Kamion wants a few fixes into partman and we're in the middle of a kernel ABI transition
<Riddell> Mithrandir: ok
<herzi> mjg59: ping
<pitti> infinity: uploaded
<Kamion> Riddell: both, though
<Kamion> priority is on desktop if anything
<mjg59> herzi: Hi
<herzi> mjg59: you did some wacom stuff in ubuntu, can you take a look at https://launchpad.net/bugs/42653 please?
<Ubugtu> Malone bug 42653 in wacom-tools "Please add on-the-fly-rotation support" [Normal,Unconfirmed]  
<mjg59> Uh. We have that code.
<mjg59> Or did, last time I checked
<Hadaka> ah, right, tjanks
<Diziet> pitti: yay indeed.  It probably fixes other bugs too but we're relatively short of reports against gs-esp.
<pitti> StevenK: could you find out the reason for the empty pot file?
<infinity> dholbach: On my way to bed, but I'm bugging you first, so nya nya. :)
<highvoltage> dholbach: how's bugday?
<infinity> dholbach: In the latest goffice, the new package "libgoffice-1-2-dbg" doesn't have a Description field, which leads to soyuz rejecting the binary upload from my buildds.  Please fix. :)
<Mithrandir> dholbach: popcon seems to work now.
<janimo> nomed: meeting in #xubuntu
<janimo> Gloubi|AFK: meeting. when you stop being AFK :)
<Mithrandir> janimo: are you ok with releasing xubuntu flight-7 tomorrow?
<LaserJock> Mithrandir: cool, now if we can just get people to use it :-)
<janimo> Mithrandir:hmm. I am I guess
<janimo> ok
<nomed> janimo, #xubuntu or #ubuntu-meeting ?
<janimo> nomed: meeting
<janimo> sorry
<janimo> Mithrandir: tomorrow evening?
<Mithrandir> janimo: I'd need to have one of you test the images and such, but we'll do that tomorrow after kernel abi bump and such.
<Mithrandir> janimo: sounds good to me.  I'll make xubuntu images when I do the other images tomorrow morning.
<janimo> Mithrandir: sure. I can test the live at least
<Mithrandir> thanks.
<nomed> i can do that me too if needed
<janimo> Mithrandir: so the flight7 candidate is approximately todays iso + new kernel and such?
<janimo> nomed: sure.
<infinity> janimo: Dude, care to look at why thunar fails to build on amd64 and powerpc sometime in the next 24 hours?
<infinity> janimo: Just so your sources and binaries agree for Flight-7.
<janimo> infinity: I'll look tahnks
<Mithrandir> janimo: approximately, yes, but I'll roll image tomorrow and would appreciate to have the right set of images tested. :-)
<janimo> Mithrandir: ok
<Kamion> janimo: there'll be at least one new ubiquity upload before then with (if I get them done in time) one or two fairly substantial changes
<infinity> janimo: The sooner, the better, if you want Mithrandir to let it in. :)
<janimo> infinity: ok :)
<TheMuso> Mithrandir: http://www.themuso.id.au/ubuntu/casper -- Final bugfixes. Everything finally seems to check out here. No hurry as we do not know yet how we are going to get ubiquity to be fully accessible.
<Kamion> Mithrandir: (for a laugh, try selecting Vietnamese in a current image's ubiquity. You might need to 'echo SET debian-installer/locale en_US.UTF-8 | sudo debconf-communicate' afterwards to recover ...)
<janimo> otherwise it means no amd64 images, hence flight 7 postponed?
<janimo> xubuntu flight I mean
<Kamion> only if thunar is currently uninstallable on amd64/powerpc as a result
<Kamion> which, according to http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html, it isn't
<Kamion> isn't uninstallable, that is
<Mithrandir> TheMuso: "no hurry" as "I would like this into flight-7" or "this should go in whenever"?
<infinity> janimo: Yeah, it's not the end of the world if it doesn't build, but you have a better idea of the bugs beta testers are seeing if the versoins are the same on all arches and you have a baseline.
<infinity> janimo: So, it's in your best interest to make sure it builds, but not critical for Flight-7.
<TheMuso> Mithrandir: No hurry, as it should go in whenever.
<janimo> infinity: oh ok got it. I think upstream has just commited some fixes wrt 64bit 
<infinity> janimo: It /is/ critical for the final release, of course, we don't want to ship packages that don't build.
<infinity> janimo: 64-bit may explain amd64, that doesn't explain powerpc... (and you can't explain powerpc failing with endianess either, since hppa and sparc are also big-endian and they built fine)
<infinity> janimo: But, good luck anyway. :)
<janimo> infinity: thanks. I'll poke upstream if I can't figure it out
<tritium> simira: re: your question in #ubuntu, perhaps gnome-system-tools
<simira> tritium: thanks
<tritium> simira: the package description claims there's a tool for managing bootloaders, although I don't seem to find it...
<simira> tritium: I can't even find the package yet...
<tritium> ok
<infinity> tritium: We intentionally don't include said tool because it can muck up the user's grub config in ways that don't play nicely with our automagic updating stuff, IIRC.
<tritium> infinity: ah, okay.  Thanks.  Sorry, simira.
<simira> infinity: how can I play with grub without editing menu.lst directly, then?
<simira> tritium: np, I blame infinity, not you
<infinity> simira: At the moment, you can't, really.
<simira> infinity: I'm not really satisfied with that answer
* Mithrandir tickles simira, then runs off home.
<infinity> zul: I assume your xlockmore changelog doesn't actually match the source?
<infinity> zul: (Seems to imply that the binary is installed in /usr/X11R6/bin, when it should just be in /usr/bin)
<Kamion> simira: unfortunately, until somebody fixes boot-admin not to cause more serious bugs every time somebody runs it, the alternative is worse
<simira> Kamion: ok, I'll make Tollef fix it, then. Or make him teach me how to. :D
<zul> infinity: it should be /usr/bin yes
<zul> whoops..typo that should be /usr/bin in the changelog
<abattoir> Kamion: hello... I'd like to make a Kubuntu OEM Installer as part of Google SoC... I'd like to know if the "OEM installation mode" in the CD requires a blank harddisk, or can it use a partition?
<tepsipakki> Kamion: just wanted to tell you that the multiverse/local-repository-support in apt-setup works like a charm, thanks :)
<Kamion> tepsipakki: great, good to hear
<Kamion> abattoir: it's the same as any other Ubuntu installation mode; you can get to the manual partitioner if you want
<Kamion> abattoir: a fair chunk of the work in doing a Kubuntu OEM installer is in making the core code frontend-independent, much the same way as Ubiquity does
<Kamion> also, my feeling is that once you do that it stops being worth having separate glade files for each component, and maybe the OEM installer's UI should just all be in the oem-config package
<Kamion> which would reduce our diff from Debian in the component packages so would probably be a good thing anyway
<abattoir> Kamion: I havent looked at the Ubuntu Installer yet... but I was thinking of an application which runs under KDE, which helps the OEMs tweak 'their Version' of the OS...
<abattoir> eg. install drivers, configure KDE, change elements of the Desktop etc...
<Kamion> abattoir: that's rather different to the OEM installer
<Kamion> abattoir: the OEM installer is something that is run when the end user first starts up their new computer, and asks them for personal details
<Kamion> abattoir: I'm sure what you describe is useful, but could you call it something else? :-)
<ogra_> i think thats rather near to my branding tool proposal
<zakame> hmm what's up with https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/BugReportingRoadmap ?
<abattoir> Kamion: My proposal consists of twin applications, the second one is what you describe.....
<infinity> dholbach: Merry Christmas, I just uploaded the fix for that goffice bug.  You may disregard my previous messages. :)
<Kamion> abattoir: ok
<Kinnison> infinity: I thought I told you to go to bed
* seb128 wonders what is dholbach doing for some hours now
<infinity> Kinnison: I told myself to do that too.  I keep not getting around to it.
<abattoir> Kamion: I have a mockup http://abattoir.4t.com/Images/hlada.png
<abattoir> is this what you are referring to?
<Kamion> abattoir: that looks similar to the OEM installer, yes, although we don't have any provision for network configuration in it yet
<Kamion> partly because I figured just assuming DHCP would do for the majority ...
<Kamion> what's the "Register" step?
<pitti> seb128: his dog ate him
<abattoir> That depends on the OEM, they could make the user register w/ them if they want...
<Kamion> if you'll take my advise, don't do "First Name" and "Last Name"
<abattoir> do you want to see my proposal?
<Kamion> advice, rather
<seb128> pitti: probably something like that ;)
<abattoir> Kamion: ok...
<infinity> I prefer freeform "Full name", and they can fill it out however they like.
<Kamion> names are complicated when you consider conventions in different countries; trying to split them up is more pain than it's worth
<pitti> seb128: if you miss him, shall I call him?
* infinity ponders good ol' wookey@debian.org
<Kamion> abattoir: feel free to e-mail it to me, cjwatson@ubuntu.com; though I don't promise to reply immediately :)
<pitti> infinity: did you plan to update mysql to 5.0.21 in dapper?
<seb128> pitti: no, no real hurry, I've just some bugs where I could use his opinion but that can wait :)
<infinity> pitti: Yes, I got the UVF exception from mdz yesterday.
<pitti> infinity: cool; it fixes a security issue; I'll toss you the CVE as soon as I have it
<pitti> infinity: (patch is relatively easy, I'll care for stables)
<seb128> pitti: hum, I've just noticed you are not on #ubuntu-bugs for the bug day ... :)
<infinity> pitti: Oh, thanks, if you get it to me before the Debian upload, I'll make sure it's in the Debian changelod for 5.0.21-1
<pitti> seb128: check again :)
<abattoir> Kamion: I have already submitted it through Google, I just wanted some doubts cleared :) ...
<seb128> pitti: hehe
<seb128> pitti: german slackers!
<pitti> seb128: I just fixed your gdm, dude :) (in stables)
<seb128> ah, nice
<Kamion> abattoir: I think you probably want to start looking at oem-config to get an idea of what's available/doable. (Ignore the crap UI. If Ubiquity weren't taking up so much of my time I'd fix it up before Dapper, but I think it'll have to wait until Edgy now.)
<seb128> pitti: fort that .ICEauthority permissions bug?
<abattoir> Kamion: Ok, thanks :)
<pitti> seb128: yes
<seb128> pitti: be careful, you want that change too: http://cvs.gnome.org/viewcvs/gdm2/daemon/slave.c?r1=1.325&r2=1.326
<pitti> seb128: I know, I have it
<seb128> pitti: that was an issue with 2.14.4 which has been fixed monday, without it the gid was not set correctly
<seb128> k
<pitti> seb128: and I tested it over and over again in a clean real breezy
<seb128> better to make sure so you don't have to do it again in case you didn't nice ;)
<seb128> should be fine so
<pitti> seb128: right, thank you
* seb128 hugs pitti
<pitti> seb128: I just don't understand why all this mess is necesary in the first place; just rm'ing the file should work, too, or not?
* pitti hugs seb128, too
<seb128> not sure, I've not tried to understand that code to be honest ;)
<seb128> I just updated to new version which was marked as fixing the issue for dapper
<pitti> I understood the old and new code, and I think the new one is reasonable, but it still seems way too complicated to me
<pitti> seb128: yep, 2.14.4 + that patch should be fine
<seb128> feel free to open a bug against gdm on bugzilla.gnome.org
<seb128> upstream is really nice, and open to discussion
<seb128> a little too verbose to my taste (like you have a quick question and you get several pages of details explanations for it) :)
<ogra_> Amaranth, hey cool, thanks a lot :)
<Amaranth> ogra_: ?
* ogra_ just saw the wiki mail now
<Amaranth> my spec writing skills are bad, was hoping you could flesh out any details that might be needed
<ogra_> Amaranth, just having that as a base is already enough for now
<Amaranth> had a comment on my application, said i needed to show my skill-set :)
<ogra_> i'll flesh it out later, it was just important that we have *anything*
<ogra_> point them to alacarte ...
<Amaranth> i did :)
<Amaranth> it was from pygi, i think
<Amaranth> crap, going to be late for school
<Amaranth> back later
<ogra_> ciao and thanks again
<simira> mvo: is kernels supposed to be updated with update-manager?
<jsgotangco> yeah it could
<pitti> Mithrandir: oops, shit, my autofingers stroke me
<pitti> Mithrandir: I uploaded a security fix of libnasl
<pitti> Mithrandir: shouldn't be on the CD, and is not disruptive; sorry, though, I thought too late
<Mithrandir> pitti: sure, no problem.
<Mithrandir> pitti: as a penance, you'll have to develop a tool called autofingers which does something cool.
<simira> hmmm
<pitti> heh, several things come to my mind at once :)
* pitti uploads to stables instead to not disturb any further :)
<Kamion> pitti: SURELY you mean "struck" or something. :-)
<lamont> Kamion: that changes the whole meaning though.....
<pitti> yay my ISP
<pitti> Kamion: the autofinger tool Mithrandir wants should really be something that autocorrects my Denglish
<pitti> hey lamont 
<dholbach> Mithrandir: you rock
<Mithrandir> dholbach: it'll rock even more when we have a css that doesn't suck
<dholbach> probably :)
* dholbach looks
* tseng installs popcon to drive up the mono numbers
<simira> popcorn?
<simira> hm
<thom> tseng: not so much installing as turning it on :-)
<tseng> simira: no, popcon.
<tseng> hey thom 
<tseng> hows things?
<thom> good ta. you?
<tseng> good.
<LaserJock> anybody know what "touch: missing file operand" means when I do dpkg -i ?
<tseng> LaserJock: could you be more specific? is that from a failing postinst?
<simira> oh, popcon.
<simira> hm, wll
<simira> hi thom :)
<LaserJock> tseng: post-remove
<tseng> LaserJock: there you go. blame the package
<tseng> their script is broken
<LaserJock> tseng: it isn't in the package, it must be one of the added ones
<bddebian> Howdy peoples
<pitti> hi bddebian 
<bddebian> Hi pitti
<Tonio_> hi
<kyr0> hi
<bddebian> Hello kyr0
<kyr0> are there package cd's/dvd's with all packages from a currently stable ubuntu(breeze) avaliable for download?
<kyr0> the main problem is, that many people dont have a working internet connection or dont want to download X GB of data from the internet. If it would be possible to burn all available packages on 4 or 5 dvd's it would be much easier to share this great distribution!
* desrt hugs benc
<stratus> kyr0, http://cdimage.ubuntu.com/releases/breezy/release/
<zul_> is there a template for writing a spec?
<kyr0> stratus: hmm is this dvd really including all packages? 
* kyr0 cant imagine
<stratus> zul_, https://wiki.ubuntu.com/SpecTemplate ?
<stratus> kyr0, it includes the supported packages, nothing from 'universe' btw.
<zul_> thanks
<stratus> zul_, you're welcome
<bddebian> Kamion: What does Reason NBS mean in the removal of python2.1?
<kyr0> stratus: ah okay :) 
<ogra> hey stratus 
<stratus> ogra, pong :)
<ogra> some days ago a guy asked me for help how to set up debians new ltsp
<ogra> i told him to use ltsp-build-client which he couldnt find apparently, why did you rename it ?
<stratus> we didn't
<ogra> seemed its called -make-client
<ogra> hmm
<ogra> thats strange
<ogra> i have manpages btw
<stratus> ltsp-make-client looks like something in debian-edu (skolelinux)
<ogra> just merging them in my package
<ogra> aha !
<ogra> peres fault !
<stratus> i think it's a pere script, but ltsp-build-client is there
<stratus> i think he was going to merge ltsp-make-client features in ltsp-build-client, but it's debian-edu only
<ogra> yep, but then i understand
<desrt> is there any way to see a list of packages that are current ftbfs?
<ogra> desrt, LP
<desrt> google is really bad at finding stuff on lp
<ogra> teach it !
<ogra> https://launchpad.net/distros/ubuntu/+builds
<desrt> nice.
<ogra> there is also a dapper link i think
<stratus> ogra, ltsp-server 0.82debian2 (latest in Debian) has no ltsp-make-client. I've checked again. It seems that the guy was installing a branch that is being used in debian-edu, but i dunno
<ogra> https://launchpad.net/distros/ubuntu/dapper/+builds
<ogra> thats it
* desrt is wondering why linux-source was updated last night with no corresponding linux-image upgrade
<desrt> a hah.  sparc ftbfs
<ogra> stratus, its fine, i just thought you had renamed it everywhere
<stratus> ogra, no way, not with me alive btw. heh
<ogra> :)
<stratus> ogra, are you still subscribed in pkg-ltsp-devel ?
<ogra> yep
<ogra> i saw youre going for local swap as the main feature ?
<stratus> did you see my message about pkg-ltsp work during debcamp?
<ogra> yep
<ogra> i wont be there, too much edubuntu prerelease workv 
<stratus> no, the local swap thing was just a comment in a bug pere opened
<ogra> ah, k
<stratus> oh, it would be good
<ogra> my biggest target for next release is localdev support
<desrt> alef-null; nice nick
<ogra> but without reinventing the wheel with ldm
<ogra> err
<ogra> lbus, sorry
<stratus> we would like to implement the profiles thing in ltsp, splitting the source in more sane binaries and organize ltsp-build-client
<ogra> i also agree with vagrant that we should redo -update-kernels
<stratus> the major goal during debcamp is share even more code between the projects, with the 'profile' thing, so every hack you need to apply into ltsp-build-client should go in a separate subdirectory 'ubuntu'
<stratus> sure
<stratus> do you think it's possible that we reach a point where we've basically the same source package in debian, ubuntu (edubuntu), sacix and debian-edu but with different 'profiles' ?
<ogra> two other things i'd like to have are thick client support (running all of the desktop on the client) and a quasi kiosk mode (running firefox fullscreen locally instead of a real session)
<ogra> stratus, sure
<stratus> i think today it's just a matter of clean up the code and organize stuff to read the changes (or run scripts) from a subdirectory per profile
<ogra> but i wont be able to look into it much before release anyway
<stratus> ogra, great.
<stratus> ogra, well but it seems that at least me and otavio will hack on it during debcamp, probably vagrantc will join us too.
<stratus> ogra, otavio told me about revamp the 'localapps' thing once we had in the package, i dunno if it will be possible to run all of the desktop on the client, but it should be.
<ogra> it is, i know highvoltage did it in breezy already
<stratus> ogra, i had a chat with otavio for some hours and we even discussed write some stuff from scratch in python, but vagrant can't code in python. :(
<ogra> its just some tweakage to ltsp-build-client to install the desktop in the chroot
<ogra> bah, so he's refusing progress ?
<ogra> :)
<stratus> ogra, this kind of tweakage in ltsp-build-client that we want to move to a 'profile' thing, the basic profiles should be 'auto discovered' (lsbrelease), the rest are 'localapps' and stuff like that
<ogra> i'd like to be able to use an --option to ltsp-build-client
<stratus> ogra, no, it seems that otavio tried to teach him without too much success. Well, i think he can handle the 'subdirectory' thing that we should keep in shell script, we've a lot of code and we don't need to trash everything. The best thing we can do is write ltsp-build-client itself again.
<ogra> so some of it needs to be hardcoded i guess ... (a bunch of default modes)
<ogra> indeed there can be profile files for it
<ogra> whats wrong with ltsp-build-client in shell ? 
<stratus> we were thinking about profile directories and not files, so you can drop a shell script there and it will run
<ogra> i wouldnt rewrite the existing stuff
<stratus> that's ugly
<ogra> but its shell now and works fine 
<highvoltage> ogra: do you think ldap is likely to happen for edgy on edubuntu?
<stratus> the idea is move ltsp-build-client to that directories and write a new ltsp-build-client to run that code from scratch, do you see?
<ogra> i see no reason to put time into rewriting it
<stratus> we will need to write (at least in part) code to run the profiles in their directories
<ogra> highvoltage, no idea ... write a spec ;)
<highvoltage> ogra: the biggest problem with dislkless fat when i tried it was proper authentication. if ldap works easily in edubuntu then it's much easier
<highvoltage> ogra: ok :)
<stratus> see, we will move and split ltsp-build-client shell script code into subdirectories
<stratus> we need code to identify what needs to be processed and run in each subdirectory, so... ;}
<ogra> stratus, i'd really like to rather put my limited time into getting the whole thing feature complete before rewriting half the world
<stratus> ogra, we won't really.
<stratus> ogra, ltsp-build-client would be for example: "common/ ubuntu/ debian/ ltsp-build-client.py"
<stratus> ogra, common/ contains almost all the current code in ltsp-build-client (shell script)
<ogra> i understand what you say, but i dont really understand the reason 
<ogra> whats wrong with enhancing the current way the script works ?
<stratus> share all the code, except for the project subdirectories
<ogra> we already cover three distros with the same codebase
<stratus> the code is wrong, that's the problem
<Riddell> Kinnison, Kamion: in ubiquity does gparted not do any formatting any more?
<stratus> almost the same codebase
<ogra> i dont see where its wrong
<ogra> my codebase is at least identical with peres and vagrants bzr archives
<stratus> well, if i want to implement 'localapps' now i won't share that with you instantly
<ogra> not if you move away from our common codebase 
<ogra> thats right
<stratus> i could just drop some shell scripts in debian/ subdirectory or write a new profile 'localapps/'
<stratus> that would be saner, imho
<ogra> yes, but nobody apart from debian could benefit from it
<stratus> no, you would benefit instantly just merging from my bzr repo
<ogra> i'd rather see us collaborating on the same code and getting it right for us all instead of splitting up development
<stratus> no, we aren't splitting really ogra
<stratus> we're organizing it better, imho
<ogra> it looks to me like a split 
<ogra> everybody will work in his subdir
<ogra> over time we'll part 
<stratus> no, everybody will work in common <-
<ogra> instead of finding a solution to the problem that *just works* for everyone
<stratus> the bits that are different (that can't be merged) will go into debian/ or ubuntu/ or sacix/
<stratus> there's no solution that *just works* for everyone
<ogra> until now that worked
<stratus> see, i want epiphany as default browser in 'localapps' and you want firefox, what we're going to do in our current scenario?
<ogra> i dont see why it should change
<stratus> just an example
<ogra> i can set that in the config file pere implemented
<stratus> in my view, it would be better not install any browser in 'localapps/' profile and subdirectory and let you install FF in 'ubuntu/', and i do the epy install in 'sacix/'
<ogra> we wont have idenical packages
<stratus> sure
<ogra> so my config can differ from yours
<ogra> but we can still use the same code atm
<stratus> i see, but what you said isn't much different than keep something like
<stratus> 'common/ localapps/ ltsp-build-client'
<stratus> right?
<ogra> nope
<stratus> what's wrong with that?
<ogra> why should i have debian/ sacix/ dirs in ubuntu ? 
<ogra> there is no need for me
<stratus> no, no
<stratus> 'common/ localapps/ ltsp-build-client'
<stratus> there's no debian/ or sacix/ above
<ogra> as there is no need for debian to have an ubuntu subdir
<ogra> and i dont see the need for the two other sibdirs either
<ogra> i run ltsp-build-client once and never again
<ogra> so it can read its config from a conffile i ship in the package+
<ogra> and do the stuff we need in the code 
<ogra> whats the purpose of the subdirs in that scenario ?
<stratus> well, i think ltsp-build-client code is rather ugly and could be splitted in a 'foo/' subdirectory like we do with patches in packages, imho
<ogra> lest clean the code then, but not add complexity
<stratus> there's no complexity there, it's just using our approach with packages
<ogra> but ltsp-build-client is a one time script, not a package
<stratus> we don't have just a patch file in debian/ and a simple config file
<stratus> you can consider that debian/rules is a 'one time script' too
<ogra> no we even have a bunch of different patch systems
<ogra> thats what makes packaging and ugly job sometimes
<ogra> s/and/an
<ogra> yes, but debian/rules and the patches have a totally different target
<stratus> ogra, well ok, it would be good if you drop a message in pkg-ltsp-devel  replying to my 'ltsp modularization' thing to let the others know about your opinion, please. I've a meeting in minutes.
<ogra> ok
<ogra> i'd be sad if we fragmented our development, really
<ogra> over time the subdirs will be the placew we do our work
<stratus> imo yes, but we can opt for a 'common' subdir and not 'debian/ and ubuntu/' as you pointed out, it was just open room for stuff like 'localapps', but if you think we could implement that without using subdirs to drop small shell scripts, i would like to hear the others.
<ogra> yep
<stratus> we're too closer to the debcamp to start writing code that won't be used by others.
<ogra> we just had an impressing amount of collaboration during this release, i'd not like to loose that
<stratus> cool.
<stratus> btw, what's your opinion on debian #365578 ?
<Ubugtu> Debian bug 365578 in ltsp-client "Subject: ltsp-client: Should usage local swap partitions when found" [Wishlist,Open]  http://bugs.debian.org/365578
<ogra> sure, lets do that, i think thats implementable in less than 5 lines of conde
<ogra> but it will slow down the boot
<ogra> ugh
<stratus> it should be configurable then
<ogra> especially if you explicitly run mkswap on every boot 
<stratus> mkswap will run just if there's a swap partition, did you see?
<stratus> there's a sfdisk call to check for swap partitions
<alef0> solaris 9 and older had partition type 82, too. that's not a nice patch...
<ogra> yes, but if there is one and for what reason ever thats a 1G partition on a slow 2G drive, your boot will last eternal
<ogra> alef0, agreed 
<stratus> ogra, sure, it's a option candidate IMHO.
<ogra> but you can check for the swap keyword or something
<ogra> thats easily fixed
<highvoltage> ogra: this will of course be disabled by default in ubuntu ltsp, right?
<ogra> highvoltage, yes
<stratus> ogra, i've 15 telecentres around that contain only real thin-clients so no need to even call sfdisk to probe.
<ogra> should be a lts.conf option
<stratus> ogra, the sfdisk call greps for the swap keyword, yes.
<stratus> ogra, the problem as you pointed out if there's a huge swap partition and the drive is too slow.
<ogra> not in the patch in the bug
<stratus> ogra, read the "awk '/ 82 /" bit. I asked pere, why not used the word 'swap'. sfdisk outputs both the type no. (82) and the name (swap)
<ogra> yep
<ogra> so it should match swap and not 82 :)
<stratus> ogra, that was my comment in the bug yesterday :P
<ogra> ohoel, sorry i only looked at the patch :)
<stratus> ogra, np heh
<ogra> grmbl
<ohoel> mohaha
<ogra> oh indeed
<mxpxpod> pitti: !
<Kinnison> Riddell: No formatting, no
<mxpxpod> pitti: I heard you have n-m working with an airport extreme
<Kinnison> Riddell: It passes on the desire for the formatting to ubiquity which is then responsible for formatting during the installation phase
<Riddell> Kinnison: but it does change the partition tables presumably?
<Kinnison> Riddell: aye, mostly because I couldn't get it to spew instructions instead
<mxpxpod> shoot
<nomed> i've seen the entry #12 on "Ubuntu SoC Projects" .. nobody considered pinot+xapian?
<Riddell> Kinnison: and it passes on the instructions with the "- FORMAT /dev/hda5 ext2" strings on stdout?
<nomed> who's the person i should contact to suggest it ?
<Kinnison> Riddell: aye
<Kinnison> Riddell: or at least it did last time I had anything to do with it
<Kinnison> Riddell: which was many weeks ago
<Riddell> Kinnison: thanks
<mxpxpod> pitti: are you there?
<mxpxpod> arg
<Riddell> mdz: what happened to the anastacia review?
<mdz> Riddell: it's looking a lot better: http://people.ubuntu.com/~cjwatson/anastacia.txt
<mdz> Keybuk seems to have executed the changes we discussed
<Riddell> mdz: could you promote wlassistant and knetworkmanager?
<mdz> Riddell: do they have approved reports for main?
<Riddell> mdz: they do
<mdz> Riddell: what's the difference between knetworkmanager and network-manager-kde?
<Riddell> knetworkmanager is the upstream name, network-manager-kde is the package name used by debian which is a meta package current in ubuntu
<mdz> Riddell: I'm in a meeting right now; I'll have a look after it's over (probably ~1 hour)
<Riddell> sure
<highvoltage> OMG, on the South African "the weakest link", they just asked, "Who founded the Ubuntu Foundation, a fund to provide support for the Ubuntu Linux distribuion, in 2005" !!!
<Riddell> oh actually pitti, did you look at knetworkmanager?
<bddebian> Hmm, I don't think I can touch kmail/kdepim :-(
<Riddell> bddebian: why not?
<pitti> Riddell: I thought I did
<pitti> Riddell: ah, yes, there was some confusion because I saw two different wifi managers
<pitti> Riddell: I'd be fine with either, a bit less fine with both, though
<mxpxpod> pitti: I heard you got n-m to work with an AE
<jjesse> knetworkmanager gets my vote :)
<Riddell> pitti: it's not marked as approved on https://wiki.kubuntu.org/MainInclusionReportKNetworkManager
<pitti> mxpxpod: temporarily; now it requires wpasupplicant again, so it doesn't any more for me
<mxpxpod> pitti: suck
<pitti> Riddell: please regard it as approved, I just forgot to do it
<Riddell> pitti: wlassistant is replacement for kwifimanager, knetworkmanager isn't installed by default
<Riddell> pitti: thanks
<bddebian> Riddell: I think it's over my head for bug #39944
<Ubugtu> Malone bug 39944 in kdepim "Set filters are ineffective" [Normal,Needs info]  http://launchpad.net/bugs/39944
<mxpxpod> pitti: what's the deal with wpasupplicat? why doesn't it work with AE?
<pitti> mxpxpod: don't ask me, but it didn't work with my netgear either
<pitti> anyway, I have to go, sorry
<pitti> Taekwondo time
<mxpxpod> pitti: later
<bluefoxicy> Hey any ideas on forcing synaptic to list all orphaned packages?
<bluefoxicy> I tried moving /usr/bin/deborphan to /usr/bin/deborphan.real and making deborphan a script that does "deborphan $* -a" but synaptic just displays a blank deborphan tag then
<mvo> bluefoxicy: my experience with deborphan -a was that it gives you a lot of false positives
<mvo> bluefoxicy: but you can always patch the source
* mvo hugs glatzor
<bluefoxicy> mvo: it gives me things like ubuntu-desktop
* glatzor hugs mvo
<bluefoxicy> I'm aware of how it operates
<LaserJock> mvo: does it work better than aptitude, do you know?
<mvo> bluefoxicy: if you patch synaptic, please make it a config option (using the _config->Find() system of apt/synaptic) so that people can easily overwrite the options in their configs
<mvo> LaserJock: aptitude generally has more knowledge and works better (because it knows about automatic installs and tracks them)
* bluefoxicy does not know how to code in python or whatever the hell synaptic is written in
<bluefoxicy> oh wow, it's in C?  I thought apt and dpkg and friends were python o.o
<mvo> bluefoxicy: c++
<bluefoxicy> ah
<LaserJock> bluefoxicy: hehe, maybe if sabdfl wrote them ;-)
<bluefoxicy> it still seems to be deliberately making sure you don't do anything besides libraries.  :/
* bluefoxicy just removed exim4 from his system, no idea how THAT got there
<Kinnison> some packages seem to depend on 'mailx' which often pulls MTAs in
<bluefoxicy> ah
<bluefoxicy> but exim left without complaint of other packages
<glatzor> mvo: could you give me a bug number with a milestone?
<mdke> Kinnison: around?
<Kinnison> ish
<mdke> Kinnison: ok, if not maybe you can respond later. Are you still taking care of gpm? If so, can you take a look at https://launchpad.net/bugs/39448 ?
<Ubugtu> Malone bug 39448 in gnome-power-manager "Screen is not locked when it should be" [Normal,Confirmed]  
<Kinnison> mdke: One sec
<Kinnison> mdke: it is working as designed. however I can see the response to that
<mdke> Kinnison: yes, the bug is about the design.
<Kinnison> mdke: g-p-m can be asked to override the screensaver's lock choice
<Kinnison> mdke: You need to get mjg59 and/or mdz to agree if you want me to change the default
<Kinnison> mdke: to test it, open gconf-editor and go to /apps/gnome-power-manager
<Kinnison> mdke: change the lock_use_screensaver_settings to false
<mdke> Kinnison: mdz replied on the mailing list at the link on the bug report (but I'm not sure of his view). mjg59 has no view.
<Kinnison> yeah, adding UI at this point is a no-go
<ogra> mdke, he just doesnt tell you
<Kinnison> but I can change the default of the lock_use_screensaver_settings key
<Kinnison> mdke: please try that and tell me if it behaves as you want subsequently
<mdke> Kinnison: I will, thanks
<Kinnison> mdke: comment on the bug if it turns out right
* Kinnison just gave up on his lp-bugs folder and marked all as read
<Kinnison> I had over 650 from my illness, no way I can catch that up, ever
* mdke nods
<Kinnison> so I'll notice if you add new comments :-)
<mdke> Kinnison: will do. Btw, I tried to work around it and turned "lock screen" on in my screensaver preferences. now my screen gets locked even when I unplug the AC adapter ;)
<mdke> kinda two extremes
<Kinnison> mdke: impressive
<Kinnison> 2.14.3-0ubuntu1 should stop a lot of the random screenlocking issues from g-p-m
<Kinnison> so if you've not upgraded g-p-m in a while, do so
<Kinnison> I have to go shopping now, ciau
<mdke> i'm up to date. ciao
<mdz> mdke: I thought I made my position clear in the bug report
<mdke> mdz: ah, I didn't see your comment on the bug
<mdke> lemme check
<mdke> mdz: you didn't comment. You said this on the mailing list: https://lists.ubuntu.com/archives/ubuntu-devel/2006-April/017321.html but I wasn't sure whether you meant that the default should be changed or not.
<pygi> GOSUB: around?
<dholbach> Diziet: _jason on #ubuntu-bugs might need your help to debug firefox
<Amaranth> pygi: Did you get my updated application?
<Amaranth> pygi: Travis Watkins
<pygi> Amaranth: what have you applied for ? name of application?
<Amaranth> pygi: willow
<pygi> Amaranth: ah, indeed...I'll look into it now 
<Amaranth> i added some info about projects i've worked on and a link to the launchpad spec
<pygi> Amaranth: ah, oki
<pygi> got it 
<mdke> oh god, it's catching
<Amaranth> cool
<Amaranth> mdke: ?
<pygi> Amaranth: thanks for that 
<mdke> the  symbol
<Amaranth> mdke: the abuse of katakana for a smiley?
<mdke> ah, it's a smiley eh?
<mdz> mdke: the default is not very important to me
<pygi> mdke: want me to stop ? :P
<mdz> mdke: so long as there is a preference
<mdz> mdke: if we can't trivially add a preference, the old default should be restored
<pygi> Amaranth: if I have any other remarks, I'll make sure you know them :P
<Amaranth> pygi: ok, thanks
<mdke> mdz: yay. that's my view too.
<highvoltage> mdz: we need some help on ubuntu kernels, and you're the best person i can think of to ask, are you terribly busy, would would you mind joining #ubuntu-server?
<mdke> mdz: it looks to me like there are gconf keys for it, but I'm not sure they are doing what they say.
<mdke> pygi: nah, was just kidding
<mdke> mdz: I'm gonna play with them and post on the bug. If we find a way to restore the default, I'll cite you as approving it in the absence of a preference.
<Surak> http://www.ubuntu.com/testing
<Surak> ops, the http://www.ubuntu.com/testing misses dapper beta 2. Who's the one we should notify about this?
<mdke> Surak: #ubuntu-doc
<Surak> thanks
<ivoks> mdz: ping
<ivoks> mdz: what's procedure for sources in queue which now have solved deps?
<Kamion> bddebian: "Not Built from Source", i.e. binary that's no longer built
<Kamion> Riddell: that's correct; all the formatting is left to partman
<Kamion> Riddell: (oh, Kinnison already answered you)
* Kinnison hugs Kamion 
<Kinnison> how's the househunt?
<Kamion> Kinnison: offer accepted :-)
<Kinnison> Kamion: excellent
<Kinnison> Kamion: mortgage sorted?
<mdke> congrats Kamion 
<Kinnison> Kamion: if you manage to move before me, I will have to murder you mercilessly in your sleep
<Kamion> Kinnison: got a promise from the bank some time ago for about 1.4 times as much as I now need, so it should be OK, but I'll go and talk to them tomorrow
<mdke> Kinnison: unsetting that gconf key works for resuming from sleep, but not the lock screen function button
<Kinnison> mdke: the lock-screen function button belongs to the screensaver iirc
<mdke> Kinnison: oh.
<mdke> Kinnison: so it's not possible you think to have the lock screen button actually lock the screen, but have the screensaver not lock when it kicks in?
<mdz> Kamion: I just did an amd64 ubiquity install (2006-05-02) and noticed that lines were still being commented out in sources.list based on failures.  did that fix not make it into that build?  the verification also took a long time for some reason; I wonder if we shouldn't just skip it, if that isn't what you did already
<_ion> What's the correct channel to discuss the development of dapper+1?
<Kamion> mdz: I'm afraid I don't immediately know what the problem is; can you please file a bug and describe your environment as accurately as possible?
<pygi> _ion: well, still this one =P
<_ion> pygi: Ok. :-)
<Kamion> mdz: I have a change in my local choose-mirror tree already to skip the verification, but haven't tested it yet
<Kamion> well, to skip part of the verification anyway
<Kamion> mdz: I did test a rather older build and couldn't reproduce the problem, so it must be transient in some odd way
<_ion> Will using zsync be considered for the "apt-get update" function in dapper+1?
<mdz> _ion: if someone is personally interested in working on it, yes
<mdz> Kamion: should I rather wait for your new choose-mirror and test that?
<_ion> I might try, if i'm feeling good enough soon enough.
<Kamion> mdz: no, that will have no effect on this particular problem
<Kamion> on the commenting out, that is
<pygi> _ion: still not good? :-/
<mdz> hmm, weird
<mdz> ok
<_ion> pygi: Nope.
* Kinnison goes for dinner etc
<pygi> _ion: arghh
<mdz> Kamion: choose-mirror or apt-setup?
<Kamion> mdz: apt-setup
<Kamion> both choose-mirror and apt-setup attempt to talk to the mirror
<Kamion> disabling both is feasible but we have to be careful not to break error messages on custom mirror setups as opposed to ones from the masterlist
<Kamion> it should still contact and verify custom mirrors
<Surak> There are some untranslated strings in isolinux directory. How are those translated? Are they in malone?
<kagou> see you later
<Kamion> Surak: gfxboot-theme-ubuntu and debian-installer help
<Kamion> Surak: and s/malone/rosetta/
<Surak> ops!
<Kamion> any other untranslated strings are probably untranslatable and too late to change at this point in time
<pygi> _ion: have you added that about zsync to SoC page?
<Surak> There's only one untranslated in pt_BR, which seems quite odd. I'll take a look. Thanks, Kamion. And oh by the way, thanks for yesterday at #ubuntu-meeting.
<_ion> pygi: No, i haven't. A good idea.
<bddebian> Kamion: Ah, OK, thx
<pygi> _ion: it's added already ;p
<_ion> Oh. :-)
<pygi> _ion:that's why I am asking
<Kamion> Surak: there are a couple of strings in gfxboot-theme-ubuntu that were introduced after the last time I imported translations from Rosetta
<_ion> Apparently i'm not the only one who has had that idea. :-)
<Kamion> if it's up to date in Rosetta, it probably just needs me to import those, which I will do soonih
<Kamion> soonish
<pygi> _ion: https://wiki.ubuntu.com/GoogleSoC2006#head-7b2fda01123e6f781ea1ba762a2ba24a1175033d
<Kamion> "Start Ubuntu in safe ^graphics mode" might be the one you're seeing
<Surak> indeed
<_ion> tiff (3.7.4-1ubuntu2) dapper; urgency=low
<_ion>   * SECURITY UPDATE: DoS and arbitrary code execution with crafted TIFF files.
<_ion> Shouldn't such updates have urgency=high?
<Kamion> probably, but it makes little difference in Ubuntu
<tseng> he probably forgot
<Kamion> to my knowledge there are two things urgency= is used for, apart from humans looking at the changelog: (1) propagation into Debian's testing distribution, (2) sorting of changelog entries presented by apt-listchanges
<Kamion> without (1), people often don't worry much about (2)
<Surak> Kamion: this and the help.
<pygi> _ion: feel free to make a detailed spec tho
<seb128> mdke: around?
<Kamion> woo, I have ubiquity displaying partman errors now
<Kamion> (after a fashion)
<Kamion> need to check that I got the KDE frontend changes right though
<dholbach> night guys
<mvo> good night dholbach
<seb128> 'night dholbach
<seb128> mdz: do we need an approval to break string,UI freeze or just to warn l10n teams and documentation team?
<mdz> seb128: for string freeze we agreed that notification was enough
<mdz> seb128: for stuff which affects the doc team, we haven't discussed it yet
<mdz> perhaps ask mdke
<seb128> mdz: the issue is http://people.ubuntu.com/~seb128/gnome-keyring-password.png
<seb128> mdz: the entries on that dialog are "_Password:" and "_Confirm password:"
<seb128> mdz: but they have no label atm, which is sort of weird ... that's fixed upstream I was considering taking the patch
<seb128> I'll ping mdke (I did some min ago but looks like he's not around atm)
<mdz> seb128: and there are no translations for those strings yet?
<seb128> mdz: not to gnome-keyring no
<mdz> seb128: I think it should be OK with the doc team, they probably don't have screenshots of that dialog, but best to confirm I think
<seb128> k, I'll wait on mdke then
<opi> who, beside JDub, manages mailman at Canonical?
<jdub> opi: i'm about :)
<opi> ah :-)
<Burgwork> mdz, seb128 afaik, we have no screenshots of  even documentation of that, but upstream gnome might
<opi> Burgwork: jdub's at service :-)
<mdz> Riddell: I don't see the reports; did someone else already process your request?
<opi> Burgwork: ignore that ;-)
<seb128> Burgwork: upstream GNOME did that to his stable branch 1 month ago
<seb128> that change
<seb128> so I think it's fine for upstream
<Burgwork> seb128, then I think we are good
<seb128> cool
<seb128> Burgwork: I'll do the change and mail the documentation and l10n lists then
<Surak> duh. X won't start on a machine with some onboard ati x200 if it's set to 16mb. 32mb works. Who's the poor x guy? :-)
<Burgwork> seb128, cheers
<mdke> seb128: sup?
<seb128> mdke: cf discussion we just had
<mdke> seb128: oh yeah, what Burgwork said
<mdz> Riddell: they're not on the approved list; are you sure they were approved? by whom?
<seb128> mdz: atm gdm Depends on "ubuntu-artwork | edubuntu-artwork | xubuntu-default-settings", any objection to move that to Recommends and desktop-seed ubuntu-artwork?
<mdz> seb128: does gdm work without ubuntu-artwork now?  I thought we did that because it needed the theme
<seb128> mdz: if that's a Recommends seeded it'll be installed by default and people can switch to an another theme and remove the package if they want to
<seb128> mdz: it fallbacks on the graphical default upstream theme after displaying a message if the Human theme is not installed
<mdz> seb128: if it falls back gracefully, i see no problem
<seb128> mdz: ok, I'll do the change now then :)
<Surak> Kamion, will bug #38718 be fixed until dapper? it seems a simple one, and confusing to some people.
<Ubugtu> Malone bug 38718 in ubiquity "Espresso should select the language first, and then give information" [Normal,Confirmed]  http://launchpad.net/bugs/38718
<Mithrandir> seb128: unless you've already done it, please don't until flight-7 is out.
<seb128> Mithrandir: when is flight7?
<Mithrandir> seb128: tomorrow
<seb128> Mithrandir: was ready to dput that after a reboot to make sure it's alright
<seb128> hum
<seb128> I've some other fixes to that upload
<seb128> should I delay everything of the just the artwork change?
<Mithrandir> seb128: do you have the debdiff somewhere?
<seb128> Mithrandir: no, forget about it, I'll go to bed now and delay the bug fixes I've planned to after flight-7, there is no hurry
<Mithrandir> seb128: ok, thanks.
<seb128> and better to get some sleep before the 4am meeting anyway ;)
<Mithrandir> I'm going to sit up and hack casper, I think.
<seb128> good luck with that ;)
<Mithrandir> I'm pondering finding a cup of coffee, but not sure if that's a good idea.
<seb128> Mithrandir: should http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkfilechooserdefault.c?r1=1.282.2.17&r2=1.282.2.18&only_with_tag=gtk-2-8 be delayed to after flight too?
<seb128> it makes the fileselector uses standard icons for remote folders not it doesn't block on IO every time you open a fileselector when you have network bookmarks listed
<Mithrandir> seb128: I'm ok either way.  Looks safe enough.
<seb128> s/not it/so it
<seb128> Mithrandir: ok, I'll still push that change then ;)
<Mithrandir> ok
<mdke> seb128: OMG that's a massive fix, awesome!
<seb128> mdke: the GTK one? yeah, that's a nice one ;)
* mdke nods happily
<Surak> hum. regression in ubiquity. :-(
<mvo> Mithrandir: I have a pending pango upload that fixes a race on a upgrade? do you want it postponed as well?
<Mithrandir> mvo: debdiff?
<mvo> http://librarian.launchpad.net/2454793/pango1.0_1.12.2-0ubuntu2.debdiff
<mvo> ^-- Mithrandir
<Mithrandir> mvo: how is this a race earlier?
<seb128> Mithrandir: pango module versionning changed, they are moved from 1.4.0 to 1.5.0 but the index is updated by the postinst
<mvo> Mithrandir: https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/41297 has the details (the last two-three comments). in a nutshell, its what seb128 said
<Mithrandir> oh, indeed.
<Ubugtu> Malone bug 41297 in update-manager "dist-upgrade fails when debconf-gnome is invoked during the upgrade" [Major,Unconfirmed]  
<seb128> Mithrandir: so between the upgrade and the configure the index point to the wrong place, and gtk stuff don't like that
<Mithrandir> mvo: I think it's ok, but let me read through the debdiff once more
<Mithrandir> mvo: you'll end up having an md5sum mismatch for /var/lib/pango/pango.modules, won't you?
<mvo> Mithrandir: yes, possible (if you have additional modules installed, currently only pango-libthai does this) 
<mvo> so I guess we need to exclude it from the dh_mdsums
<Mithrandir> mvo: I think that'd be good.  Apart from that, I'm ok with it.
<Kamion> Surak: 38718> yes, as I explained in the bug; but not until shortly before release candidate
<mvo> Mithrandir: thanks, I'll do a upgrade test before I upload too (just to be sure that nothing breaks and it actually fixes the bug)
<Mithrandir> mvo: thanks.
<Surak> Kamion: ok - just triaging some correlated bugs for you now. However, bug #40364 is appearing again (with yesterday's amd64 live), so I can't really test ubiquity today.
<Ubugtu> Malone bug 40364 in ubiquity "language selection broken" [Major,Needs info]  http://launchpad.net/bugs/40364
<Kamion> Surak: please get me /var/log/installer/syslog after running 'UBIQUITY_DEBUG=1 sudo ubiquity'
<Kamion> (and reproducing the problem, obviously)
<pygi> night all
<Surak> Sure
#ubuntu-devel 2006-05-09
<seb128> doko: around?
<mdke> seb128: time for a quick question?
<seb128> doko: do you remember what https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/33352 was about?
<Ubugtu> Malone bug 33352 in gtk+2.0 "gtk+2.0 should Build-Depends on a newer glib" [Normal,Confirmed]  
<seb128> mdke: sure
<doko> seb128: trying to stay awake ...
<mdke> seb128: so, System/Lock Screen locks the screen, but function/lock screen on the laptop keyboard doesn't, it just blanks. Do you know if this is a gnome-control-center bug, or gnome-screensaver? And, should I look upstream for a bug report, or in ubuntu
<seb128> mdke: looks like a gnome-power-manager bug :p
<mdke> seb128: apparently gnome-power-manager doesn't do that. gnome-screensaver does them both. mjg59 said he thought the bug would be in one of those two packages
<doko> seb128: don't know anymore, the build log is 5 days newer ...
<doko> than the bug report
<mdke> seb128: could it be that the hotkey isn't assigned to do gnome-screensaver-command --lock, whereas the menu entry is?
<seb128> mdke: does "gnome-screensaver-command --lock" work?
<seb128> no
<mdke> seb128: yes, it works.
<seb128> did you configure your key to the keyboard shortcut dialog correctly?
<mdke> seb128: it gets done automatically
<seb128> are you sure?
<seb128> to gnome-keybinding-properties
<mdke> seb128: I haven't touched it, it all works (or worked) out of the box
<seb128> I've just assigned "Lock Screen" to something it was not assigned on my box
<seb128> could you look if it's assigned to something and confirm that's the key you use?
<mdke> seb128: it's assigned to a key combination which is *not* the key I'm using
<seb128> k, so that's the issue
<mdke> specifically, ctrl + alt + |
<seb128> assign it to the correct key :p
<mdke> seb128: it would be wrong of me to do that. This laptop was a present, on condition that I file bugs when it doesn't work out of the box :)
<seb128> sure it doesn't work out of the box, we don't assign anything to that action
<sfllaw> mdke: :P
<seb128> :)
<mdke> seb128: it worked out of the box on breezy
<mdke> mjg59: any ideas?
<mdke> maybe this is hotkey related?
* mdke is handicapped by not knowing how the whole hotkey, gnome-keyboard-lark stuff works
<mjg59> All hotkey-setup does is send KEY_COFFEE
<mjg59> It's up to the gnome stack to actually /do/ something with that
<seb128> mdke: in fact upstream schemas has that:
<seb128>             <key>/schemas/apps/gnome_settings_daemon/keybindings/screensaver</key>
<seb128>             <applyto>/apps/gnome_settings_daemon/keybindings/screensaver</applyto>
<seb128>             <type>string</type>
<seb128>             <default>&lt;Control&gt;&lt;Alt&gt;l</default>
<mjg59> I've no idea what catches it
<seb128> so it's probably an upstream change
<seb128> and should be ctrl-alt-L
<mdke> seb128: so, I'll try setting it to nothing, and see if it works
<seb128> not ctrl-alt-|
<seb128> maybe if you set it to nothing pbuttond or something takes over
<seb128> or used to
<mdke> I set it to nothing, and it still just blanks rather than locks
<Surak> Kamion: again, bug #40364 was fixed just by an "sudo apt-get update ; sudo apt-get install localechooser-data" - I'll boot the machine again to post on the bug the debug output without updating it.
<Ubugtu> Malone bug 40364 in ubiquity "language selection broken" [Major,Needs info]  http://launchpad.net/bugs/40364
<mdke> >_<
<seb128> mdke: so something out of GNOME is acting if GNOME doesn't handle it
<seb128> might pbuttond?
<mdke> who is likely to know about this?
<seb128> mjg59 or pitti
* mdke bounces the ball back to mjg59 hopefully
<seb128> mdke: http://bugzilla.gnome.org/show_bug.cgi?id=171833
<Ubugtu> Gnome bug 171833 in Keybinding "Default lock screen keyboard shortcut" [Enhancement,Resolved: fixed]  
* mdke shrugs hopelessly. All he knows is that it's not working.
<seb128> mdke: it had no default action before so whatever does the blank screen for you know was working before
<mdke> right, if I set that key action to something, it locks the screen properly
<mdke> but the function key doesn't
<mdke> so, looks like Gnome is working
<seb128> which means that GNOME is doing is part correctly ;)
<seb128> s/is part/its part
<mdke> mjg59: let's do it like this. You tell me where the file the bug, based on that, and I'll do it.
<mdke> s/the file/to file
<mdke> note: i can't assign the function hotkey in gnome-keyboard-malarky because it blanks the screen and doesn't register in the dialogue
<seb128> seems like whatever is running it takes over the event before GNOME
<seb128> do you have pbuttond running?
<mdke> not that I can see
<mdke> I've got two instances of hald-addon-keyboard and one of thinkpad-keys
<seb128> maybe stop thinkpad-keys to try?
<Surak> Kamion, forget what I mean about localechooser-data. The bug comes up only with 256mb of ram. With 512, it disappears. (I let it there for 15 minutes to see if languages list would appear - it didn't) - this machine has no swap partition, and needs 32megabytes to be allocated to onboard video.
<Surak> s/mean/said
<mdke> seb128: no change.
<seb128> and if you stop gnome-screensaver?
<seb128> maybe it's a gnome-screensaver feature...
<mdke> seb128: no change.
<seb128> grumpf
<seb128> and without gnome-power-manager?
<mdke> except, lock screen in the menu stops wor
<mdke> gah
<mdke> seb128: no change.
<mdke> ignore the two lines above that
<seb128> yeah, so I don't know
<seb128> you must have something
<seb128> copy a "ps aux" somewhere on pastebin.com if you want
<mdke> alrighty
<seb128> I might spot a processus looking like it does it :)
<mdke> seb128: http://pastebin.com/697130
<seb128> mdke: I don't spot anything special .. maybe powernowd?
<seb128> mdke: what laptop is that?
<mdke> seb128: thinkpad T43-1871
<seb128> mdke: cat /etc/acpi/thinkpad-lockorbattery.sh
<seb128> mdke: does running /etc/acpi/screenblank.sh do that?
<mdke> seb128: http://pastebin.com/697139
<seb128> mdke: looks like acpid is what you are looking for
<mdke> http://pastebin.com/697141
<seb128> mdke: I bet than running /etc/acpi/thinkpad-lockorbattery.sh is what pressing the key do
<seb128> mdke: sh /etc/acpi/thinkpad-lockorbattery.sh
<mdke> it blanks the screen
<mdke> matt@kalliope:~$ sudo sh /etc/acpi/thinkpad-lockorbattery.sh
<mdke> bash: xscreensaver-command: command not found
<mdke> bash: xscreensaver-command: command not found
<mdke> and says that.
<seb128> right
<seb128> here you go
<seb128> bug acpid ;)
<mdke> will do, thanks.
<seb128> np
<mdke> I appreciate you spending so much time to help on such a small problem at this time of night
<seb128> np, I'm pondering going to bed or not
<seb128> we have the weekly meeting at 4am
<seb128> which is not a so nice time for a meeting :p
<mdke> oh, right.
<mdke> ouch
<Riddell> mdz: MainInclusionReportWlassistant and MainInclusionReportKNetworkManager are under approved in UbuntuMainInclusionQueue, pitti approved both
<sfllaw> Say.  Where do documentation bugs get filed?
<mdke> sfllaw: if on a package, on that package. if on the ubuntu specific docs, the ubuntu-docs product or package
<mdke> sfllaw: what's the bug, out of interest?
<sfllaw> bug 39411
<Ubugtu> Malone bug 39411 in base-installer "386 kernel installed on 686-capable machines" [Wishlist,Confirmed]  http://launchpad.net/bugs/39411
<mdke> sfllaw: interesting one. he's suggested adding it to the download page, we don't have a bug tracker for the website, but I'm inclined to think that this isn't significant enough to document on that page. It might be something for installation-guide?
<sfllaw> Yes, I think so.
<sfllaw> mdke: That's the package-name I needed.
<mdke> cool
<mdz> Riddell: they are *now* ;-)
<sfllaw> mdz: Here's a question you can answer...
<sfllaw> All of these "can't resume from S?" bugs.
<sfllaw> Do they belong in acpi-support?
<sfllaw> Or linux-source-2.6...
<sfllaw> ?
<mdz> sfllaw: to a certain extent, it depends, but most often linux-source-2.6.15
<sfllaw> So bug 35174 would be moved to linux-source-2.6.15?
<Ubugtu> Malone bug 35174 in acpi-support "ThinkPad X60 cannot resume from suspend to RAM" [Normal,Needs info]  http://launchpad.net/bugs/35174
<mdke> sfllaw: in my experience filing them in acpi-support is always good, because the maintainer will generally be aware of what is going on with the kernel too.
<mdz> sfllaw: acpi-support contains the scripts which control the suspend/resume process, so occasionally they will be acpi-support's fault, but it's rare these days
<mdke> then again, "my experience" constitutes my own laptop.
<mdz> sfllaw: that bug is a good example of the distinction
<sfllaw> Also, many of these fail-to-resume bugs appear to be hardware specific.  Collapsing them as duplicates is not the Right Thing, is it?
<mdz> sfllaw: the trouble is that the laptop doesn't suspend properly when the USB modules are loaded
<mdz> that could be worked around in acpi-support, but it's a bug in the kernel
<mdz> and should be moved there
<sfllaw> Excellent.
<sfllaw> I like it when sanity checking says I'm right.  :)
<mdz> acpi-support used to unload and reload USB modules before and after suspend to work around these bugs
<mdz> but nowadays it generally works right without it, and any remaining bugs in the kernel should be fixed
<mdz> that one is already subscribed, but be sure to subscribe the laptop team for laptop-specific issues in the kernel
<sfllaw> OK.  I'll remember that.
<mdz> the right people hear about these bugs when they're filed on acpi-support, because they're bug contacts there, but for the kernel, that obviously doesn't work so well
<Surak> mdz: about your answer on bug #41472, "The good news is that the string "Install" is likely to be translated for other applications already, so we should be able to get it translated quickly.", the problem is that the icon is not in rosetta. that's bug #39064
<Ubugtu> Malone bug 41472 in ubiquity "Espresso installer logo not descriptive" [Normal,Needs info]  http://launchpad.net/bugs/41472
<Ubugtu> Malone bug 39064 in ubiquity "espresso's .desktop only in english." [Normal,Confirmed]  http://launchpad.net/bugs/39064
<Surak>  /join #ubuntu-meeting
<Surak> night all.
<Riddell> fabbione, mvo: do you have the exact error from 41717?
<bddebian> Howdy peoples
<Mithrandir> iz tired.
<bddebian> Mithrandir: Then go to bed :-)
<Mithrandir> meeting in about an hour
<Mithrandir> it's the 0400 meeting.
<bddebian> Doh
<HiddenWolf> poor Mithrandir
<sfllaw> I'm going to miss the gym, I think.
* HiddenWolf makes fresh coffee for the team
<Mithrandir> HiddenWolf: well, somebody always has the bloody middle-of-night timespot.  This week, it's the europeans.
<HiddenWolf> I'm up reading newspapers
<HiddenWolf> :P
<sfllaw> I'm going to make some food.
<bddebian> sfllaw: Great, what are we having? :-)
<sfllaw> bddebian: Pierogies.
<infinity> mdz: Around?
<bddebian> sfllaw: Cool
<bddebian> sfllaw: Potato, cheese, what? :-)
<sfllaw> Whatever I pull out of the freezer.
<sfllaw> Sadly, I have yet to learn how to make homemade pierogies.
<zul> perogies are awesome especially with baccon
<sfllaw> zul: They are.  But don't let Eastern European grandmothers hear you say that.
<zul> hehe
<bddebian> heh
<robertj> I had to go look perogies up in wikipedia but now I'm hungry
<robertj> if any of you have nice polish grandmoths that want to come on holiday in the US for a month we have a spare bedroom!
<robertj> %s/grandmoths/grandmothers/g
<bddebian> One of my brother-in-laws is Polish so we get Perogies every year :-)
<ogra> Kamion, cc1: warning: command line option "-nostdinc++" is valid for C++/ObjC++ but not for C
<ogra> Kamion, whats that in my CD build logs ?
<Mithrandir> ogra: it's been there forever, you can just ignore it
<ogra> ok
<ogra> i've never noticed it
<mdz> infinity: yes
* ogra curses 
<bddebian> mdz: Did you make a change to the varconf bug?
<mdz> bddebian: I've changed a few hundred bugs this week
<mdz> which bug do you mean?
<infinity> mdz: See my last comment on bug #29858 ... Can you think of any clever way to NOT break old initrds, while also having our "update the initrd every time something that uses it is upgraded" magic?
<Ubugtu> Malone bug 29858 in initramfs-tools "root on lvm fails to boot." [Major,Confirmed]  http://launchpad.net/bugs/29858
<bddebian> mdz: Bug #41369  No big deal, I just didn't understand what changed
<Ubugtu> Malone bug 41369 in varconf "UVF Exception Request: varconf" [Normal,Unconfirmed]  http://launchpad.net/bugs/41369
<zul> night folks
<mdz> infinity: replied
<bddebian> Gnight zul
* Kinnison goes to get something savory before the meeting
<mdz> bddebian: I subscribed ubuntu-archive and cleared the assignee
<infinity> mdz: LP disagrees with you. :)
<mdz> bddebian: see the instructions for requesting a sync
<mdz> infinity: I replied by mail
<infinity> Oh. :)
<bddebian> mdz: I didn't assign that one.  I already got chastised by Kamion for doing that early on
<mdz> bddebian: you asked what I changed; that's what I changed
<mdz> bddebian: https://launchpad.net/distros/ubuntu/+source/varconf/+bug/41369/+activity
<Ubugtu> Malone bug 41369 in varconf "UVF Exception Request: varconf" [Normal,Unconfirmed]  
<bddebian> mdz: No biggie, I was just asking, sorry
<ogra> grmbl, what the hell added 8Mb to my CDs
<Mithrandir> BenC: around?
<sladen> infinity: what about taking the installed kernel versions, reverse-sorting them and only updating the first one
<ogra> why do we have pcmcia-cs in ship ? i thought that was superseded by pcmciautils 
<Keybuk> Colin was going to own the purging of that, I guess he's not got around to it yet
<Keybuk> it's only in ship though, not installed by default
<infinity> sladen: We do only update one.  That doesn't help when you call update-initramfs BEFORE the new kernel is installed.
<ogra> wont save my ass anyway 
<Keybuk> it may be useful to people with older kernels, I guess
<ogra> Keybuk, "only in ship" is somewhat pointless with an 8MB oversized CD 
<infinity> mdz: Hrm, your idea would be to only allow "update-initramfs -u" (without a -k argument) to operate on the running kernel?  That's an attractive thought, but it still breaks on upgrades now if we upgrade kernel first, then udev, since udev can't get its hooks into the new kernel's initramfs.
<ogra> and nothing left i could drop apart from fonts
<Keybuk> ogra: I didn't think pcmcia-cs is 8MB
<infinity> mdz: I think asking the udev hook to just bail if it discovers it's incompatible is more sane.
<ogra> Keybuk, indeed not, but it adds up :)
<ogra> (i cant find the reason why its suddenly oversized)
<mdz> infinity: except I don't think there's a mechanism for that which won't make update-initramfs fail too
<Keybuk> infinity: what about udev?
<mdz> Keybuk: bug #29858
<Ubugtu> Malone bug 29858 in initramfs-tools "root on lvm fails to boot." [Major,Confirmed]  http://launchpad.net/bugs/29858
<Keybuk> I thought the kernels that are "not compatible with udev" also happen to be those not compatible with initramfs :)
<mdz> Keybuk: we need to ensure that the right version of udev ends up in initramfs
<infinity> mdz: Adding a "Print an error message, do nothing, but exit 0" state to mkinitramfs is simple enough, if udev can make use of it.
<infinity> Keybuk: The udev in dapper doesn't work with the kernels in breezy, afaik.  At least, that seems to be the case with any number of bug reports we've seen.
<Keybuk> right, but then the kernel gets updated anyway, so what's the problem?
<infinity> Keybuk: So, if a dist-upgrade leads to "udev upgraded, then kernel upgraded", the OLD kernel will have a broken initramfs.
<Keybuk> doesn't update-initramfs get called twice for that?
<Keybuk> oh, I see, this is the fact update-initramfs updates them all?
<infinity> Keybuk: Which is pretty devastating if the new kernel doesn't work, or if there is no new kernel (because the user doesn't have linux-$(arch) installed to pull it in)
<Keybuk> (I bitched a lot about this back at UBZ to jbailey :p)
<infinity> Keybuk: No, update-initramfs doesn't update them all, it updates the newest.
<infinity> Keybuk: Or, the "best".
<infinity> Keybuk: If udev is installed BEFORE the new kernel, the current running kernel IS the newest/best.
<infinity> Keybuk: We have no way of knowing that a BETTER one will be installed 30 seconds later.
<Keybuk> the trouble is, the "does udev work" check can only be performed on a running kernel
<Keybuk> (it's actually "does udevplug work")
<sladen> infinity: could it be handled by diverting 'update-initrd' at the start of an upgrade using dpkg-divert and then un-diverting afterwards (this is used for the fonts...)
<infinity> Keybuk: Can you not just fudge it based on version numbers?
<infinity> Keybuk: If we're configuring for << 2.6.15, piss off?
<Keybuk> infinity: version number of what?
<Keybuk> installed kernels?
<infinity> sladen: All sorts of tricks like that will work fine for the upgrade tool, that doesn't fix dist-upgrade on a non-desktop machine.
<sladen> infinity: effectively it turns it into a call back and would mean that it only gets run only, even if there are several updates and also only gets run on the latest kernel
<Keybuk> you can't dpkg -l reliably within a dpkg run :)
<infinity> Keybuk: No, the version of the kernel we're currently generating an initramfs for.
<Keybuk> we could do that -- maybe a switch to update-initramfs
<infinity> ...?
<Keybuk> update-initramfs -u -V 2.6.15
<Keybuk> "only update kernels newer than 2.6.15"
<infinity> Oh, I see what you mean.
<infinity> That's from the other end from where I was suggesting (which was just to check the version in your hook and bail), but that would work well.
<infinity> And probably involves less code.
<infinity> Of course, that doesn't stop the user from manually running "mkinitramfs" and breaking their initramfs, but I suppose if they do that, they can keep both pieces.
<infinity> (Bailing in the hook would prevent all foot-shooting, in theory)
<infinity> Oh, wait, no.  Doing it as a switch to update-initramfs solves nothing.
<infinity> It needs to be in the hook.
<infinity> (udev installs, u-i is a no-op, then usplash installs, u-i runs and uses the wrong udev, then the new kernel installs)
<Keybuk> doing it in the hook would fuck over existing initramfs users, no?
<Keybuk> as mkinitramfs would be merrily generating them an initramfs anyway
<Keybuk> it'd also result in update-initramfs failing
<Keybuk> which would result in udev failing to configure
* Mithrandir mumbles something about "let's make grub assemble the pieces and we won't have this problem"
<infinity> Keybuk: Part of this discussion was that "mkinitramfs needs a 'Print an error, do nothing, and exit 0' failure state for udev to use"
<infinity> That's not tough for me to hack in today.
<Keybuk> I'm *really* against that
<infinity> Not sure how it would "fuck over existing users", though.
<Keybuk> there's no easy way to write shell in the udev hook that'll actually work reliably
<Keybuk> and not fuck up on custom kernels, etc. which udev has to still work for
<infinity> Custom kernels have versions too...
<Mithrandir> maybe feelings as well
<Keybuk> infinity: right, but we can't predict the version string, no?
<Keybuk> you realise they're lucky if their system boots with the breezy kernel and the new udev userspace, anyway, right? :P
* Keybuk never tested that
<Keybuk> in fact, I wouldn't be at all surprised if the combination of the breezy initramfs and the dapper udev userspace is fucked
<Keybuk> the udev database format changed
<infinity> It should boot far enough to mount root and get a new kernel installed, generally.
<infinity> Since all the storage and such will be loaded in the old initrd with the old udev.
<Keybuk> why are they rebooting before installing the new kernel?
<infinity> Why do hundreds of users not have the linux-image-$(arch) metapackage installed?
<Keybuk> well, in theeeeeory the new udev init script would just unmount /dev and leave the old static dev behind
<Keybuk> but that's never been tested with the breezy initramfs
<Keybuk> might not work if usplash is hanging on to /dev, for example
<infinity> So, you're saying you think this whole conversation is pointless because breezy kernels might not boot anyway?
<infinity> (I'm pretty sure some do, FWIW)
<infinity> Keybuk: Anyhow, the kernel version is in $version, exported by mkinitramfs.  So you have that to test against.
<Keybuk> they boot enough to perform system recovery
<Keybuk> infinity: which version though?
<infinity> Keybuk: I just need to provide you with the "bail and do nothing" error class.
<Keybuk> the version of the kernel package?  the upstream version of the kernel inside?  the ubuntu version?  what patch abi, etc.?
<infinity> Keybuk: The full version as you'd see in `uname -r` or /lib/modules/$version/
<infinity> Keybuk: Simple shell to discover if that's 2.6.15ish enough for you.
<Keybuk> it's not simple! :p
* Keybuk would just call dpkg --compare-versions <g>
<infinity> (Yeah, that's what mkinitramfs uses too)
<infinity> Why reinvent that wheel, I suppose? :)
<Keybuk> random question
<Keybuk> why not just change that version? :p
<Keybuk> seeing as it'll bail badly there *anyway*
<Keybuk> there's bound to be some idiot who tries a warty->dapper upgrade and wonders why udev, usplash, etc. fail to configure
<infinity> And just claim (incorrectly) that the dapper initramfs-tools won't work with older kernels?
<Keybuk> if you wanted elegance, you could call each hook with a "minimum-version" argument and let them return one :p
<infinity> That's doable.
<Keybuk> anyway, I'm happy with whatever you decide; and I'll make whatever change you tell me to, like a good little bitch <g>
* Keybuk puts his collar on and offers you the lead
* infinity tugs experimentally.
<infinity> Alright, I'll hack something up today.  This is "initramfs-tools bugfixing day"
<infinity> Also, am I on crack, or did the meeting start 17 minutes ago without us?
<Keybuk> I put them into different windows, so I can watch both <g>
<Keybuk> the meeting did start 17 minutes ago
* infinity didn't get pinged.
<infinity> And I completely lost track of time.
<Keybuk> that i2o/hda bug is annoying me
<Keybuk> did you see mdz's post on it?
<Keybuk> which pretty much proves what Tollef said
<Keybuk> the kernel's exposing i2o drives as /dev/sd* not /dev/i2o/hd* now
<Keybuk> at least via one set of drivers
<infinity> No, it's doing both (well, either), depending on which driver you load.
<infinity> Which is crack.
<infinity> But also not MY crack.
<infinity> So i wash my hands of this one.
<Mithrandir> Keybuk: i2o_block exposes it as /dev/i2o/hd* as it used to.
<Keybuk> aye, it's a "someone who understands i2o PICK ONE DRIVER"
<Keybuk> we can blacklist the other
<Mithrandir> dpt_i2o exposes it through sd_mod.
<Mithrandir> no, we can't.
<Keybuk> dpt_i2o sounds right to me
<Keybuk> kill i2o_block! :p
<infinity> I suspect they both work on different sets of devices, but have some overlap, or something equally irritating.
<Mithrandir> dpt_i2o only works on i386 with those controllers it claims to work with.
<Mithrandir> i2o_block will always work.
<Keybuk> Mithrandir: so what's the fix?
<Mithrandir> if dpt_i2o will work, you want that, since it gives you more twiddly bits to twiddle.
<Mithrandir> Keybuk: can you say "load dpt_i2o, but if it fails, load i2o_block"?
<Keybuk> Mithrandir: yes, write a kernel driver that does that
<infinity> I suppose the "fix" is to make i2o_block use sd_mod too, but that's way too much effort this late.
<Keybuk> this is the same "problem" we have with the two prism54 drivers
<infinity> One station, one AP?
<Mithrandir> Keybuk: if we have to choose one, go with i2o_block
<Keybuk> infinity: softmac vs. fullmac
<infinity> Ahh.
<Keybuk> the choice is "if this bit of code only the kernel can do fails, load this one, if it works, load that one"
<Keybuk> so I've suggested a tiny prism54_magic driver be written that wraps whichever one of the two would actually work for that device
<Mithrandir> Keybuk: can you run modinfo dpt_i2o and dump that in a query for me?  I don't have any i386 boxes handy.
<Keybuk> modinfo: could not find module dpt_i2o
<Keybuk> oh, heh
<Keybuk> i386
<Mithrandir> or somebody else with an i386
<Keybuk> filename:       /lib/modules/2.6.15-21-686/kernel/drivers/scsi/dpt_i2o.ko
<Keybuk> author:         Deanna Bonds, with _lots_ of help from Mark Salyzyn
<Keybuk> description:    Adaptec I2O RAID Driver
<Keybuk> license:        GPL
<Keybuk> vermagic:       2.6.15-21-686 SMP preempt 686 gcc-4.0
<Keybuk> depends:        scsi_mod
<Keybuk> alias:          pci:v00001044d0000A501sv*sd*bc*sc*i*
<Keybuk> alias:          pci:v00001044d0000A511sv*sd*bc*sc*i*
<Keybuk> srcversion:     813219280BD2DFF356A9C25
<Mithrandir> the modalias pci:v00001044d0000A511sv*sd*bc*sc*i* is shared with i2o_core
<Keybuk> indeed
<Keybuk> so what I'd do there is take the alias away from both of them
<Mithrandir> but as you can see, i2o_core has a catch-all too.
<Keybuk> and write an icklewickle driver that picks the right one
<Keybuk> ie. kmod it in and force-bind it to the device that it knows will work
<Keybuk> this is always preferable to a modprobe install hack
<Keybuk> (the other alternative)
<Mithrandir> can you do modinfo-based blacklists?  So you can say "don't load this driver for this pci id"?
<Keybuk> because the install hack won't work for people that happen to have two i2o raid controllers, one which needs dpt_i2o and one which needs i2o_block
<Keybuk> Mithrandir: no, modprobe doesn't know what pci id it's actually looking for, etc.
<Mithrandir> ok
<Keybuk> you could try putting "alias pci:v00001044d0000A501sv*sd*bc*sc*i* ..." in a modprobe config file, that might override the module-supplied ones
<Keybuk> I'm not convinced though, it may just augment them
<bddebian> Riddell: If/when you get a sec.  You did the last upload for ekg and this doesn't seem unreasonable? Bug #38311
<Ubugtu> Malone bug 38311 in ekg "Please build libgadu without openssl support" [Normal,Unconfirmed]  http://launchpad.net/bugs/38311
<Keybuk> also bear in mind that this isn't doing what you think
<Keybuk> udev DOES NOT match devices to drivers
<Keybuk> neither does modprobe
<Keybuk> all they're doing is loading drivers they think devices might need
<Keybuk> the kernel matches devices to drivers
<Keybuk> we can influence that a bit by making sure only one of the two possible drivers is loaded automatically
<Keybuk> but that has to be across the board, ie. "NEVER LOAD THIS DRIVER"
<Keybuk> as soon as you get "only sometimes load this driver" you'll find someone (hi, fabbione!) who always manages to build a PC that causes both to be loaded
<Keybuk> and then you're back to the kernel picking one of the drivers
<Keybuk> so "pick one of two drivers, where we need both" is always best solved in the kernel
<Riddell> bddebian: if it's really the case that the servers don't support ssl that doesn't seem like it could cause many problems
<Keybuk> (I always pick on fabbione; after some random bug I can't remember anymore caused by him having eight different IDE controllers in the same box, or something)
<bddebian> Riddell: True enough.  Wishlist and low priority it or reject it?
<Mithrandir> Keybuk: well, dpt_i2o is nice to have, but I think we can blacklist it if we have to.  I certainly don't have time to do the tiny kernel driver you're talking about.
<infinity> Mithrandir: Will i2o_core bind to and drive EVERY piece of hardware that dpt_i2o will?
<Keybuk> what happens if you load both?
<Mithrandir> infinity: yes.
<Keybuk> I guess one of them "wins" the device
<Keybuk> rather than you getting the device as both /dev/sd* and /dev/i2o/hd*
<Mithrandir> Keybuk: you don't get both.
<Keybuk> bah :p
<Keybuk> which does the installer favour, btw?
<Mithrandir> I can't remember what happens though.  It takes me a day to find out.
<Keybuk> I remember something early on where the installer always picked one over the other
<Mithrandir> dpt_i2o on the controller I tested.
<Keybuk> oh, I can guess what happens
<infinity> Not sure if that's deterministic.
<Riddell> bddebian: Wishlist, priority doesn't need to be low
<Keybuk> whichever driver gets initialised first reserves and binds to the device
<pitti> mvo: it's basically " grep '0 pot' http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt"
<bddebian> Riddell: OK, thx
<Keybuk> so randomly you get either /dev/sd* or /dev/i2o/hd*
<infinity> Some people seem to be getting i2o_core in the installer, then dpt_i2o in initramfs (hence the "doesn't reboot after install" issues)
<pitti> mvo: that file is updated automatically daily around noon
<Keybuk> depending on random fluctuations in the space/time/kernel continuum
<Keybuk> (it's actually predictable, just changeable)
<Mithrandir> infinity: that'd be bad, agreed.  Then it'd be better to just blacklist dpt_i2o and have those who want it unblacklist it and deal.
<infinity> Well, the blacklist file could have a comment that says "if you intend to unblacklist this module, you may want to blacklist i2o_core instead, so they don't race with each other"
<infinity> That should cover the 10% of users who can read.  The other 90% can go jump.
<mvo> pitti: thanks
<Mithrandir> infinity: i2o hardware is server class gear which means you'll generally have more clued users.  I think.
<pitti> mvo: mailed you the current list
<infinity> Mithrandir: Fine, 30/70 instead of 10/90, then. :)
<mvo> pitti: thanks again :)
<Mithrandir> infinity: heh. :-)
<pitti> mvo: let's coordinate and do the fixing in the next days (I'll do some, too), so that we can forget about this finally and get Rosetta going
<mvo> pitti: agreed
<Keybuk> infinity: as long as the installer obeys the same blacklist, that'd work
<Keybuk> I still don't know where the installer gets its list-o-modules
<Keybuk> it's not been important until now, because we've never blacklisted a storage controller -- which are the only class of driver that actually carry over to the configuration of the real install in some way
<Keybuk> infinity: was just looking at bug 40522 given our previous conversation
<Ubugtu> Malone bug 40522 in initramfs-tools "Check for kernels < 2.6.12 may not always do the right thing" [Normal,Needs info]  http://launchpad.net/bugs/40522
<infinity> Keybuk: I suspect the version it's trying to run against isn't the one he thinks it is.
<infinity> Keybuk: Also, makes a good argument for that not dying with an "exit 1", I think.
<infinity> "WARNING: Kernel version too old, not generating initrd ; exit 0" would work just fine, I suspect.
<Keybuk> aye
<Mithrandir> sfllaw: is there any particular method you use for attacking the bug list or do you just start at the top of the 10k list and go through it?
<sfllaw> Mithrandir: I look at the 10k list and see which ones look tractable.
<Mithrandir> 10k is a scary number.
<sfllaw> http://tinyurl.com/rc4bs
<sfllaw> It's not so bad.
<sfllaw> Anyway, pick a bug, any bug.
<Keybuk> Mithrandir: I prefer to think of it as a mere 10 light bugs
<sfllaw> Then look at its package.
<sfllaw> And try to cross-correlate things.
<sfllaw> After weeding out the dups, I go on to simple confirmations.
<sfllaw> All throughout, I look for bugs that could have been reported upstream or in other distros.
* Keybuk tends to search for random and/or interesting words
* bddebian goes 1 by 1 :-(
<tritium> Mithrandir: will the new kernel be 2.6.15 or .16?  I ask because of patches that would help fan control on iMac G5.
<Mithrandir> tritium: .15
<tritium> (in .16)
<seb128> sfllaw: would you mark bug forwarded upstream you didn't notice on your box as confirmed?
<pitti> mvo: wget fixed and uploaded
<tritium> Okay, that's what I thought.  Thanks
<Mithrandir> tritium: but BenC is pulling stuff from .16 too, so you could talk to him about it.
<tritium> Mithrandir: thanks.  I think I'll do that.
<sfllaw> seb128: If the bug shows up from several other people, and there's repo steps upstream, then yes.
<bddebian> Heya tritium
<tritium> hi there bddebian 
<bddebian> What is RFE wrt to a bug report?
<bddebian> Request For ???
<pitti> bddebian: Enhancement? -> Wishlist
<ogra> bddebian, think about all the spam you get everyday :)
<sfllaw> seb128: Especially if there's a patch in another BTS or distro.
<Kamion> ogra: debian-cd uses cpp to munge its package lists, and doesn't bother to suppress all the warning
<Kamion> s
<ogra> (enhancement ;) )
<bddebian> ogra: hehe
<seb128> sfllaw: right, I do that too. I was just wondering if a crasher with a debug bt reported by one people should be marked as confirmed so it's out of the way
<ogra> Kamion, ah, right, i just never noticed it before
<sfllaw> seb128: To me, Confirmed means, "A developer probably has enough debug information to fix the bug."
<sfllaw> I'll keep it as Needs Info until I pull enough teeth to get to that stage.
<seb128> sfllaw: hum, I should probably mark all the bug I forward as confirmed so ;)
<sfllaw> :)
<seb128> I usually forward bugs only when they are useful for upstream to do something
<sfllaw> seb128: That's forwarding reports upstream?
<Keybuk> I tend to use "Confirmed" as "multiple people have actually agreed the bug exists"
<Keybuk> and "In Progress" as "developer has enough information to fix the bug"
<sfllaw> Keybuk: Well, I'm not a developer.
<sfllaw> And there's Needs Info.
<sfllaw> Needs Info is the state where a bug is unreproducable.
<Keybuk> yeah, I use Needs Info whenever I ask questions
<sfllaw> So if there isn't enough info for a developer, why bother a developer?
<Keybuk> if I ask a question, I set the bug to Needs Info, and then toggle back to Unconfirmed or Confirmed after
<Keybuk> true
<tritium> Mithrandir: do I talk to you or BenC about bug #40009 getting resolved in the next kernel?
<Ubugtu> Malone bug 40009 in linux-source-2.6.15 "No reboot or shutdown with ipw2200 module loaded" [Normal,Unconfirmed]  http://launchpad.net/bugs/40009
<Keybuk> as a developer, I'd love to only get Confirmed (your definition) bugs ;)
<sfllaw> Keybuk: That's why I'm here.  :)
<Keybuk> sfllaw: oh, while we're on the subject
<seb128> sfllaw: I try to not forward things that will be maked as NEEDINFO by upstream directly (ie: I try not forwarding crashers before getting a debug backtrace)
<Mithrandir> tritium: BenC.
<Keybuk> a good Ubuntu trick for any bug involving hardware is to ask for /var/log/udev
<sfllaw> seb128: That's my policy, yes.
<Keybuk> almost always better than lspci output, because it actually lists every damned thing
<sfllaw> seb128: We want to be helpful to upstream.
<tritium> Mithrandir: okay
<Mithrandir> tritium: I'm not a kernel hacker. :-)
<pitti> mvo: whois fixed, too
<tritium> Mithrandir: I'm not much of any kind of hacker ;)
<Mithrandir> did launchpad just fall off the face of the planet?
<Keybuk> Mithrandir: the entire data centre keeps vanishing
<Keybuk> gets lost somewhere in Level 3 / mnet
<sfllaw> There's an instability in the time-space continum.
<sfllaw> Continuum?
<sfllaw> Yes.
<pitti> tseng: can you please fix beagle to produce a POT file?
<Keybuk> insanity in the spice-team frenulum!
<pitti> Riddell: can I bother you with POT file generation in kio-apt?
<Riddell> pitti: now on my todo list for tomorrow
<Riddell> pitti: was there something else that needed pot generation?
<pitti> Riddell: indeed, konversation is the only other KDE package on the list
* pitti sees 'kino' as well :)
<Riddell> will do
<pitti> thank you
<ogra> pitti, kino != KDE
<Riddell> anyone assigning kino issue to me will be thrown to the dens of the gnome packagers
<ogra> :)
<ogra> bddebian, could you make the RFE bugs whishlist please ? 
<bddebian> ogra: I did
<bddebian> Well 2 of them anyway
<Mithrandir> iwj do you want ff bugs to actually be assigned to you or will you pick them up by yourself?
<ogra>   Priority: None => Low
<ogra>        Status: Unconfirmed => Confirmed
<ogra> thats not telling about whishlist
<bddebian> ogra: It was already wishlist
<ogra> ah
<ogra> k
<bddebian> :-)
<ogra> (i didnt actually look at the bug, sorry, just saw the change)
<bddebian> Why is there no libldap-2.2-dev package? (Debian doesn't have one either)
<Mithrandir> because it's called libldap2-dev?
<tritium> I don't suppose I should confirm a bug that I reported, right?
<infinity> bddebian: Because there shouldn't be.
<infinity> bddebian: There won't be until libldap2.2 is mangled to use gnutls.
<infinity> (at which point, libldap2 from 2.1.x will go away)
<Kamion> Riddell: qtparted is hanging on exit here trying to write "stdin" to stdout
<Kamion> Riddell: shouldn't those debug messages in QP_MainWindow::slotReadStdin be going to stderr, not stdout?
<Kamion> er cerr
<bddebian> infinity: So should I reject a bug asking for it?
<infinity> bddebian: Yes.
<bddebian> Thx
<Riddell> Kamion: I'm working on qtparted just now, that's sorted on my local machine
* Kamion tries a workaround in ubiquity so that he can get on with things
<sladen> infinity: for ipw2200 led=1  where's the best place to add that (all lots of Acer's want it), or would be better just to have userspace try to flick the LED on startup (like I do for Asus)
<Keybuk> /etc/modprobe.d/options
<infinity> sladen: You want Keybuk for that sort of thing. :)
<infinity> sladen: I avoid loading modules if I can.
<Keybuk> that's our collection of module options that should really be set in the bloody driver by default, but BenC hasn't yet been persuaded to do so (or it was "hard")
<Keybuk> generally if it's a good default, just patch the damned driver
<Keybuk> -static int led = 0;
<Keybuk> +static int led = 1;
<Keybuk> easy patch, that one <g>
<Keybuk> infinity: you don't still compile your own? *gasp*
<infinity> Keybuk: No, I run stock kernels on my laptop, but I try to avoid caring about how module loading works. :)
<infinity> Keybuk: I do compile my own monolithic kernels on all my server kit, though.
<Keybuk> heh, you take the "is broken ... ask Keybuk" approach?
<sladen> Keybuk: led=1 isn't needed for everything (and might even break some stuff ...who knows).  Your call.  modprobe.d/options, le kernel or something else?
<infinity> Keybuk: With your munging of udev and modprobe in the last cycle, I expect you know more than you ever wanted to know about module loading.  I prefer not to duplicate knowlege, when I can be out learning other stuff. :)
<sladen> Keybuk: regarding that thinkpad docking issue, what about having grub grab the UID of the disk *it* thinks is the master and pass that as a second option to the initramfs to try if it can't find the first root=
* infinity runs out for a lunch date with a pretty Hungarian girl.
<Keybuk> sladen: modprobe.d/options is applied for everything so early that if it breaks stuff, then you're fucked
<Keybuk> so I consider adding anything to modprobe.d/options equivalent to modifying the default in the driver
<Keybuk> given both are resolved the same way (adding a modprobe option to change the parameter)
<Keybuk> changing the driver is more elegant, as it can't be mistakenly forgotten
<Keybuk> sladen: if it's possible, sure
<bddebian> Damn, I'm not even making a dent.. :'-(
<sladen> it's not lunchtime in Hungary...
<Keybuk> sladen: of course, if we wrote root=UUID=* for everything anyway and put UUID=* in fstab instead of /dev/*, the problem goes away too
<sladen> Keybuk: /etc/fstab full of UIDS just becomes minging ugly for a human to look at and debug, but yes, it's a finalish solution
<Keybuk> I think it's almost certain that we'll do that for edgy now
<Keybuk> given we'll probably have the hda->sda switch in that cycle anyway
* sladen thinks about bed.  sitting at the end of the road to use wifi, because my housemates forgot to renew teh intaweb is getting colder and the birds is getting annoying
<mdz> BenC: ping?
<Kamion> I share the maintainability concern, I must say
<Kamion> for admins
<bddebian> Hmm, should Samba home shares be writeable by default?
<Keybuk> Kamion: admins are free to change it back to /dev/hope-its-the-same-as-last-time
<HrdwrBoB> they aren't
<Keybuk> but I think writing UUIDs by default is much better
<bddebian> HrdwrBoB: ?
<Kamion> Riddell: it also seems to be calling slotReadStdin() when stdin is closed, rather than using the exception handler; do you also have that fixed locally?
<Kamion> Riddell: if so, could I have your changes? I need to test stuff after that or else chances are I'm going to end up breaking the KDE frontend
<Keybuk> (the most reliable way I can come up with to do the hda->sda migration is actually just to go down the list and grab the UUIDs, and replace them with those -- it means we don't rely on the SCSI order being the same as the IDE one)
<HrdwrBoB> bddebian: well they are not at the moment
<HrdwrBoB> but IMHO they should be
<bddebian> HrdwrBoB: That's my question.  There is an LP bug requesting that :-)
<Kamion> and I think we need this qtparted bug fixed for Flight CD 7; at the moment I don't see how to get past qtparted ...
* bddebian wishes he could help more
<HrdwrBoB> ah :)
<Kamion> sladen: why are you assigning general live CD bugs to ubiquity?
<sladen> Kamion: urmm.  Because it's 5am.
<Kamion> I chucked one of them back to usplash, but maybe it's supposed to be casper
<Kamion> I chucked the other off to casper
<fabbione> morning
<bddebian> Morning fabbione
<ajmitch> hi fabbione 
<sladen> Kamion: I'll bump the other one off to casper and let tollef have it
<Kamion> ok
<bddebian> Did Riddell go do bed after the meeting?
<fabbione> Kamion,mdz: I need UVF exception for #40153
<fabbione> otherwise our -evdev driver doesn't work at all
<sladen> bddebian: 46 minutes 15 seconds idle on muse, very likely
<bddebian> sladen: OK, thx
<fabbione> mvo: ping?
<mvo> fabbione: pong
<fabbione> mvo: are you merging libdevmapper and lvm?
<fabbione> be very careful when you do it.. specially the clvm bits where the delta with debian is big
<fabbione> bug #38007 <-
<Ubugtu> Malone bug 38007 in lvm2 "pvmove coredumps" [Major,Confirmed]  http://launchpad.net/bugs/38007
<mvo> fabbione: it was assigned to me yesterday, I haven't looked at it yet at all
<mvo> fabbione: could you please add whatever helps me to the bugreport? I'm not sure I will be able to deal with it before the weekend (linuxtag talk is coming as well)
<fabbione> mvo: don't want to sound silly but i suggest to do it as soon as you can. Specially because i have a lot of machines on LVM and can test naturally without having you to spend dedicated time
<fabbione> mvo: ok.
<Kamion> mdz: followed up to bug 41109
<Ubugtu> Malone bug 41109 in ubiquity "espresso hangs after setting time" [Major,Confirmed]  http://launchpad.net/bugs/41109
<dholbach> fabbione: mvo and I are going to prepare LinuxTag and stuff today
<dholbach> fabbione: so better not count on it
<Kamion> mdz: I'm not sure that the EINTR bug reported in some comments on that bug is the same as the one described by the original reporter; I've followed up asking the reporter to re-test, though
<fabbione> dholbach: whatever.. i am concerned because lvm is delicate part of server/base install.. and there are stuff relaying on it's behaviour like the installer
<dholbach> I understand that - maybe somebody else, more familiar with the code should do it then, no?
<bddebian> Gnight peoples
<dholbach> night bddebian
<fabbione> dholbach: i am trying to give mvo a few hints on what to test....
<mdz> Kamion: if you'd rather I file it separately, I can do so
<dholbach> I merely indicated that "as soon as you can" might take a bit and I never heard of mvo as an LVM speciaslist :)
<mdz> Kamion: I saw there was already another bug open about a hang at that point
<mdz> I didn't even notice that the original description didn't match the comments
<ajmitch> hm
<Kamion> mdz: the traceback you reported is bug 41921, and should be fixed now
<Ubugtu> Malone bug 41921 in debconf "strange EINTR in keyboard chooser" [Major,Fix released]  http://launchpad.net/bugs/41921
* ajmitch didn't realise that the sync just requested was removed from dapper a couple of days ago
<Kamion> (check out that list of dups)
<mdz> Kamion: is there anything newer than 20060503?
<mdz> Ubuntu 6.06 "Dapper Drake" - Beta 2 amd64 (20060503)
<mdz> that's what I get as daily-live/current
<Kamion> mdz: 20060503 is current
<Kamion> dapper-live-amd64.manifest:debconf 1.4.72ubuntu4
<mdz> Kamion: it probably shouldn't say 'beta 2'
<Kamion> switch it back to Alpha?
<Kamion> which is the normal designation
<Kamion> committing
<fabbione> hmmm
<pygi> mornin'
<ajmitch> hi
<pygi> hi ajmitch
<jdub> is there a way to get apt-cache madison output for all packages?
<jdub> oh, never mind
<mdz> apt-cache madison `apt-cache pkgnames`
<mdz> but surely you don't want that 
<jdub> yeah, i'm on crack
<jdub> i want to determine on a broken system which packages have been installed from dapper
<jdub> will i have to apt-cache policy <pkg> for everything?
<mdz> if you've run apt-get update since the last upgrade, you're fucked
<infinity> Do an agressive pin to dapper, then see what apt-get dist-upgrade says.
<infinity> (or an agressive pin to whatever dist you think you want)
<jdub> was hoping to pull everything back to breezy
* jdub spanks bad sysadmins
<infinity> Package: *
<infinity> Pin: release a=breezy
<infinity> Pin-Priority: 1001
<infinity> (In /etc/apt/preferences)
<jdub> then an upgrade will upgrade dapper packages to breezy?
<infinity> Then see how bad the damage is with "apt-get update && apt-get -s dist-upgrade"
<infinity> Yeah, any pin > 1000 will force downgrades.
<mdz> Kamion: sorry, I added my additional comments to #41109 which were meant for #41921
<infinity> Sick, scary, wrong, don't ever do it, but for this case, it will show you what you want.
<jdub> mmm
<jdub> thanks
* jdub is happy to have never had to learn pinning ;)
<infinity> (I use this to sidegrade from sarge to breezy, since they're "close, but not quite identical")
<mdz> jdub: infinity's recipe will give you "what's newer than breezy", though you asked for "what's been installed from dapper"
<dholbach> I used it to sidegrade from pre-sarge sid to pre-warty :)
<mdz> jdub: presumably he understood what you meant and I took you literally, but just to be sure
<jdub> mdz: yeah :)
<infinity> mdz: I've been here 2.5 years now, so I speak fluent Australian.
<infinity> (My, how time flies)
<mdz> Kamion: ok, now I've gotten ubiquity into a state where ubiquity is wait4(debconf-communicate) and debconf-communicate is blocked in read(0,...)
<mdz> I got here by clicking "next" on the first 3 screens
<Kamion> mdz: boggle; if you can reproduce that with UBIQUITY_DEBUG=1 set, that'd be great
<Kamion> I've not seen that
<mdz> Kamion: I don't run it without debug anymore
<mdz> Kamion: log by mail or malone?
<Kamion> mdz: malone
<mdz> I can get you a shell on the machine where it's in this state if you like as well
<jdub> infinity: fie. "someone wanted mysql 5, and it was in dapper, so..."
<Kamion> hmm, yeah, I'm up for another 15 minutes or so I guess
<infinity> jdub: Should have poked me for a backport.
<infinity> jdub: I have one or two lying around at any given time.
<jdub> infinity: yeah? that might be an option
<Kamion> mdz: this is 42865?
<infinity> jdub: If you're too far gone into dapper-land to downgrade successfully, you may as well just do a full upgrade, and I'll welcome you to the server testing team. :)
<jdub> oh dude
<jdub> i'm running dapper everywhere
<jdub> i'm just saving a potential client from doom
<infinity> Heh.
<infinity> If current dapper has much doom left, we're going to have a pretty bumpy release.
<infinity> I'd hope it's mostly doom-free.
<jdub> yeah, they're figuring out whether to go back (backports might help) or start testing dapper 'for real'
<infinity> With that, I'm going to ignore IRC for a while again and get back to my doom-removal practices.
<jdub> 'oops' ~= 'for real'
<jdub> infinity: got a link to backports?
<jdub> before you fly away to mars
<infinity> jdub: Not a current mysql5 right now, but I can do one for you.  What arch?
<jdub> no, don't let this interrupt your attack on doom
<infinity> I can do it later when I'm pretending to have "spare time".
<infinity> I wasn't going to do it right now. :)
<jdub> it'd be a waste of your time whenever you did it ;)
<jdub> though talking benc into sucking down a new sata_promise driver would be a good use of your time
<mdz> Kamion: I was trying to reproduce that (and failing) when this happened
<infinity> jdub: Feel free to talk him into it.
<infinity> :)
* infinity goes off to battle doom some more.
<Kamion> mdz: is it with a current live CD now?
<mdz> Kamion: 20060503
<jdub> #40478
<Kamion> ok
<jdub> bug #40478
<Ubugtu> Malone bug 40478 in linux-source-2.6.15 "Promise TX4300/4310 driver update" [Normal,Unconfirmed]  http://launchpad.net/bugs/40478
<infinity> Phone if anyone needs me, I'm off to the land of initramfs and constant reboots.
<mdz> Kamion: fd 0 is a pipe; I tried to match it up via /proc, but either I'm a muppet, or the other end of it is...er...esd
<Kamion> the other end should be ubiquity; I don't see how it could end up being anything else
<Kamion> unless the id has been reused
<mdz> Kamion: could something have caused esd to be spawned, and inherit the fd?
<mdz> it looks awfully like that's what happened
<Kamion> oh, could be
<Kamion> what spawns esd?
<mdz> Kamion: http://librarian.launchpad.net/2461106/proc
<mdz> Kamion: GNOMEy bits can spawn esd
<mdz> that fd should be set close-on-exec
<Kamion> hate esd
<Kamion> right, yeah
<Kamion> at least after debconf-communicate has been spawned
<mdz> note that it's a second instance of esd running as root
<mdz> which smells like ubiquity spawned it
<Kamion> must have been a GNOME library
<Kamion> sounds like we should attempt to suppress that
<mdz> I wonder if other hangs could be explained by this
<mdz> e.g., clicking on an inactive button triggering a sound event
<mdz> Kamion: can I kill this instance and play with it some more, or do you thin kyou'll want to see it inaction?
<Kamion> after dapper, I'd like to attempt to get ubiquity to run as non-root except when spawning other processes
<Kamion> mdz: go ahead and kill it; thanks for the analysis
<kagou> morning
<Coyctecm> https://launchpad.net/distros/ubuntu/dapper/+bug/1
<Ubugtu> Malone bug 1 in Ubuntu Dapper "Microsoft has a majority market share" [Critical,Confirmed]  
<Coyctecm> :DD
<mdz> Kamion: clicking the window close button while it's creating the filesystem closes the window but leaves everything running in the background
<Coyctecm> horrible bug!
<Coyctecm> ;D
<mdz> I imagine it should ignore me instead
<Kamion> mdz: bug 41732
<Ubugtu> Malone bug 41732 in ubiquity "Cancelling install via X button on progress bar does not halt installation" [Normal,Confirmed]  http://launchpad.net/bugs/41732
<mdz> thanks
<Kamion> fairly easy to fix
<mdz> Kamion: have you ever seen that "partition #2 of /dev/hda as" bug?
<Kamion> mdz: yes, frequently, it's filed somewhere
<mdz> I mentioned it in the context of one of my other bugs
<Kamion> it's a bug in partman_commit somewhere, haven't figured out exactly what; it's on my high-priority list
<mdz> but I'm completely unable to reproduce it anymore
<mdz> anything I can try?
<Kamion> rm -rf /var/lib/partman might let you reproduce it
<Kamion> bug 40587
<Ubugtu> Malone bug 40587 in ubiquity "file system type labels blank in summary at end" [Normal,Confirmed]  http://launchpad.net/bugs/40587
<mdz> Kamion: do you expect it's distinct from bug 37872?
<Ubugtu> Malone bug 37872 in ubiquity ""No root file system" error" [Normal,Confirmed]  http://launchpad.net/bugs/37872
<Kamion> mdz: looks like the same bug, yes; I'll duplicate
<mdz> Kamion: is the unknown/multi-line error significant?
<Kamion> mdz: I've fixed debconf to allow using the debconf protocol properly, but not partman (mostly because I haven't added escape to cdebconf yet); however the one you point to isn't important
<Kamion> we work around that already, albeit in a nasty untranslatable way
<Kamion> the problem will be more of the form that we're writing slightly the wrong stuff into /var/lib/partman/devices/, I expect
<mdz> I just got it to happen again
<mdz> but only without debug
<Kamion> I've got debug logs of the problem on various occasions; don't worry too much about it
<Kamion> I'll work on it tomorrow
<Kamion> fix for the cloexec thing in my tree, but I need to go to bed now rather than spending more time testing that, I think
<Kamion> though it would be nice to be able to reproduce it; will have to poke about
<fabbione> mdz, Kamion: could you please review my UVF request before you disappear? so i can take something out of my todo list? thanks
<Kamion> Mithrandir: I think I missed the livefs builds, but once ubiquity 0.99.72 binaries are in the archive, as far as I'm concerned you can start livefs builds for flight-7
<mdz> Kamion: good night
<mdz> Kamion: I'll take care of fabio's request
<Kamion> fabbione: there's little point in me trying to make judgement calls in this state; if mdz doesn't do it before then, I'll look when I get up
<Kamion> ah, ok, thanks
<Kamion> night
<fabbione> Kamion: ok thanks.. good night
<dholbach> hey janimo
<janimo> dholbach: hey
<janimo> are the candidate images ready?
<Tonio_> hi everyone
<infinity> Kamion: You didn't miss livefs builds, the cronjob is disabled anyway, since we were in Flight prep.
<pygi> GOSUB: around?
<janimo> infinity: there are not candidate images yet right?
<janimo> s/not/no/
<fabbione> dholbach: #41301 is gtk bug...
<fabbione> dholbach: it's a problem with desktop stack going crazy.. i have seen it here too and it's definetely not X
<fabbione> it's a focus issue
<fabbione> and X does not handle the focus.... kthxbye
<janimo> bug #41301
<Ubugtu> Malone bug 41301 in xorg "Mouse clicks stop working sporadically" [Normal,Confirmed]  http://launchpad.net/bugs/41301
<bluetoad> Hi fabbione
<fabbione> hi bluetoad 
<bluetoad> You went like a steam train at the bugs last night
<fabbione> bluetoad: welcome dude :)
<fabbione> eheh
<fabbione> bluetoad: i plan to get down to 50 by the end of tomorrow
<bluetoad> wow.  I'm watching a few but not much info coming from reporters
<bluetoad> I was going to ask about those Radeon ones you fixed with sync.
<schweeb> fabbione: is sparc CD installer working yet? or still have to tftp (sorry to bug you directly, but mail list, google, and wiki fail me here)
<fabbione> schweeb: on what kind of hw?
<fabbione> i am aware of a silo bug on v240
<fabbione> otherwise it should work
<fabbione> bluetoad: i noticed that we are facing a new kind of issue...
<bluetoad> what's that?
<fabbione> bluetoad: basically X has problems using Sync when monitor is on DVI
<fabbione> the logs are tricky to read
<fabbione> you notice that there is a ddc probe on port1 (port0 being the analog output)
<fabbione> or also called ddc2
<fabbione> you sometimes see that ddc2 doesn't return any value
<fabbione> and even if they return, sometimes they are just not used or taken into account
<fabbione> i did speak with upstream this morning and they did confirm that this is the case
<schweeb> fabbione: blade 1500
<fabbione> also when the monitor is CRT
<fabbione> schweeb: should work
<schweeb> excellent, thx
<schweeb> the mini.iso from current/ under Dapper?
<bluetoad> fabbione: I wondered  about crt for power pc
<fabbione> schweeb: i didn't test that one specifically.. i used the normal -server/desktop iso, but please test it and let me know...
<fabbione> bluetoad: you mean for when they use external monitors?
<pitti> Hello again
<bluetoad> fabbione: I meant lcd for power pc.
<fabbione> bluetoad: what about them?
<fabbione> they are usually on DVI port, but we always write sync ranges on ppc+ati unconditionally of the output port
<fabbione> so that's covered pretty well
<fabbione> oh btw
<bluetoad> #29540 still has a problem on g3 notebook 
<fabbione> guys. bluetoad is the first guy with enough balls to work on X with me...
<bluetoad> no brains
<fabbione> you desktop ladies :P
<fabbione> bluetoad: they know why they are guilty :P
<fabbione> bug #29540
<Ubugtu> Malone bug 29540 in xorg "Fails to write out sync ranges on G3 iBook video (ati rage 128)" [Major,Fix released]  http://launchpad.net/bugs/29540
<bluetoad> yep
<fabbione> hmmm
<schweeb> fabbione: hrm, no regular build for flight 6? (it's 0bytes) http://cdimage.ubuntu.com/ports/releases/6.06/flight-6/
<fabbione> schweeb: there is beta out or daily
<schweeb> oh, nm
<schweeb> it's way to late for me to be trying to do any type of thinking
<fabbione> bluetoad: I tested the daily install for 20060408 and it did not work. It still had the same
<fabbione> bluetoad: he needs to try a more recent CD
<schweeb> thx for the info
<fabbione> from an upload to livecd propagation can take up to 24 hours or more
<fabbione> bluetoad: he did expect to get the fix on the CD the exact same day.. that's just not possible
<bluetoad> fabbione: I don't think we have logic for lcd in powerpc
<bluetoad> That's why I'm trying to get the detailed log
<fabbione> AHHHHH
<fabbione> GRRR HMMM MEEHHHH
<bluetoad> Don't even have a Device Id in the report, either.
<fabbione> one sec..
<fabbione> let me boot up my ppc
<fabbione> bluetoad: ok i see the issue here..
<fabbione> the panel on that laptop is broken and doesn't return indo
<fabbione> info
<fabbione> pitti: ping?
<bluetoad> fabbione: so what do you do about that?
<fabbione> bluetoad: thinking right now...
<fabbione> who has an iBook G3 here?
<fabbione> jdub: ^^???
<fabbione> jdub: is your toilet seat the ibook g3, isn't it?
<Kamion> schweeb: huh, wonder why that's 0 bytes
<jdub> fabbione: yeah
<fabbione> jdub: do you have it handy?
<jdub> fabbione: sort of - what do you need?
<jdub> i'd need to download dapper/ppc bits
<jdub> which might take a while
<Kamion> schweeb: hard to tell now, use the beta instead of flight-6
<Kamion> I suspect that ISO is lost
<Kamion> (if it ever existed)
<pitti> fabbione: pong
<fabbione> jdub: ok, i can wait for that.. i need you to do a clean dapper install on it and see if X is autoconfigured properly or you can suffer of #29540
<fabbione> pitti: same question as jdub...
<jdub> fabbione: with the beta live iso?
<fabbione> jdub: whatever.. live or install are fine
<Kamion> mm, on investigation I'm going for the "never existed" option
<fabbione> jdub: but please if you have the issue allow me to grab some info so i can fix it
<Kamion> use beta2 rather than beta if you're using the live CD
<jdub> Kamion: ok
<pitti> fabbione: I don't have a G3, my iBook is a G4
<fabbione> pitti: ok thanks anyway
<fabbione> bluetoad: the issue seems to be isolated to the ibook g3, so we can special case that one, once we have a unique keyword to use
<fabbione> brb
<jdub> fabbione: sucking an image down now
<bluetoad> fabbione: OK
<Kamion> mvo: libpango1.0-common fails to install, is breaking builds; e.g. http://librarian.launchpad.net/2461122/buildlog_ubuntu-dapper-i386.ubiquity_0.99.72_FAILEDTOBUILD.txt.gz
<Kamion> seems ok on upgrade
<Kamion> hmm, idle 2.5 hours, maybe I'll look myself
<bluetoad> fabbione:  I need fly.  I'll have a look at some more tomorrow.  Got commitments tonight (now).
<jdub> fabbione: 1hr to go, even from au ;)
<fabbione> jdub: it's ok.. even with 2 hours
<fabbione> oh he left alreayd
<fabbione> Kamion: livecd -> casper reconfigure X with DEBUG stuff turned.. where is that log stored?
<fabbione> never mind
<fabbione> i am blind
<Kamion> Mithrandir: ubiquity build blocked on libpango1.0-common installability; I'm sorting it out
<sivang> morning all
<pygi> mornin' sivang
<sivang> hey pygi 
<YokoZar> Is apt-get build-dep supposed to ignore pipes in the package build depends?  I have a package build-depend on "libicu28-dev | libicu34-dev" and apt-get complains that libicu28-dev isn't installable, but that libicu34-dev replaces it...then errors out.
<pitti> hi janimo 
<janimo> hi pitti
<pitti> janimo: if Mithrandir/infinity allow uploading, can you please fix xfce4-verve-plugin to build a POT?
<pitti> janimo: it's the only XFCE package left without one
<janimo> pitti, ok
<janimo> I was postponing that since there's also a bugfix update I needed to bring in but will do now instead
<pitti> janimo: oh, some days don't matter
<pitti> janimo: I just wanted to make sure that it's on your list
<janimo> ah ok, I thought you needed to cross of something for flight 7 :)
<janimo> on my list definitely
<pitti> thanks
<pygi> hi vuntz__
<vuntz__> hello pygi
<janimo> any idea why pbuilder could barf with: ln: creating symbolic link `/etc/pango/pangox.aliases' to `/var/lib/defoma/pango.d/pangox.aliases': No such file or directory
<janimo> just saw this today, wonder if something in this area changed or the chroot is corrupted
<Kamion> janimo: libpango1.0-common is broken for fresh installs; I'm working on it right now
<janimo> Kamion, ah, thanks
<pitti> mvo: please remove console-data from the 'missing POT' list. It does have a POT, but po and pot are in debian/, so my scripts ignore them
<carlos> Riddell: hi, around?
<pitti> hi carlos 
<carlos> pitti: I saw that you are fixing packages that lack the .pot file (wget and whois) 
<carlos> pitti: hi
<pitti> carlos: yes, I hope we can finish the list RSN
<janimo> Mithrandir: 1) upload exception for xfdesktop (bugfixes for removable media on desktop)? 2) are candidates going to build today? (I need to plan since it takes ~4 hours to DL)
<carlos> pitti: I'm finishing now my list
<pitti> carlos: can you confirm that you could import console-data? the layout is a bit special
<carlos> pitti: I can import anything 
<carlos> pitti: if it has a .pot file
<carlos> we get the files anyway
<carlos> and if it's not imported automatically, I approve them manually
<pitti> carlos: yes, it has, but since my scripts ignore debian/*, they don't pick them up
<carlos> nothing is lost like we did with hoary and breezy
<Kamion> janimo: (note that candidate builds are blocked on libpango1.0-common too)
<pitti> carlos: can you please check console-data? (just to make sure)
<janimo> Mithrandir: also upload exception for xfce4-verve-plugin. Nothing critical (POT file generation)
<carlos> pitti: https://launchpad.net/distros/ubuntu/dapper/+source/console-data/+translations
<pitti> carlos: ah, sweet. thanks!
<Kamion> ok, pango1.0 fix uploaded
<pitti> Mithrandir: permission to upload gcompris? only change is building a POT, the debs don't change at all
<Kamion> infinity: are you around, or is that an auto-rejoin?
<Kamion> ah, /me notices the /away
<Kamion> Mithrandir: ok, since ubiquity 0.99.72 is blocked on pango and will need a retry anyway, I'll upload 0.99.73 in the next archive cycle with a fix for a problem mdz noticed last night
<StevenK> pitti: I suspect the reason for the empty POT file is no strings to translate.
<pitti> StevenK: so there are no *.po files?
<StevenK> pitti: For ldaptor-webui there are; for ldaptor (which has the empty POT file), there are none.
<pitti> StevenK: ok, if there are no po files and no _("foo") strings (and no .desktop files either) it's safe to assume that there's nothing to be translated
<pitti> StevenK: so removing the POT file should be fine
* StevenK nods. 
<StevenK> ldaptor 0.0.42ubuntu3 is in the archive which does that.
<Mithrandir> janimo: since those only touches your files, please do.
<Mithrandir> pitti: preferably not.
<pitti> Mithrandir: ok, I'll stage the uploads then
<Mithrandir> Kamion: ok, so we should be ready to build images in roughly two hours?
<fabbione> Mithrandir: can you give me 10 minutes to upload another xorg-7.0.0 please?
<fabbione> Mithrandir: it would be also nice if you could give me the 2 keyboard patches i asked for :/
<Mithrandir> fabbione: debdiff?
<mjg59> Hm. Don't we need the new l-r-m first?
<Mithrandir> fabbione: sorry, I won't have time to do that in the next ten minutes.  I also just saw one request?
<fabbione> Mithrandir: one.. possibly..
<fabbione> Mithrandir: one sec for the debdiff. the code is safe tho
<fabbione> Mithrandir: http://people.ubuntu.com/~fabbione/debdiff
<Kamion> Mithrandir: unless you want to wait for the new kernel
<fabbione> Mithrandir: i remember one/two requests, but i might be wrong.. i parsed something like 120 bugs yesterday..
<mjg59> Kamion: We don't currently seem to have an l-r-m for the current kernel ABI
<Kamion> mjg59: the seeds still point to 2.6.15-21
<mjg59> Kamion: Ah, ok
<Kamion> mjg59: so as long as no ftpmaster decides to remove -21, it should work
<mjg59> Kamion: It would be immensely helpful if we could get more -22 testing
<Kamion> Mithrandir: your call, I guess
<Kamion> I need to upload d-i anyway, for localechooser and kbd-chooser fixes
<mjg59> Though if that's going to cause a significant holdup, then I wouldn't worry
<Kamion> mjg59: well, we were expecting a fixed kernel that built on sparc yesterday ...
* fabbione is in the need of food
<Kamion> so unless we want to attempt to make it go without sparc (which is kinda painful), we have to wait for a whole kernel build cycle
<fabbione> Mithrandir: i am grabbing a bite.. back in 10
<Mithrandir> Kamion: hmm, true.
<Kamion> my inclination would be to go ahead without, I think
<Mithrandir> Kamion: given that we were promised a new kernel more than twelve hours ago, I'm not too inclined to wait either.  So, let's go ahead once you have the bits you want in the archive.
<zakame> hi all
<janimo> Mithrandir, was logged out, did you approve the xfdesktop upload?
<janimo> I guess it will take a few hours to build so if it holds back flight7 I'll just leave it to later
<janimo> it's not critical just nice to have
<tseng> pitti: do you have a doc on that?
<tseng> pitti: i really know nothing about it
<Kamion> infinity: did anything ever try to build debian-installer_20050317ubuntu20 for breezy-security, and if so could I see the build logs? It looks like it didn't build successfully anywhere
<Kamion> Mithrandir: install CD builds should be a few minutes faster now than for the last release, BTW; although I expect all that will do is make the disparity between install CD and livefs build times even more obvious ;-)
<tseng> janimo: ping
<janimo> tseng: hi
<tseng> janimo: hi, would you mind taking malone #42350 off my hands?
<Ubugtu> Malone bug 42350 in beagle "Beagle's daemon is not autostarted in xfce/xubuntu." [Normal,Unconfirmed]  http://launchpad.net/bugs/42350
<tseng> janimo: notourbug
<janimo> tseng, you can just assign to xubuntu-team or myself
<tseng> xubuntu-team, no problem
<janimo> thans
<janimo> k
<carlos> pitti: Riddell: https://chinstrap.ubuntu.com/~dsilvers/paste/filejtGubv.html
<carlos> pitti, Riddell: That's the list of translation domains that miss a .pot file
<carlos> pitti: at the end, you have also some translation domains that should not be inside language packs
<Mithrandir> janimo: 11:22 < Mithrandir> janimo: since those only touches your files, please do.
<carlos> pitti: I think there are some others missing, but that's the current list I got
<janimo> Mithrandir: ok
<carlos> pitti: also, as I noted there, I don't know where 'childpanelextension' comes from
<tseng> janimo: if you need action from me after you find the cause, gimme a poke
<janimo> tseng, ok althoug hthis looks like many gnome autostart apps do not start under xfce
<janimo> have to see why
<tseng> yes.
<tseng> doesnt seem that bad, if people didnt see it 'enabled' in an xfce ui
<Mithrandir> janimo: please tell me when you have the .debs in the archive and I can build you cds.
<janimo> tseng, as they are marked only show in gnome I am not surprised
<janimo> tseng, so if you want beagle to run in xfce fix the .desktop file . the ball is back at you :)
<tseng> janimo: then it should not show up in their gui
<janimo> I think the autostart daemon is marked only show in, but the actual executable is not?
<janimo> I think they say they run beaglke-client or whatever it;s called but no daemon is there to back it up
<tseng> selected in the "Autostarted applications" panel
<janimo> ok, I'll look even closer then
<janimo> o, so an xfce4-session bug then.
* janimo takes the ball back
<tseng> if you ignore my .desktop, ignore it consistantly :)
<janimo> Mithrandir the CDs you are about to build are candidates or final flights?
<Mithrandir> janimo: they're always candidates until we have released them.
<janimo> ok
<pitti> carlos: ok, some of them are on my list, too
<carlos> pitti: ok
<pitti> carlos: however, can we walk through the list in /msg? there are some suspicious ones
<carlos> sure
<carlos> Riddell: ping
<Riddell> carlos: pitti just sent me the list of kde packages from your list, I'll look into them
<carlos> Riddell: ok, thanks
<carlos> Riddell: those are translation domains I got from kde-i18n-* packages
<carlos> not sure if those are not valid anymore or that we miss the .pot file, if are not valid, just tell me and I will ignore those .po files
<carlos> like I did with kdevelop ones
<carlos> mdke: hi, Could I close #42645?
<pitti> carlos, Riddell, tseng, mvo, seb128, dholbach: I just created https://wiki.ubuntu.com/MissingPotFiles for coordination of POT file fixes; can you please use this as well and update it accordingly?
<seb128> pitti: sure
<seb128> good idea ;)
<carlos> pitti: thanks
<Diziet> Mithrandir: Yes, please assign firefox bugs to me, or at least make sure I'm subscribed.
<Mithrandir> Diziet: ok
<seb128> pitti: what are those "docs" listed?
<seb128> pitti: why do they "must" be fixed?
<pitti> seb128: carlos wants to import them into Rosetta
<carlos> seb128: it's documentation using .po files to translate it
<carlos> same thing like help/* files
<seb128> pitti: yeah, but do you have to do to fix them?
<seb128> like gdm uses cdbs, it should "just work" no?
<seb128> same for gnome-*
<carlos> pitti: btw, how is that your Wiki name is MartinPitt2 ? is there another MartinPitt that is not you?
<pitti> seb128: hm, I fixed cdbs for help/ , but not for docs/ etc.
<pitti> carlos: hm, no idea TBH
<fabbione> hey
<seb128> pitti: what do I need to run? intltool-update -p is only for po no?
<fabbione> xorg bugs almost fit in one LP page!
<tseng> there was a large import of debian developers into launchpad users i think
<carlos> pitti: https://launchpad.net/people/pitti <- Fix it there ;-)
<pitti> seb128: -p will generate a pot file
<seb128> fabbione: nice work ;)
<fabbione> 1   75  of 85 results
<seb128> pitti: yeah, but it complains that help is no a po dir
<seb128> intltool-update: Unable to proceed.
<seb128> Make sure to run this script inside the po directory.
<pitti> seb128: no idea TBH, I don't know how these are handled
<seb128> hum
<seb128> I don't agree that are a "must" fix for dapper
<carlos> seb128: I think they are not using intltool for them
<seb128> language packs don't ship them anyway
<pitti> seb128: but there must be a pot somehow, how else did the translators get initial po files?
<pitti> seb128: right
<carlos> seb128: no it's not a must
<pitti> seb128: we can defer the docs/ stuff until later
<seb128> the wiki pages is "Source packages whose POT files must be fixed"
<pitti> seb128: but it's nice to have a todo list anyway
<seb128> pitti: right ;)
<pitti> seb128: don't take it too seriously - read it as 'eventually', not 'RIGHT NOW!' :)
<lucas> hi, are there some guidelines somewhere for reporting bugs like "When I log out, display hangs, Xorg takes 100% CPU, and can't be killed using kill -9" ?
<seb128> pitti: I don't like having half of the page being GNOMEish :p
<pitti> seb128: hm, with help/ it works with 'cd help; make pot'
<pitti> seb128: maybe it works with docs/, too?
<seb128> hum
<seb128> for sound-juicer it needs to cd help/sound-juicer
<seb128> then "make pot"
<seb128> and that works fine
<pitti> seb128: that merely requires a rebuild then
<pitti> seb128: help/ is cdbs'ed
<pitti> seb128: same for the help/ part of gnome-applets
<seb128> I did upload those package some days ago or this week
<seb128> that is weird
<seb128> you cdbs change is not that new
<seb128> right
<seb128> cd $(DEB_BUILDDIR)/help; make pot || true;
<seb128> it does that
* pitti checks build log
<seb128> for s-j you need to cd help/sound-juicer as said
<seb128> running "make pot" from "help" doesn't work
<pitti> make[1] : Entering directory `/build/buildd/sound-juicer-2.14.3/help'
<pitti> make[1] : *** No rule to make target `pot'.  Stop.
<pitti> ?
<pitti> WTH?
<seb128> $ ls help
<seb128> Makefile  Makefile.am  Makefile.in  sound-juicer
<seb128> $ grep pot help/Makefile
<seb128> $
<pitti> aah
<seb128> $ grep pot help/sound-juicer/Makefile
<seb128> _DOC_POT = $(if $(DOC_MODULE),$(DOC_MODULE).pot)
<seb128> .PHONY: pot
<seb128> pot: $(_DOC_POT)
<seb128> 
<seb128> if that's clear that way :p
<pitti> seb128: ok, that needs manual fixing then
<pitti> seb128: yes, sorry, didn't read thoroughly enough
<seb128> will do
<pitti> hi sabdfl, good morning
<sabdfl> hey pitti
<zakame> hello sabdfl 
<sabdfl> how are we on the RaceToDapper?
<pitti> full spead ahead :)
* ..[topic/#ubuntu-devel:slomo] : 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 | If your initramfs is broken in any way, please save a copy for infinity | LP upgraded, report issues on #launchpad | Flight-7 preparations in progress, uploads to main must be approved by Mithrandir
<zakame> indeed
<zakame> hi Hobbsee 
<Hobbsee> hi zakame 
<Tonio_> hi
<kasina> hi Tonio_
<infinity> Kamion: I've been in "ingore IRC mode" for ages (first work, then dinner), sorry.
<Kamion> not a problem, superseded
<Mithrandir> ok, building livefs-es for ubuntu and install images for ubuntu, will do the rest of the derivatives once those are done.
<infinity> Hrm?  You uploaded another d-i to breezy-sec?
<infinity> Oh, no you didn't.  Then no idea what you meant by "superseded".. :)
<infinity> Kamion: Anyhow, I'll talk to you about it after your lunch/
<Mithrandir> slomo_: please don't upload to main now, we're trying to get flight-7 out.
* infinity grumbles about that debhelper breakage.
<infinity> I wonder if I should take all the blame, or give half to dholbach. :)
<infinity> slomo_: Also, can you please avoid build-depending on exact versions of debhelper required for bugfixes?
<infinity> slomo_: Though I suppose in this case, it doesn't hurt, since anything using dh_iconcache will (well, should) have a pretty high versioned build-dep anyway.
<infinity> slomo_: Oh, actually.. Hrm.  No.  CDBS calls dh_iconcache in a conditional, so it doesn't need an inflated build-dep, so you just made all those package unbackportable, when previously they were fine.
<pitti> carlos: can you please take a look at bug 41130?
<Ubugtu> Malone bug 41130 in language-pack-de " instead of a new line when running espresso and entering the wrong password" [Normal,Unconfirmed]  http://launchpad.net/bugs/41130
<pitti> carlos: this happens a lot; can this be checked in Rosetta?
<seb128> carlos, pitti: rosetta will import a help/sound-juicer/sound-juicer.pot correctly, right? (ie: the location is not an issue)
<carlos> seb128: no, it will not be an issue, I approve them manually the first time I see them
<seb128> carlos: ok, fine then ;)
<carlos> pitti: yes, we could do something to fix those
<pitti> carlos: (I believe the translation itself has already been fixed)
<carlos> pitti: https://launchpad.net/products/rosetta/+bug/46
<Ubugtu> Malone bug 46 in rosetta ""special symbols" when people copy-paste text from original to translation" [Normal,Confirmed]  
<carlos> pitti: please, add your comments there, I'm going to change its priority
* StevenK wonders what the next bug number after 1 is.
<janimo> is there a way to auto-assign bugs on specific packages to a team besides just making it a bug contact?
<Riddell> pitti: know anything about this cups error?  Request Entity Too Large"
<pitti> Riddell: uh, no, sorry
<pitti> janimo: no; but subscribing the team to the package should be good enough
<Riddell> pitti: I can give it to you in 3 different frontends if you want :) http://kubuntu.pastebin.com/697830
<pitti> janimo: you'll see it in +packagebugs, get mails, and so on
<zul> heylo
<pitti> Riddell: is that hplip?
<Riddell> pitti: yes
<janimo> pitti: yes, but no way I see to get all bugs on all packages of xubuntu-team
<janimo> https://launchpad.net/people/xubuntu-team/+packagebugs
<janimo> https://launchpad.net/people/xubuntu-team/+assignedbugs
<janimo> a combination of these two somehow
<pitti> Riddell: bug 42401 probably
<Ubugtu> Malone bug 42401 in cupsys "lpadmin: Request Entity Too Large" [Normal,Unconfirmed]  http://launchpad.net/bugs/42401
<pitti> Riddell: Can you please set LogLevel to debug2, remove error_log, restart cupsys, try to add the printer, and attach error_log to that bug?
<pitti> Riddell: then I can toss it to upstream
<Riddell> pitti: how do I set the LogLevel?
<Riddell> oh, cupsd.conf
<pitti> Riddell: yes
<ogra> woah
* ogra just bought a new usb wlan adapter for his brother in law (for win 2000) 
<janimo> carlos, for each xfce package I want in rosetta I need to set up a project first right?
<ogra> apparently that thing has a mass storage device inside as well, holding the driver
<carlos> janimo: no if it's for Ubuntu
<ogra> i just tried it on my ibook and hal freaks out
<ogra> pitti, ^^^
<carlos> janimo: you don't need to do anything for Ubuntu
<pitti> Seveas: do you still have the USN RSS feed somewhere?
<carlos> just upload a source package that produces the .pot file
<janimo> carlos, hmm it's all automatic? cool
<Seveas> pitti, yes
<pitti> ogra: oi, backtrace appreciated :)
<janimo> yay, less boring work than I tought :)
<Seveas> ubuntulinux.nl/files/usn.xml
<carlos> janimo: needs something on my side, but you don't need to care, yes
<ogra> pitti, its not even seeing the wlan device inside :)
<janimo> carlos: thanks. So once you do whatever that is, they can be translated and end up in the language packs?
<carlos> janimo: I did that already 
<janimo> carlos: are subsequent upstream package uploads which change/add new translations taken into account too?
<pitti> ogra: freak out == crash, or behave weird?
<carlos> janimo: only if they land into Ubuntu's archive
<pitti> ogra: in the latter case, can you generate a hal debug output (wiki.ubuntu.com/DebuggingRemovableDevices, second half of the page) and attach it to a bug?
<pitti> Seveas: merci
<ogra> pitti, an endless add/remove loop of the storage device
<carlos> janimo: https://launchpad.net/distros/ubuntu/dapper/+lang/es look for xfce*
<ogra> looks funny in the device manager 
<janimo> carlos: ok. indeed the packages seem to be translatable. I did not even check before as I assumed it requires some work onmy part
<ogra> pitti, i doubt its a hal thing ... seems to be rooted deeper
<ogra> (rather kernel)
<janimo> carlos, ok so if I add a new language to a package and translate it, I can just export the .po file and sent it upstream too?
<ogra> pitti, its not urgent, i dont need it running here, i just thought i'd test it before installing it on the win2000 pc
<infinity> Seveas: Have you talked with anyone about getting those RSS feeds into the DC, by any chance?  I've been using them for ages now, and I'd love it if they lives on ubuntu.com somewhere, just so they'd be a bit easier to advertise.
<Riddell> pitti: added
<carlos> janimo: yes, but if it would have some Ubuntu specific strings (depending if you changed the source code like we did with GNOME and KDE to include some specific changes)
<Seveas> infinity, I've proposed it several times and people tend to like it. No one takes action though
<janimo> carlos, only a few packages have minimal changes. looks good thanks
<mdke> carlos: sure, no problem about closing it: I only filed it in case you wanted to figure out what happened. For me, the problem is fixed so I don't mind.
<infinity> Seveas: Ahh.
<carlos> mdke: I'm not able to reproduce it, if you see it again I tell me it and I will try to be faster to debug it...
<pitti> Riddell: thanks
<carlos> pitti: btw, the language snapshot for today failed, the mirror is still running so I will need that you run your script by hand later...
<pitti> carlos: no problem, if it succeeds tomorrow I don't need to do anything
<carlos> well I would need an updated report today... so if you could run it today, that would be good (I will ping you when my tarballs are ready)
<Mithrandir> Riddell: kubuntu install images up, please test.
<Mithrandir> pitti: any chance for you to test the install images for ppc?
<Riddell> Mithrandir: thanks
<pitti> Mithrandir: of course, I'm just waiting for the 'new images up' anouncement
<Mithrandir> pitti: install images are up now.
* pitti jigdos away
<janimo> Mithrandir: can spin xubuntu as well, the debs are in. thanks
<Mithrandir> janimo: will do once edubuntu has built.
<ogra> Mithrandir, there is no point in building edubuntu
<ogra> its still 3 Meg to big
<pitti> Mithrandir: live images will follow?
<ogra> err 8
<Mithrandir> ogra: ok.
<Mithrandir> ogra: does that mean you won't release a flight 7?
<mdke> carlos: sure thing.
<ogra> yep
<Mithrandir> pitti: yes, once the live fs-es are built, I'll do that.
<pitti> 'k
<ogra> Mithrandir, i have too much on my plate currently, live should be fine though 
<Mithrandir> ogra: "yes, you will release flight-7" or "yes, you won't release flight-7"?
<ogra> yes i wont
<Mithrandir> ok
<infinity> Mithrandir: Oh, I suspect we'll want to skip ports-live this time around (though it's too late for me to stop you from kicking off those livefs builds now, sorry)
<infinity> Mithrandir: I still have some ports-live bugs to fix, so there's not much point in holding up the other arches based on 3 CD images almost no one will test.
<infinity> Mithrandir: I'll make sure they start getting fixed dailies on the weekend or something.
<Mithrandir> infinity: ok.  I'm just waiting for weddell to finish now.
<infinity> Mithrandir: Which qualifies as "ports" too. :)
<infinity> Mithrandir: So you may as well just sping the live ISOs right now. :)
<infinity> s/sping/spin/
<janimo> Mithrandir:  the image will go to http://cdimage.ubuntu.com/xubuntu/daily/20060504/ right?
<janimo> I am writing a call for testing in advance
<Mithrandir> janimo: yes.
<Mithrandir> seb128: bug 39640; should this be rejected?  We don't have gaim 2 in the repositories?
<Ubugtu> Malone bug 39640 in gaim "[2.0beta3]  gaim: status pulldown menu is half empty (drawn offscreen)" [Normal,Unconfirmed]  http://launchpad.net/bugs/39640
<seb128> Mithrandir: not really, upstream are nice enough and some of them are subscribed to the package
<seb128> Mithrandir: the package comes from my people.ubuntu.com page too and I've asked to send feeback on launchpad making clear from the title they are using 2.0beta3
<Mithrandir> seb128: oh, ok.
<seb128> Mithrandir: we can ignore them for now so, upstream reply and it'll be useful when we upload gaim2.0
<Mithrandir> seb128: ok, I'm just going through unconfirmed and confirming bugs.
<Mithrandir> janimo: xubuntu install images up
<janimo> Mithrandir: thanks
<janimo> Mithrandir: I assume they are uploading now as it's only a 400Mb sparc one
<janimo> from apr 19th
<Mithrandir> janimo: they're still syncing it seems, yes, but http://cdimage.ubuntu.com/xubuntu/daily/20060504/ already has amd64 images.
<janimo> yup, I see they're showing up one by one
<janimo> http://cdimage.ubuntu.com/xubuntu/daily/20060504/report.html
<janimo> what does uninstallable  mean here?
<janimo> not made it to the CD? As xubuntu has OOo in ship but does not install it
<Mithrandir> that they can't be installed.  You can ignore those, ooo2 has been renamed to ooo.
<pitti> Riddell: if you do 'lpadmin -p LaserJet -v usb://HP/LaserJet%201022 -P /usr/share/ppd/hpijs/HP/HP-LaserJet_1022-hpijs.ppd', do you get this error, too?
<pitti> Riddell: ooh, wait: what is 'ls -l /var/cache/cups/ppds.dat' for you?
<pitti> Riddell: your error_log has just one error: 'Unable to write "/var/cache/cups/ppds.dat" - Permission denied'
<Riddell> ls: /var/cache/cups/ppds.dat: No such file or directory
<pitti> $ ls -ld /var/cache/cups/
<pitti> drwxrwxr-x 3 cupsys lp 4096 2006-05-02 20:06 /var/cache/cups/
<pitti> ^ for me, that's how it should be like
<Riddell>  /var/cache/cups/ ls drwxr-xr-x 4 root root 0 2006-04-26 02:59 ppd
<Riddell> ls -l /var/cache/cups/
<Riddell> total 0
<Riddell> drwxr-xr-x 4 root root 0 2006-04-26 02:59 ppd
<pitti> Riddell: ls -ld /var/cache/cups?
<Riddell> ls -ld /var/cache/cups
<Riddell> drwxrwxr-x 4 cupsys lp 40 2006-05-03 03:50 /var/cache/cups
<pitti> hm, that looks fine
<Riddell> lpadmin -p LaserJet -v usb://HP/LaserJet%201022 -P /usr/share/ppd/hpijs/HP/HP-LaserJet_1022-hpijs.ppd
<Riddell> lpadmin: Request Entity Too Large
<pitti> Riddell: and lpstat -p doesn't show the printer?
<Riddell> lpstat -p
<Riddell> printer LaserJet disabled since Thu 04 May 2006 01:13:22 PM UTC -
<Riddell>         reason unknown
<Riddell> which is strange, I don't have a laserjet
<pitti> Riddell: you just added it with that lpadmin command :)
<Riddell> ah, right :)
<pitti> hm, I can't reproduce it here
<bddebian> Morning folks
<bddebian> Riddell: Mind if I ask you a dumb question?
<Riddell> bddebian: please do
<pitti> Riddell: if you purge cupsys, rm -rf /etc/cups and /var/{cache,run}/cups and reinstall, do you still get it?
<bddebian> Riddell: There are several bugs about icons not showing in Gnome for KDE apps.  KDE uses .menu files while Gnome uses .desktop correct?  Or am I wrong?
<Riddell> bddebian: both gnome and kde use the freedesktop xdg menu spec
<Riddell> bddebian: got an example?
<bddebian> Ohh, hmm
<bddebian> Riddell: I'll find one, I just got on.. :-)
<Mithrandir> Riddell: https://launchpad.net/distros/ubuntu/+source/keep/+bug/39380 for instance
<Riddell> bddebian: ah, adept will be so because it's run as "kdesu adept"
<Ubugtu> Malone bug 39380 in keep "No menu icon in GNOME" [Normal,Confirmed]  
<Riddell> do it's probably looking for the kdesu icon not the adept icon
<bddebian> Riddell: Ah, hmm
<bddebian> Heya dholbach
<Riddell> dholbach: any idea how for gksudo apps gnome doesn't look for the gksudo icon?  we're wondering how to get it to do the same for kdesu apps
<Riddell> Mithrandir: that's a mystery, the keep icon is in /usr/share/icons/hicolor/*/apps/keep.png
<Riddell> hmm, adept has Icon=adept so that should be ok too
<dholbach> Riddell: maybe you ping mvo later about it
<Riddell> lpadmin -p LaserJet -v usb://HP/LaserJet%201022 -P /usr/share/ppd/hpijs/HP/HP-LaserJet_1022-hpijs.ppd
<Riddell> lpadmin: Request Entity Too Large
<Riddell> pitti: ^^ after stopping, purging, removing directories, reinstalling and starting again
<bddebian> Rat bastards closing my bugs
<bddebian> Riddell: .desktop files should get icon from /usr/share/pixmaps/foo.xxx
<bddebian> It should'nt grab gksudo/etc icon
<Riddell> it should get it from the standard icon locations
<bddebian> Damn bug stealers
<bddebian> Riddell: Isn't that /usr/share/pixmaps?
<Riddell> seems like a gnome bug to me
<bddebian> That's where I usually have been installing them when adding .desktop files and they seem to work
<Riddell> no, /usr/share/pixmaps is a last resort, it should be /usr/share/icons/theme/size/apps/
<Riddell> and for .desktop files theme should be hicolour since that's the fallback theme for everything
<bddebian> Hmm
<Riddell> and speain of icons, cdimages.ubuntu.com really needs a crystal theme :)
<Riddell> speaking
<bddebian> Damn, now you have thrown me all off for my bug hunting today.. :-)
<seb128> bddebian: what is your issue?
<seb128> bddebian: you might be interested by http://live.gnome.org/GnomeGoals/AppIcon
<bddebian> seb128: Same as always.  Figuring out what to look at today :-)
<pitti> Riddell: alright, thank you
<bddebian> I was going to try to hit some kubuntu bugs today I guess
<Riddell> bddebian: yes please :)
<bddebian> Riddell: You say that now, util I start inundating you with questions ;-P
<seb128> bddebian: heh you are not done with GNOME bugs, there is still some not triaged, don't run away like that :p
<bddebian> seb128: I move around.  I hit Unmet Deps one day, Unconfirmed the next, MOTUScience bugs, etc, etc
<seb128> ah, k ;)
<seb128> you like change :)
<bddebian> Not that I can actually do anything substantial mind you :'-(
<bddebian> Hello Kyral
<Kyral> hey
<bddebian> seb128: I'd actually like to help main a lot more but most times I think I just get in the way
<tritium> bddebian: you can look at the bugs I've reported or subscribed to :)
<seb128> bddebian: I'm sure there is things you can do easily, confirming bug, closing duplicates, etc. And asking questions is not "get in the way", you learn and become better at doing what you do by yourself then ;)
<bddebian> seb128: Well I seem to annoy the hell out of certain people :-)
<bddebian> tritium: You have assigned bugs? :-)
<tritium> bddebian: motu-science, but I've also reported a few and subscribed to a few
<Mithrandir> mgalvin: around, by any chance?
<mgalvin> Mithrandir: yup, hi
<bddebian> tritium: I think I've fixed all the MOTUScience ones that I can vix
<bddebian> Err fix even
<Mithrandir> mgalvin: sorry for the late notice, and I'm not sure if it's needed, but we're going to release flight 7 today or tomorrow.  Any chance you could whip up a nice-looking "what's changed since beta" page for me?
<tritium> bddebian: yeah, you've been filling my inbox!  Nice work :)
<bddebian> tritium: Bah, thx
<jjesse> mgalvin and i talked about this and are there a lot of changes that would neccesistate a flight7 wiki page?
<Kamion> infinity: oh, d-i/breezy-security; I thought you were talking about the *other* thing I was trying to get hold of you about :-) (ubiquity rebuild, no longer necessary)
<jjesse> as i was going to do a KubuntuFlight7 page
<Mithrandir> jjesse: given that we're in deep freeze, no, I hope there aren't too many changes, but I'l been stuck in my little hole for the last few days, so I'm not sure.
<mgalvin> Mithrandir: as jjesse was saying, it seems all the changes are mostly bug fixes so i was thinking of just linking to the announcement
<Mithrandir> mgalvin: ok, I guess that works.
<Riddell> jjesse: knetworkmanager is in ship (on cd but not installed by default) and wlassistant is in desktop
<mgalvin> as was done for flight 1 and beta 2... although... i will spend some time looking at everything... if there is enough to cover i will create a page for it
<pitti> Mithrandir: ppc/install went fine
<Riddell> jjesse: kubuntu espresso is now ready for some serious testing
<jjesse> Riddell: would that be a change for releasenotes?
<mgalvin> Mithrandir: i will let you know for certain either way if i get a page ready in time
<Riddell> jjesse: yeah, I guess so
<infinity> Kamion: Ahh, I suspect the ubiquity ping had no payload, so I assumed both prods were for the same thing.
<Kamion> infinity: yeah, I'm still interested in whether debian-installer_20050317ubuntu20 built anywhere
<Kamion> infinity: yeah, my bad
<infinity> Kamion: It didn't build anywhere due to the "jackss doesn't host a d-i component in breezy-security" thing, or whatever it was, but I can certainly work around that.
<Kamion> btw, for the install CDs, it's worth checking for breakage in kbd-chooser choices; I didn't, er, actually test that change
<Kamion> infinity: where else would the packages come from? I don't think they've been ambered
<infinity> Kamion: Oh, if they've not been ambered, then they can't come from anywhere yet.  We don't build-from-accepted.
* infinity goes to look at the latest logs.
<Kamion> hmm, actually, we might be ok
<Kamion>   cdebconf | 0.84ubuntu12 | breezy-security | source
<Kamion>   cdebconf | 0.84ubuntu12 | breezy-security/universe | amd64, hppa, i386, ia64, powerpc, sparc
<infinity> Yeah, we fail here:
<infinity> Get:5 http://jackass.ubuntu.com breezy/main/debian-installer Packages [21.0kB] 
<infinity> Failed to fetch http://jackass.ubuntu.com/dists/breezy-security/Release  Unable to find expected entry  main/debian-installer/binary-sparc/Packages in Meta-index file (malformed Release file?)
<Kamion> yeah, building from drescher's breezy-security should work fine then
<infinity> Fetched 71.9kB in 0s (74.2kB/s)
<infinity> And I can obviously work around that.
<Kamion> yep, changing the buildds' /etc/apt/sources.lists should be sufficient
* infinity nods.
<infinity> I can do that right nowish, then.
<infinity> (Last time I suggested doing that, you said you wanted to fix jackass instead or some such.. I guess you're over that?)
<ogra> Kamion, can you (or another CC member) please make the people of the EC administrators of edubuntu-members ? (no hurry though)
<ogra> Kamion, http://www.edubuntu.org/news/3 has the list
<Kamion> ogra: I don't think the CC has any special privileges with respect to that team; we're just indirect members. you're marked as the administrator, AIUI you should be able to do it yourself
<Kamion> infinity: I think we might as well JFDI
<ogra> Kamion, nope, CC is the owner
<ogra> only the owner can make new admins apparently
<Kamion> oh yes, so it is
<ogra> as i said, no hurry
<ogra> if it happens during the next days/weeks thats fine 
<ogra> (we wont have an EC meeting before june)
<Mithrandir> Riddell: kubuntu live images up too
<Riddell> Mithrandir: tnks
<Riddell> thanks
<Kamion> ogra: done
<ogra> meh, i just wanted to move it from my todo to yours, didnt want to cause work now :)
<ogra> thanks :)
<Kamion> was easy enough while I was there
<ogra> ok :)
<bddebian> Wow, KDevelop is kinda cool
<Riddell> :)
<bddebian> Riddell: Is this correct or should this be filed under konqeror package?  Bug #42485
<Ubugtu> Malone bug 42485 in kdebase "Improve Konqueror defaults for Dapper" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/42485
<Riddell> bddebian: it should be kubuntu-default-settings
<Riddell> bddebian: and you can reject it, that feature is inaccurate and causes lots of disk activity
<bddebian> Riddell: Oh, OK, thx
<Riddell> thank you
<Gloubiboulga> janimo: around?
<janimo> yes
<janimo> ogra: does ltsp-client-builder in the installer mean it is automatically installed right?
<janimo> does it somehow imply install X only and no desktop?
<janimo> there's a report of todays xubuntu CD not installing much besides Xorg, and a ltsp config error during install
<janimo> ogra: seems it's CD errors so nevermind
<bddebian> Should a .pot file be in the -dev package instead of the normal lib package?
<seb128> a .pot should not be shipped by a binary package
<seb128> what bug is that?
<bddebian> Bug #33676
<Ubugtu> Malone bug 33676 in kdelibs "produces zero-length kde.pot" [Normal,Unconfirmed]  http://launchpad.net/bugs/33676
<seb128> bddebian: why do you speak about lib package?
<Riddell> bddebian: which package is it shipped in?
<seb128> bddebian: the .pot is the list of strings to translate, part of the source directory and used by rosetta
<bddebian> seb128: http://librarian.launchpad.net/2433849/buildlog_ubuntu-dapper-i386.kdelibs_4%3A3.5.2-0ubuntu13_FULLYBUILT.txt.gz
<seb128> Riddell: according to the bug it's kdelibs package
<Riddell> seb128: kde.pot is specil, it's a list of standard strings to be excluded from other .pot files
<bddebian> In -dev package:  -rw-r--r-- root/root     13730 2005-09-10 09:27:50 ./usr/include/kde/kde.pot
<Kamion> kdelibs4-dev
<Kamion> if it's been fixed now, great
<seb128> Riddell: https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/33676
<Ubugtu> Malone bug 33676 in kdelibs "produces zero-length kde.pot" [Normal,Unconfirmed]  
<infinity> Kamion: I haven't actually tried the build yet, but I'm a bit concerned about cdebconf appearing to be in universe, according to madison-lite...
<infinity> Kamion: Does d-i pull from universe, or will that break horribly?
<bddebian> Wow, if I try to install kdelibs4-dev on my kubuntu install it brings in a BOATLOAD of packages??
<Riddell> bddebian: I did fix that so if you can confm that kde.pot has strings in it that's all good
<Riddell> and it does need to be in -dev
<Riddell> bddebian: yes, it'll bring in the -dev packages needed by KDE
<bddebian> Yikes, OK, I'll check it thx
<Kamion> infinity: that's only cdebconf.deb; the necessary udebs are in main
<infinity> Kamion: Ahh.  Check.
<infinity> Kamion: I'll fire up some builds right now, then.
<Kamion> hmm need to fix madison-lite's config to spot udebs in -security
* bddebian becomes Riddell's slave the the day :-)
* Riddell hugs bddebian 
<Riddell> bddebian: if I happen not to be around you may get kde answers from #kubuntu-devel
<bddebian> Riddell: Ah, OK, thx
<bddebian> BTW, kde.pot in -dev is fine
<bddebian> Riddell: Are they more responsive than #xubuntu?
* bddebian hides
* Kamion prods madison-lite
<Kamion> cdebconf-udeb | 0.84ubuntu12 | breezy-security/main/debian-installer | amd64, hppa, i386, ia64, powerpc, sparc
<infinity> Kamion: test-building on i386, if that goes fine, will do the other 5.
* Kamion wonders if there's a workaround for http://bugzilla.gnome.org/show_bug.cgi?id=56070 that's less hideously ugly than the one that uses motion-notify-event
<Ubugtu> Gnome bug 56070 in gtk "Can't click button after setting it sensitive." [Normal,Reopened]  
<bddebian> Gah, I think I'm over my head on these.. :-(
<iegary> Diziet: I was wondering if bug #41093 was worth getting in (looks like a simple patch), and was told to ping you. It's not in the 1.5 branch upstream, but is in 1.8.
<Ubugtu> Malone bug 41093 in firefox "Firefox leaks memory if the clipboard contains 500001 bytes or more" [Normal,Unconfirmed]  http://launchpad.net/bugs/41093
<janimo> tseng: ping
<ogra> janimo, there is a seed bug i got reported yesterday, ldm needs to be added to the seeds in ubuntu
<janimo> ogra: ubuntu or xubuntu?
<ogra> (since ltsp-client doesnt have a hard dependency on it anymore)
<janimo> can this make the install fail?
<ogra> janimo, i suspect all distros apart from edubuntu, where ldm is explicitly seeded
<janimo> ogra: ldm is in the ship seed for xubuntu alreday
<janimo> explicitely
<janimo> but the tester said it was bad CD as well
<janimo> so that may explaiin the issue
<ogra> yep, shit happens :)
<janimo> any idea what you need to get rid off to fit on the CD?
<Gloubiboulga> I'd say a dead cd drive even :)
<janimo> Gloubiboulga: you seem to not be affected too much :)
<ogra> i'm pondering between a11y or some asian fonts
<ogra> :(
<janimo> you cannot drop evolution right?
* janimo ducks
<Gloubiboulga> the base system has been installed, I'm happy with that and a working internet connection ;)
<ogra> else i'd have to tear down some edu apps, which is the last i would do
<ogra> i want the desktop as similar as possible, else we'd have to have extra documentation
<ogra> so no, evo is a must
<janimo> yeah, but exposing children to that application :(
<janimo> besides some Kansas schools may not install edubuntu because of it :)
<Keybuk> they could always use the KDE version, Kreationism
<ogra> janimo, even if it looks like, edubuntu is not only for children ;)
<ogra> Keybuk, lol
<janimo> ogra, well grown-up should not be exposed to evo either
<pitti> Mithrandir: shall we test new live images/
<infinity> Kamion: Okay, they're all built and landed in queue/byhand on jackass.
<pitti> ?
* infinity decides that 2am is a fine time to attempt a nap.
<jsgotangco_> lol
<ogra> janimo, whats the alternative ? surely not sylpheed or mutt :)
<giftnudel> pine
<giftnudel> maybe thunderbird?
<Kamion> infinity: thanks - I'll work out what to do with them in a bit
<ogra> (i'd take balsa, its very userfriendly and small)
<ogra> giftnudel, tb eats half of the CD, nope, thanks ;)
<giftnudel> hehe
<ogra> i need to free 8M
<giftnudel> balsa is nice, I tested that a year ago and liked it
<ogra> (i wouldnt mind to drop some stuff if it wouldnt be the i386 CD)
<giftnudel> and you don't have anything to drop?
<ogra> nope
<ogra> edubuntu is on the very edge
<ogra> everything i can drop now is essential ubuntu stuff or some edu app
<ogra> neither thrills me
<giftnudel> firefox?
<giftnudel> and use epiphany instead
<ogra> yelp depends on ff
<ogra> ephy as well
<ogra> no wayy
<ogra> -y
<giftnudel> I see, but I guess you were thinking about it longer then me, so my suggestions were probably already considered
<jsgotangco_> we can go follow the xubuntu route and have abiword instead :)
<bddebian> ugh
<jsgotangco_> hehe
<giftnudel> maybe two editions, one for asian languages and one for the rest, then you can remove a lot of the langpacks ....
<ogra> and get fired because i caused so much extra costs at shipit ? 
<janimo> ogra: evolution 33M, thunderbird 26M
<giftnudel> 7 MB
<janimo> there's your 8M :)
<ogra> tb is long gone :)
<Kamion> giftnudel: double money in shipit, double disk space on cdimage/releases (which is at a premium), double testing time
<Kamion> none of these are trivial resources to spend
<giftnudel> yeah, I see
<giftnudel> ogra: but if you use balsa and drop evo, you should be fine, right?
<ogra> apart from balsa being in universe, yes
<giftnudel> there is always a catch ... 
<jsgotangco_> ogra: bah, punish the students and make them use mutt
<janimo> is there really a need for pop3/imap outside corporate world and developers?
<janimo> all mail should just be webmail
<ogra> heh
<giftnudel> yeah, internet is cheap anyway
<ssam> is it ok to discuss google summer of code applications here
<highvoltage> mako!
<Keybuk> mdz: go a moment?
<mdz> Keybuk: yes
<Keybuk> do you have any beverage in your hand/mount?
<Keybuk> uh, mouth
<Keybuk> or anything breakable nearby?
<bddebian> Uh oh
<mako> highvoltage: hey there
<Keybuk> I'd like to change the way udev enumerates /sys
<Keybuk> right now we walk /sys/devices and touch everything with a uevent
<Keybuk> it turns out that's wrong
<Keybuk> we should be iterating through /sys/bus/*/devices instead
<Keybuk> this fixes the T42 Docking Station problem, and a number of raid controller problems -- all with hda becoming hde under certain circumstances
<Keybuk> I've been gathering comparisons of the two methods on people's machines this afternoon via the mailing list, and so far the /sys/bus method finds the same set of devices
<Kamion> mdz: btw, the reliable way to reproduce that ubiquity/partman problem with missing filesystem types on the summary screen is to rm -rf /var/lib/partman, start ubiquity, and then make sure at least one partition you're trying to mount has been newly created in gparted
<Keybuk> I think I killed mdz :)
<mdz> Keybuk: better than not having a beverage, I was looking at other windows
<mdz> Keybuk: does /sys/bus/*/devices end us up at the same actual inodes in /sys? or different stuff?
<Keybuk> the way /sys works is that /sys/devices is the actual tree of kernel objects
<Keybuk> with an infinitely deep topology
<Keybuk> /sys/bus are symlinks into this tree of the actual devices, but listed in logical order
<Keybuk> so they are the same actual inodes, yes
<Keybuk> the difference is that rather than finding an IDE controller at, e.g.
<Keybuk> /devices/pci0000:00/0000:00:01.0/0000:01:05.0
<mdz> Keybuk: where did the revelation come from that we should be doing it this way?  does upstream concur?
<Keybuk> which would be logically "first"
<Keybuk> we find it at
<Keybuk> /bus/pci/0000:01:05.0 instead
<Keybuk> yup
<mdz> it presumably fixes the docking station problem by giving us a different ordering
<Keybuk> upstream's done it this way since we got our modifications added in
<mdz> what about the raid controller problems?
<Keybuk> and we discussed it then, I didn't believe at the time our method was "wrong" just different
<Kamion> argh, I see, my implementation of update_partition in ubiquity was TOTALLY WRONG
<Keybuk> exactly, we get a logical ordering by PCI Bus id rather than actual physical topology
<Keybuk> which seems to be what we're after
<mdz> Kamion: it did seem somehow related to creating the partitions in gparted
<mdz> Kamion: does that mean you found the bug?
<Keybuk> two or three people (linked on the same bug) have reported problems where an IDE RAID controller can cause the ordinary IDE to get renumbered if it's connected and powered up
<Kamion> mdz: I believe so; I think I just implemented parted_server.py on far too little sleep and misread the shell code in partman
<Kamion> will have to test a bit though
<Keybuk> it's the same underlying problem, the controller is on a different bus -- and the bridge for that bus has a lower pci id than the ordinary ide controller
<mdz> Keybuk: it seems like we have just as much chance of breaking working setups by changing the order
<Keybuk> mdz: there is a slight possibility of that, if they're relying on a toplogy-first order
<Keybuk> ie. they have two conflicting drivers and they'll now get loaded in the opposite order again
<Kamion> apart from the more complicated mistake, apparently I managed to translate:
<Kamion>     [ "$part" ]  || return 0
<Kamion> into:
<Kamion>         if info != '':
<Kamion>             return
<mdz> Keybuk: is there any way we can implement this change for new installs but leave existing installs alone?
<Keybuk> mdz: how do you tell on boot how new or old the install is?
<giftnudel> maybe add a config file somewhere?
<mdz> Keybuk: when installing udev, leave yourself a note
<mdz> when generating the initramfs, read the note
<Keybuk> mdz: given we'd be dropping the "current" way in edgy anyway (it is just plain wrong) I'd prefer to either just do it now, or wait until edgy
<mdz> Keybuk: we're too close to the release to break the world
<Keybuk> well, yes
<Keybuk> that's why I'm talking about it, rather than just uploading it :p
<Lure> Kamion, Riddell: bug 42967 with today's Live CD ubiquity
<Ubugtu> Malone bug 42967 in ubiquity "crash on when starting partitioner" [Normal,Unconfirmed]  http://launchpad.net/bugs/42967
<Keybuk> I'm happy to just tell people that dapper doesn't work in these configurations
<Keybuk> and that the fix is known, and edgy would be fine
<mdz> it seems fairly straightforward to fix in a backward-compatible way, though
<Riddell> Mithrandir: kubuntu install CDs all good, still going to take another ~3 hours for live CDs
<Riddell> Lure: thanks
<mdz> but I, too, am happy to say that the fix is too intrusive
<mdz> Keybuk: of course, in edgy, we're going to probe-for-root by default anyway, right? ;-)
<Keybuk> one would hope so
<Keybuk> I rather hope we'll have libpata in edgy too
<Kamion> Lure: funky, thanks. I'd best have a look at that
<Kamion> Mithrandir,Riddell: I think Lure's bug may be RC - it probably affects any installations on systems with existing NTFS filesystems
<slomo_> infinity: hrm right... sorry :( i'll write it on my todo list of things to fix after flight7
<infinity> slomo_: Thanks for fixing my debhelper bug, though (or dholbach's bug, depending on how you look at it, since I assumed he'd use /g in his regex)..
<pips1> doko, ping!
<carlos> Riddell: hi, around?
<pips1> ajmitch, ping
<dieman> Keybuk: do you care which kernels are used when using that check-udev script?
<dieman> Keybuk: ie: only Dapper?
<Keybuk> dapper
<dieman> ok
<dieman> hrm
<dieman> otherwise I could run it on the couple hundred hoary machines here :)
<dieman> well, i'll email what my laptop said
<infinity> Actually, comparing it to hoary would be pretty useful, as long as you tag the hoary output as such.
<dieman> hmm
<dieman> ok
<Keybuk> true
<infinity> Keybuk: Assuming you can determine from said output how hoary would be enumerating those devices..
<infinity> Then you can see how badly this change would break (or unbreak) upgrades.
<infinity> Oh, wait?  hoary?... Not sure how useful that would be compared to breezy.
<infinity> My brain mapped s/hoary/breezy/ instrinctively.
<infinity> But it's up to Scott.
* infinity defers and backs away from the keyboard.
<Keybuk> the main thing missing from breezy is just confirmation which ones didn't matter anyway
<infinity> Keybuk: Do you know if this change would improve (or degrade) the breezy->dapper upgrade scenario?
<infinity> Keybuk: Cause if it breaks dapper->dapper a bit, but fixed breezy->dapper, the latter is the more important upgrade path.
<infinity> (Of course, as mdz suggested, a way to make dapper->dapper happy would be swell too)
<Keybuk> infinity: it's actually compatible with breezy
<Keybuk> which did logical enumeration, rather than topological
<Keybuk> so it should avoid breezy->dapper upgrade breakage
<infinity> Keybuk: Err, which is compatible with breezy?... The current way, or the proposed new way?
<Keybuk> "new" way
<infinity> Keybuk: Would have been helpful to mention that in your debate with mdz, then.  dist-upgrades leading to a user's root disappearing are pretty much teh suck.
<Keybuk> current way breaks things compared to breezy
<Keybuk> I didn't think of it :p
<Keybuk> too used to dapper
<infinity> mdz: ^^^ (last 5 or 10 lines)
<Riddell> carlos: hi
<carlos> Riddell: I need to leave, but is a fast question....
<carlos> Riddell: why kdepim and koffice provide the same kdgantt .pot file?
<carlos> Riddell: I had to disable the one from kdepim and leave the one from koffice
<Riddell> carlos: I'm not too sure, I'll look into it
<carlos> ok, thank you
* carlos -> out
<dieman> heh
<dieman> the script didn't output anything on any of my hoary machines anyhow, im guessing it checks stuff hoary didn't do anyhow?
<Diziet> iegary: re 41093: How bad is this problem, really ?  The patches are indeed nice and small.
<mdz> Keybuk: what have we broken for breezy users?
<iegary> Diziet: it seems to be responsible for memory bloat when large amounts of data is copied to the clipboard. Not a must-have though. There are much worse problems than this with C+P in mozilla, but this is just low-hanging fruit.
<Kamion> Mithrandir: damnit. 42967 is RC, I think, and I'm being called away for dinner and haven't tested it yet. There's a patch in my bzr repository if you want it urgently ...
<Keybuk> mdz: nothing
<mdz> <Keybuk> current way breaks things compared to breezy
<Keybuk> mdz: for breezy users, the current cod emay be broken
<Keybuk> yes
<mdz> that doesn't *sound* like nothing...
<Kamion> Mithrandir: (but if you're uploading from bzr be careful to debian/rules update first)
<Keybuk> breezy did:  for DEVICE in /sys/bus/pci/devices/*
<Kamion> Mithrandir: failing that, I'll nip back in a couple of hours, do the testing, and upload
<Keybuk> which is what I'm proposing we make dapper do
<Kamion> mdz: translation, he means his new way doesn't break anything but the current code breaks, AIUI
<mjg59> Keybuk: If a module for a network device is loaded, will udev automatically bring up the interface if it's flagged auto?
<Keybuk> mjg59: ye
<mdz> Keybuk: thing is, we won't know if we've screwed them until it's too late to fix
<Keybuk> well, we know the dapper stuff didn't break too much
<Keybuk> so far this IDE renumbering issue seems to be the primary breakage
<mjg59> Keybuk: Is there any way to inhibit that?
<Keybuk> mjg59: don't flag it auto
<mjg59> Keybuk: Since it means the "only ifup interfaces that were up previously" bit of resume, well, doesn't
<Keybuk> mjg59: explain
<mjg59> Keybuk: On suspend, we check which interfaces are up. We remember that, and then down them all.
<mjg59> Keybuk: On resume, we only up the interfaces that were up
<Diziet> iegary: Right.  Well, thanks for pointing it out and I'll think about it.  I expect I'll include it.
<mjg59> Keybuk: Except we also unload the network modules, and then reload them. So all the interfaces end up up.
<Keybuk> mjg59: right ...
<Diziet> (What I really meant was how many people does this affect?)
<mjg59> And you made the change to acpi-support for the "Only bring up some interfaces" IIRC (though it may have been mdz)
<Keybuk> it was me
<Diziet> (I don't have a good feel for how common huge clipboards are.)
<mjg59> Keybuk: So, this situation is obviously sub-optimal
<Keybuk> mjg59: obviously, but no, there's no way to inhibit that
<mjg59> Keybuk: Horrible ideas include the use of a lock file
<mdz> mjg59: it has been just as sub-optimal since ~warty, though, no?
<Keybuk> mjg59: edgy
<mjg59> mdz: It's now differently suboptimal because the code looks like it does one thing, but a completely unexpected side-effect does something else
<iegary> Diziet: they're pretty common - large multi-megabyte text file loads in the browser instead of saving to a file. rather than whipping out wget, the average person might copy/paste into an editor.
<mdz> mjg59: much like the laptop-mode comment, which said "this is disabled by default" and then enabled it by default
<mjg59> mdz: Yeah
<mjg59> mdz: If loading the modules brings up the devices, we should just remove that bit of acpi-support
<Keybuk> the problem is you're talking about adding locking and crap around a piece of code that really should just work
<Keybuk> I mean really *needs* to just work
<mjg59> Keybuk: But there's no way of making it just work in the current form
<mjg59> Until we fix the entire kernel
<Keybuk> fair enough, let's leave it as it is then
<mjg59> Well, stub out the current code
<mjg59> Because it just runs extra ifups
<Keybuk> it's rarely harmful to up interfaces, no?
<mjg59> Right, but there's no point in having redundant code
<mjg59> Especially when it makes it look like stuff behaves one way, when it doesn't
<Keybuk> sure
<janimo> ogra: 'building ltsp chroot' at the end of xubuntu install. Can that be made optional?
<janimo> given the ltsp builder is in the installer seed
<Diziet> iegary: Mmmm.
<ogra> not ifr its in the seed i think
<janimo> ogra, for edubuntu it does not install for all install menu options?
<mjg59> Keybuk: But the interface bringing up is backgrounded, right?
<Keybuk> right?
<ogra> janimo, right we have a separate seed for workstation installs that doesnt install it
<nomed> janimo, i think "xfdesktop" hates you :)
<mjg59> If I do "modprobe ipw2100" followed by "modprobe e1000", nothing is going to block?
<Keybuk> right
<janimo> nomed, why it crashes again?
<Keybuk> you only get blocking when you use udevplug
<mjg59> What if I do "modprobe ipw2100", it creates eth0, it launches dhclient and I then do "ifup eth0"?
<janimo> ogra, so that separate seed does not have that in the installer?
<janimo> separate installer seed you mean?
<ogra> yep
<janimo> oh crap
<mjg59> That is, I do ifup eth0 before the first dhclient has returned
<Keybuk> mjg59: then ifup eth0 will return immediately because the interface is already up
<nomed> janimo, have u seen the comment to the bug ?
<mjg59> Ok
<Keybuk> or, if the ifup eth0 happened somewhere between eth0 being created and ifup being run to launch dhclient ...
<janimo> ogra, I thought it would trigger only if something in the desktop seed or som e other references it
<Keybuk> the ifup eth0 would block until finished
<Keybuk> except it's backgrounded in that script too
<janimo> otherwise all xubuntu installs put a ltsp
<ogra> janimo, nope ...
<janimo> which is not what I want
<janimo> nomed, not yet
<mjg59> Keybuk: Yeah. It /ought/ to be ok
<janimo> installe r is stuck in building ltsp chroot for a while now
<ogra> yep
<ogra> its a bit unresponsive
<ogra> i have a patch for eft pending to make it throw out more info
<janimo> nomed, I did not get mail
<Keybuk> mjg59: this gets tested every time dapper boots
<janimo> will check url direcly
<nomed> realy absurd in general .. but what i do not understand is that he thinks we should have a mount point dir already for removable devices :/
<ogra> janimo, console 3 should have the output
<janimo> ogra, ok
<mjg59> Keybuk: I'm getting occasional hangs on resume for reasons I haven't determined yet
<janimo> but this is not what I want for default xubuntu, so should I take it out from the installer seed?
<ogra> i would do so
<ogra> it will be in the expert menu anyway
<ogra> so users doing an expert install can select it
<mjg59> Keybuk: So I just wanted to make sure it wasn't a bizarre and nasty network race thing
<Keybuk> I'm not aware of any of those
<Keybuk> and I tested the locking pretty thoroughly
<mjg59> Ok, cool
<mjg59> I just need to figure out how to dump stuff usefully
<Keybuk> what kind of stuff do you need to dump
<Keybuk> why does the first 10 minutes of a Simpsons episode never have anything to do with the rest?
<jdub> because that's where the jokes go
<ogra> to keep you intreasted
<zul> simpsons are getting tired though
<zul> family guy is way more funnier
<zul> anywyas
<_ion> True.
<tseng> jdub: hi
<janimo> nomed: actually it's a polite answer why you say xfdesktop hates me? :)
<janimo> ogra: so I remove ltsp builder frominstaller seed it causes failed installation step
<janimo> tseng: upstrream xfce just fixed autostart editor to not show desktop which have onlyshowin gnome set
<tseng> janimo: cool
<janimo> however it would be nice if beagle set xfce as well
<janimo> since it can run there too
<tseng> I guess
<janimo> I need to ask mvo to do the same for update notifier
<tseng> can i say
<janimo> they're generic gtk apps which use gnome libs too
<tseng> onlyshowin=gnome,xfce?
<janimo> tseng, yes
<tseng> ok
<tseng> thats fine
<janimo> I'd say it could even go in kde
<tseng> no
<janimo> is that a daemon?
<tseng> kde uses a different file path
<tseng> for autostart files
<tseng> yay for standards
<janimo> I'd thought only show in is to be used when teh app could cause confusion or misbehaviour in a specific environment
<Keybuk> the nice thing about them is that there are so many to choose from
<janimo> not when it's written using the other ui toolkit
<tseng> eh
<tseng> its done so that gnome uses it in one path
<tseng> and kde uses it in another
<tseng> you can debate the onlyshowin= all day for all I care
<tseng> when they use the path I'll happily list anything in there you want
<janimo> so far xfce will do thanks :)
<tseng> np
<janimo> Kinnison: hello, could g-p-m's autostart file have xfce added besides gnome in the autostart .desktop file's onlyshowin entry? I file a LP bug to remind you if you wish
<Diziet> doko: You said in your meeting paste that you wanted my feedback on something font-related ?  Can you send me a mail about that ?  I have to go now but I want to answer you ASAP.
<nomed> janimo, yes better then usually .. anyway always same mood
<doko> Diziet: that was two weeks ago, last meeting I did want feedback from Riddell ;-)
<Diziet> Oh!
<Diziet> Good.
<Diziet> I thought it looked familiar.
<janimo> nomed: we had a private mail exchange and the communication seesm to have improved since :)
<Diziet> But I thought `surely my IRC scrollback doesn't go back that far'.  Evidently it does.
<nomed> that's cool :)
<Diziet> You see, it just occurred to me that I didn't search in each client for the nick I use with the other one ...
<Diziet> Anyway, I'm off now.  Thanks :-).
<janimo> Gloubiboulga: hi I got the LTSP error too
<janimo> looks like we need to have new CDs :(
<Mithrandir> Kamion: I was out biking so if you'd like to upload, that'd be nice.
<Mithrandir> Kamion: I presume this affects all distros?
<Gloubiboulga> janimo, ok, it's not an issue with my drive then...
<Kamion> Mithrandir: just uploaded; yeah, it affects both the GTK and KDE frontends :(
<Kamion> was introduced by the fix to make ubiquity handle partman exceptions
<Mithrandir> Kamion: we'll just roll new images once it's in, then.
<Treenaks> gar @ dying spamd
<ogra> Amaranth, btw, since you want to work on an edubuntu SoC project, being in #edubuntu might be good :)
<kagou> is there rules to use for permissions on directory/files under /var/log ?
<Amaranth> ogra: good idea :)
<ogra> :)
<shutdownrunner> Hi. I'm trying to install ubuntu under compaq deskpro 350. all the time I'm getting errors. Under dapper I don't know what the problem is "Attempted to kill init ...", but under breezy I get "Acpi : Unable to load system description database" and something about [_SB_]  not to be found. Have you got any ideas what this is? If you could suggest where I could look for a solution, I'd also be grateful.
<janimo> Mithrandir: a new xubuntu install CD will be needed unfortunately. The current one tries to install LTSP and fails. So I took out that package from the installer seed for now
<Mithrandir> janimo: ok, tell me when you have new meta packages in the archive.
<Kamion> you don't need a -meta upload for an installer seed change, just a CD rebuild
<Kamion> assuming rookery has the new seeds
<Mithrandir> oh, ok
<janimo> Mithrandir:  The seeds are mirrored already in Kamion's bzr branch soI guess it's good to go
<Mithrandir> janimo: build running
<janimo> Kamion, so if I want a ltspserver install should I not put it in the installer seed as it affects workstation install as well?
<janimo> Mithrandir: thanks
<janimo> the 4 packages that made up the ltsp menu entry which I added to the LP bug may need to be ammended with the ltsp-client-builder then
<janimo> Mithrandir: ok rsynced the new image, started testing
<ben-2006> hey, I am planning on entering the google summer of code for an ubuntu project - anyone got any tips?
<pygi> ben-2006: I might be of help considering I am a mentor there :)
<pygi> ben-2006: what project are you interested in?
<ben-2006> i've completed an application for the sync tool (haven't submitted it yet)
<pygi> ben-2006: point me to the link on Ubuntu SoC wiki pls?
<ben-2006> want to complete another application (just to give me more chance, really excited about the opporunity)
<ben-2006> 2secs
<ben-2006> https://wiki.ubuntu.com/MultipleComputersSynchronization
<pygi> ben-2006: also, please move to #summer-discuss at slashnet, cause this is not appropriate place
<pitti> hey seb128, wb
<seb128> re pitti
<pitti> seb128: thanks for the POT files, great!
<seb128> are we still upload frozen? :)
<pitti> (- fixes)
<seb128> pitti: np
<pygi> Kamion: around? :)
<Riddell> Mithrandir: still expecting flight 7 tonight?
<Mithrandir> Riddell: no, tomorrow.
<Mithrandir> Riddell: we need to redo the live images.
<Riddell> yeah, just wondering if that was happening today
<Riddell> but tomorrow is good
<pygi> Kamion: still not here? :-/
<Kamion> pygi: it's my evening, dude
<Kamion> pygi: I'm going to bed now, but if you say what you want then I'll reply when I'm next around
<pygi> Kamion: yes, sorry :-/ Enjoy :)
<pygi> will do, thanks
<andreasn> JaneW: ping
<pygi> andreasn: I don't think she's here now :)
<andreasn> ok
<andreasn> thanks
<andreasn> when can I usually reach her?
<janimo> Mithrandir: ok xubuntu install CD looks good on i386 can become flight 7
<carlos> pitti: I know is a bit late... but if you are still around and can execute the script to compare the language packs tarballs... that would be really good
<pitti> carlos: yes, I can
#ubuntu-devel 2006-05-10
<pitti> carlos: started
<carlos> pitti: thanks
* pitti bangs his head on the table over dhclient
<pitti> Mithrandir: still here?
<AlinuxOS> pitti, ;) thank you for mozilla-firefox-locale-ka replying.
<pitti> AlinuxOS: I'll care for it after the flight-7 freeze
<AlinuxOS> pitti, :) i was waiting for  mozilla-firefox-locale-all mantainer for 3 months...(nothing done)... so I can patiantly wait for filight-7 freeze :)
<AlinuxOS> no problems
<AlinuxOS> finally I have 65% of translated GNOME :) and it looks really cool! :)
<pitti> yay
<AlinuxOS> 30 new Ubuntu georgian users in this 2 montsh! it's great!
<AlinuxOS> thank you, and all ubuntu-devel, rosetta and GENERAL UBUNTU Team :)
<AlinuxOS> me including :)
<AlinuxOS> looolz
<AlinuxOS> pitti, ;) good night
<pitti> night!
<poningru__> hi I wanted to talk to someone about w32codecs
<poningru__> err nm
<jdong> poningru__: what about them?
<lifeless> ell
<lifeless> pre4 is not frozen
<lifeless> meh, ECHAN
<mgalvin> infinity: ping
<quidam-> i need help with unionfs, plz :(
<fabbione> morning
<quidam-> fabbione, hello :)
<zul> hey fabbione 
<quidam-> fabbione, can you help me with unionfs? please...
<fabbione> quidam-: no, i don't know unionfs and you should ask in #ubuntu
<fabbione> zul: still awake?
<zul> fabbione: yeah kind of
<zul> its too hot
<quidam-> fabbione, i ask in #ubuntu but anybody help me :'(
<fabbione> quidam-: this is not a support channel.. and again..i don't know unionfs so i can't help
<quidam-> fabbione, well thanks.... :-)
<zul> sheesh
<zul> crap its 1:30
<fabbione> zul: time to go to sleep?
<zul> yeah i think so
<zul> talk to you later
<fabbione> cya
<fabbione> jdub: ping?
<kagou> morning
<zakame> hi kagou 
<Coyctecm> morning
<dholbach> good morning
<pygi> mornin' dholbach
<dholbach> hey pygi
<zakame> good morning dh	
<dholbach> hey zakame
<mvo> Mithrandir: is a abiword upload ok (freeze-wise?). it adds pot file creation during the build
<mvo> Mithrandir: same for subversion (upload to generate pot during build)?
<Mithrandir> mvo: preferably not.
<pef> hello
<pef> can someone able to read uploads logs tell me why my uploads are discarded ? I'm using loic@ubuntu.com as address in changelog, and I'm trying to upload to universe
<pef> thanks
<pitti> Good morning
<pef> good morning pitti
<ajmitch> morning pitti 
<pitti> hey pef, hi ajmitch 
<fabbione> Mithrandir: http://people.ubuntu.com/~fabbione/debdiff
<Mithrandir> fabbione: this probably won't make flight-7, but feel free to upload it. 
<fabbione> Mithrandir: ok thanks
<fabbione> done
<kagou> net/j #ubuntu
<fabbione> LADIIIEEESSS AND GENTLEMEN... xorg source package bugs can fit in one LP page now
* pitti hugs fabbione 
* Mithrandir got a package from IBM yesterday.  Big package.
<ivoks> yay!
<fabbione> Mithrandir: what did you order?
<Mithrandir> fabbione: nothing, but they've decided to lend me a power5
<ajmitch> very ncie
<fabbione> Mithrandir: ah
<fabbione> hey sabdfl 
<sabdfl> fabbione: !
<sabdfl> how's life?
<ajmitch> hello sabdfl 
<pygi> hi sabdfl
<fabbione> sabdfl: pretty good.. how are you?
<sabdfl> dholbach: what's the bug number with the width between network activity monitor and wifi signal strength indicator?
<sabdfl> fabbione: rocking
<Mithrandir> so just a single-cpu 1.65GHz power5.  I guess I'll be able to test ppc installs today. :-)
<fabbione> Mithrandir: if it's the last g5 i am not sure we even support it
<fabbione> last -> latest
<Mithrandir> fabbione: well, then I get to see if we can make it supported. :-)
<fabbione> according to benh we need .17-* to support the latest g5 cpu's
<fabbione> Mithrandir: unlikely...
<fabbione> the patches are very intrusive
<fabbione> i already discussed it with upstream a couple of weeks ago :)
<Kamion> pef: what was the package name?
<dholbach> sabdfl: bug 34521
<Ubugtu> Malone bug 34521 in ubuntu-artwork "network monitor's icon have too much unused space" [Wishlist,Confirmed]  http://launchpad.net/bugs/34521
<fabbione> he said that if he feels really bored, he will do a backport for us, but the first attempt done for yellow dog resulted in stability issues
<pef> Kamion: frozen-bubble
<Kamion> you know it's bad when you wake up in the morning, look at your inbox, and think you're reading ubuntu-bugs
<Mithrandir> fabbione: g5 != power5, though
<Kamion> yeah, g5 => power4
<Kamion> ish
<sabdfl> dholbach: thanks. am updating iconprio page
<dholbach> sabdfl: cool
<Kamion> pef:  -> http://librarian.launchpad.net/2450307/5gQEEomc8QElytnt0k3f2rQW9m0.txt (GPG verification of frozen-bubble_1.0.0-6ubuntu1_source.changes failed: Key expired)
<sabdfl> dholbach: have upgraded to latest bzr format fwiw
<fabbione> Mithrandir: you lost me now.. what CPU is in there?
<Mithrandir> fabbione: a 1-way 1.65GHz Power5.
<Mithrandir> fabbione: IBM part no 9123-1939
<dholbach> sabdfl: I'll watch out for it.
<fabbione> Mithrandir: ok..
<fabbione> let me know how it goes then...
<Mithrandir> ubuntu live cds up, please test.
<pitti> Mithrandir: yay, will do the ppc one
<pitti> Mithrandir: did the install change from yesterday's?
<Mithrandir> pitti: no
<pitti> alright
<pef> Kamion: ok, thank you very much :)
<maswan> Kamion: well, strictly speaking, the g5 (ppc970) is a stripped-down power4 core with added altivec, and the power5 is a beefed-up power4. they are about as different, really. the power6 brings a big core update though.
<maswan> sorry, job requires me to keep track of these things. :)
<Mithrandir> maswan: we'll be doing flight-7 today, should I just prod you to get it mirrored when it's out?
<maswan> Mithrandir: sure
<Mithrandir> Riddell: kubuntu live images up, please get them tested.
<Riddell> Mithrandir: ok
* pitti cleans the last unassigned item from https://wiki.ubuntu.com/MissingPotFiles
<pitti> janimo: hi! ISTR that you fixed verve's POT, right? can you please update the wiki page?
<janimo> pitti: ok, did not know there was a wikipage for it, just your logs
<janimo> but will do now
<pitti> janimo: oh, I created it yesterday, and I thought I told you; sorry if not
<fabbione> seb128_: ping?
<seb128_> fabbione: pong
<fabbione> seb128_: got 2 minutes?
<seb128_> sure
<janimo> pitti, np. Cleared that entry as I think it's ok now.
<fabbione> seb128_: bug #28052
<Ubugtu> Malone bug 28052 in xorg "Can't adjust mouse sensitivity" [Normal,Confirmed]  http://launchpad.net/bugs/28052
<G0SUB> pitti: ping
<seb128_> fabbione: what about it?
<fabbione> seb128_: i am writing a small proof of concept to check if it is X or gnome, but i can't get that GDK_DISPLAY() thing at all...
<G0SUB> pitti: I have attached bn_BD locale XPI for firefox to a bug report and have assigned it to you. Please take care of it. thanks :)
<fabbione> seb128: whatever i try to include gdk/ or gtk stuff, it is always undefined
<pitti> G0SUB: thanks, I will
<janimo> mvo: regarding the pot file for abiword you may coordinate with slomo as I think he has 2.4.4 packages in preparation anyway
<fabbione> seb128: mind to give me an hint on what i should look for?
<mvo> janimo: I can send slomo_ my debdiff 
<pitti> mvo: can you set your stuff to 'pending' as well, if you have a fix for it?
<janimo> mvo, would it be ok to mention Xfce too in the OnlyShowIn section of the autostart file of update-notifier?
<seb128> fabbione: have you tried to "#include <gdk/gdkx.h>" ?
<janimo> it can be used in xfce after all and people do use it
<janimo> if so shall I file a report in LP?
<fabbione> seb128: yes, i did.. let me redo it and i will show you
<pitti> janimo: yep, tarball has a pot now
<sivang> morning all
<seb128> fabbione: do you build with $(pkg-config --cflags --libs gdk-2.0)?
<fabbione> seb128: yes .. see /msg
<seb128> lemme try
<Mithrandir> janimo: xubuntu images up, please test.
<fabbione> seb128: linking is later.. but there should be no error already at compile
<Mithrandir> janimo: live images, that is.
<janimo> Mithrandir: just downloading now
<janimo> Mithrandir: install is good to go in case you missed last night's ping
<seb128> fabbione: I said "#include <gdk/gdkx.h>"
<seb128> fabbione: the "x" after "gdk" is important
<seb128> fabbione: works fine with it here
<fabbione> seb128: that would do :)
<fabbione> thanks
<seb128> cool
<seb128> np
<fabbione> fabbione@gordian:/usr/src/ubuntu/x/gnome-sucks$ make
<fabbione> cc -Wall -ggdb -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -c main.c
<fabbione> cc -lX11 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lX11   -o main main.o
<fabbione> this works :)
<seb128> :))
<seb128> gnome-doest-suck
<seb128> doesnt
<fabbione> ahha
<fabbione> i got you there :)
<mvo> janimo: yeah, send me a patch. sorry, but I'm very very busy with linuxtag stuff
<janimo> mvo, sure
<seb128> fabbione: you want to gdk_init(&argc, &argv); so it gets the display correctly
<Kamion> sfllaw: FYI, "debian-installer" is a much better catch-all package for installer problems than "base-installer"; the latter is the component that installs the base system
<fabbione> seb128: ok thanks,,
<seb128> np
<jbailey> pitti: In the patch 3, they've patched aio_abi.h, which I'm not convinced is right looking at upstream headers.
<jbailey> Unfortunately my big endian system is in another continent right now, so I don't want to play with the firewal on it for testing. =)
<pitti> jbailey: ok, then let's wait with that until you are back
<jbailey> pitti: My inclination is to just do ip.h and tcp.h if they work.
<Kamion> siretart: openal binaries accepted FYI
<fabbione> seb128: that bug is GTK bug! AHAHA I HAVE THE PROOF NOW! AAHHAHA
<seb128> fabbione: hum, but the same code used to work .. what is wrong with it?
<fabbione> seb128: 
<fabbione> seb128: the values you pass to the thresholds
<fabbione> let me sum up the proof of concept
<fabbione> and how to test it
<fabbione> seb128: to package should i reassing it?
<seb128> feel free to do the summary on the bug and reassign
<seb128> control-center
<fabbione> ok
<fabbione> gnome-control-center or just control-center?
<seb128> control-center
<fabbione> ok
<seb128> that's the name of the source package for gnome-control-center
<seb128> fabbione: your testcase shows that the value is changed correctly
<fabbione> seb128: let me finish to write please
<seb128> alright ;)
<pitti> Mithrandir: ppc/live system and ubiquity install success
<fabbione> seb128: ok.. description added
<seb128> fabbione: right
<seb128> fabbione: does the behaviour changed on the xorg side?
<fabbione> seb128: nope...
<fabbione> that stuff didn't change since 2001
<fabbione>  /* $Xorg: GetPCnt.c,v 1.4 2001/02/09 02:03:33 xorgcvs Exp $ */
<fabbione> on the note.. 2001 is because of the relicensing
<seb128> fabbione: what would you consider as a good range for the value?
<fabbione> the code is waaaay older
<fabbione> seb128: i dunno really...
<fabbione> seb128: i never touch that stuff.. it just works for me
<seb128> me neither
<fabbione> seb128: "probably" something between 1 and 1/4 of the entire screen size?
<seb128> GNOME UI change it from 1 to 10
<fabbione> 10 means 10 pixels and it starts accelerating
<seb128> which is nothing
<fabbione> but 10 pixels here at 4800x1200 is like a small fart on the mouse
<fabbione> 1 to 50 ?
<fabbione> you can also check the return value btw...
<fabbione> BadValue = 2
<fabbione> otherwise the call to the function return 1
<seb128> what does the badvalue means?
<fabbione> that's from libx11 headers
<fabbione> it's a return code
<fabbione> nothing more
<fabbione> see how i wrote it in my code
<fabbione> badvalue = call
<seb128> right, I've read the manpage but it doesn't give the meaning of the code
<fabbione> if badvalue = 2 there is an error
<fabbione> yeah i did look in the x code for that
<fabbione> #define Success 0
<seb128> hum
<fabbione> #define BadCall 1
<seb128> there is some xorg issue for me
<fabbione> #define BadVAlue 2
<fabbione> bu
<fabbione> but
<seb128> threshold_return: 1
<fabbione> the code always return 1 in success
<fabbione> yes
<seb128> it should accelerate really quickly
<seb128> and it used to do
<seb128> and it doesn't
<fabbione> it starts to accellerate after 1 pixel
<seb128> right
<fabbione> it doesn't tell you how much it will accelerate
<fabbione> that's the other value
<seb128> it used to jump really fast when doing that
<fabbione> that we know it works
<fabbione> acceleration factor != accell threshold
<seb128> right
<seb128> the factor is what you notice
<fabbione> exactly
<seb128> it's how quickly it speeds up
<fabbione> right
<seb128> where the threashold is when it starts to speed up
<fabbione> exactly
<seb128> and 1 or 10 pixel doesn't make a real difference
<seb128> gotcha
* fabbione ^5s seb128 
* seb128 hugs fabbione
<fabbione> mv gnome-sucks X\ \-\ gnome\ 1\ \- \0
<fabbione> whops
<seb128> lol
<fabbione> :D
<fabbione> seb128: phear that i am taking away rust from X again
<fabbione> X bugz? no thanks -> gtkz ;)
<fabbione> ok next bug
<fabbione> thanks seb128 
<seb128> thank *you* fabbione :)
<Mithrandir> pitti: thanks.
<pitti> Mithrandir: I'll give amd64 a whirl, too, in some minutes
<Mithrandir> hmm, did scott stop the really, really evil "umount /var; mkdir; remount" hack or is it still in?
<Kinnison> janimo: please do file if you haven't
<janimo> Kinnison: ok
<Riddell> Mithrandir: all 6 kubuntu CDs are looking beautiful
<Mithrandir> Riddell: yay, nice.
<Mithrandir> Riddell: do you want to announce yourself (after I've published them) or should it just be part of the regular ubuntu announcement?
<Riddell> Mithrandir: just include them in the same announcement I think
<Riddell> it's only a flight
<Mithrandir> yup, and there are no big changes since beta 2, afaik.
<Kamion> I'd like to write a paragraph or two about the ubiquity bug fixes
<Kamion> do I have time for breakfast first? :)
<Riddell> Mithrandir: if you could say that wlassistant and knetworkmanager are on the CD that would be cool
<Mithrandir> Riddell: sure.
<Mithrandir> Kamion: sure, I have some ubuntu testing still left.
* pitti tests live amd64, brb
<pitti_live> Kinnison: here?
<pitti_live> pitti_live: you are the partman bitch, right?
<thom> pitti_live: things must be bad when you start talking to yourself :-)
<Kamion> pitti_live: that would normally be me
<ogra> Kamion, probably he wants give a hint that he wants to take over ;)
<pitti_live> thom: oops :)
<pitti_live> Kamion: I just wondered whether there is a better way to format a partition than removing it and adding it again
<Kinnison> pitti_live: I'm here, but kamion is the partman person
<pitti_live> erm, s/partman/parted/
* pitti_live should really sleep more
<Kamion> pitti_live: YM gparted
<Kinnison> pitti_live: gparted I've worked on, yes
<Kamion> pitti_live: not at present
<pitti_live> ok
<Kamion> Kinnison: was that one of the things we disabled?
<Kamion> IIRC it didn't actually work ...
<Kinnison> It wasn't reliable
<Kinnison> you reformat in the partition allocator I guess
<pitti_live> I just selected /dev/hda3 as root partition, then I got a complaint that I didn't have a root partition selected
<Kamion> Kinnison: doesn't have a filesystem selector
<pitti_live> ('reformat' was enabled, too)
<Kamion> doesn't even display the filesystem at the moment for that matter, although that's a bug
<Kamion> pitti_live: did the confirmation screen say something like "partition 3 of /dev/hda as"?
<Kamion> rather than "partition 3 of /dev/hda as ext3" or whatever
<pitti_live> Kamion: yes, indeed
<pitti_live> Kamion: although it sometimes omit the file system even when it works (and the partition had a valid fs previously)
<Kamion> pitti_live: bug 37872; partman_commit is kinda borked, I'm working on it
<Ubugtu> Malone bug 37872 in ubiquity ""No root file system" error" [Normal,Confirmed]  http://launchpad.net/bugs/37872
<Kamion> pitti_live: as a workaround, go back from the summary page and then go forward again
<Kamion> the extra partman init that happens when you do that sorts it out
<pitti_live> Kamion: well, it works for me for the case of previous valid file systems, so it's not that bad
<Kamion> (usually ...)
<pitti_live> ah :)
<Kamion> I tried the obvious quick fix last night, but it turns out to be problematic
<Kamion> I'll need some more intrusive changes to make it work properly, so I decided not to attempt to cram it into flight-7
<pitti_live> off to test the new installation, brb
<pitti> Mithrandir: amd64/live + ubiquity success
<pitti> Kamion: I just noticed that /etc/modules does not have 'lp' in an ubiquity install; this might be one source the plethora of 'parallel printer doesn't work' bugs
<Kamion> pitti: bug 40826
<Ubugtu> Malone bug 40826 in ubiquity "need to emulate hw-detect's /etc/modules setup" [Normal,Confirmed]  http://launchpad.net/bugs/40826
<pitti> Kamion: ah, thanks
<Kamion> upgraded to major and ubuntu-6.06
<janimo> Mithrandir: xubuntu livecd seems ok
<Mithrandir> Kamion: hmm, seems like ubiquity isn't entirely happy on my amd64.
<Mithrandir> Kamion: something broke and it complained about "can't make file system", then went back to the partitioner which seems to never finish loading.
<Kamion> quite possibly 37872 again; anything in /v/l/i/syslog?
<Kamion> actually, no, probably not 37872
<Mithrandir> Kamion: it seems to fail to find /dev/sda5
<Mithrandir> (however, /dev/sda6 exists)
<Mithrandir> Kamion: http://err.no/tmp/syslog
<Kamion> oh, not a debug log, poo
<Kamion> can't make much out of that other than "it didn't crash"
<Kamion> what's on the screen?
<Mithrandir> why don't we run ubiquity in debug mode by default?
<Kamion> because it logs the password
<Mithrandir> 'cause it then logs the root pw?
<Kamion> well, the user password, but yes
<Mithrandir> we should just fix that, then.
<Kamion> it's really hard
<Kamion> I tried
<Mithrandir> grep -v instead of cp to the installed system? :-)
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357118
<Ubugtu> Debian bug 357118 in debconf "Subject: debconf: exposes passwords in debug messages" [Normal,Open]  
<Kamion> I don't really want it in the live filesystem log either, because then people will file bugs containing it
<fabbione> Mithrandir: http://people.ubuntu.com/~fabbione/debdiff
<Mithrandir> true.
<fabbione> Mithrandir: i am ok even if it's not in F7
<Kamion> the only other solution I see is carefully arranging to run everything but user-setup with DEBCONF_DEBUG set
<Kamion> although, no, I remember why I didn't do that - the password appears in install.py's debug log too
<Mithrandir> Kamion: at least doing so for the problematic areas, which seem to mostly be the partitioner atm?
<Kamion> yeah, could do
<Mithrandir> that shouldn't be sensitive
<Kamion> indeed, it isn't
<Kamion> what's on the screen when the partitioner "seems to never finish loading"?
<Kamion> a progress bar?
<Mithrandir> yes, got to 10%
<Mithrandir> let's see if I can reproduce it with debug on
<Mithrandir> bingo
<Kamion> I had a similar problem briefly during development but I thought I'd fixed it
<Mithrandir> same url, now with a debug log
<Mithrandir> apparently, something goes BOOM and the kernel doesn't rescan the partition table or something
<Mithrandir> since I don't have /dev/sda[15] 
<Mithrandir> Kamion: unsure if this is a blocker or not; the previous install on that drive was an i386 dapper install with automatic lvm setup
* fabbione hugs Mithrandir 
<Mithrandir> fabbione: ok, go ahead
<fabbione> Mithrandir: thanks!
<Mithrandir> sorry about being slow to respond, got dragged into the debugging fest.
<fabbione> yuop
<fabbione> no problem
<fabbione> hence the bug and not the cluebat :D
<fabbione> s/bug/hug
<Mithrandir> heh
<Mithrandir> :-)
<Mithrandir> Kamion: prod?
<Kamion> Mithrandir: sorry, was elsewhere, one moment
<Kamion> Mithrandir: I don't think it's a blocker because it isn't a regression - the handling for partman errors like that used to be even worse (a confusing crash)
<fabbione> ogra: ping?
<Kamion> Mithrandir: you're right, /dev/sda was busy
<Kamion> debconf (developer): <-- SUBST partman/exception_handler_note DESCRIPTION The kernel was unable to re-read the partition table on /dev/sda (Device or resource busy).  This means Linux won't know anything about
<Kamion> the modifications you made until you reboot.  You should reboot your computer before doing anything with /dev/sda.
<Kamion> we don't handle partman/exception_handler_note at the moment ...
<Kamion> probably should
<ogra> fabbione, pongedipong
<Kamion> Mithrandir: do you happen to know what might have been busy on that disk?
<Kamion> Mithrandir: maybe lvm/raid being active?
<fabbione> ogra: what's the ETA for you to put your hands on that terminal client?
<ogra> fabbione, during next week
<Mithrandir> Kamion: lvm, yes.
<Kamion> we don't disable lvm at the moment so that's a possibility
<Mithrandir> so not a blocker?
<Kamion> nope - can you file a bug though?
<Mithrandir> (I'd argue so, at least.)
<Mithrandir> sure, will do
<ogra> fabbione, i'll drive to linuxtag tomorrow from here (Kassel) and go back to my old house afterwards
<fabbione> ogra: ok thanks 
<Kamion> should be relatively easy to (a) improve the error handling and (b) stop the error occurring in the first place
<Mithrandir> Kamion: against partman, then?
<Kamion> Mithrandir: no, ubiquity
<Mithrandir> 'k
<Hadaka> what do I need to set up an environment that would allow me to build ubuntu live-cds and install-cds at home?
<sfllaw> Kamion: Thanks.
<Mithrandir> janimo: what's the state of xubuntu flight 7?
<fabbione> pitti: is jdub on the way to .de?
<pitti> fabbione: I don't know, I didn't hear anything about his plans
<fabbione> pitti: ok thanks
<ogra> fabbione, he's not scheduled for any talks on linuxtag though
<fabbione> ogra: ok thanks
<ogra> (if that gives you a hint)
<fabbione> i am really in the need of somebody with that toilet seat^W^Wimac g3
* pitti looks at his G4 and feels sorry for fabbione 
<Mithrandir> fabbione: that's an ibook, not an imac though.
* ogra does the same
* highvoltage just has a nano, so listens to it instead
<fabbione> Mithrandir: yeah the ibook
<Mithrandir> we need to make the edgy live cd boot quicker.
<fabbione> we need to make X run from initramfs
* fabbione hides
<janimo> Mithrandir: I pingeed earlier, it's ready
<pitti> we need a framebuffer port to gtk
* pitti hides as well
<Mithrandir> janimo: cool, thanks.
<Mithrandir> janimo: I'll just include xubuntu too in the regular announcement if that's fine with you?
<highvoltage> pitti: seriously, that would be cool
<sabdfl> BenC: bug #43092
<Ubugtu> Malone bug 43092 in linux-meta "CompactFlash PCMCIA disk is not detected" [Normal,Unconfirmed]  http://launchpad.net/bugs/43092
<fabbione> can anybody access this pic? http://vern.chem.tu-berlin.de/~stephan/images/ubuntu-cinemadisplay.jpg
<janimo> Mithrandir: sure
<fabbione> it's supposed to be a corrupted screen
<Kamion> Mithrandir: oh, I still owe you text about ubiquity - writing a mail now
<Mithrandir> Kamion: thanks
<ogra> pitti, ??? 
<ogra> pitti, http://developer.gnome.org/doc/API/2.0/gtk/gtk-framebuffer.html
<pitti> ogra: I know, but we don't *use* it :)
<ogra> :)
<fabbione> pitti: thanks god!
<pitti> (not that we should, though)
<pitti> </bitch mode>
* fabbione is waiting for http://developer.gnome.org/doc/API/3.0/gtk/gtk-kernel.html
<pitti> lol
<fabbione> ;)
<_ion> :-D
<pitti> fabbione: you mean, 'modprobe gtk'?
<fabbione> pitti: yeah .. a gtk userland <-> gtk kernel interface..
<pitti> that's what the world needs
<highvoltage> is gtkfb packaged anywhere?
<fabbione> highvoltage: afaik it's used in g-i in debian.. so i guess it is
<highvoltage> wow
<ogra> isnt anaconda based on it as well ? 
<highvoltage> aha. libgtk+2.0-directfb0
<highvoltage> ogra: anaconda uses Xorg
<ogra> hmm, really ? why do they use such a shoddy resolution then ? 
<ogra> i never saw it diong more than 640x480
<ogra> *doing
<fabbione> ogra: because 640x480 is the only resolution supported universally by everything
<ogra> heh
<highvoltage> my fb works at 1024x768
<ogra> i thought using X would circumvent that
<fabbione> ogra: ?????
<ogra> oh, indeed, you still dont know the moniors capabilities 
<ogra> *monitor
<Kamion> Mithrandir: you have mail
<fabbione> ogra: each time you write about X you make hot.. would you like to maintain it on a permanent base?
<Mithrandir> Kamion: thanks.
<ogra> fabbione, nope, to time consuming, i'd have to give up edubuntu
<Mithrandir> fabbione: have you (or infinity) tested ubuntu-server or are you going to skip f7?
<fabbione> Mithrandir: -server is infinity business.. i am 100% on X till release
<Mithrandir> ok
<Mithrandir> infinity: ^^
<sivang> infinity: I'm preparing a changed source in addition to the comments you had for me the other day (upbackup). so I'll guess I'll also need a source NEW kick as well.
<Kamion> sivang: are you changing the source package name, then?
<sivang> Kamion: correct, I hope that would not cause too much of a problem?
<Kamion> sivang: no, just checking
<sivang> Kamion: k, thanks.
* Mithrandir twiddles thumbs as md5sum does its thing.
<_ion> mithrandir: % md5sum /dev/urandom?
<Mithrandir> _ion: nah, slightly less random; doing the release flight-7 dance.
<pitti> AWTY? :)
<Pygi> Kamion: around?
<Evaso2> hi guys why the vpn modules of network-manger applet are not compiled in debian?
<Kamion> Pygi: hi
<Evaso2> i mean debian/ubuntu
<Pygi> Kamion: perhaps you have talked to evan already about the ubiquity migration thingy?
<_ion> OpenVPN support would rock.
<_ion> I use it in my network.
<Evaso2> The problem i think is that this plugin are not present in the official tarball
<Evaso2> because upstream maintainer will want to package as a separate tarball but there are some issue in the gnome ftp automation
<Evaso2> so also if this plugin are not in the main network-manager tarball could be retrieved for 0.6.2 cvs version and packaged in ubuntu as a separate package
<Kamion> Pygi: yes, we've exchanged a couple of mails
<Kamion> I gave him some advice, although I haven't looked over his current proposal yet
<giftnudel> Evaso2: it's apparently not stable enough
<Pygi> Kamion: uh,oki :) Please do take few mins too look it over
<Pygi> seems nice
<giftnudel> but there is some additional deb source where I got it from
<giftnudel> _ion: want the deb source where you can get the plugins?
<_ion> giftnudel: I would probably find it myself, but sure. :-)
<giftnudel> _ion, Evaso2: well anyway, they seem to be at deb http://kubuntu.no-ip.org/kubuntu dapper main
<giftnudel> deb-src http://kubuntu.no-ip.org/kubuntu dapper main
<_ion> Thanks.
<_ion> Tonio's repository.
<giftnudel> this was where the experimental n-m was downloadable
<giftnudel> yes
<giftnudel> oh, and they seem to work well, used them 10 times at the uni so far without a problem
<Evaso2> giftnudel: but there isn't any official plugin version on release 0.6.2?
<giftnudel> no not that I know
<Kamion> Pygi: IIRC the changes are pretty small from when I last looked, and it was fine then; I've offered to mentor
<Evaso2> giftnudel: but why in the official news file of the 0.6.0 version in the upstream tarball there is: 
<Evaso2> Two new VPN modules are part of the distribution: openvpn and pptp.
<Evaso2> i doesn't understand
<Evaso2> are part of the official distribution or not?
<giftnudel> well, part of n-m's distribution, not of ubuntu
<Pygi> Kamion: well, please then say so in mentors page
<Evaso2> giftnudel: so ubuntu has not packaged it because seems unstable?
<giftnudel> that was the last info I got, yes
<Kamion> Pygi: I'll get round to it at some point. JaneW already knows, I think
<Evaso2> Ok so a valid alternative could be kvpnc
<Pygi> Kamion: ah,oki
* JaneW checks... what do I know?
<Kamion> JaneW: that I'd like to mentor the "extend ubiquity to add automatic migration of documents and settings from other systems" project if it's accepted
<bddebian> Morning folks
<ajmitch> hello bddebian 
<bddebian> Heya ajmitch
<Pygi> ajmitch: hi hi
<JaneW> Kamion: oic, I'll indicate that on the application then.
<Kamion> JaneW: where's the mentor page that Pygi refers to?
<Pygi> Kamion: http://code.google.com/soc/ubuntu/open.html
<Pygi> here's that application
<Pygi> http://code.google.com/soc/ubuntu/app.html?csaid=xevand@gmail.com:f70e97ac:ebc677f7
<JaneW> http://code.google.com/soc/ubuntu/app.html?csaid=xevand@gmail.com:f70e97ac:ebc677f7
<Kamion> aha, thanks
<JaneW> Kamion: select 'I'd like to mentor this...' in the evaluate section
<Kamion> done
<Pygi> Kamion: Thanks
<Mithrandir> maswan: around?
<ssam> is the simple-prog-app likely to be accepted by ubuntu? has anyone offered to mentor it?
<ssam> https://wiki.ubuntu.com/simple-prog-app
* Mithrandir hopes he has done the publish-release correctly and triggers mirrors.
<pitti> janimo: call me blind/stupid/whatever, but I can't find the g-v-m bug about the XFCE show snippet any more; I'm sure that I assigned it to me, and everything
<pitti> janimo: oh, nvm, got it
<Kamion> Mithrandir: looks ok to me
<Kamion> thanks a lot for doing that
<kagou> Ubugtu: can we imagine that, in the futur,  ubugtu will save logs on ubuntu chans ?!
<Kamion> kagou: we already have a logbot
<Kamion> kagou: http://people.ubuntu.com/~fabbione/irclogs/
<kagou> Kamion: you talk about fabbione ?!
<kagou> Kamion: fabbione don't save all chans, not ubuntu-bugs
<maswan> Mithrandir: yes?
<Mithrandir> maswan: flight-7 published, care to mirror?
<Kamion> kagou: ask him to
<Mithrandir> maswan: at least in five minutes or so
<maswan> Mithrandir: tell me when
<kagou> Kamion: i will
<Mithrandir> maswan: willdo
<bddebian> Kamion: Are syncs held up at all still?  I saw ffmpegtheora go through but not eris and varconf?
<Kamion> Mithrandir: time to lift flight-7 freeze? not that it was particularly honoured ;-)
<Kamion> bddebian: no, they're fine now, your syncs are in the queue AFAIK
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | LP upgraded, report issues on #launchpad | Flight-7 released
<Mithrandir> Kamion: yes, done.
<pitti> Mithrandir: contratulations!
<ogra> yay
<pitti> that means we can upload again?
* ogra applauds
<Mithrandir> Kamion: I guess the "mail u-d-a and lart people" should work for flight-8 or RC, whatever we end up with.
<bddebian> Kamion: OK, thx
<Mithrandir> pitti: yay all of us, really. :-)
* pitti goes for a dput dump
<bddebian> Uh oh :-)O
<bddebian> -O
<ogra> pitti, gah, you worked on gcompris !
* ogra twiddles thumbs waiting for the source to show up
<ajmitch> ogra: does he inherit all its bugs?
<pitti> ogra: chinstrap:~pitti/uploads/
<pitti> ogra: I staged them there
<ogra> ajmitch, nah, i just worked on the same package yesterday
<Mithrandir> if somebody would like to proofread http://err.no/tmp/flight7.txt, that'd be nice.
<pitti> ogra: oh, sorry
<ogra> pitti, thanks !
<ogra> pitti, dont worry, i (or rather upstream) only changed configure options
<ogra> seems the binary packages ship ~6-7MB unused .ogg files we dont need to package at all
<pitti> ogra: I was just about to remove ~/uploads, good timing :)
<sfllaw> Mithrandir: Sure.
<pitti> ogra: or put them into a separate deb and suggest: it (and don't put it on the CD)
<ogra> pitti, there is no code in gcompris at all using it, they are thought for future use
<ogra> upstream sent me a fix and will apply it as well to CVS for next release :)
<ogra> (just some --exclude options)
<sfllaw> Mithrandir: I'll e-mail you a diff.
<bddebian> Morning sfllaw
<Mithrandir> sfllaw: can you just dump it somewhere?  You haven't sent me mail before (afaik), so you'll be greylisted.
<sfllaw> Ah.
<sfllaw> Lemme see...
<Mithrandir> just a pastebin or tell me here or whatever'd work
<bddebian> WTF?  I was bug fixing all day yesterday and my karma went from >40K to ~20K??
<sfllaw> bddebian: It got halved.
<ajmitch> bddebian: yes, they were all halved
<bddebian> eeks
<bddebian> I'll never make 50K before release now :-)
<ogra> pitti, you can wipe it, thanks, got the source
<maswan> Mithrandir: let me know when to trigger the sync
<Kamion> Mithrandir: hmm, maybe note that that partitioner problem is just for the live CD installer
<Mithrandir> maswan: there's still one mirror syncing from little, but if you just trigger and see that it starts pulling it'd be good.
<maswan> Mithrandir: ah, ok. I wouldn't like to just get half of it though.
<Mithrandir> maswan: I'll ping you when it's done then.  Should be in just a few minutes.
<maswan> Mithrandir: 'k. I'll be here for another hour or so
<Mithrandir> Kamion: better now?
<Kamion> Mithrandir: yep
<sfllaw> Mithrandir: http://pastebin.ca/53726
<sfllaw> pastebin.com _eats_ diffs.
<Kamion> the whitespace thing in passwords might be too minor to bother mentioning, not sure
<Mithrandir> Kamion: *shrug*, it's not like it's a huge announcement anyway
<Mithrandir> sfllaw: argh, please don
<Mithrandir> 't reflow paragraphs
<Mithrandir> or use wdiff or something
<sfllaw> Whoops.  Sorry.
<Kamion> sfllaw: the sentence is "whitespace ... now works", not "... passwords now work", IMO
<Kamion> i.e. I think the verb should agree with the singular noun
<sfllaw> Isn't whitespace a mass-plural?
<Kamion> oh, hmm, I suppose you could regard it as such
<janimo> hey how come flight 7 is the latest alpha since 2 betas were already released ?
<Kamion> and I suppose it's arguably "leading whitespace and trailing whitespace now work" anyway
<Kamion> janimo: we're not giving it the same level of QA as a beta
<janimo> ah. ok
<sfllaw> I suppose "Leading and trailing whitespaces in passwords now work properly"
<sfllaw> is best.
<Kamion> we've done this for every release in the past, although we called it "preview" rather than "beta" then so I guess it didn't come up
<Kamion> sfllaw: could just s/whitespaces/spaces/
<sfllaw> Kamion: Yes.
<Kamion> if you can figure out how to type a tab into every password-asking interface reliably then you're a better man than I anyway
<sfllaw> Or newline.
<Kamion> not to mention ... right
<Mithrandir> Kamion: C-v tab, maybe?
<Kamion> Mithrandir: bet you that doesn't work everywhere
<Mithrandir> sfllaw: sure that wiki should be capitalised?
<Kamion> it *might*, but. :-)
<Mithrandir> Kamion: as long as it works in gtk you're fine though. :-)
<sfllaw> Mithrandir: Actually, no.
<Kamion> Mithrandir: ... and getty/login
<Kamion> and ssh
<Mithrandir> those should be easy enough
<Kamion> and everything that might ask you for an ssh password (nautilus presumably)
<sfllaw> It _used_ to be a proper name, but I guess it's a common noun now.
<Mithrandir> maswan: please rsync now.
<Mithrandir> sfllaw: I'd say so, at least.
<Mithrandir> sfllaw: I think I've applied all your changes now, care to go through it once more?
<maswan> Mithrandir: dapper/flight-7/dapper-install-amd64.iso
<Mithrandir> maswan: what about that?
<maswan> Mithrandir: that's as far as it is, so it is downloading files
<Mithrandir> maswan: oh, ok.  Thanks. :-)
<janimo> will there be another beta before RC?
<maswan> Mithrandir: seems to be syncing in ~8M/s, so it is speedy too.
<Mithrandir> maswan: can you just verify it'll show up at the urls mentioned in http://err.no/tmp/flight7.txt ?
<[g2] > where might one acquire the livecd-rootfs to build the livecd ?
<sfllaw> s/Flight 7 cd/Flight 7 CD/
<Mithrandir> [g2] : it's on the livecd.
<tseng> [g2] : you can extract it from the iso
<maswan> Mithrandir: yes, same as before. I just verified the first one too (mostly empty directory right now)
<Mithrandir> maswan: thanks a lot.
<[g2] > Mithrandir tseng That'd be handy :)
<Mithrandir> sfllaw: fixed.
<sfllaw> I'm fairly happy.
<Mithrandir> it'll just go to u-a and maybe to slashdot and some other sites, but not mainstream media so we're fine even if it's not perfect.
<sfllaw> Everything else I wanted to change is stylistic.
<Mithrandir> ok, sent.
<Mithrandir> oh well, I think I'll decide it's weekend for me now.
<Mithrandir> see you around on Monday.
<tseng> have fun Mithrandir 
<Kamion> janimo: probably not another beta, but there'll be another flight I think
<janimo> so that flight will not be alpha anymore if it happens?
<Kamion> Mithrandir: damn, just spotted a couple of errors
<Kamion> http://cdimage.ubuntu.com/kubuntu/releases/dapper/flight-7/ (Edubuntu)
<Kamion> http://cdimage.ubuntu.com/xubuntu/releases/dapper/flight-7/ (Kubuntu)
<Mithrandir> Kamion: uh, true
<Kamion> janimo: EPARSE
<janimo> or last in todays announcements means last as of now not last for dapper?
<ogra> ouch
<Kamion> janimo: it says "latest", not "last"
<Kamion> which normally just means "current"
<janimo> indeed, I can't read :(
<Kamion> but different emphasis, "just released", that sort of thing
<ryanpg> hi all... I noticed that somewhere in the recent xorg stuff I lost EXA support, (ati radeon m9)
<ryanpg> is this a known issue or should I file a bug?
<Mithrandir> Kamion: anything else, since I just cancelled my posting?
<ryanpg> btw, checking Xorg.0.log reveals no error messages (it reports parsing "Option "AccelMethod" "EXA" in xorg.conf but also reports "RADEON(0): Using XAA acceleration architecture")
<Kamion> Mithrandir: "show stopper" should be either "showstopper" or "show-stopper"
<mgalvin> why does ubuntu-standard include "telnet"?
<Kamion> Mithrandir: I don't see anything else
<Mithrandir> Kamion: ok, fixed.
<Mithrandir> there, sent.
<Mithrandir> then I'm off for real
<ogra> mgalvin, because you probably want to telnet into a server or something
<ogra> or test a port
<mgalvin> true, i ask b/c...
<carlos> doko: hi, around?
<doko> carlos: yes
<mgalvin> i was playing with the harden* packages and harden-clients will not work b/c it tries to remove telnet
<Kamion> harden-clients is brain-dead IMO
<carlos> doko: hi, I restored Esperanto translations from a backup for Breezy after all data migrations we did
<ogra> yeah
<carlos> doko: and they had full translations for ooo-writer, but after restoring the backup and import the tarball you gave me
<carlos> doko: they have more than 400 missing strings
<ogra> especially, whats insecure about a telnet client ? 
<mgalvin> might any of the harden packages be useful (they do include some useful tools)
<ogra> as long as you dont run the server telnet is very handy
<carlos> doko: I wonder if the breezy tarball you gave me is for the ooo2 backport you told me about or it's for oo.org 1.x
<mgalvin> ogra: agrees
<mgalvin> i agrees rather
<Kamion> ogra: see the harden-clients package description
<Kamion> I mean, it does what it says on the tin, I just think it's pointless
<carlos> doko: and that 2.x did some changes/additions that produced those 400 untranslated strings
<ogra> yeah
<doko> carlos: the updated tarball is from 2.x, many things did change between 1.x and 2.x, so it's no surprise.
<doko> it's sure possible, that esperanto ddoesn't have a translation yet.
<Keybuk> I don't know what the Debian coreutils maintainer "has done"
<carlos> doko: ok, the Esperanto team was worried with the data lose we had and this change was a bad, it looks like they lost something
<Diziet>   * Try to recover from badly planned move on part of dpkg maintainer to
<Diziet>     put a *local* diversion on md5sum. There is no good way to handle this;
<Diziet>     hopefully nobody will do something so stupid in the future.
<carlos> doko: but with your confirmation is enough to give them a valid explanation
<carlos> doko: thank you.
<doko> hmm, well, I never did build esperanto packages for 2.x
<carlos> doko: Rosetta has translations for it
<doko> carlos: but no importet ones?
<doko> carlos: but no imported ones?
<doko> all translated in Rosetta?
<carlos> nomed, 100% translated using Rosetta
<carlos> yes
<carlos> nomed: sorry, xchat autocompletation... you know....
<nomed> np :)
<doko> hmm, maybe some translations from 1.1 could be imported ...
<carlos> doko: they told me that they are sending them to upstream now, so you should get them for dapper + 1, but I guess we should create our own language pack for dapper
<carlos> doko: most of them, Rosetta already have them for breezy's 2.x
<Diziet> I think the right answer is to make dpkg Pre-Depend: on the appropriate version of coreutils and remove the diversion from the dpkg postinst.
<carlos> the new .pot files you provide me 'migrated' it to latest 2.x
<Diziet> This still doesn't help a sysadmin who wanted their own local diversion of md5sum.textutils, because coreutils's postinst will remove it, but at least it will avoid md5sum ever vanishing.
<doko> carlos: so you say, that Rosetta took all strings from 1.1 and which did apply to 2.x?
<carlos> ok, let's start again...
<carlos> https://launchpad.net/distros/ubuntu/breezy/+source/openoffice.org2/+translations
<carlos> Esperanto did all their translations there
<carlos> doko: I guess that's not really 1.1, but a 2.x beta
<carlos> right?
<carlos> later, we removed all upstream translations and we removed some Esperanto translations at the same time while fixing the broken .po files imported some months ago
<carlos> I restored the Esperanto translations and imported the .po and .pot files you provide me
<Diziet> pitti: Did you want to talk about these French Canadians and their ff homepage ?
<pitti> Diziet: wrt my recent bug reply? sure
<doko> carlos: hmm, right. but maybe "someone" should export the translations from all languages in 1.1, which do not have yet translations in 2.x
<Diziet> I've just sent another mail, so you probably want to read that.  Should turn up in a minute or three.
<carlos> doko: I just checked and we never imported 1.1 translations into Rosetta....
<pitti> Diziet: btw, I'm currently working on m-f-l-all, I hope I don't disturb you with that
<carlos> doko: https://launchpad.net/distros/ubuntu/breezy/+source/openoffice.org/+translations
<carlos> it doesn't have any translation other than the package templates
<carlos> doko: hmm do you think is possible that from the OO.org2 beta released with breezy to the one in dapper, ooo-writer would change more than 400 strings?
<carlos> s/change/change-add/
<Diziet> pitti: No, not at all.  I don't really consider that one mine :-).
<pitti> ok :)
<doko> carlos, 400 are just 0,7% ...
<pitti> Bengali firefox really looks nice
<carlos> doko: talking about ooo-writer, that's 2573 strings so it's more than 0,7%....
<carlos> 15%
<Kamion> Diziet: presumably we pretty much lose hope of sid->dapper migrations working sensibly
<Kamion> Diziet: (because the Pre-Depends will be satisfied with the current version in sid, but that won't actually contain the code we want)
<Kamion> oh for feature dependencies
<doko> carlos: could you give me a list of these strings? but I'm unsure if I do have time to evaluate these ...
<Diziet> Kamion: Err, no, I think it should be OK.
<Kamion> Diziet: also, can coreutils be careful only to remove the diversion on upgrade from versions before this fix? Then a sysadmin could at least put the diversion back afterwards.
<Diziet> Kamion: Yes, I was just thinking that would work.
<Diziet> I'll have to look at the changelog for sid's coreutils to make sure it's all right.
<Kamion>   * Fix md5sum diversion problems with a hacksaw (Closes: #340119)
<Kamion> heh
<carlos> doko: https://launchpad.net/distros/ubuntu/breezy/+source/openoffice.org2/+pots/ooo-writer/eo/+translate?show=untranslated
<carlos> doko: I'm doing some checks now anyway
<maswan> Mithrandir: done
<mgalvin> hmm, i know root is disabled but found "PermitRootLogin yes" in sshd_config so if someone enable root... that my not be desired
<bddebian> OK, sorry but no one in -motu is answering.  Anyone have a feeling on removing package pcsx?  Bug #41501
<Ubugtu> Malone bug 41501 in pcsx "[unclear]  [UNMETDEPS]  pcsx has unmet dependencies" [Normal,Needs info]  http://launchpad.net/bugs/41501
<Diziet> mgalvin: /usr/share/doc/openssh-server/README.Debian.gz
<mgalvin> ah the new default, ok
<mgalvin> Diziet: thanks
<Pygi> o joy :)
<Pygi> Ubuntu based tablet distribution
<bddebian> Kamion: See, this is my problem :-)
<bddebian> I guess I should mail ubuntu-devel?
<Kamion> bddebian: I'm afraid there's no magic answer to help you get help from other people
<Kamion> "is answering" suggests you tried #ubuntu-motu; try mail instead
<Kamion> mgalvin: it's the default upstream as well; it's not just the packagers who think it's a good idea
<bddebian> Kamion: Is it more appropriate for ubuntu-devel ML or ubuntu-motu?
<Kamion> bddebian: -motu at first, I guess
* bddebian grumbles
<Kamion> in general we should only be removing packages (in a delta relative to Debian, if you see what I mean) if they're genuinely useless in Ubuntu
<Kamion> if it's just that they're broken and we've decided we don't have time to fix them, I don't think that's a good reason for removal; somebody might come along later who does have time, and it's extra effort later to tell the difference between the stuff that we removed because we never want it again and the stuff we just removed for one release
<sivang> Kamion: source uploaded, let me know if you have any reservations before a NEW kick.
<bddebian> Well they are currently unbuildable in Ubuntu, doesn't that make them useless?
<Kamion> bddebian: fundamentally useless, not just as-it-happens-at-the-moment useless
<Kamion> like support for Linux 2.4 only would be fundamentally useless in Ubuntu
<Kamion> but a PlayStation emulator intuitively seems to have uses
<Kamion> sivang: I normally do :-)
<Kamion> let people know if I have reservations, I mean, not have reservations
<bddebian> Kamion: So if I pulled the psemu deps from debian and uploaded would they end up in NEW, or is that a no no?  ( I hate having broken packages in the archive )
<sivang> Kamion: ah okay, although both would be acceptable and treater to the fullest extent by me :)
<Kamion> bddebian: when edgy opens, we'll be doing a huge sync from Debian, and at that point we need to work out which packages need to be reintroduced becase they're now fixed
<Keybuk> ya know, it's just occurred to me that we don't have mom-for-edgy
<ogra> Keybuk, fix that !
<ogra> we'll die without her
<sivang> yes, he must :)
<bddebian> This sucks
<mgalvin> Kamion: yup, the doc Ian pointed me at explained it all, thanks :)
* Keybuk sends magic vibes to the launchpad team
<Kamion> bddebian: syncing psemu-video-x11 from Debian sounds reasonable
<pitti> seb128: can you upload your batch of pot files as well?
<Kamion> bddebian: I'm doing that now
<Kamion> bddebian: (it'll end up in NEW, yes, but that's OK)
<seb128> pitti: I've doing so, let me some time, I've 17 uploads to do now than the freeze is over
<seb128> s/I've/I'm
<bddebian> Kamion: Oh, thx, I would have requested it.  I didn't mean to give you work.  I have already given you enough so far ;-P
<Kamion> bddebian: let me know what other deps are needed, if any
<pitti> seb128: oh, wasn't meant as a hurry, sorry :)
<Kamion> bddebian: note that psemu-video-x11 provides psemu-video
* pitti hugs seb128
<seb128> pitti: np, I'm on it ;)
* seb128 hugs pitti
<bddebian> Kamion: Aye, I knew that
* bddebian hugs Kamion and bows his head in shame
<Kamion> no trouble, done
<Kamion> try to take the above in the spirit it was intended, though, as a sort of general guide to how to decide whether something should be removed or not
<Diziet> Freaky.  Why does dpkg now have a ChangeLog ?
<bddebian> Kamion: OK, thx
* bddebian takes that to heart for mgpadesk
<bddebian> Err mgapdesk
<bddebian> So many bugs, sooo little time :'-(
<bddebian> Kamion: Dumb question.  I assume psemu-x11 will run through the normal buildd process?
<Kamion> bddebian: yeah, although it'll land in binary NEW as well
<pitti> seb128: saw your uploads, great :) this should make https://wiki.ubuntu.com/MissingPotFiles look really good
<bddebian> Kamion: Well I just wanted to wait to see if it builds, then I can check/try pcsx
<seb128> pitti: yeah, I'll clean the wiki page when I'm done with the uploads, only 1 package to upload for it :)
<_ion> bug #43117
<Ubugtu> Malone bug 43117 in linux-meta "grsec support in linux-image-server" [Normal,Unconfirmed]  http://launchpad.net/bugs/43117
<Kamion> siretart: freealut binaries accepted, since I understand you were waiting for them
<mgalvin> infinity: ping
<bddebian> Kamion: How long before I should be pull the source package from the archive?  (Sorry to keep bugging you btw)
<Kamion> bddebian: publisher runs start at :03 every hour and run for about 30 minutes; after that, the source will be available
<bddebian> OK, thx
<elmo> Mithrandir: you done with flight 7, at least as far as little is concerned?
<Mithrandir> elmo: yes
<Mithrandir> elmo: it's published and the announcement sent.
<Keybuk> anyone here got a T42 and Docking Station? :p
(elmo/#ubuntu-devel) Kamion: yes, so far I've rsynced /home and /srv, and synced the installed packages.  anything else you can think of?
<Kamion> rsyncd configuration
<elmo> right, /etc.  I'll also have to update everyone little triggers, meh
<Mithrandir> crontabs.
<Kamion> I don't think much else is cdimage-specific
<Kamion> oh yeah; though the cdimage crontab is easily restored and mine is trivial
<bddebian> elmo: Any chance you could check on my @ubuntu.com e-mail on LP?
<elmo> bddebian: no chance whatsoever
<elmo> ok, I'm locking down little, stopping cron, rsync etc.
<bddebian> elmo: OK, thx
<seb128> pitti: pot updates done ;)
<sivang> Kamion: I see source is accepted, is you now or infinity that needs to approve the binary ?
<Kamion> sivang: any member of ubuntu-archive
<sivang> Kamion: k, thanks.
<Kamion> we have a tool that displays the queue for us, so we don't need to be told
<elmo> Kamion/mithrandir/%cdimage: ok, lithium is up, wanna log in and check it out?
<Keybuk> "lithium"
<Keybuk> that well known breed of penguin
<elmo> Keybuk: we ran out of penguins and base stations
<Keybuk> what are we onto now?
<Kamion> elements, by the looks of things
<Keybuk> we could have "caffiene" ... that's a type of penguin
<elmo> right, the periodic table
<mdz> Keybuk: "mint"
<Keybuk> unobtainium.ubuntu.com
<Mithrandir> Kamion: cdimage crontab enabled.
<Mithrandir> elmo: seems to work fine.
<Kamion> Mithrandir: thanks
<Kamion> enabled my crontab too
<elmo> old crontabs are in /root/little-cron btw
<Mithrandir> 1.1TB on /, that's usable.
<Kamion> elmo: no need, I saved mine in time :)
<Kamion> mm, disk space
<Keybuk> mdz: I've decided not to change the hardware enumeration :)  it turns out to be a more complicated problem than I first thought <g>
<Kamion> let's try not to use it all at once
<Keybuk> mdz: I'll just make edgy very broken instead, muahahaha
<elmo> it's got more CPU + memory to come
<mdz> Keybuk: colour me relieved
* Kamion tries a CD build
<elmo> but there's been some unobtanium problems with them, ATM
<Mithrandir> elmo: how's the I/O compared with little?
<Keybuk> mdz: the upstream code triggers devices in "readdir order"
<Keybuk> which seems to be rather ... odd
<Mithrandir> I/O >> cpu on cd-building machines.
<elmo> Mithrandir: at least 2x as good
<Kamion> it's going to take at least a year to get out of the habit of 'ssh little'
<Mithrandir> elmo: oh, that's rocking.
<Keybuk> what was little?  cd image building?
<Kamion> Keybuk: yes
<Keybuk> Kamion: I'm trying *not* to get into the habit of typing "ssh lp_archive"
<elmo> if you guys need more than 1.1Tb, it'll need to be external, this is the max you can fit in these machines with currently available SCSI disks in our paranoid RAID 5 setup
<Keybuk> I already type "ssh breezy" when I mean "ssh paperboy", if I'm only logging on because it's running breezy and I want to compare something
* Mithrandir should make a cdimage ssh alias.
<Mithrandir> anyway, weekend.
<Mithrandir> see you all around on Monday.
<mdz> Mithrandir: enjoy
<elmo> Kamion: oh, the apt cache is probably amusingly fux0red
<elmo> Kamion: since it's gone from i386  -> amd64
<Kamion> I think cdimage rm -rf's it between each build
<elmo> seriously?  why?
<Kamion> because I only noticed it did that last week
<elmo> heh
<elmo> because you know, you wouldn't want your cache to, like, cache anything
<Kamion> /usr/bin/stat: cannot stat `/srv/cdimage.no-name-yet.com/ftp/dists/dapper/main/i
<Kamion> nstaller-amd64/20051026ubuntu31/images/netboot/ubuntu-installer/amd64/pxelinux.c
<Kamion> fg.serial-9600/default': No such file or directory
<Kamion> wonder whose fault that is
<Kamion> seriously, can we rename that to cdimage.ubuntu.com at some point? :)
<elmo> those files seemed to be owned by mithrandir, is that normal?
<Kamion> yeah, if he ran a build as himself
<Kamion> which I do as well from time to time
<Kamion> should be harmless normally, we take some care to try to keep everything g+w
<Kamion> /usr/bin/mkisofs: unrecognized option `-jigdo-jigdo'
<Kamion> elmo: could you please install the mkisofs/dapper we had on little?
<elmo> ugh, ight
<Kamion> also it seems to want a password now when sshing to syncproxy
<Kamion> ImportError: /srv/cdimage.no-name-yet.com/britney/update_out/britneymodule.so: cannot open shared object file: No such file or directory
<Kamion> I'll need to fix that ...
<elmo> yeah, I still have to fix all the machines it triggers
<Keybuk> pitti: my spider sense is telling me that DHCP is failing for a lot of people today
<Kamion> elmo: could I have libapt-pkg-dev and python-dev for a bit pleae?
<Kamion> please
<elmo> Kamion: done
<elmo> Kamion: fixed mkisofs installed too
<pitti> Keybuk: because of the patch I uploaded an hour ago?
<pitti> Keybuk: that was actually supposed to fix a fair number of failures
<Keybuk> pitti: I don't know.
<Keybuk> I'm just starting to see vague comments about DHCP not working in my INBOX
* Kamion fixes britney
<Kamion> DAMNIT BAZ
<Keybuk> you still use baz?
* Kamion removes his arch revlib
<Kamion> Keybuk: yes for cdimage, until I get a bzr import of debian-cd
<Keybuk> I purged the spawn of satan that is baz from my life some time ago
<pitti> Keybuk: ok, my last version isn't even in the archive yet, so it's not due to it
<Kamion> sadly I am dependent on imports
<Keybuk> pitti: perhaps not.  could be just the nm patch people are testing
<Keybuk> pitti: just thought I'd mention it
* Kamion goes out for a bit
<pitti> Keybuk: ok; other than my current fix (which I believe is correct) dhcp didn't change in a while
<pitti> Keybuk: I'm sub'ed to dhcp3 bugs, so I'll see what's going on
<elmo> Kamion: ok, all triggered machines updated now too, FWIW
<Keybuk> Kamion: you could run baz2bzr over the import in a cronjob
<Keybuk> pitti: it appears to be in the archive
<pitti> Keybuk: the source is, the deb isn't yet 
<Keybuk> deb is
<Keybuk> dhcp3-client | 3.0.3-6ubuntu6 |        dapper | hppa
<Keybuk> dhcp3-client | 3.0.3-6ubuntu7 |        dapper | amd64, i386, ia64, powerpc, sparc
<thom> elmo: continuing the tradition of untypable machine names you really ought to have gone for http://www.godchecker.com/pantheon/aztec-mythology.php?_gods-list
<thom> there are some classics there
<elmo> haha
<jsgotangco> batman is an aztec god??
<Keybuk> infinity: ping
<elmo> thom: that's so much better than your last suggestion
<elmo> (whales, IIRC :-P)
<fabbione> LOL
<Keybuk> ssh yiacatecuhtli
<thom> heh
<Keybuk> (if you pronounce that like Kamion does ... the only response is "bless you")
<infinity> Keybuk: Hrm?
<Keybuk> infinity: did you upload the initramfs sickness yet?
<thom> Keybuk: i think Tlahuixcalpantecuhtli is probably the winner
<infinity> Keybuk: Nope, should do tomorrow.
<infinity> (ie: in 12~16 hours)
<bddebian> Heya infinity
<Keybuk> thom: I think I caught that off a one-night-stand once
<infinity> Keybuk: Do you have a pending udev upload that I'd muck up if I uploaded udev with initramfs-tools when I do my thing, just to make sure they go in together?
<infinity> (Not that they'll need to go in together, but I may as well fix the bug all at once)
<Keybuk> I was about to do a udev upload, and wondered whether I should wait on the basis avoiding two in one publisher run ;)
<infinity> Nah, do yours, and I'll upload my stuff tomorrow.
<Keybuk> okies
<Keybuk> be sure to update the initramfs-tools depends ;)
<bddebian> Damn, still no source for psemu-x11 :-(
<Kamion> Keybuk: true, I could do
<Kamion> bddebian: psemu-video-x11
<Kamion> is there
<bddebian> Hmm weird
<maswan> elmo: speaking of hostnames, I know a guy that named a server WxrtlHltl-jwlpklz after a demon in a pratchett book.
<bddebian> Hmm, nope, now there is it
<bddebian> Err it is
<Keybuk> maswan: isn't that a cat word?
* ogra thinks that was a god
<Keybuk> ... dvs tungan gr inte av nr man frsker uttala det. [17:13:30]  - lisll - har haft xilark och WxrtlHltl-jwlpklz som nattuksbord hemma hos Grabben ...
<Keybuk> heh @ google
<LaserJock> I noticed some element names today on some *.ubuntu.com, I got all excited :-)
<bddebian> LaserJock: Nerd ;-)
<bddebian> Kamion: pcsx builds with that, thanks
<maswan> Keybuk: heh, yeah, that's Grabben. former ACC admin. :)
<LaserJock> bddebian: I would have prefered some good laser names but I'll settle for elements ;-)
<Keybuk> lasers have names?
<LaserJock> sure
<LaserJock> HeNe and YAG are two I have
<maswan> Hmm.. One place I know of have fileservers named after protein sequences
<LaserJock> yeah, our theoretical group does that
<LaserJock> the other one does, fate, luck, chance, chaos, etc.
<bddebian> heh
<bddebian> chaos is a cool server name
<Keybuk> we could name them after the deadly sins
<Keybuk> gluttony, sloth, changing the debian/ directory from debian/patches, etc.
<LaserJock> bddebian: anarchy was the powerbook
<bddebian> Hehe @ Keybuk
<Keybuk> right, weekend time
<Keybuk> going to grab food, and head out skating; seeing as the weather's so nice
<LaserJock> Keybuk: so maybe we can add checkinstall to the list ;-)
<Kamion> bddebian: great
<ogra> LaserJock, pfft, be consequent, lets switch the buildds to checkinstall rather ;)
<LaserJock> ogra: I'm sure it would cut down on the number of bug reports :-)
<ogra> a lot :)
<LaserJock> ogra: heah, if they don't have a working web browser or email client they can't submit a bug report
<ogra> exactly :)
<bddebian> pfft :-)
<ogra> and what should they do with a browser anyway without X
<jsgotangco> lol
<stratus> ogra: can you mail pkg-ltsp-devel with your modularization ideas (conf. file and all that we discussed here) until monday, please? :)
<jsgotangco> make LP compatible with lynx?
<ogra> stratus, i'll try
<LaserJock> jsgotangco: hmm, we would have to figure out a way to break it too :/
<stratus> ogra: ok, i'll talk with otavio about your ideas but i'm sure he will want to discuss all the topics (by mail or here).
<ogra> yep
<stratus> ogra: i've asked until monday due to debcamp/debconf
<ogra> just note that i'm on LinuxTag tomorrow
<stratus> ogra: until when?
<ogra> so i might not be on IRC for longer bits
<ogra> it ends tomorrow
<stratus> oh, ok
<mdz> seb128: what was g-s-t using instead of gksu before?
<seb128> mdz: it has its own sudo mode
<seb128> mdz: but it was using it for some days, we tried it to fix the "UI is running with sudo so browser buttons, etc start apps as admin"
<seb128> with it's own mode only the backend is doing sudo
<mdz> right, having only the backend run as root is better
<mdz> but as of 0ubuntu8 it runs the whole thing under gksu?
<seb128> mdz: 
<seb128> gnome-system-tools (2.14.0-0ubuntu6) dapper; urgency=low
<seb128>   * debian/patches/64_gksu-in-desktop-files.dpatch:
<seb128>     - don't run the programs with gksu but use the sudo mode instead,
<seb128>       fix the issue with the UI running with sudo too (Ubuntu: #23230)
<seb128> gnome-system-tools (2.14.0-0ubuntu8) dapper; urgency=low
<seb128>   * debian/patches/08_desktops_changes.dpatch:
<seb128>     - use gksu for the menu items again so the UI is consistent with the other
<seb128>       applications of the desktop (Ubuntu: #40680)
<seb128> mdz: that's when we stopped using gksu and when we started using it again
<mdz> yes, that's what I'm asking about
<bddebian> Should we have a libxf86config.so* or has that been deprecated?
<mdz> oh
<mdz> seb128: I don't use those tools very often ;-)
<seb128> mdz: right, the whole thing runs under gksu again
<seb128> like it did since warty
<seb128> is that an issue?
<mdz> I was curious about the change
<mjg59> Launching nautilus as root sounds like a bit of an issue
<seb128> mdz: ok ;)
<mdz> seb128: was the UI inconsistency the only reason to switch it back?
<seb128> mjg59: 
<seb128>   * debian/patches/20_use_sudo_user.dpatch:
<seb128>     - patch by Dennis Kaarsemaker <dennis@kaarsemaker.net>
<seb128>     - Use su -c $SUDO_USER for launching nautilus/totem/gnome-cd if that
<seb128>       variable is set (Ubuntu: #23230)
<mjg59> Ah, cunning
<seb128> mdz: the main reason yep
<mdz> hm
<seb128> mdz: we had also an issue with "install ntp|samba..."packages patch
<seb128> but it was as easy to fix as the nautilus one we fixed other way
<Seveas> seb128, I'm surprised the patch applied, it's a few months old (written for the breezy version) 
<seb128> Seveas: upstream doesn't do a lot on it for some time
<Diziet> This buffer_* stuff in dpkg is a bit mad.  Not to mention subtly broken :-/
<bddebian> Should we have a libxf86config.so* or has that been deprecated?
<mdke> Znarl: around?
<Znarl> mdke : Hi!
<mdke> Znarl: hello :) Thanks for your email today, I wanted to clarify something I didn't understand.
<bddebian> fabbione or infinity: awake?
<fabbione> noi
<fabbione> no
<bddebian> OK, sorry
<fabbione> bddebian: what's up?
<bddebian> fabbione: mgapdesk is looking for libxf86config (-lxf86config).  Is there something I can replace that with?
<fabbione> bddebian: never heard of that library
<bddebian> Hmm
<crimsun> (it was in xlibs-static-dev, but it doesn't exist in dapper)
<bddebian> /usr/X11R6/lib/libxf86config.a
<mdz> bddebian: what for?
<bddebian> mdz: ?
<mdz> bddebian: libxf86config
<bddebian> mdz: Oh, mgapdesk
<mdz> bddebian: is mgapdesk a person or a program?
<bddebian> Package in universe.
<SuperQ> anyone know how to convert hotplug usermaps to udev?  I'm trying to get an odd-ball USB serial device working with Dapper (works fine with breezy)
<bddebian> Orphaned in Debian but Kamion suggested I try to fix it
<crimsun> SuperQ: see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2005-December/000028.html
<crimsun> SuperQ: look at the bottom
<mdz> bddebian: the source is still around, in hw/xfree86/parser in xorg-server
<SuperQ> crimsun: yea, thanks!
<bddebian> mdz: Aye, but looking on google, it looks like it only ever gets built as a static lib
<sivang> Kamion: if I see that a package has binary packages in LP, that does not neccessary mean that it's been NEW'd for the bin packages ?
<sivang> oh man, this is weird. There is now an 'upbackup' package in the repo, with an old branch snapshot, can I ask to have it removed, and let only the new hubackup package prevail?
<Kamion> sivang: builds listed in launchpad just mean it's built, not necessarily accepted
<Kamion> sivang: I've accepted them now, may take an hour or two to reach mirrors due to the vagaries of publisher run times though
<Kamion> if you mean hubackup
<Kamion> sivang: yes, that's expected, please file a bug to have upbackup removed
<Kamion> file it on upbackup and subscribe ubuntu-archive to the bug
<sivang> Kamion: many thanks! I owe you. I will report that bug now.
<ben-2006> Hello, i'm looking at re-writing the samba/folder shares tool as part of SoC and I was wondering if you could confirm what the underlying code is written in - python / GTK?
<mdke> ben-2006: I don't know but I guess that if you download it you can find out
<ben-2006> well i have ubuntu setup
<mdke> ben-2006: ok. you can get the source code with "apt-get source gnome-system-tools"
<seb128> ben-2006: Novell has worked on a nautilus samba share extension which looks nice, maybe you should have a look to that before starting on your project
<ben-2006> oh - didnt know thats how you got the source - thank you :)
<ben-2006> seb128: As it might be better to use that or to gain some ideas/understanding/concepts
<seb128> ben-2006: http://gentoo.ovibes.net/nautilus-share/mediawiki-1.4.4/index.php/Accueil
<ben-2006> thanks
<seb128> ben-2006; I think they based the work on that
<seb128> ben did several changes to it
<seb128> ping sebest about it when he's around
<seb128> he's upstream for nautilus-share
<ben-2006> cool
#ubuntu-devel 2006-05-11
<mdke> jdub: eia
<setuid> Why does Ubuntu's kernel only support 32-bit AES? 
<Burgwork> setuid, I have no idea, and you are unlikely to get an answer, as it is friday afternoon and all the kernel monkey are either in the eastern us or europe
<setuid> Fri May  5 19:07:56 EDT 2006
<setuid> I'm trying to figure out how to encrypt this volume... encfs is kind of lame, and requires a loopback file
<setuid> losetup/cryptsetup don't handle more than 32-bit keys
<setuid> Both are definitely sub-optimal
<mjg59> setuid: It's not likely to be deliberate. Can you file a wishlist bug against linux-source-2.6.15?
<setuid> I'll see what I can do 
<setuid> Right now, losetup needs patching to support proper encryption
<setuid> Try this: 
<setuid> dd if=/dev/zero of=mycryptofs bs=1k count=5000
<setuid> losetup -e AES256 /dev/loop0 mycryptofs
<setuid> ... use a password of at least 20 chars
<setuid> It'll die with some bogus: ioctl: LOOP_SET_STATUS: Invalid argument
<mjg59> setuid: I'm quite happy to believe you :)
<mjg59> Can you file a bug against util-linux as well?
<setuid> ;) 
<setuid> How many do you want me to file tonight? ;) 
<setuid> # losetup -e AES256 /dev/loop/0 mycryptofs
<setuid> Password: 
<setuid> ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length (256 bits) not supported by kernel
<setuid> niiiice
<mjg59> Oh, right. That error is from the kernel.
<mjg59> What patches does losetup need?
<setuid> http://clemens.endorphin.org/Cryptoloop_Migration_Guide
<setuid> Second para down
<mjg59> Ok
<mjg59> If you file a bug against util-linux and include that, that'd be great
<setuid> I'm testing the patch now
<mjg59> I can't promise that it'll make dapper, but there's a chance
<setuid> Dapper deprecated already?! 
<setuid> What're we at now? 
<mjg59> No, feature frozen
<setuid> I would call this 'grave', not a feature
<mjg59> Which? The lack of losetup support, or the kernel encryption?
<mjg59> If you want functionality that isn't upstream, then that's a feature
<setuid> Lack of support for aes256
<mjg59> It may be a highly desirable feature, but, well
<setuid> The kernel has it, but util-linux doesn't let me use it 
<setuid> because util-linux truncates the key
<mjg59> If it's a plain bug, then it can be fixed
<setuid> Sure
<setuid> mjg59: where is $PREFIX defined in $PACKAGE/debian, if I have the source for a package? 
<setuid> Something's wrong here
<setuid> Wha'ts the command to see what args a package was built with again? 
<jmg> bhey all hows it going?
<vdepizzol> will ubuntu 6.06 come with flash player?
<crimsun> vdepizzol: no.
<vdepizzol> crimsun: why not?
<crimsun> vdepizzol: are you referring to Macromedia/Adobe's?
<vdepizzol> crimsun: yes, the flash plugin for web
<crimsun> vdepizzol: it's in multiverse: 'flashplugin-nonfree'.
<bddebian> Howdy peoples
<bddebian> Do we need to do a UVF / sync request on LP to bring in something NEW?
<bddebian> sfllaw: You there or just a reconnect?
<bddebian> Damn it's quiet tonight
* mgalvin makes noise ;)
<zul> heylo
<bddebian> Heya zul
<zul> hey bddebian 
<myleftfoot> hi guys... in dapper is gdm compiled with the --enable-secureremote option?
<bluetoad> Fabbione? 
<fabbione> hey bluetoad 
<bluetoad> How's it going?
<fabbione> bluetoad: pretty good i would say
<fabbione> you?
<bluetoad> Pretty good.  Off to the movies soon.
<bluetoad> I've been looking through the bugs.  Don't know where I can help.
<bluetoad> Might be 1 bug  #42354
<Ubugtu> Malone bug 42354 in xorg "Screen configuration misses horizontal/virtical refresh rates" [Normal,Unconfirmed]  http://launchpad.net/bugs/42354
<bluetoad> Still waiting on others
<fabbione> i saw that one coming in yesterday.. but it's like weekend :)
<bluetoad> I'll leave you alone.
<sfllaw> No rest for the weary.  :)
<bluetoad> Reckon.
<fabbione> ehhe
<fabbione> bluetoad: nah it's ok
<fabbione> i am not going to kill you if you want to talk
<bluetoad> No worries.  Just though I'd check in.
<fabbione> ehe thanks a lot dude
<bluetoad> Enjoy the day.  I'm off.  Let me know if there is any small things to look out for.  Knowledge is a sketchy on all this.
<fabbione> bluetoad: have fun
<bluetoad> You too.
<hunger> ~.~.
<hunger> ~.
<hunger> Sorry for that...
<_ion> hunger: Trying to kill the ssh session? :-)
<_ion> hunger: And then remembered the IRC client is running on the local machine? ;-)
<mdke> Znarl: around?
<mwright1nigh1> Hi,  I don't know if any developers here have  HP server to test with but a DL380 G4 running latest iLO (Integrated Lights Out) won't display ubuntu as it boots
<mwright1nigh1> you see grub, and the loading kernel thing, then you lose the console
<mwright1nigh1> I can give a web ilo login (needs java 1.4.2+) tomorrow to a developer BUT, I will be building the server after tomorrow so won't be able to give it out after then if anyone wants to test
<HrdwrBoB> do you have advanced iLO?
<HrdwrBoB> not sure if it would be a licensing issue
<mwright1nigh1> iLO advanced
<mwright1nigh1> I work for HP
<mwright1nigh1> Fedora and Rhel works ,except when I type linux rescue
<mwright1nigh1> then they fail cause they don't handle the virtual scsi cdrom
<Kaloz> morning. who's in charge of xubuntu stuff?
<tseng> janimo, crimsun. but if you have a bug you are better of putting it in launchpad
<tseng> irc gets lost, esp when people arent here
<Kaloz> well, i've asked because dunno who to contact, as the wavelan plugin is in the universe
<Kaloz> the sources is right, just the binary package is wrong
<Kaloz> seem slike someone forgot to update it
<Kaloz> the .deb is an older version with (now) broken dependencies
<mdke> sounds like a bug would be helpful
<Kaloz> i've udnerstood that, just dunno if that one will get into main or not with the move of xfce into main, so i was wondering what against should i fill the bug
<Gloubiboulga> Kaloz, it's a known bug
<Gloubiboulga> Kaloz, some plugins have not been ported to the new panel yet
<Kaloz> Gloubiboulga: it's ported, just the .deb was not updated :)
<Gloubiboulga> Kaloz, you're upstream?
<Kaloz> Gloubiboulga: nope, but i can read the changelog :P 0.5.0 has "* New upstream release, ported to the 4.4 panel API" in the changelog, but the binary .deb is at 0.4.3 still
<Gloubiboulga> Kaloz, ok, I'll update the package then
<Omeg> Hey guys.
<Kaloz> Gloubiboulga: yay :)
<Gloubiboulga> Kaloz, I can install the package from the repos
<Kamion> Kaloz: xfce4-wavelan-plugin | 0.5.0-0ubuntu1 | dapper/universe | source, amd64, i386, ia64, powerpc, sparc
<Kamion> Kaloz: .debs look up-to-date to me
<Kamion> Kaloz: but they're only timestamped yesterday, so perhaps your mirror is just a bit out of date; try archive.ubuntu.com
<slomo_> hmm... what happened to the buildds? nothing is built since many hours it seems
<seb128> slomo_: ah, nothing ... reply to my question about gst-plugins-good0.10 on #launchpad so, thank you ;)
<mdke> seb128: hiya. I still get asked for my ssh key or keyring password when I try to open (e.g.) epiphany/gnome-terminal preferences, did that fix you mentioned recently land? or was that for another bug?
<seb128> mdke: it was for the fileselector itself (ie: the open or save dialog), but the same should probably be done for the widget that lists a path
<mdke> seb128: ah right. Do you need a bug for it?
<seb128> mdke: btw keyring "always" option work between sessions now, so if you store it once to your keyring it should be better
<seb128> mdke: no, thank you, I'll use the other bug for that too
<mdke> cool.
<slomo_> seb128: what question? i'm not in #launchpad ;)
<seb128> slomo_: <seb128> does anybody know why gst-plugins-good0.10 0.10.3-0ubuntu1 build has not been tried?
<seb128> slomo_: they are debugging it
<slomo_> seb128: cool... so let's wait and i'll get some food now :)
<seb128> enjoy your lunch ;)
<bddebian> Heya peoples
<mdke> seb128: if you want, you can change the url for "Online Support" from help.ubuntu.com to help.ubuntu.com/6.06 
<seb128> mdke: ah, thank you
<sits> why would gdm start two Xs?
<HrdwrBoB> if it was told to
<bddebian> If I have -I/usr/include/foo   and the package does #include "foo.h"  Does that work?  Or does "foo.h" only look in the current dir?
<klepas> anyone seen Daniel Holbach of late?
<zul_> nope...
<sits> HrdwrBoB: would that only happen in /etc/gdm/gdm.conf
<mdke> klepas: he doesn't work at weekends. But if you email him, he'll see it
<klepas> cheers
<klepas> shall drop him a mail :)
<HiddenWolf> he doesn't work weekends? Since when? :P
<mdke> HiddenWolf: I've never known him to use irc at weekends, anyway
<mdke> maybe occasionally.
<bddebian> Folks.  What is the proper procedure for bringing in something new from Debian that cannot be synced? (swt-gtk in this case) ?
<bddebian> It's a depends for swingwt
<seb128> klepas: dholbach is at linuxtag today
<klepas> ah, cool
<klepas> seb128: if you're there, say hi ;)
<seb128> nop, I'm not :)
* bddebian gets no love
* HiddenWolf hugs bddebian
<HiddenWolf> seb128: man, how many hours do you make?
<seb128> ?
<bddebian> Thx HiddenWolf :-)
<HiddenWolf> seb128: you're _always_ here. :)
<zul_> i think he means you never sleep seb128
<seb128> HiddenWolf: I try to not IRC on saturday usually, I just started it to ask to the buildd admin why gst-plugins-good0.10 was not building :p
<HiddenWolf> seb128: do you ever leave the work behind? 
* bddebian will just throw up swt-gtk and see if he gets yelled at I guess
<seb128> HiddenWolf: when I'm uptodate with my work ;)
<seb128> why is not often with the bug flood we get :/
<bddebian> Amen to that
<HiddenWolf> uhuh, massive amount of bugs. :/
<ivoks> ho ho ho
<ivoks> ups... sorry :)
<Evaso2> hi guys somebody knows the status of freepascal in debian?
<slomo_> seb128: and -good is still not built *sigh* do they make some progress? *builds it himself now*
<seb128> slomo_: no idea of what they are doing
<seb128> are you in a hurry?
<slomo_> well... i won't have time to play with gst or anything else later today, tomorrow, on monday and on tuesday because of too much other work ;)
<HiddenWolf> seb128: I was wondering, in the flood of bugs/packages that you get, how do you decide what to do / fix ?
<bddebian> Everything ;-)
<seb128> HiddenWolf: I just decide
<seb128> I mean, what sort of question is that
<HiddenWolf> seb128: like, how do you prioritise?
<seb128> good sense?
<seb128> if that's "nautilus just crash for everybody" we have to fix it no?
<seb128> and if that's "gconf-editor icon is blurry on a 48 pixel panel" that's not a priority
<mdke> haha, nice example
<seb128> there is no magical way ...
* bddebian has a magic wand
<bddebian> OK, I'm getting really confused with this libswt crap.  Many of the binarys apparently come from eclipse now but what replaces libswt-gtk-dev?  Just eclipse?
<bddebian> eclipse-sdk?
* bddebian loves talking to himself
<jpatrick> improves confidence
<slomo_> bddebian: ask doko 
<sebest> seb128: hello
<zyga> hey everyone
<kagou> hi
<mdke> who knows lots about asian fonts on Ubuntu?
<HiddenWolf> mdke: check the scim maintainer field?
<mdke> thanks
<crimsun> mdke: ping freeflying-ibook, for instance
<freeflying-ibook> mdke: 
<mdke> hiya
<freeflying-ibook> mdke: I know a few about Chinese fonts :)
<mdke> freeflying-ibook: does the "serif" font on Ubuntu contain all necessary asian fonts?
<mdke> (i know nothing about fonts at all)
<freeflying-ibook> mdke: almost
<mdke> so I've been trying to build some pdfs using the "serif" font, but all asian characters come out as #
<mdke> I've described the problem here http://news.gmane.org/gmane.text.xml.fop.user, and had one reply, which suggested that serif might not provide asian characters. But I have to say, viewing asian characters in a serif font on my system looks absolutely fine.
<freeflying-ibook> mdke: do you have language-selector in your /etc/fonts/
<mdke> language-selector.conf
<freeflying-ibook> this file configure the CJK fonts , alias CJK to serif
<mdke> freeflying-ibook: the file is basically empty.
<freeflying-ibook> mdke: it's a symlink , it will be linked when you use CJK locales
<freeflying-ibook> mdke: maybe I can have a try with your pdf files
<mdke> freeflying-ibook: the problem is not in viewing the pdf files, it is in creating them. Have a look at my post at the above url.
<freeflying-ibook> mdke: give us a while
<mdke> freeflying-ibook: ok, I'm hoping for some more replies on that mailing list anyway.
<freeflying-ibook> mdke: fop-0.20-5, which u r using now can not support CJK fonts 
<mgalvin> Mithrandir: just a heads up, i am creating a flight 7 page (just now getting time to do it :-/)
<mgalvin> better late then never i guess :)
<nix4me> is there anyone that can point me to a definative answer on why cups in dapper is not accepting connections from windows machines?  I know this is a devel channel but im going crazy trying to get this to work
<infinity> nix4me: bug #39484
<Ubugtu> Malone bug 39484 in samba "cups smb printing backend no longer works" [Major,In progress]  http://launchpad.net/bugs/39484
<infinity> nix4me: A user has posted some temporary wotkaround packages there while I work on fixing the actual bug properly.
<infinity> nix4me: His packages should solve your problem for now.
<nix4me> ok, i will have a look.  thank you
<nix4me> ive beat google and the forums to death
<infinity> nix4me: If you have a bug, it seems sane to search for it in our bug trackers. :)
<nix4me> yes i agree, at first i though it was my config.  then i started realizing it might be a bug
<infinity> (google indexes Malone eventually, but never fast enough to be of any use for bugs that aren't months old)
<nix4me> that bug is the reverse of what i have
<nix4me> i cant print from windows to ubuntu
<infinity> Oh.... Could you ever?
<infinity> (And I suspect, then, that you're using IPP, not SMB...)
<infinity> And I also suspect that this is a support question, then, not an issue dealing with a bug at all.
<nix4me> hmmm
<infinity> If it is via SMB, though, and not IPP, try those packages.  It can't hurt.
<nix4me> ipp is what im using
<infinity> Then A) I have no clue, and B) Please take this to #ubuntu.
<nix4me> ive tried that, help was useless
<nix4me> thanks anyway
<nix4me> ill keep banging away
<infinity> Well, is this a regression for you?
<infinity> ie: Did it once work, and now doesn't?
<nix4me> it worked in breezy
<nix4me> there are howtos and all
<infinity> You may want to read this:
<infinity> https://lists.ubuntu.com/archives/ubuntu-devel/2006-April/017211.html
<infinity> And perhaps give feedback directly to Martin.
<nix4me> ok
<Mithrandir> mgalvin: thanks
<mgalvin> np
<tseng> Mithrandir: is there anyway of knowing the kernel version from flight5?
<Mithrandir> tseng: short of downloading and looking?
<desrt> -18 ish?
<desrt> tseng; figure out the release date of flight5 and look at the linux-source changelog
<tseng> good idea
<mgalvin> Mithrandir: are there any known bugs and caveats worth noting on the flight 7 tour?
<Mithrandir> mgalvin: there are a couple listed in the announcement.  Apart from that, espresso isn't too happy about installing to drives which currently have LVM on, but nothing more that I know of.
<mgalvin> Mithrandir: ok thanks
<mgalvin> Mithrandir: was the announcment made yet? i didn't see it
<Mithrandir> mgalvin: it might not have made it to u-a, but I know I sent it.
<Fjodor> Can it be considered a bug that I should notify you guys of, that Xlib doesn't like my locale (en_DK.UTF-8)? locale -a reports locales ending in .utf8, and en_DK is there
<sits> ok I'm stuck trying to turn on CUPS debug output
<sits> can anyone tell me what to tweak so the library outputs more detail?
<Coyctecm> hmmm gvim doesn't appear in gnome menu
<sits> Coyctecm: which version of gvim
<sits> and which version of Ubuntu
<sits> (gtk-vim is in Accessories for me)
<Coyctecm> sits: dapper and 6.4.6
<Coyctecm> gtk-vim
<sits> er
<sits> sorry that should have been
<sits> gnome-vim
<sits> or vim-gnome even
<Coyctecm> what's the difference between gtk-vim ang gnome-vim, i haven't noticed anything..
<sits> try checking the description
<omeg> Absolutely gigantic message regarding usplash sent to mailing list :)
<omeg> Ah, it just managed to reach the latest digest.
<Coyctecm> hmm weird
<Coyctecm> fglrx says my card has only 64mb memory
<Coyctecm> radeon x600 pci express
<Coyctecm> this card have 256mb memory
<Coyctecm> dri works fine thought
<Coyctecm> weird
<infinity> omeg: The reason the default usplash image appears "squished" on 4x3 aspect ratio screens is because it's designed for 640x400, not 640x480, since 640x400 is the default we give people.
<infinity> omeg: And, while I don't want to be a jerk about it, the odds of us changing anything this much this late in the game are slim.  I do want to do a "text free usplash" for edgy, though.  I agree that it's the friendlier way to go.
<omeg> infinity: wait, how does that work? Why squish the logo vertically when using a more wide resolution? Wouldn't that mean that you'd need a more tall version of the logo?
<omeg> And it's too bad if something cool like that can't be changed for Dapper anymore. But I think that it would be kind of neat to see that last mock-up I linked to in a future release of Ubuntu beyond Dapper.
<fabbione> omeg: dude learn to format your emails at 80 chars..
<omeg> fabbione: I expect that people's e-mail readers trim e-mails at 80 characters when viewing it in text-only mode.
<fabbione> omeg: wrong, you don't expect.. you write them properly. that emails is unreadable..
<infinity> omeg: No, think of the math.. If the resolution is 10x8, but your screen is 10x10, then the image needs ot be "squished", since it will get "stretched" when displayed.
<omeg> infinity: would it be possible to remove the text from usplash and then just add a "System is starting up..." message above the progress bar (and also position the elements on the screen differently like seen in that other mockup I sent?)
<infinity> fabbione: Content-Type: format=flowed is pretty common these days.
<infinity> fabbione: If mutt still isn't handling it, perhaps it should be taught to.
<fabbione> infinity: than fix bugs in your t-bird pkgs dude :P
<infinity> fabbione: I'm reading his mail in Tbird, works fine...
<fabbione> because that's what i am using..
<fabbione> not here
<fabbione> it looks like all without rewrapping..
<fabbione> veeeery llooooong liiineeeesssssss
<omeg> Above suggestion assumes the new font, same one that's used on the CD splash screen, by the way, since that was supposed to be the change in the first place.
<infinity> fabbione: Bizarre.  Screenshot?
<fabbione> infinity: sure.. in a sec..
<infinity> omeg: Yeah, I'll see if the font change is possible.  usplash/bogl is picky about what sorts of fonts it likes.
<omeg> It's too bad that it's not a monospace font, which was reported earlier to be easier to implement.
<infinity> omeg: The "remove all the text" change is simple enough to do, but simple isn't the point, the point is that we're way too late for drastic interface changes.
<omeg> It's still a pretty easy font, though. Just letters with two pixels space between them.
<infinity> omeg: To be fair, the current font isn't monospace either, I just WISH it was.
<omeg> Yeah, that's right.
<omeg> Still, what about just removing the font and not adding a "System is starting up..." message?
<infinity> omeg: monospace tends to be much more readable and easy to line up and parse for "repetitive text" of the sort that boot messages are.
<fabbione> infinity: on people..
<omeg> To be honest, my first interest is just getting that awful font out of the screen I see daily. :P The fact that many people don't want or need to see the startup logging is a second issue to me.
<omeg> infinity: I agree about the monospace issue.
<omeg> I have made a monospace font which I offered earlier, but people thought it was a little too small.
<infinity> omeg: My biggest issue isn't necessarily with vertical font height, but with "spindly" versus "partial bold".
<infinity> The latter would be prefereable to me, since the screen as it stands has very rich colours, and a spindly font looks out of place.
<infinity> OTOH, fixing the screen to be less saturated would fix that problem too.
<infinity> (We were supposed to have new artwork for usplash for dapper, but that didn't seem to pan out..)
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/zeta.png <-- here's that font I was talking about.
<omeg> I'll make a bold version if you're interested.
<Amaranth> wow that's tiny
<omeg> It was originally designed for a home-made RPG that I was working on. It was to be in 320x240. So yeah, it's a tad tiny. :)
<omeg> I'm going to try and make it one pixel higher and bold...
<infinity> Bolding it will probably make the whole thing about 2px wider (if you want it to still be readable), so another 2 or 3 px higher should round it out nicely.
<infinity> But I'm not font design expert, or I would have made my own ages ago.
<fabbione> infinity: you are a GENIUS!
<fabbione> thanks
<omeg> infinity: yeah, just about that. I'll experiment around a little.
<omeg> Capitals are done...
<infinity> omeg: The other unfortunate thing is that bogl only tends to like fonts of the BDF variety (which is why I didn't just switch to one of the many TTF fonts out there that could have worked fine)
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/zeta_8x5.png <-- 8x5 version of Zeta. Now making a bold version.
<omeg> BDF?
<infinity> BDF is an X font format.
<omeg> I don't really know how to make font files. I only created this font in Windows FON format because there was a simple editor that I could use.
<omeg> I don't know how to make a TTF, let alone a BDF. Maybe the FON file can be converted somehow?
<infinity> FON is Adobe Type1, right?
<infinity> I might be able to work something out.
<omeg> I'm not sure. As far as I know, it's a very old font file type that's been around in early Windows versions.
<infinity> omeg: xmbdfed is a (ugly, but functional) BDF bitmap editor.
<infinity> omeg: Since your font is pure unhinted, unaliased bitmaps, it might be fairly simple to slap it in there...
<infinity> Maybe.
<omeg> I'll try it. Can't be worse than Pushy, which I think was the name of the font editor I used for Windows.
<omeg> No, Softy was the name.
<omeg> I just opened it while having the picture in the background and copied it manually, which takes some time, but seems like the only real way to do it. :P
<omeg> The M is so difficult...
<omeg> By the way, isn't there a different way of showing the logo in usplash? It's kind of too bad that you're distorting a logo like that. I like the way it looks on black.
<infinity> -EPARSE
<infinity> I don't like the current artwork, but if by "distorting", you mean the height change between aspect ratios, the only fix for that is including two sets of artwork, one for 640x400, and one for 4x3 screens.
<omeg> Aren't most screens still 4:3?
<infinity> omeg: Pretty much all (but widescreen) screens are 4:3, but not all resolutions are 4:3.
<infinity> omeg: So, 640x400 on a 4:3 screen, means the original art has to be "squished", so it "stretches" again and looks right on a 4:3 screen.
<infinity> omeg: Think of your BIOS logo (which is at 640x400 on a 4:3 screen)... It's the same as usplash.
#ubuntu-devel 2006-05-12
<omeg> Aha. I always thought it was 640x480 by default.
<Amaranth> infinity: 640x480?
<Amaranth> 640x400 is 8:5
<infinity> Yes, I know.
<infinity> And it's also the default resolution for the EGA/VGA BIOS of most PC video cards, and the default resolution of vga16fb.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/zeta_8x5-bold.png <-- here we go.
<omeg> Now to make a mock-up of how it would look in usplash.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/_usplash_misc_7.png <-- hmm... I kind of liked the font also used on the CD a bit better. It might be nice for the logging, but most (including myself) believe we should not do logging anymore.
<omeg> *CD splash screen
<infinity> As I already said, the logging won't be going away for dapper.
<infinity> And even if it goes away in edgy, you will be able to optionally turn it back on.
<omeg> Okay... so it's not possible to get rid of the logging before release?
<infinity> I doubt it'll happen.
<omeg> What about the possibility of making the change and then installing it into the system at a later update?
<infinity> That's even worse. :)
<omeg> Well, I guess I can kind of agree with that...
<infinity> We don't make UI changes to stable releases, and we try not to make them after the UI freeze (which is long past)
<omeg> What if I supplied you with a BDF font somewhere in the next few days?
<infinity> And, other than the "it'll irritate people and cause a time consuming flamewar" issue, there's also just the issue that people like me need to spend the next 3 weeks fixing as many bugs as possible, not implementing feature changes.
<infinity> If you supply me with a less crap font, I can get that in with minimal effort on my part (and minimal impact on the UI), so I don't see that one being an issue.
<omeg> I'll try my best to tame that xmbdfed thing you were talking about, then. Since my main issue here is the fact that, well, I find the current logging font at startup to be really ugly.
<infinity> (As for the mockup you just gave me, I suspect that the "text-free" version will be REALLY text-free... "System is starting up" is redundant, when everyone knows what the progress bar means)
<omeg> Maybe. I think that's up for debate. I don't think it's entirely illogical to state what's happening.
<infinity> I suspect I'll just have a logo and a progress bar... And maybe, for the first 5 seconds, a "F1: boot messages, F2: text-mode" hint at the bottom.  Or something.
<infinity> I've not put too muhc thought into it, since the latter part (allowing keystrokes to do something) requires real effort.
<infinity> Right now, the keyboard passes straight through to init.  Which is actually really handy.  So, trapping one or two keys, while passing the rest through, will require some thoughtful coding.
<sits> does anyone have a usb printer?
<sits> I have a small test
<omeg> infinity: I'll try to come up with some things for future releases. I should really have checked in before UI freeze, though, I guess. :)
<infinity> omeg: I'm open to plenty of suggestions for edgy (though, I'd prefer not to spend much time thinking about them until after June 1st) :)
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/_usplash_misc_8.png <-- what do you think of this?
<omeg> The font, that is.
<omeg> What is Edgy, by the way? The stable release that comes after Dapper?
<infinity> omeg: Yeah, Edgy Eft.  Ubuntu 6.10.
<infinity> omeg: That font's probably a bit too large, I'd guess, to get all the text in horizontally.
<omeg> Hmm, you're right. Maybe if it has 1 px spacing instead of 2?
* infinity shrugs...
<infinity> Experimentation++
* infinity decides to wander off and do "weekend work" instead of "work work".
<infinity> omeg: Mail me (adconrad@ubuntu.com) when you have more stuff to look at.
<infinity> omeg: Bonus points if one of those things is a font. :)
<infinity> omeg: You're only the third person in the last 3 months who's offered a new font, so I'm becoming skeptical. :)
<infinity> omeg: Deliver that pixel font of yours in a useable state, and you'll be my new best friend.
<omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/_usplash_misc_9.png
<omeg> Thanks. I'll try to make a BDF font out of it.
<mdke> any asian font geeks still around?
<neuralis> hmm. my dapper just broke very strangely.
<mdke> or perhaps even anyone who knows even something vague about fonts?
<kagou> hi
<czr> hi. a bit ot question. is it easy to setup a cross-arch toolchain (gcc/libc) inside ubuntu (5.10)?
<czr> (running on i386, want to build x86-64 stuff)
<zakame> hi all
<infinity> czr: "apt-get install libc6-dev-amd64" and compile with "gcc -m64"
<pygi> please do see and comment http://students.mimuw.edu.pl/~mb219407/ubuntuRPG.html
<pygi> thanks :)
<Mithrandir> pygi: I'd love to see it real-time, but apart from that, interesting.
<pygi> Mithrandir: I suggested real-time, but turn-based on combat :)
<pygi> Mithrandir: problem is who would mentor that?
<Mithrandir> pygi: no idea; prefereably somebody with some gfx experience, etc.
<pygi> Mithrandir: indeed :)
<ajmitch> pygi: having developers battling it out?
<pygi> ajmitch: hehe :)
<zakame> ooh!
<pygi> I indeed don't know...I'll let you decide :)
<infinity> Ooo, I could run around killing hordes of Mithrandirs and banging infinities on the head with my mace.  Count me in.
<pygi> ok, 3 votes by now :(
<zakame> indeed
<Mithrandir> I'll be chucking live cds at anybody who dares come near me?
<Mithrandir> and have an armour made of amd64 dualcores?
<infinity> Sounds about right. :)
<highvoltage> Mithrandir: in that case, you'll have lots of people running to you :)
* zakame would be one of them
<infinity> highvoltage: Not if they're razor-sharp LiveCDs that decapitate you.
<Mithrandir> they won't run for long, at least. :-P
<pygi> more votes? :P
<highvoltage> infinity: probably not :)
<pygi> for or against? :P
* pygi knows ajmitch is against :P
<highvoltage> Mithrandir: if you throw out Windows XP cd's, perhaps we'd keep our distance then
<ajmitch> for an ubuntu SoC project, I think it's crack :)
<highvoltage> Mithrandir: but we'll also be putting in more effort to kill you
<infinity> Yeah, I don't think it's a sane SoC project.
<pygi> but other things are higher priority I believe, so he's right :)
<infinity> We can't really claim we need this feature in Ubuntu.
<pygi> infinity: agreed :)
<infinity> But it's a cool project for someone to do in non-sponsored space.
<Mithrandir> I want somebody to sit down and write a clone of syndicate or syndicate wars.
<infinity> Especially if I get to crush opponents with my pedantry, and wear an armour of +12 build logs.
<pygi> :P
<highvoltage> you can have a level with 10000 bugs you have to kill, to save dholbach from insanity
* pygi taking notes, for some more sane days :)
<zakame> don't forget the X god :)
<pygi> infinity: have you looked over the samba applications?
<infinity> Well, the comments on the GUI config tool seemed to end up in it being a "not really necessary" spec.
<infinity> What was the other one?
<pygi> well, there are several ones
<infinity> Oh boy.  Links?
<pygi> lemme go check it out :
<pygi> :)
<pygi> none are good by my opinion tho :P
<pygi> http://code.google.com/soc/ubuntu/app.html?csaid=io.alex.2002@gmail.com:0b88daa9:90900c7c
<pygi> one
<pygi> http://code.google.com/soc/ubuntu/app.html?csaid=sed.nivo@gmail.com:0450af38:273c59fb
<pygi> two
<pygi> third you saw probably
* infinity kicks Firefox.
<infinity> LOAD FASTER.
<pygi> :)
<pygi> not so much good applications this year I am afraid :(
<infinity> I don't suppose we have any students interested in running more underwater fiber to Australia as their SoC project?
<pygi> but those we selected are good
<pygi> no, indeed :)
<ajmitch> I could try & do that
<ajmitch> but I doubt you'd care about faster connectivity to NZ
<infinity> Bah, there's no one worth talking to in NZ anyway. :P
<infinity> Oh, this isn't bandwidth anyway, it's broken Google.
<infinity> Awesome.
<infinity> The server encountered a temporary error and could not complete your request.
<infinity> Please try again in 30 seconds. 
* infinity waits.
<infinity> pygi: Meh.  It's not loading for me.
<infinity> pygi: Do they link to specs in the wiki or something?
* pygi check
<pygi> infinity: nop, but I could pm you applications?
<neuralis> infinity: i don't think it's just .au; it's not loading here either.
<infinity> pygi: Sure.
<pygi> tell  me when you are done with this one
<pvanhoof> guys ... update-manager (which runs as root) has a very critical security problem
<pvanhoof> I don't understand howcome nobody has yet written a malware software for it, please ask me .. I filed it as a non-public bug #43328
<pygi> pvanhoof: please subscribe me to the bug
<pvanhoof> I'm certain I can cook a prove of concept for this one. For any gtk+ (or maybe even x11) developer this wouldn't be very hard at all
<pvanhoof> s/prove/proof
<infinity> pvanhoof: The builtin terminal is intenationally not read-only for the (now rare, but still real) case where a maintainer script will prompt on stdout/stdin without using debconf.
<infinity> pvanhoof: Currently, the assumption is that people running update-manager have full admin rights, so it's not really a security bug.
<pvanhoof> infinity, shall I prove it by writing a little tool that listens for the user-passwords?
<pvanhoof> I can do this in 50 minutes
<infinity> pvanhoof: I'm not sure what that would prove.
<infinity> pvanhoof: Being able to listen for user passwords is an inherent problem with sudo and friends in general.
<highvoltage> pvanhoof: as soon as you write a tool that listens for passwords, there'd be millions of ways you can get root on a system
<pvanhoof> that I can run the tool and get it to become root, then only thing I'd have to do is sending keytrokes to it. I'm certain the terminal widget has security issues
<infinity> pvanhoof: There's not much you can do to fix that except to never allow a user to escalate their privileges.
<infinity> pvanhoof: It's assumed that users who have sudo privileges also practice reasonably safe software practices.  If that's not the case for you, you're handing out sudo to the wrong users.
<pvanhoof> look, first of all it's absolutely not good to run a gtk+ application as root .. but lets say that's okay
<infinity> (For instance, you do NOT give sudo to everyone in a university computer lab so they can use update-manager, you just do updates remotely via SSH behind their backs)
<pvanhoof> then second of all .. the program (written with gtk+ libraries) that runs as root has a terminal which gives access to send characters to a root-console
<pvanhoof> and that terminal isn't set read-only
<pvanhoof> and I can make the tool being run in that terminal interrupt by sending ctrl+c
<infinity> Yes, but the root console is started by someone who HAS ROOT PRIVILEGES.
<infinity> This is no different than you typing "sudo su - root" in a gnome-terminal.
<pvanhoof> the password I have to enter is the same as the password of my user
<pvanhoof> I don't understand why ubuntu doesn't develop a helper program for this 
<pvanhoof> and pipes that output to a read-only widget
<Mithrandir> how would using a helper program help?
<pvanhoof> that would be perfectly secure
<infinity> Because if it's read-only, how do you interact with the terminal?
<pvanhoof> because that way the gtk+ application wouldn't have to be root Mithrandir 
<infinity> (Note that sometimes, you WILL need to interact with the terminal, that's one reason why it's there)
<highvoltage> you'd still have your user password, you could just open a terminal and type sudo su -, like infinity pointed out :)  so how would it be more secure?
<infinity> The fact that Ubuntu has tried really really hard to remove al postinst prompting may have spoiled you a bit, but plenty of .deb packages still prompt in maintainer scripts.
<pvanhoof> then patch the apt-get libraries so that you never have to interact with the terminal? the fact that you have to interact with the temrinal simply tells me the complete design is wrong
<Mithrandir> pvanhoof: if you can interact with a user's X session, you can listen for any keystrokes.  How's that news?
<pvanhoof> highvoltage, using a helper tool you wouldn't have to use sudo
<Mithrandir> pvanhoof: it's not apt, it's not dpkg, it's maintainer scripts.
<infinity> pvanhoof: apt-get has nothing to do with a PACKAGE using the maintainer scripts to interact with the user.
<pvanhoof> don't allow such scripts in your packages? It's ubuntu people who maintain the packages
<infinity> pvanhoof: And as pointed out, if you have sudo access and you ever intend to use it at all, for anything, if I'm running an application in your X session, I can snarf your password.
<pvanhoof> this is silly finger pointing. If you create a distro, you are responsible for the packages
<infinity> pvanhoof: This is why you don't run untrusted software on a trusted account.
<pvanhoof> yes, so why do you guys allow this ?!
<Mithrandir> infinity: not only that, you can drive more or less any application too.
<pvanhoof> people do run untrusted software on trusted accounts 
<infinity> pvanhoof: Then they shouldn't.  This is inherent in how X works.
<Mithrandir> I don't think we'll rework X today at least.
<pvanhoof> again, finger pointing. If you'd simply use a helper application that can ONLY upgrade the system, you wouldn't have to put that sudo thing there
<highvoltage> pvanhoof: is there any system in the world that doesn't let you run untrusted software on a trusted account?
<ajmitch> this is why we need SEX - security-enhanced X
<infinity> pvanhoof: And the any number of other things you may want to use sudo to do?..
<highvoltage> hehe
<ivoks> pvanhoof: ? only root can upgrade system 
<pvanhoof> ivoks, correct, but now there's a ui tool that also runs root and to which I can send keystrokes .. and that tool even has a root terminal non read only
<pvanhoof> and it's predictable .. so it's ten times worse than running su - in a xterm
<ivoks> pvanhoof: and this is something you can do if you run apt-get dist-upgrade?
<ivoks> pvanhoof: s/can/can't/
<pvanhoof> ivoks, no it's something I can invoke from another application
<pvanhoof> ivoks, right but that isn't invokable by an application, nor predicatable
<pvanhoof> this is
<ivoks> what's not invocable?
<pvanhoof> when I run a xterm and I do a su -, I know as an admin I might be in danger
<czr> thanks infinity
<ivoks> ok
<pvanhoof> but this tool , I can run it from an application
<pvanhoof> and I can send it keystrokes from that application
<infinity> pvanhoof: And same for update-manager, which is WHY we only allow admin users to do it.
<pvanhoof> and once it runs, it has a writable terminal
<ivoks> pvanhoof: but when you run update-manager you know you run it as root
<ivoks> pvanhoof: so, again, you know you are in risk
<infinity> pvanhoof: update-manager isn't SUID or anything.  You're still being asked to authenticate with sudo (well, gksudo).
<pvanhoof> infinity, 99% of the desktop computers have one or two user accounts .. and the setup does not let you make user accounts that don't have this possibility
<pvanhoof> infinity, and since the password is the same as the one the user must enter, I can very easily know that password
<infinity> pvanhoof: Erm, what?  New users created with the GUI user admin tool, or from the CLI with adduser are NOT in the admin group.
<pvanhoof> most people will enter the same password for every question, and I can mimic the dialog box
<infinity> pvanhoof: You're just talking about the inherent scariness of sudo in general here, this has nothing to do with update-manager at all.
<_ion> User stupidity cannot be fixed with software solutions.
<pvanhoof> for example I can replace a menu-item, mimic the dialog box and launch the original application and send the password to the gtkentry
<pvanhoof> all this can be done in a little script
<infinity> pvanhoof: And it's an attack vector we're aware of, and one we really can't do anything about without going back to the days of pure user/root separation that pisses people off cause they can't get anything done.
<ivoks> pvanhoof: and you can't do this with a shell app?
<pvanhoof> and then I have an application with a root termal not being read-only
<infinity> pvanhoof: sudo is a tradeoff, and we all know it.
<Mithrandir> pvanhoof: you still need to get your exploit onto the user's machine.
<pvanhoof> infinity, if you don't add that sudo entry .. and if you create a little helper tool that has SUID root priveledges but can ONLY upgrade the system
<pvanhoof> you wouldn't have this problem
<pvanhoof> and creating such a tool is not difficult
<pvanhoof> and you can pipe commands to such a tool, while it's being run as a suid tool
<_ion> Update/] ] 
<_ion> Whoops.
<pvanhoof> and that pipe can be made VERY secure
<_ion> Update-manager isn't the only piece of software that needs root privileges.
<pvanhoof> _ion, then do that for all the softwares that need root priviledges
<infinity> pvanhoof: This isn't the only reason users have sudo access.
<infinity> pvanhoof: We made a conscious decision to give the first user sudo access and disable root's password.
<_ion> pvanhoof: I'm sure the Ubuntu folks appreciate your patches that make software more secure.
<pvanhoof> that is just telling me: because it's a lot of work: we prefer to introduce a security problem
<infinity> pvanhoof: If you want it setup your way on your machines, set a password for root and remove the sudo config.
<ivoks> pvanhoof: suid isn't perfect solution either
<pvanhoof> infinity, I know I will not run untrusted softwares ... but common users will
<ivoks> pvanhoof: you would have to suid apt-get, or dpkg
<highvoltage> update-manager isn't something that you'd want suid anyway
<ivoks> pvanhoof: and, again, you have security issue
<pvanhoof> infinity, for my system this isn't important, but for normal people (which is the target audience of ubuntu, right?) it is
<pvanhoof> ivoks, that is wrong, you probably do upgrades and etc using a apt-get library
<pvanhoof> or a dpkg library
<pvanhoof> and since you can specify which tools to run and how
<pvanhoof> even that wouldn't be a problem
<infinity> pvanhoof: Actually, no.  update-manager does some stuff as root that isn't directly apt-get related.
<pvanhoof> if I from a user tool pipe 'e' to a SUID application
<infinity> (fiddling with sources.list, running dist-upgrade recipes, etc)
<pvanhoof> and cause of that 'e' the application will launch apt-get install bla
<infinity> update-manager NEEDS root.
<ivoks> pvanhoof: but, what will prevent you from installing my .deb package wich will sniff your password?
<infinity> Not everyone on a machine NEEDS to be able to run update-manager.
<pvanhoof> infinity, even updating such a text file can be made secure
<infinity> If.  You.  Don't.   Trust.  Your.  Users.  Don't.  Give.  Them.  A.  Trusted.  Account.
<infinity> pvanhoof: If they have the privileges to update sources.list, they have the privileges to add a source to it and install malware.  You lose.
<pvanhoof> ivoks, if you don't allow untrusted changes to the sources.list file, how can they isntall one?
<ivoks> pvanhoof: dpkg -i ?
<pvanhoof> infinity, then don't give the normal user account those privileges
<pvanhoof> ivoks, they are a user , they can't install using dpkg -i
<infinity> pvanhoof: Now we're in circles.  I just told you not to give them those privs. :)
<pvanhoof> only the suid root tool can do that
<infinity> pvanhoof: OTOH, if you want them to be able to update the system, they need those privs.  Catch-22.
<pvanhoof> infinity, you can allow the suid root tool to make specific changes, not any change
<infinity> pvanhoof: There's no way to allow someone to do something without allowing them to do it.
<ivoks> pvanhoof: so, they won't be able to upgrade?
<pvanhoof> infinity, you could for example make a command like: "change mirror to Belgian"
<ivoks> pvanhoof: I'm sure, you understand, we are talking about admin user here?
<pvanhoof> infinity, and it would upgrade the sources.list file to the belgian mirrir
<Mithrandir> pvanhoof: uh, how about adding custom mirrors, which people tend to do?
<infinity> pvanhoof: And why would a user who you don't trust to install new software NEED to change the mirror list at all?
<pvanhoof> ivoks, if you really need to trust an admin user, then the ubuntu installation should prompt and warn for that during the installation procedure
<infinity> pvanhoof: Either you trust them to install software, and they have (transitive) root.  Or you don't.
<ivoks> pvanhoof: it does
<pvanhoof> Mithrandir, that is something a person who knows how to use the root account should do
<pvanhoof> ivoks, howcome it didn't let me add more NORMAL users then?
<infinity> pvanhoof: So, for the "regular home user with one user on the system", you're suggesting they should all employ someone (you?) to be root on their computer whenever they need it?
<ivoks> pvanhoof: it didn't, but it has a note that you should do that after install
<pvanhoof> or why wasn't that the default and the last account created, with a big fat warning, the admin account?
<infinity> pvanhoof: Because they're too stupid to use their own computers?
<infinity> pvanhoof: A compelling argument, but not one that users are likely to agree with.
<pvanhoof> well then, just wait for ubuntu to become more popular .. you'll see the malwares that abuse this with 1000ths
<ivoks> pvanhoof: i understand our concern, but people need a way to administer computers
<ivoks> eh...
<pvanhoof> ivoks, then stop finger pointing and make softwares in a secure way that do this
<ivoks> pvanhoof: you don't understand
<pvanhoof> I do
<ivoks> pvanhoof: malware would do harm in shell as in GUI
<pvanhoof> I'm one of the guys that make the ubuntu softwares. I TELL you it's NOT difficult and it IS possible
<ivoks> you can't force people not to install malware
<ivoks> pvanhoof: sure it's possible
<ivoks> pvanhoof: but you have to get user to install malware
<pvanhoof> so why don't you guys do it?!
<ivoks> pvanhoof: it won't install by it self
<Mithrandir> pvanhoof: if you can come up with a non-movie attack scenario and patches to fix it, I'm sure they'll be appreciated.
<ivoks> pvanhoof: you don't listen to anything other people tell you, right?
<pvanhoof> I am listening, but right now ubuntu implements the exact same type of security problems the windows platform has
<ivoks> it's not malware, virus or worm if user has to install it
<pvanhoof> and ubuntu simply fingerpoints just like how microsoft fingerpoints
<pvanhoof> it is not the solution
<ivoks> pvanhoof: no, these two are not a like
<ivoks> pvanhoof: ubuntu starts all users apps with non-root privileges
<ivoks> pvanhoof: that's not something windows doo
<ivoks> pvanhoof: if you take a look at windows problems
<ivoks> pvanhoof: 99% of them aren't cause of instalation of programrs
<ivoks> pvanhoof: but holls in explorer, outlook, etc
<ivoks> pvanhoof: wich run as admin user
<ivoks> pvanhoof: this is not the case with ubuntu
<pvanhoof> percentages aren't very important for security issues. That one security problem, can be so major it will defect every ubuntu install
<pvanhoof> running gtk+ applications as root is not smart .. and putting a writable terminal inside that tool is , well , insane
<fabbione> pvanhoof: since you make Ubuntu, mind to tell me exactly what is your LP account?
<azeem> so is there an analysis how many packages still use the terminal for i/o during installation?
<fabbione> pvanhoof: i am curious to see what you do for it
<pvanhoof> fabbione, I don't 'make ubuntu', I develop softwares, my gnome foundation e-mail is pvanhoof@gnome.org, feel free to mail me
<azeem> I think OEM packagers should get told NOT to do this if they want their packages to work
<pvanhoof> fabbione, and I'm not into that type of discussions
<infinity> fabbione: That would be https://launchpad.net/people/pvanhoof
<ivoks> eh, come on guys...
<pvanhoof> indeed, come on
<fabbione> infinity: thanks
<infinity> 03:20 < pvanhoof> I'm one of the guys that make the ubuntu softwares.
<infinity> Come on indeed.
<pvanhoof> azeem, indeed
<infinity> Supporting your position with a (false, no less) power play is fun!
<pvanhoof> azeem, just tell the oem packagers not to do this
<azeem> infinity: he said, he's one of the upstream GNOME people
<ivoks> :)
<fabbione> pvanhoof: did you come here to troll or something?
<azeem> (thought it wasn't very clear)
<pvanhoof> pvanhoof, I came here to tell update-manager has a serious security issue
<pvanhoof> well, I didn't came here, I just mentioned it
<pvanhoof> and people started asking me about it
<ivoks> pvanhoof: ok, but with an attacking attitude
<azeem> pvanhoof: the developers have analysed your report
<pvanhoof> ok. which is fine for me .. I was just responding the questions being thrown at me
<ivoks> and insted of translating desktop guide, i'm flamimng here :)
<infinity> pvanhoof: Can you actually obtain a root shell through update-manager itself?
<infinity> pvanhoof: Ctrl-C shouldn't give you one, since it's not running an interactive shell in the first place.
<pvanhoof> I don't yet know that
<infinity> pvanhoof: That will just cancel the current operation and leave you with a non-functional terminal.
<pvanhoof> but I'm more or less certain it would be possible. Also given the fact that there's a lot bugs in that widget
<infinity> pvanhoof: So, your complain seems to be with gksudo itself, which one would hope invokes X tricks to block keyboard grabs.
<pvanhoof> and a lot known and unknown bugs in any gtk+ widget
<pvanhoof> gtk+ was never designed with security in mind
<infinity> pvanhoof: Which then leaves us with the attack vector of "I can spoof a gksudo window to ask a user for their password"
<infinity> pvanhoof: Which is a valid attack vector for ANYTHING, and also requires the user to INSTALL and RUN your spoofing app.
<pvanhoof> gksudo , because it only asks for the user-password, can be tricked .. and since its also a gtk+ application it can probably be cracked as well
<infinity> pvanhoof: If the embedded terminal is insecure, that's a bug.
<infinity> Anyhow, I'm done arguing.  You can argue with mvo in the bug log instead, I guess.
<pvanhoof> sure .. but if ubuntu wouldn't use sudo, but a helper tool that runs with root priveledges but has a very limited interface (using stdin: a pipe): it wouldn't be a security problem
<infinity> But without a proof of concept, this all seems rather vague and hand-wavey.
<pvanhoof> well, just wait for a buffer overflow or something like that in the terminal widget. Which isn't very hard to find
<infinity> Yes, we have such bugs all the time, and we fix them.  Oddly enough.
<pvanhoof> or in the application being launched in that terminal
<infinity> Doesn't change the fact that you'd have to run something specifically designed to exploit it for the bug to be a problem.
<pvanhoof> you are done agruing about this, you said, infinity. If you want to do this in a constructive way .. I'm available
<ivoks> bye all
<pvanhoof> it's a security problem, and a proof of concept will probably some day be build. I have more important things (and certainly more interesting things) todo than to proof something which is basically .. basic knowledge
<pvanhoof> and something that is known for years .. perhaps check out the security warnings on a tool (which I once wrote) xsu, gnome superuser, etc
<pvanhoof> a long time ago when I was naive and yough
<pvanhoof> young
<Mithrandir>  * Security
<Mithrandir>  Gnome Xsu 2.0 uses the standard su binary to gain it's root access. This way,
<Mithrandir>  all security issues should be solve
<Mithrandir> +d.
<pvanhoof> which wasn't true
<pvanhoof> and I don't recommend using gnome xsu 2.0
<Mithrandir> it's what the description currently says.
<pvanhoof> I gave maintainership to Mark Finlay, who died a few years ago
<pvanhoof> and I stopped developing that little tool, for it shouldn't be used
<pvanhoof> the main security problem with gnome xsu is that is sends the password over a hidden vte terminal widget
<pvanhoof> and then of course it does try to clear that memory and destroy the widget asap, but still it's insecure (of course)
<Mithrandir> if you have access to a user's X terminal, you can find out what's going on there.  It's really as simple as that.
<pvanhoof> I agree, but the update software does not need to run a tool using su or sudo
<pvanhoof> a tool that will do this can be developed, and put suid root. If that tool is secure (which is far more easy than making a sudo-entry in the sudoers file secure), there's no problem
<Mithrandir> you're aware that the first user is allowed to execute anything, right?
<pvanhoof> in that case it would only be allowed to execute that suid root application and feed it commands via the stdin, and those commands would always only cause upgrade procedures
<pvanhoof> which is legal for the first user
<pvanhoof> just don't introduce security problems in that tool, of course
<pvanhoof> that would be catastrophical of course 
<Mithrandir> I still don't see why you think this is more secure as it doesn't address the real problem (X), but just changes one of many tools which require root to function properly.
<pvanhoof> because there's no more sudo or su which can run anything.. you can only run that tool (which is +s indeed)
<pvanhoof> and that tool (because it's programmed that way) can only run commands it is designed to run
<pvanhoof> or perform procedures or etcetera
<Mithrandir> I see it as lots of complexity for not much gain -- you'll have a lot more applications which have to be run as root.
<pvanhoof> and whatever X tries .. only the commands being fed to that tool will be accepted. And those commands are not like: run this program
<pvanhoof> no the commands are: upgrade, switch mirror, install package x
<pvanhoof> Mithrandir, well, you gain not having to secure that first user cause of the sudoers file
<pvanhoof> which is far more complex it seems
<pvanhoof> because of X problems, indeed
<Mithrandir> uh, no.  The first user still needs to be able to, say, run synaptic or network-admin
<pvanhoof> you can build-in such commands in the tool
<pvanhoof> synaptic can also instruct the same tool
<pvanhoof> you wouldn't run synaptic as root
<Mithrandir> synaptic is able to, and needs to be able to add any repositories.
<Mithrandir> so you've just abstracted the attack one step away.
<pvanhoof> well, I'd make selecting specific repo's possible, but not adding custom ones
<pvanhoof> if you want to add a custom one, I'd tell the user to gain real root priveledges
<Mithrandir> synaptic needs to be able to add custom ones.
<pvanhoof> and specific ones can have a public key etcetera
<pvanhoof> well, you'd loose that functionality .. 
<Mithrandir> that's not acceptable.
<pvanhoof> but then again, I don't know a lot normal users who'd care
<pvanhoof> and the expert users know how to become root anyway
<pvanhoof> and face it, those people use apt-get from a terminal, not synaptic
<Mithrandir> some do, some don't.
<pvanhoof> sure but, making ubuntu insecure because some experts want to use synaptic to add a custom mirror?
<pvanhoof> It's not a valid reason anymore
<Mithrandir> saying that "since this functionality is impossible to secure, we'll remove it and force people who need it to use a terminal" is not acceptable.
<pvanhoof> synaptic can also work via that tool
<pvanhoof> well then, you could make it possible
<pvanhoof> by allowing the tool to accept a custom url
<Mithrandir> other examples are disk-conf or user-admin
<pvanhoof> but for example would the tool try to get a public key 
<pvanhoof> and return a question to the user like: are you sure you want to accept this key
<Mithrandir> apt already does that, but that doesn't help you at all.
<pvanhoof> true
<Mithrandir> how many people would say "no"?
<Mithrandir> how many people do you know who checks SSL certs?
<pvanhoof> yes, I agree. which is why I wouldn't make that possible
<pvanhoof> but if its a key feature, even that would be possible
<pvanhoof> and it would be at least more secure
<Mithrandir> so you'll remove the ability to add system users, partition disks, change network settings, etc because you can't secure it?
<pvanhoof> all those features are features for the real administrator .. so
<Mithrandir> s/it/them/
<pvanhoof> if such a person is needed
<Mithrandir> who is the real admin on a single-user system?
<pvanhoof> then it shouldn't be the first/default user created
<Mithrandir> it seems like you want to secure the system from the admin itself.
<pvanhoof> but the setup procedure should ask for normal users first
<pvanhoof> and then ask for the administrative user last
<Mithrandir> so you argue.  We disagree.
<pvanhoof> Mithrandir, okay, then ask during the setup procedure: is this a single user system? and then warn about those priveledges
<Mithrandir> not acceptable.
<Mithrandir> we want to ask as few questions as possible
<pvanhoof> Well, then you have the same security issues Win XP has, which implements the same security problem
<HrdwrBoB> yes.;
<Mithrandir> no, you don't.
<HrdwrBoB> it has a person on the other end.
<HrdwrBoB> that's an inherent security risk
<pvanhoof> Mithrandir, I can imagine muiltiple users having the priveledge to upgrade the system, or the non-admin user or a normal-user having the priveledge to upgrade the system
<Mithrandir> if you don't see the difference between "run everything with administrative priviledges whether it needs it or not" and "ask for (the users) password when priviledge escalation is needed", I don't think this discussion is going anywhere.
<pvanhoof> and that doing the tasks you described shouldn't therefore also be a priveledge for that same user
<HrdwrBoB> pvanhoof: ... you can do that now
<HrdwrBoB> restrict sudo access to update-manager
<pvanhoof> HrdwrBoB, right, and cause of that .. there's a security problem
<Mithrandir> so your design will protect against the case of "somebody getting access to update-manager, but not root on the system".
<pvanhoof> Mithrandir, correct , but then you make it one step more easy to secure the entire system. The tasks you mention aren't common tasks
<pvanhoof> a common task is running openoffice and writing an email
<pvanhoof> such a user doesn't need to repartition the drive
<Mithrandir> then that user won't be an admin user.
<pvanhoof> Mithrandir, the current installation procedure of ubuntu does not help the person who installs the operating system with that
<pvanhoof> so I can assure you for 80% of all installations, it's at this moment the same user
<HrdwrBoB> either a) they are a single user machine and they should have access to everything because to do otherwise is a PITA for the user
<pvanhoof> probably more
<HrdwrBoB> or b) they are a non priveleged user, in which case, there is no issue
<HrdwrBoB> EOF
<Mithrandir> pvanhoof: did you know that 73.2% of all statistics are made up on the spot?
<pvanhoof> Mithrandir, which is why I said: probably
<pvanhoof> I don't know that statistic , but I'm more or less certain about it
<Mithrandir> be honest, you're guesstimating numbers.
<pvanhoof> is it worth the risk? What if tomorrow somebody does write a poc ?
<HrdwrBoB> so you're saying you don't trust people to partition their disks either
<pvanhoof> HrdwrBoB, I trust a priveledges account to do that .. but not the standard account. It doesn't have to do that
<HrdwrBoB> ... so again
<HrdwrBoB> you're back to standard roiot/normal user practise
<pvanhoof> on the standard account, people work. Which means they use the internet, they read email and they launch applications and click on buttons like: [Yes] 
<HrdwrBoB> which, as has been established, is not good for normal users
<HrdwrBoB> which apparently make up 80%
<Mithrandir> users added by users-admin won't be members of group admin by default, if you add them to a group whose description is "Executing system administration task" you better understand what that means.
<highvoltage> but when the browse the web, read mail, they're not running firefox or whatever with sudo, so what's the problem?
<pvanhoof> Mithrandir, so why not create two users during the installation procedure, and explain the difference?
<Mithrandir> pvanhoof: so you're saying that you want the full separation of root/user.  That's trivial to do; sudo passwd root ; sudo rm /etc/sudoers 
<Mithrandir> because people have trouble relating to it, they forget passwords, etc.
<HrdwrBoB> pvanhoof: because it's supposed to be EASY 
<HrdwrBoB> not HARD
<pvanhoof> highvoltage, because as that user, I can let an application launch that gksudo
<highvoltage> but why would a user with admin rights purposely run gksudo firefox?
<pvanhoof> highvoltage, a user who downloads some malware and tries to install it (accidently) or runs it, allows the tool to use gksudo
<HrdwrBoB> highvoltage: if they had severe brain damage
<pvanhoof> and that tool can abuse the design problems of X
<highvoltage> HrdwrBoB: so how would a root user change that? then they'd just be prompted by gksu, and the same thing will happen
<pvanhoof> and those design problems probably make it possible to abuse update-manager
<Mithrandir> pvanhoof: you're getting very close to what Bruce Scheier calls a movie-plot threat.  See http://www.schneier.com/blog/archives/2006/04/announcing_movi.html
<pvanhoof> highvoltage, the root user wouldn't be used for normal tasks
<HrdwrBoB> pvanhoof: so, rather than make it easier for everyone, and have a VERY VERY small attack vector that's pretty much available anyway
<HrdwrBoB> you'd like to make life really hard for everyone to make security a poofteenth better.
<pvanhoof> actually, with the terminal widget being writable .. the attack vector is rather huge
<HrdwrBoB> ... no, it's not
<\sh> morning
<highvoltage> hi \sh 
<pvanhoof> HrdwrBoB, as a (upstream) gnome developer myself, I tell you it is
<pvanhoof> HrdwrBoB, I can point you to multiple locations that are not audited for security in the code of that widget
<pvanhoof> nor are designed with security in mind at all
<Mithrandir> anyway, I have to go out in the great weather here to visit my grandfather, so I'm sorry I can't follow this ever-so-exciting discussion any further. :-)
<pvanhoof> oh and, the last months people have been doing a lot developments in improving improvemance of that widget .. I know behad and federico have been doing very cool but also complex and crazy tricks with subsystems like pango and the vte widget
<pvanhoof> It's very possible those introduced new problems
<pvanhoof> and they are not putting their focus on security
<pvanhoof> nor should they, the gtk+ statement is clearly that gtk+ is NOT designed with security in mind
<Omeg> Hey infinity. Did you receive that font I sent you?
<kos_tom> hi
<kos_tom> i'd like to modify the Ubuntu LiveCD, so that the kernel has support for network and NFS. Where can I get the sources and .config of the 2.6.12-9-386 kernel used in the LiveCD ?
<kos_tom> or is there a procedure to regenerate the Ubuntu LiveCD initrd ?
<infinity> kos_tom: The LiveCD kernel has support for network and NFS already.
<kos_tom> infinity: the Breezy LiveCD ?
<tseng> yes
<kos_tom> hum, strange. let me test it again, then ;)
<tseng> the livecd in breezy has the same kernel you use on your real install
<kos_tom> what I'd like to do is to modify the LiveCD initrd to mount the LiveCD cdrom from NFS.
<tseng> do what?
<tseng> nfs root?
<tseng> i think you should probably spell out exactly what you are doing, instead of throwing out hints, it seems sortof exotic
<kos_tom> i'm sorry, but I don't see network support in the LiveCD kernel. I've booted it, it didn't detect a network, and there are no modules for it (checked with modprobe -l)
<tseng> then your network hardware isnt supported or autodetection failed
<kos_tom> tseng: well. Here's my use case. I'm from a Linux User Group, and we often go in places where there are multiples computers with Windows, and we use Ubuntu LiveCD during our meetings.
<tseng> the livecd doesnt support any more or less than the real install
<kos_tom> tseng: my network hardware is the one emulated by Qemu, a standard NE2k card.
<tseng> "or autodetection failed"
<infinity> The LiveCD definitely supports that.
<kos_tom> tseng: so, we use CDs, but CDs are really slow to read, and I except the network to be much faster.
<kos_tom> tseng: so, I wanted to allow the computers to boot "Live", but from the network, instead of from the CD.
<kos_tom> see what I mean ?
<tseng> sure
<infinity> This would actually be much simpler with dapper, I suspect.
<infinity> Where you would just have the casper initramfs fire up an NFS connection, then grab the squashfs from the nfs share instead of from the CD.
<kos_tom> infinity: the /lib/modules/<version>/kernel/drivers/net/ is empty in the initrd. I don't see how it can support the network, then.
<infinity> kos_tom: I said the kernel did, I didn't say the initrd did.
<tseng> (sigh)
<tseng> its on the 'real' filesystem
<kos_tom> tseng: yep, but I cannot access the 'real' filesystem without the network, in my case. So what I need, is to have more modules in the initrd.
<infinity> Which just requires firing up a livecd locally, editing /etc/mkinitramfs/* to taste, then running "mkinitramfs -o /tmp/mynewinitrd"
<infinity> Err, with a kernel version on the end of that. :)
<mdke> freeflying: around?
<tseng> edubuntu probably has ootb support for nfs root
<tseng> i am guessing
<infinity> The workstations do, not the LiveCD.
<infinity> Not it's a single change in /etc/mkinitramfs/initramfs.conf
<infinity> s/Not/But/
<freeflying> mdke: pong
<mdke> freeflying: ah awesome. So I'm trying fonts to find one which supports the right characters. I've tried Freefont and Dejavu and neither have worked. which can I use?
<mdke> freeflying: is there a font which contains fonts for all the asian characters that I might need for asian translations of the documentation?
<freeflying> mdke: fop can not support chinese fonts, so you can not get it work, especially the version u r using now 
<mdke> freeflying: the fop developers say it does.
<mdke> and I've got 0.92beta working as well
<mdke> I just need a few fonts to try out
<freeflying> mdke: seems theree haven't a fonts inlude all asian fonts
<bddebian> Hello peoples
<mdke> freeflying: ok. In that case I would think that we'll have to get a list of fonts for the various languages. What works for zh_CN?
<freeflying> mdke: we r using ttf-arphic-uming
<mdke> preferably ttf
<bddebian> mdke is still messing with fonts? :-)
<mdke> freeflying: ok. I haven't got that installed for some reason. I'll check it out
<mdke> freeflying: is that likely to work well in print?
<mdke> bddebian: yeah :/
<bddebian> doko: You around by any chance?
<freeflying> mdke: it's in ubuntu/kubuntu/edubuntu install cd,  it can work well in print
<doko> bddebian: not for work
<bddebian> ?
<mdke> freeflying: yeah actually I have it installed, but it's not in /usr/share/fonts/truetype, I'll dig around
<bddebian> doko: Not for a quick question? :-)
<freeflying> mdke: it's in /usr/share/fonts/truetype/arphic/ 
<mdke> oh yeah :)
<bddebian> Anyone else know anything about eclipse/libswt?
<doko> bddebian: what is wrong with eclipse?
<mdke> freeflying: I'll mail you if I get a pdf working :)
<freeflying> mdke: ok
<bddebian> doko: Nothing, I'm looking at swingwt which needs libswt-gtk-dev.  Has something in eclipse replaced that?
<_ion> Btw, here's my gimp-resynthesizer package in case anyone's interested. http://johan.kiviniemi.name/ubuntu/
<bddebian> farg
<doko> bddebian: please join #ubuntu-java
<mdke> freeflying: fop is crashing with uming :-( I'm so unlucky
<freeflying> mdke:  heh
<popey> Can anyone tell me if evolution-caldav is likely to be ready for dapper?
<Omeg> Hey infinity
<Omeg> I e-mailed you a BDF font which I converted from that Zeta font that I showed earlier (the really small one).
<Omeg> If that one seems to be operable, I'll remake that other font in BDF.
<Omeg> It could be that your mail server ignored the e-mail because maybe it thinks "BDF" is a scary file format. :P
<infinity> Omeg: No, I got it, but I'm also very busy.
<Mithrandir> infinity: not to mention it being Sunday?
<infinity> Mithrandir: Which makes it suck that much more that I'm ALSO busy. :/
<bddebian> Who wants cheese with their whine?
* bddebian hides
<Omeg> I do!
<Omeg> Er.
<Omeg> I thought you said wine.
<Omeg> Tsh.
<infinity> He was trying to be funny.
<infinity> It didn't work.
<tseng> hi bddebian 
<bddebian> Heya tseng
* bddebian hugs infinity
<kos_tom> is there any documentation about the procedure used to build the Ubuntu LiveCD (and particularly the initrd stuff) ?
<Mithrandir> kos_tom: the initrd is built by just installing casper.
<tseng> Mithrandir: it would be great if LiveCDCustomizationHowto were updated, hint wink
<Mithrandir> tseng: it would be great if my day had 48 hours in it too. :-)
<tseng> :)
<pygi> Mithrandir, tseng, whoever: patch to enable internet connection settings in g-n-p .... do we need that? :)
<Treenaks> Mithrandir: move a bit further north, you'll get 6-month days ;)
<Mithrandir> Treenaks: true dat.  I'll get 6-month nights too, though.
<Treenaks> Mithrandir: so? just skip a release cycle ;)
<Mithrandir> pygi: uh, unsure.
<Mithrandir> Treenaks: I think my boss might be unhappy about that. :-)
<tseng> pygi: g* = seb128
<tseng> pygi: but i doubt it, we are post feature freeze
<tseng> since a long time ago
<pygi> tseng: I know...someone suggested that as a SoC project :-/
<tseng> oh, i dont know anything about that, sorry
<j^> would it be possible to add something like 'find -name \*.glade -exec sed -i "s/<property name=\"invisible_char\">\*<\/property>//g" \{\} \;' to dh_install so that the default invisble char is used?
<_ion> That would be nice.
<j^> to also get those with translatable="yes", it would have to be: find -name \*.glade -exec sed -i "s/<property name=\"invisible_char\".*>\*<\/property>//g" \{\} \;
<_ion> .* wouldn't be good, rather [^>] * instead.
<_ion> sed -i 's#<property\>[^>] *\<name="invisible_char"[^>] *>\*</property>##g'
<_ion> Maybe something like that.
<infinity> Not sure why you're escaping < and > occasionally in that regex. :)
<_ion> infinity: word boundary
<infinity> Anyhow, adding hat sort of thing to dh_install is just plain wrong.
<infinity> debhelper isn't meant to fix random bugs and odditied in packages, you should just patch the packages that do things "wrong".
<j^> infinity i filed it as #bug 43369 
<infinity> It seems about as silly as asking dh_clean to walk your source tree before you compile and fix random poor programming practices.
<_ion> Maybe lintian should complain about <property\>[^>] *\<name="invisible_char"[^>] *>\*</property>
<j^> the problem with fixing glade-2, which is generating those wrong glade files is that this will not fix it until the upstream author opens and saved the file in glade-2 again
<j^> which could be -- never.
<infinity> And you can't fix the packages directly with a simple patch?
<j^> infinity this is again something you would have to do over and over again until glade-2 is fixed
<infinity> And if I have documentation that has the above string in it, your dh_install hack wipes it out.
<infinity> Yay.
<infinity> (Or any other random scenario I can come up with where such a hack is obviously just plain wrong)
<j^> infinity, fine with me that was just a suggestion, feel free to gome up with a better way
<infinity> glade is source code, just like any other language.  If the source is buggy, fix it, don't rely on hepler tools to munge it.
<infinity> (Sure, it's a whacky pseudo-source generated by an IDE, but that doesn't change anything)
<infinity> If you really want invisible_char to be ignored completely, make libglade ignore it and always use the default.
<j^> infinity http://bugzilla.gnome.org/show_bug.cgi?id=335702 is the bug to fix glade-2
<infinity> (Or whatever will end up interpreting it at runtime)
<j^> i dont want it to be ignored, i dont want the default to be set in each app again and again
<j^> but since fixing this in every app that uses glade is not possible, patching libglade to ingore it + fixing glade-2 to not output it by default might be better than fixing .glade files during install
<\sh> j^: so if the default is set in the .glade file, and libglade finds it, it overrules the global system setting?
<infinity> (For that app)
<\sh> strange..it sounds to me more a problem in handling application defaults over user/system defaults
<j^> \sh global system setting is more changing the default in form of a patch
<j^> so setting vs. default is lost
<\sh> j^: well, application ships with default settings, e.g. password char #...now system settings should overrule the application setting, and user setting the system setting
<kos_tom> huhu, modifying the initrd to support NFS seems to be trickier than I expected ;-(
<sivang> who's the right person to bug about adding my blog to planet ubuntu feeds?
<highvoltage> sivang: jdub
<highvoltage> btw, am i right that you would be able to, upgrade from one enterprise release of ubuntu to the next, without all the steps inbetween?
<sivang> highvoltage: no idea, but this seems rather something we should be better support.
<highvoltage> sivang: *big nods*
<sivang> highvoltage: I don't expect enterprises to hae to go throught troulbe of in-between releases, 
<sivang> highvoltage: they might just swich to other distro.
<highvoltage> as far as i understand, it might cost a lot of work for package maintainers to make sure the scripts inside the deb makes sure that it properly upgrades from the last version, and from a distro released 2 years ago... but then again, perhaps it's been thought through and solved already.
<highvoltage> on the other side, re-installing once every three years isn't *that* bad... but i would like to see an upgrade, if i need it.
<sivang> highvoltage: indeed. we need to remember that the universal operating system which we base off, promises no reinstalls. we should probably stick to this :)
<highvoltage> yeah :)
<HiddenWolf> a problem here is that it becomes rather difficult to see if your system gets damaged by the upgrade.
<HiddenWolf> bugs aren't decent enough to tell if they stem from upgrading or not. :)
<sivang> this could be solved by ridgid vmware enabled , release X to Y upgrades, and testing that system is usable and not flawed.
<sivang> it could consume alot fo time, but I suspect there might not be fully automatic or better way to do so.
<HiddenWolf> hm, is vmware free yet?
* sivang heared soem of it is, at least.
<HiddenWolf> I was asked to test if a bug was around on the livecd too, but I'm too lazy to burn&reboot
<HiddenWolf> :)
<sivang> HiddenWolf: btw, you know I released a beta of hubackup to universe?
<HiddenWolf> sivang: I saw. :)
<HiddenWolf> sivang: will it eat my data, or can I try it? 
<sivang> HiddenWolf: well, it's a beta, and experimental :) but I took great measures so it won't eat your data, but you know how the GPL goes..:)
<sivang> "shall not be responsible.....nor for any purpose...etc blah"
<HiddenWolf> sivang: licence good and well, but I know your IP. ;)
<HiddenWolf> sivang: this is the part where you shiver. ;)
* HiddenWolf needs another language course
* sivang shivers
<sivang> :)
<sivang> HiddenWolf: well, could just be nice if you give it a test. I needs as much feedback to make this a worthy product. See about bugs already filed against the source package in LP, I provided there soem expleneation why media must reside (or usb drives must be plugged) prior to firing up the program so it ill find backup target devices. let me know if it finds your extenral hard drive
<sivang> HiddenWolf: feel free to be aparnoid and run it on a dummy home folder of a dummy user
<sivang> HiddenWolf: I won\t get offended :-)
<HiddenWolf> sivang: as soon as I have an external drive. ;)
<sivang> ah, well, you have a CDRW?
<HiddenWolf> yeah. usbstick too. 
<sivang> HiddenWolf: if you don't back up media files then usbstick could probably contain all your home
<HiddenWolf> should be able to, yeah
* sivang now needs to work hard on making device detection in real time, that is responding to the hal plug events and updating device tables accordignly.
<sivang> anyway, time for some break.
<sivang> laters
<HiddenWolf> sivang: relax man, it's sunday :)
<sivang> HiddenWolf: will do , thanks :)
<HiddenWolf> sivang: shoo, go enjoy some good weather. :)
<sivang> HiddenWolf: I actually need to take a nap, had a bad night and couldn't get too much sleep. but thanks for the offer
<HiddenWolf> you should've napped this afternoon, in the sun somewhere. :)
<HiddenWolf> (hint: works better without a laptop)
<sivang> HiddenWolf: yeah, well, being sick I had to go to the doctor (actually sunday is a regular work day in .IL but I'm in a sick-day) , buy some stuff to eat etc, and then attended to some email and stuff. now is rest time :)
<HiddenWolf> fair enough.
<HiddenWolf> sivang: get well. :)
<highvoltage> 2/win 4
<elmo> doko: did you break apt on ia64?
<elmo> apt-get: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory
<doko> elmo: didn't touch that in the last months
<elmo> well I haven't updated this chroot in a few months, but that's the state of apt after a dist-upgrade
<elmo> oh, blah, sorry, I'm losing my mind
<doko> it's from last July
<elmo> I was in the wrong chroot (sid != dapper) - don't mind me
<j^> svn: Unrecognized URL scheme for 'https:// ... hm
* robertj files the sure-to-be contriversial bug #43426
<sivang>  /whois robertj robertj 
<sivang> oops :)
<sivang> robertj: I was trying to recall if you are the robertj I talked to about VideoCon framework that will be usable through client FOSS programs 
<sivang> (that told me he takes part in development)
<_ion> http://homepage.mac.com/bradster/iarchitect/images/mdsclue.gif :-D
<sivang> _ion: nice to recall those horrific dialogs :) in which it it shows you it's always a loose-loose situation :)
<Tuxist> hi
<robertj> sivang: not me
<robertj> sivang: was afk, but that's not me
<ryan_rousseau> Hi everyone, I have submitted a proposal for a quizzing application to included in Edubuntu.  It is meant to be replacement for KWordQuiz.  I was wondering if there is anyone interested in mentoring such a project?
<maxco> hello
<maxco> is there graphical designer of ubuntu here ?
<maxco> (not only programmer please)
<winkle> try #ubuntu-art or something
<maxco> okay thank you
<winkle> seems to be +i though
<maxco> arm
<sivang> yes, I also cannot connect
<mdke> *work
<maxco> it is #ubuntu-artwork
<maxco> I have a question for here
<maxco> what does the developpers do for ubuntu ?
<mdke> they maintain the software
<maxco> they put their hands into C/C++ or it is only maintaining/organizing ubuntu in the hard system part ?
<mdke> they do a bit of everything :) Lots of software gets written from scratch, lots is already written
<maxco> okay
<maxco> is one of the aims of ubuntu to create a "ubuntu desktop", ie. not only a customized Gnome ?
<Seveas> @config channel plugins.bugtracker.bugsnarfer True
<mdke> maxco: no, Ubuntu uses existing desktops, like Gnome (Ubuntu), KDE (Kubuntu), xfce (Xubuntu) etc
<maxco> yes, but I mean, "making more than a Gnome with orange themes and icons"
<maxco> "ubuntu software" or something like that
<maxco> a Gnome desktop but with some tools/modifications only for ubuntu
<maxco> hum I think it would be to Gnome devs to do that, not you
<mdke> maxco: that's basically what is happening now. Things like Add/Remove Applications, and Update-Manager are tools which Ubuntu has added
<maxco> yes exactly what I wanted to say !
<maxco> okay, that mean that ubuntu devs takes care about developping more users friendly tools, great
<sivang> they also make sure to push them back to the relevenat communities,
<sivang> there is not too much ubuntu specifci parts, unless something limits their use in other communities like GNOME upstream, debian etc.
<maxco> okay you make stuff in function of the community demands ?
<sivang> maxco: mostly, yes.
<sivang> maxco: every new feature starts as a specifciation proposal, then it's discussed drafter and get feedback from the community
<sivang> maxco: the community can also participate in development, bug fixing etc
<maxco> I think you are a lot claimed for XGL stuff ?
<sivang> maxco: me?
<maxco> developpers in general
<sivang> maxco: well, Matthew Garret has indeed made XGL available from universe for dapper, with realtively fussless installation :)
<maxco> ho, cool
<maxco> personnally I will wait to get a more decent video card ( non ati ) :p
<sivang> heh
#ubuntu-devel 2006-05-13
<maxco> if I want to improve the look and the feel of the ubuntu desktop, I think I have to get involved into Gnome instead of ubuntu ?
<sivang> maxco: you can do that, or you can work on stuff in ubuntu which can get used by larger communities if appropriate
<maxco> yes
<maxco> but the "appropriate" word hurt me a little bit
<maxco> if I want to inovate a bit, I cant very much because users dont want to break what they are used to
<maxco> I think to the "spatial" browsing of nautilus for exemple
<maxco> I think that community does not let you to experiment new design, new concepts of the user interface, etc ... because they just dont have ideas about what thing could be added to improve the user-friendlyness, where dev/designer could
<maxco> then, they just use what they know, when they looks a new feature on windows/macos, they want the same on linux, some things like that
<sivang> sort of, yes, we;ve had a couple of those I think
<maxco> but linux really have to get a design update
<sivang> maxco: if you have a suggestion or so, feel free to add it to the wiki as a specification, or discuss it over the mailint lists for broader consideration.
<maxco> oh, yeah okay
<sivang> maxco: if you want to change the way the desktop is, then I think you better work it out upstream
<sivang> maxco: =GNOME,KDE etc..
<maxco> yes, what I though
<maxco> I am currently using xfce ( but with some gnome tools ) and I really like the way that xfce takes
<maxco> they take care about user/computer interface and standards ( I mean freedesktop ones )
<maxco> I think I could get a touch with its devs
<sivang> maxco: Doesn't GNOME also follows those standards? 
<maxco> less than xfce does ?
<maxco> or maybe in the past they dont
<maxco> dont know very well
<maxco> I really like gnome, I use it as well as xfce
<maxco> but somethings disturb me, like some designs and the slowness of gtk
<maxco> I think I could start by developping my ideas concretely and propose them to Gnome/xfce devs
<maxco> but I want to keep a link to ubuntu, because I really love this distrib
<sivang> maxco: okay, then you can do that in two leverls.
<sivang> levels, even
<sivang> maxco: 1) work with Xubuntu developers and propose your ideas. sometimes things are accepted in ubuntu, then upstream sees its good and decids to adopt them.
<sivang> maxco: 2) work and propose stuff directly to XFce developers, I know they are already in contact with some of the Xubuntu developrs, and pushing ideas back and forth.
<maxco> okay cool, I will do that
<maxco> I just have a little question : how linux devs works on the last cvs version of a project without breaking all their system with dependencies problems ?
<maxco> because if you want to work on the last version of a tool, you need to get the last version of the libs
<crimsun> maxco: I generally keep chroots for that sort.
<maxco> chroots ? you make a little system inside your usual one ?
<crimsun> maxco: indeed.
<sivang> maxco: some break their system and then waste time restoring it, like me :) some use chroots, yes 
<maxco> oh good idea !
* sivang onces b0rked his /etc/passwd when working on system-tool-backends
<maxco> :p
<sivang> crimsun: have you been doing work on dh_iconcache ?
* sivang looks for someone a bit more knowledgeable about this.
<maxco> it is so hard to work on a big project on linux ... mainly because of the libs/headers dependencies ?
<crimsun> sivang: I haven't -- been embroiled in other bugs, sorry.
<sivang> crimsun: no problem, thanks anyway ;)
<sivang> maxco: hard is relative. Usually each big project has it's own stack of development tools and build ways, once you control those, it becomes easy I think
<maxco> yes of course
<maxco> but unflexibility breaks innovation ( it is only my advice )
<maxco> erm, s/advice/opinion
* maxco is french
<sivang> maxco: sure, but sometimes when a system is responsible for so many things, there is not escape from complexity and size..
<sivang> maxco: taking the approach of componentization could help alot in this cases, though.
<maxco> yes yes I agree
<maxco> I am thinking to xfree/xorg
<sivang> exactly
<maxco> the result is that they become unappropriate for today needs, and you need to make some hacks like xgl
<maxco> even they was well-designed at the begining
<maxco> if on day a guy say "hey I want my desktop being managed only by opengl", you can wait a very long time before this guy release his idea
<maxco> it is the way AIXGL takes
<maxco> I think there is something to work on arround that, but I dont know very well where to go in
<maxco> even google encounters problems when I ask him such questions :p
<maxco> I wonder how OSX manage it
* maxco are sorry to "think" on the chan
<maxco> *is
<sivang> maxco: hehe, but yes, discussinons like this might be more appropriate over #ubuntu-offtopic
<maxco> yes sure :p
<maxco> sorry I really need to talk about my ideas and thinking
<maxco> I could write articles and make a website ... maybe
<maxco> at least on such a channel, there are advanced users and developpers, not only newbie that dont understand something
<maxco> *who
<bddebian> Heya peoples
<dilinger> anyone know what xserver-xorg is using libdiscover1 for?
<infinity> dilinger: PCI ID -> video driver mappings?
<dilinger> infinity: that's what i figured, but debian's doesn't seem to have it, there's no mention of it in the binary (strings /usr/X11R6/bin/X |grep disc), and it's not linked directly against it
<infinity> The X server doesn't do it on the fly, just the debconf config stuff uses it.
<dilinger> ah, i see
<dilinger> shouldn't it be dep'ing on discover1, then?  it looks like it calls the binary itself in the .config file
<infinity> It doesn't?
<infinity> (base)adconrad@cthulhu:~$ apt-cache show xserver-xorg | grep Depends
<infinity> Depends: xserver-xorg-core, xserver-xorg-driver-all | xserver-xorg-driver, xserver-xorg-input-all | xserver-xorg-input, x11-common, laptop-detect, xresprobe, mdetect, discover1, dmidecode
<dilinger> oh, i misread
<dilinger> nm then
<dilinger> thanks
<crimsun> would a main uploader take a look at ubuntu bug #43423 and apply one of the patches to fix subversion?
<crimsun> https://launchpad.net/distros/ubuntu/+source/subversion/+bug/43423
<Ubugtu> Malone bug 43423 in subversion "svn over https not working any longer" [Critical,In progress]  
<infinity> crimsun: No patch required, since I'll be updating to 1.3.1, which supports the new NEON fine.
<crimsun> infinity: ok, thanks for the heads-up.
<infinity> (People use SVN over https?)
<infinity> Actually, I should know that, since I had to fix a misfeature in apache2 for that same use case.
<yves> I do.
<infinity> (SVN over https with client certs = explodey after a security fix that broke a misfeature people had been relying on)
<crimsun> infinity: the doc team does. And sorry about the duplicate comment.
<infinity> Oh, if the doc team uses it, I'll prioritise the update and fix.
<infinity> Since the doc team is the only group I can think of with a VALID reason to be using SVN on dapper *and* complaining about it. :)
<infinity> (How dare they run an OS to document it!)
* infinity loves that neon's API is so painfully unstable that SVN upstream has to maintain such a silly "working list" in their source treee in the first place.
<infinity> Anyhow, I'll fix it up right after I go get some lunch to work out my frustrations from the morning hackery. :)
<bddebian> heh
<sleazye> sleep stopped working after update today...think it was acpi...is this a known issue?
<crimsun> sleazye: acpi-support_0.79?
<crimsun> probably better addressed in #ubuntu-laptop
<sleazye> yes 0.79
<dreyes> anyone try installing zimbra????
<dreyes> anyone here???
<bddebian> Give me a sec
<dreyes> well i followed this forum here http://wiki.zimbra.com/index.php?title=Building_the_software_yourself#CVS_Update
<dreyes> and It installed okay except for a local host but it installed
<dreyes> but I can't even log infinity 
<bddebian> Oh, I thought you meant an Ubuntu package
<infinity> dreyes: This doesn't belong in #ubuntu-devel.
<dreyes> got ya see ya
<whiprush> hey infinity 
<whiprush> quick question for ya ...
<whiprush> chances of you visiting ootb LDAP goodness during edgy?
<infinity> whiprush: Decent, if you write me some coherent specs to look over in Paris.
<infinity> whiprush: Poor otherwise, as it's not necessarily a personal goal of MINE.
* whiprush nods
<ajmitch> whiprush: like NetworkAuthentication?
<ajmitch> which I've put in for SoC
<whiprush> ajmitch: from scanning the page, yep.
<whiprush> ajmitch: coolness
<ajmitch> whiprush: if it goes through, I should get client & server stuff done
<whiprush> you messed around with FDS at all?
<ajmitch> will be doing so
<ajmitch> I haven't had that joy yet
<whiprush> I've done so on one machine, I haven't played with it as far as the multi-master stuff goes
<infinity> I haven't player with it at all yet.
<whiprush> ajmitch: I've just kerberized our stuff at work, it's great stuff.
<infinity> Is it "yet another slapd fork" with some extra glue?
<ajmitch> nice
<whiprush> Maybe my school will send our ldap guy to paris.
<ajmitch> infinity: old netscape code
<ajmitch> sadly I won't be in paris
<infinity> ajmitch: Oh, ick.
<whiprush> infinity: forked off the old netscape code
<whiprush> then they spent a few months making the admin tools work with free java.
<whiprush> it's not /bad/, but it's not entirely fun to use either, imo.
<ajmitch> so I hope people don't spec too much that runs against what I'm working on :)
* ajmitch will be back in ~15 min
<infinity> ajmitch: Well, I don't intend to spec anything LDAP-related for edgy, I have other fish to fry.  Since I'm likely the only core-dev who gives a crap about LDAP, that probably means you're safe.
<bddebian> infinity: I gotta hand it to you man, I don't know how you deal with any/all these X bugs??
<whiprush> infinity: they invented ldap like 45 minutes from me, and for the life of me I can't find anyone in their LUG or faculty willing to work on the stuff. :-/
<infinity> bddebian: I ignore them until the nagging becomes overwhelming?
<bddebian> infinity: Heh.  I wish I could help you more man :-(
<dieman> yay
<dieman> the school acm group finally passed on the ubuntu SoC email
<dieman> to their student members on their jobs list
<infinity> I'm unsure whether to love or hate the SVN testsuite...
<ajmitch> dieman: the one where applications are due in < 24 hours?
<infinity> It's saved my ass a few times..  But it also takes like 12 freakin' days to run on my 2GHz Pentium-M.
<dieman> yeah
<dieman> sadly
<dieman> i sent them days ago
<dieman> and someone decided to leave them in the queue, obviously
<lifeless> infinity: wow. seriously?
<infinity> lifeless: No, not quite 12 days.  That might be hyperbole.
<lifeless> infinity: is it all blackbox tests ?
<infinity> lifeless: It's rather comprehensive, however.
<infinity> lifeless: EPARSE.  blackbox tests, meaning?  (I'm not a testing engineer)
* jdub wonders if god entertains test driven design... and are we the product, or the test suite?
<lifeless> jdub: haha
<bddebian> heh
<jsgotangco> lol
<infinity> Some of the magic (and pain) of the suite comes from the fact that many tests generate random repository scenarios on the fly to catch "bugs no one's though of yet".
<infinity> Which has actually caught a few, which is neat, but is also hell on entropy.
<bddebian> Gnight peopleses
<infinity> fabbione: Your last GDB upload seems to have hosed the testsuite on other arches...
<infinity> fabbione: More failures than before, and ia64 and powerpc even decided to hang.
<Lathiat> BenC: about?
<dieman> wow
<pitti> Good morning
<dieman> misfire, wrong chan
<pitti> jdub: my evo greeted me with an 'invalid file format' for the fridge web cal this morning; any idea?
<dholbach> good morning
<Mithrandir> hiya daniel
* dholbach hugs Mithrandir
<neuralis> dholbach: have you seen anyone complaining about dapper video playback in multihead setups? a malone search reveals nothing useful.
<dholbach> neuralis: I think there was one bug about multihead and totem, but that can have been upstream too.
<neuralis> dholbach: it's a very serious regression from breezy that i only now noticed, and appears non-trivial to debug :/
<kagou> hi
<sivang> morning all
<carlos> pitti: hi, I didn't get translation status mails for Saturday and Sunday, is there any problem with your scripts?
<pitti> carlos: yes, I fixed it this morning, sorry
<carlos> pitti: ok, no problem at all. Thanks
<pitti> carlos: will work again today
<pitti> carlos: btw, https://wiki.ubuntu.com/MissingPotFiles looks pretty well now; can you confirm this list?
<carlos> pitti: I think so, most of the .pot files were approved on Friday
<pitti> yay
* pitti looks forward to today's report
<carlos> pitti: I still need to do the manual imports for some packages, will try to do it today so tomorrow we would get near 100% exports from Rosetta
<sivang> jdub: when you come online, could you please add me to planel? please add http://sivan.linuxguru.net/ as a feed.
* sivang hugs slomo 
<slomo> hi sivang :)
<Mithrandir> Kinnison: is it you or ogra I should talk to about gss locking my screen (sometimes) when unplugging power?
<hunger> Yahoo, resume works for me again with the new kernel.
<hunger> Unfortunately the box shuts down right after it resumed.
<Mithrandir> mvo: 30171 should be confirmed at least, shouldn't it?
<Treenaks> hunger: Hey, it's a start :)
<hunger> Treenaks: Yeap. And getting it to resume again should have been the hard part, too:-)
<mvo> Mithrandir: yes. I currently sync by hand when I have time. I still need to figure how to merge unreleated trees in bzr then I can use the cvs import we have
<Mithrandir> mvo: I'm going through unconfirmed bugs so if we could at least just confirm it, it'd drop off my radar for now.
<mvo> Mithrandir: done
<mvo> Mithrandir: sorry for not doing it earlier
<Mithrandir> np
<sabdfl> moin moin
<sabdfl> anybody else see kernel 2.6.15-22 not properly install?
<sabdfl> it does not show up in my boot menu
<pitti> hi sabdfl 
<danimo> moinw
<danimo> where has the the fs_dav plugin for subversion gone?
<danimo> in current dapper, it's not possible to access http urls anymore
<danimo> webdav-based repos, that is
<pitti> sabdfl: I just dist-upgraded, it worked fine for me
<pitti> sabdfl: are the /vmlinux{,.old} symlinks correct?
<sabdfl> pitti: yes
<Toadstool> danimo: it's a known bug and has been fixed this night, the packages will be quickly available on your mirror
<Toadstool> hi here by the way
<pitti> sabdfl: and /boot/grub/menu.list still shows -21 for the default kernel /vmlinuz?
<sabdfl> yes
<pitti> hmm
<pitti> that indeed seems to be a bug in the kernel postinst then
<sabdfl> BenC: ping ^^^
<pitti> sabdfl: sometimes I ended up with grub using the 'wrong' boot partition (after test installs, etc.), but that doesn't seem to be the case here
<dholbach> sabdfl: a full /boot partition maybe? does  sudo update-grub  say anything?
<danimo> Toadstool: ok, tnx
<sabdfl> reinstalling gives:
<sabdfl> Not touching initrd symlinks since we are being reinstalled (2.6.15-22.34)
<sabdfl> Not updating image symbolic links since we are being updated (2.6.15-22.34)
<pitti> well, the symlinks were okay anyway
<pitti> update-grub should rewrite menu.list
<sabdfl> interesting, grub is not installed
<sabdfl> there is no chain of dependencies
<pitti> oh, that explains the issue then :)
<pvanhoof> there's something wrong with that new subversion package
<sabdfl> why is grub not a dependency of -minimal?
<pvanhoof> it can't handle https URL's
<pitti> sabdfl: some people might want lilo
<pitti> sabdfl: (I want lilo on my server, e.g.)
<sabdfl> pitti surely we should depend on (lilo | grub)
<pitti> sabdfl: indeed, the kernel should do (grub | lilo, even)
<Kamion> getting grub installed is handled by the installer
<thom> (some people might /have/ to have lilo, even if they don't want it)
<Kamion> there's no infrastructure in -minimal for alternative dependencies at the moment
<Kamion> -minimal doesn't depend on the kernel either, somewhat deliberately :)
<sabdfl> Kamion: i think -desktop at least should have the (lilo | grub) dependency
<Kamion> sabdfl: no infrastructure for it there either; germinate can't express that
<sabdfl> i also noticed that ubuntu-artwork wanted to be removed over the w/e
<pitti> thom: I never managed to get the grub equivalent of lilo's -R option working, so I just sticked to lilo on my server
<sabdfl> Kamion: ok, i'm just suggesting its a bug that the user can end up with no boot loader updates
<Kamion> sabdfl: well, only if they choose to remove packages :)
<thom> pitti: i can't remember what -R is; I have seen machines that grub physically doesn't work on
<pitti> thom: lilo -R linux.new boots the image linux.new once and then falls back to 'default='
<sabdfl> Kamion: we have smart packaging systems to keep machines lean and mean, and if there is no dependency then the packages could well end up being removed
<pitti> thom: a vital life saver if you have to adminstrate a remote server with only ssh (like I do)
<thom> pitti: oh, cute
<ajmitch> Kamion: are there a a few zope & python2.3-* packages in NEW at the moment?
<Kamion> yes
<ajmitch> ok
<pitti> thom: so, with panic= and an init.d script which autoreboots after 5 minutes (at job), I'm fairly safe against screwing up in a kernel update, etc.
<ivoks> Kamion: i noticed one bug in ubiquity (choosing croatian layout doesn't change a thing), so I'm wondering is this ubiquity bug or it has something to do with localisation packages?
<thom> pitti: yeah. LOM for the win, really :-)
<pitti> thom: LOM?
<thom> lights out management
<jdub> mjg59: ping
<Kamion> ivoks: ubiquity bug I imagine
<ivoks> Kamion: ok
<Kamion> there are some related ones filed, but none for Croatian
<ivoks> ok, i'll take a look
<ivoks> thank you
<pvanhoof> https://launchpad.net/distros/ubuntu/+bug/43526
<Ubugtu> Malone bug 43526 in Baltix "Since May 8 subversion cannot do https anymore" [Normal,Unconfirmed]  
<pvanhoof> Can somebody move that to Ubuntu?
<Kamion> pvanhoof: it's already fixed
<pvanhoof> are you uploading a new package?
<Kamion> and no, somebody can't move it to Ubuntu, look at the bug on the web
<Kamion> it's already filed on Ubuntu
<Kamion> pvanhoof: not me
<pvanhoof> okay, thanks .. whoever fixed it
<pvanhoof> *rolled libsvn and subversion back* I'll upgrade in a few hours and try again
<pvanhoof> funny monday mornings when running dapper :)
<sivang> Riddell: ping
<czr> will xen be integrated in any form for dapper?
<Mithrandir> no
<czr> lack of time or some other reason?
<phanatic> czr: i suppose feature freeze
<czr> k. thanks for that info
<Mithrandir> it's way, way, way too late now and nobody has spent the effort earlier.
<phanatic> was long time ago
<Mithrandir> It'd have been sweet if it had been pushed for five months ago, but it wasn't.
<czr> what about the next version (what was it anyway?)
<Mithrandir> edgy eft.
<czr> yeah, that one :-)
<czr> always have problems remembering the new names :-)
<Mithrandir> somebody needs to expend the effort.  If a volunteer does it, I can't see it not being accepted.
<czr> no one is working on it yet?
<Mithrandir> I don't know if it'll be a high-priority goal.  Maybe, maybe not.
<dholbach> czr: we're all focussing on getting the release ready.
<Mithrandir> we're busy getting dapper out.  Nobody's supposed to focus on eft yet.
<czr> dholbach, I understand
<dholbach> czr: cool
<czr> going to play with xen this week and since ubuntu is my fav distro just wanted to know if there are any plans. that's all :-)
<dholbach> czr: you sound like a member of the XenTeam for next release, it seems ;)
<czr> depends on how busy I'll be with other stuff :-)
<czr> and depends on how well my playing with xen will go over, but from what I've understood, getting it to work isn't that hard. getting it integrated properly might be more pita.
<sivang> czr: there's already some efforts to make it work out of the box, wait a sec I'll find you the link
<czr> sivang, thanks
<Mithrandir> czr: there's some very unofficial stuff, I think it was announced on ubuntu-devel some time ago.
<czr> well there is a project for debian at least
<sivang> Mithrandir: talking about what jmg's working on?
<sivang> czr: It seems that link has been removed, and I'm reluctant to give you repository location without the howto.. try to contact jmg on IRC when he's online
<Mithrandir> sivang: maybe that's what it is, I can't remember exactly.
<czr> sivang, that's ok. I'm going to play with xen with my own system first (not ubuntu), just asked about plans (if any) about xen-'support' in the future
<sivang> czr: jmg already has packages that install a patched dapper kernel and seems to go past installation, but I personally couldn't make the subdomains work, or connect to them..
<Mithrandir> czr: https://wiki.ubuntu.com/XenVirtualMachine/XenOnUbuntuDapper has something
<czr> I'm going to play with xen patched 2.6.16 running my own initramfs this week. so mainly the question was whether ubuntu will behave nicely running in a domU
<czr> thanks Mithrandir 
<janimo> Kamion: I am planning an upload which renames one of the xfce library binary packages. Can I ping you when it's built to let it out of NEW?
<czr> anyhow, thanks for all the links & info, I'm going to stop the xen-questions now, you have better things to do :--)
<Tonio_> hi
<Mithrandir> Kamion: 34465 should be fixed now, or haven't you had the time to check?
<zakame> hi all
<Kamion> janimo: if it's urgent, yes
<Kinnison> Mithrandir: theoretically me
<Kamion> Mithrandir: oh, yeah, that's a dup, I'll mark it as such
<Mithrandir> Kinnison: I don't know the exact steps needed to reproduce it yet, but it happened to me this morning.
<Mithrandir> Kamion: thanks.
<Kinnison> Mithrandir: check your system logs from around that time
<Kinnison> Mithrandir: g-p-m is supposed to log when/why it does things
<Mithrandir> Kinnison: what does it use as its tag?
<lucasvo> Anybody know what's the difference from embedded-ubuntu to 'miu'ubuntu?
<Kinnison> Mithrandir: not a clue, grep -i for gnome ought to do it
<Mithrandir> Kinnison: well, doesn't seem like it has logged anything here
<Kamion> sabdfl: the problem with adding grub|lilo to metapackages is that it makes it difficult to set up a chroot and be confident that stuff inside the chroot isn't going to render your machine unbootable
<Kamion> sabdfl: I think I'd rather make our smart packaging tools a little bit smarter, and tell them to try hard not to remove bootloaders
<sabdfl> Kamion: ?
<sabdfl> ok
<sabdfl> what about depending on "boot-loader" and have three things that provide that: grub, lilo, and a dummy
<sabdfl> then you can put the dummy in the chroot
<Kamion> dunno, sounds fiddly to get the chroot created properly then, but I suppose it's possible
<Kamion> I'd probably better not dive into that morass today though :)
<sabdfl> np
<Kinnison> Mithrandir: Hmm, then it's possible it wasn't g-p-m
* Kinnison ponders
<lucasvo> !seen alizardo
<Kamion> infinity: was it you who was apparently halfway through doing a retchmail sync?
<infinity> Kamion: Nope.  Blame Keybuk.
<Riddell> sivang: pong
<sivang> Riddell: let me know if this is legite, or helps in any way https://launchpad.net/distros/ubuntu/+source/amarok/+bug/43459
<Ubugtu> Malone bug 43459 in amarok "dh_iconcache added." [Normal,Unconfirmed]  
<Riddell> sivang: I've no idea, I've not looked at dh_iconcache at all, you'd need to ask a gnome packager
<sivang> Riddell: k, thanks alot.
<pitti> doko: could you please take a look at merging/syncinc libstruts1.2-java from sid? (new upstream microversion fixes three security bugs, but we have ubuntu specific java changes)
<doko> pitti: ok
<pitti> doko: thanks
<pitti> slomo: do you feel like merging ethereal with Sid, to fix a plethora of vulns?
<Kinnison> Mithrandir: There's no mention of g-p-m there at all?
* Kinnison looks confused
<slomo> pitti: hm, write me a mail with all packages and i'll get this done over the week whenever i have some free minutes :)
<pitti> slomo: just ethereal
<Kinnison> Mithrandir: grep for " because "
<Kinnison> Mithrandir: if that produces nothing then I'm not sure what happened.
<slomo> pitti: oh how boring :) it's on my todo list now... is there a bug about this?
<Mithrandir> Kinnison: nothing since May 5th.
<Kinnison> Mithrandir: do you have any of your actions set to "blank screen" ?
<pitti> slomo: I don't know, I just spotted it in ubuntu-cve (I repaired debian changelog parsing)
<Mithrandir> Kinnison: when laptop lid is closed, yes.
<Kinnison> Mithrandir: so you unplugged ac and that caused it to do laptop-lid-close action?
<Kinnison> yargh
<Kinnison> quality
<Mithrandir> Kinnison: apparently, yes.
<slomo> pitti: hm this would get us a new upstream version... maybe i'll just backport the fixes... i'll take a closer look later
<Kinnison> Mithrandir: can you run g-p-m in --no-daemon --verbose mode and log it all to a file, and then prod around and try and reproduce it?
<pitti> slomo: as you wish, but I think you don't really want to backport ~10 security fixes for ethereal (the new upstream release does not much (nothing?) else anyway)
<Mithrandir> Kinnison: I can see if I can reproduce it first, though I don't really know where to start, given that it doesn't reproduce magically
<slomo> pitti: well... it's 0.10.something -> 0.99... sounds scary :) but i didn't take a look at the changes yet
<pitti> slomo: oh, I see, our version is even older; hmm
<pitti> slomo: thanks
<chris_^> ... just a little question - you know that nvidia modules don't work in dapper with 2.6.15-22?
<Kinnison> Mithrandir: it sounds like g-p-m's internal notion of where the lid was is confused
<slomo> pitti: np :)
<pitti> chris_^: did you update linux-restricted-modules as well?
<chris_^> pitti: yes
<pitti> hm
<chris_^> on my gaming machiene (even my dapper test machine), there is with 2.6.15-21 the error message "can't load module nvidia"...
<pitti> chris_^: incidentially I have to reboot for the new kernel (and nvidia) as well, let's see
<chris_^> no, with 15-22
<Kinnison> Mithrandir: because it does the lid-close-on-battery action when ac is removed andit thinks the lid is closed
<chris_^> with 15-21 working well
<Mithrandir> Kinnison: yeah, something like that
<Kinnison> Irritatingly it seems to lose events sometimes
<Kinnison> esp if lid changes occur during syspend/resume cycles
<Mithrandir> that might very well have happened.
<Kinnison> It's really hard to debug these kinds of breakages, and even harder to fix
<Kinnison> it'd be easier if we had a reliable way to query if the lid was open or closed
<Mithrandir> : tfheen@thosu ~ > cat /proc/acpi/button/lid/LID/state
<Mithrandir> state:      open
<Mithrandir> ?
<Kinnison> it's not always reliable
<Kinnison> stupor% cat button/lid/LID/state
<chris_^> pitti: working all well?
<Kinnison> state:      closed
<pitti> chris_^: works fine here
<Mithrandir> heh, ok
<chris_^> pitti: ohh, i think restricted modules are missing
<chris_^> just thought apt has installed new version.. grml
<pitti> chris_^: yes, I dist-upgraded, rebooted, no problem
<chris_^> pitti: i dist-upgraded, rebootet, linux-restricted-modules-2.6-15-22-686 or so is missing..
<chris_^> but installed it, worked..
<infinity> This brings up a point, actually.
<infinity> Does anyone think it would be horribly heavy-handed for me to make linux-restricted-modules-$(KVER)-$(FLAVOUR) depend on linux-$(FLAVOUR)?
<infinity> It's obviously incorrect, but it would mean that people who install LRM manually will be pretty much forced from there on it to have kernels and LRM in sync on upgrades.
<pitti> chris_^: you need to have the metapackages
<infinity> chris_^: Installing "linux-686" would solve your issue for future upgrades.
<pitti> infinity: sounds like a good circumvention of this common bug; Recommneds: maybe?
<infinity> pitti: Users don't pay attention to Recommends, so it wouldn't solve the bug, really.
<chris_^> infinity: yes, thanks.. bye :)
<infinity> pitti: My rationale was basically that people who want LRM probably want their hand held in this fashion anyway, so it's not THAT bad. :)
<pitti> infinity: only apt-get install doesn't respect recommends, right? anyway, a depends would be just fine for me
<pitti> infinity: I don't see a reason why anyone using ubuntu kernels would not want to have the metapacakges anyway
<infinity> pitti: apt-get can be told to, but it won't by default.  Even dselect and aptitude let you NOT install them, though (obviously).
<pitti> infinity: right, but if I do aptitude install -R, I probalby have a reason (i. e. opt-out instead of opt-in)
<infinity> Fair point.
<infinity> Unfortunately, several dozen HOWTOs out there say "if you need to install fglrx/nvidia, invoke "apt-get install nvidia-glx linux-restricted-modules-`uname -r`"
<pitti> still, I don't object against Depends:, it's just that using recommends: would be more correct
<pitti> uh
<infinity> And since users tend to just follow such docs blindly and have no idea what they mean...
<infinity> (And no, I can't go fix every bad doc I run across..)
<infinity> Though I'd love to.
<pitti> ok, you convinced me
<infinity> Yeah, I'll asl a few more people, so it's not just a committee of two, but I think this abuse of Depends is the lesser of two annoyances.
<infinity> (You should see all the bugs LRM gets filed when stable kernels have ABI bumps)
<infinity> s/asl/ask/
<Mithrandir> Kamion: bug 29810 should be rejected with "if you want to preseed from a floppy, make sure your initrd includes something that provides mountfloppy"?
<Ubugtu> Malone bug 29810 in debian-installer "mountfloppy package not installing" [Normal,Unconfirmed]  http://launchpad.net/bugs/29810
<Riddell> mvo: mornfall got this backtrace on qt-language-selector http://rafb.net/paste/results/1QvmkW44.html
<Riddell> mvo: installed from his chroot so might be a missing dependency
<Riddell> I can't recreate it
<mvo> Riddell: thanks, can I get a bugreport about it please? I'll check it out then
<Kamion> Mithrandir: but AFAIK our cdrom initrd *does* include mountfloppy ...
<Kamion> oh, not in breezy apparently
<Kamion> so fix released, not rejected :) I'll look up when it was fixed
<Mithrandir> Kamion: thanks.
<doko> pitti, Mithrandir: no clue about norwegian, but shouldn't language-support-no depend on myspell-nn | myspell-nb ?
<pitti> Mithrandir, doko: I can add these, no problem
<Mithrandir> pitti: econtext?
<pitti> Mithrandir: adding muyspell-{nn,nb} to language-support-no
<Mithrandir> pitti: that'd be useful, I think.
<Kamion> doko: have you noticed that openoffice.org-l10n 2.0.2-2ubuntu5 FTBFS?
<Kamion> doko: and was openoffice.org-help-lt intentionally removed?
<infinity> Kamion: He knows that it's FTBFS (it's been tried twice now).  Even mentioned investigating said FTBFS in the last distro meeting. :)
<Kamion> oh, right, missed that
<pitti> Mithrandir: done
<doko> Kamion: yes, I would like to know why, build ok outside the buildd. -lt: yes, not translated, and we fall back to english anyway
<Kamion> pitti: could you remove openoffice.org-help-lt from language-support-lt's dependencies, then?
<infinity> doko: Are you positive it builds okay in a completely clean chroot?
<infinity> doko: I can do some test builds and keep a build tree for you.
<doko> infinity: I'll recheck with my next update
<pitti> Kamion: done
<Kamion> thanks
* pitti wonders why he got Rejected emails for some old uploads and at the same time an accepted email for the current upload
<^robertj> q. who determines the stylesheet for the ftp pages
<^robertj> I still feel cheated if something is blue and underlined and not a hyperlink
<phaidros> where are the changelogs for dapper packages in the www ?
<seb128> phaidros: https://launchpad.net/distros/ubuntu/dapper/+source/<package>/+changelog ?
<phaidros> tahnx :)
<seb128> np
<seb128> not sure that's what you are looking for though
<Amaranth> changelogs.ubuntu.com works too
<janimo> Kamion: if one binary pkg from a source is NEW, does it prevent the other binary build from same source and version to enter the archive as well? Not sure if archive is lagging well behind LP publisher or the former
<janimo> libxfce4util4 should be binary NEW soon
<seb128> phaidros: other way http://changelogs.ubuntu.com/changelogs/pool
<Amaranth> either way i don't think they show up right away
<Amaranth> if a package just hit the archives and you want to know what changed you have to apt-get source it
<Kamion> janimo: yes
<Kamion> uploads happen in units of .changes files
<janimo> Kamion: ok, whenever you have time then please let it out of NEW,  I'd like to rebuilt the ~40 xfce packages against it. thanks
<janimo> also, the moment it appears in the archive, is it safe to assume the buildd daemons will see it too in the same time?
<Kamion> janimo: yes
<janimo> sivang: do not bother with xfce4-trigger-launcher, I plan to fix it FTBFS and get some bugfixes in at the saem time
<janimo> thanks
<sivang> janimo: sure thing, sorry for the noise then.
<Kamion> janimo: accepted
<janimo> sivang: np, actually it made me aware of the bug being opened (known about it outside LP). same for wavelan
<janimo> Kamion: thanks
<sivang> janimo: good to know I've done some good with going over the unmetdeps :)
<janimo> ;)
<mvo> infinity: nvidia-settings is no longer required and nvidia-glx provides all that is required?
<mvo> infinity: (bug 
<mvo> infinity: #43485)
<^robertj> does anyone else get the hibee-jibees seing blue underlined text that isn't a hyperlink?
<Fjodor> HAs anyone looked at https://launchpad.net/distros/ubuntu/+source/libx11/+bug/40761?
<Ubugtu> Malone bug 40761 in libx11 "Most X apps warn about locale not supported" [Normal,Unconfirmed]  
<carlospc> ping Kamion
<Kamion> carlospc: hello
<carlospc> hi, Raphael Hertzog point me to you 
<carlospc> i'm thinking in recoding debian-cd
<carlospc> and i just want to talk a little bit with you about that
<Kamion> you'd be better to talk with Steve McIntyre, really, unless you need to know about Ubuntu-specific details
<Kamion> Steve's had a gradual rewrite in the works for a while
<sivang> doko: package 'zope' is uninstallable in dapper currently, making zope-zshell uninstallabel as well due to unemtdeps. is there a scheduled sync for that or should dependency be changed?
<janimo> Kamion: sorry for the noise, but am not familiar with the timings of the syncs between various machines in the DC. You let the package out of NEW, and it's built but not in the archive yet.
<doko> sivang: zope was removed from dapper
<Kamion> janimo: buildds produce binary uploads, which are uploaded to the queue, and may require NEW processing
<Kamion> janimo: NEW processing moves the upload from the NEW queue to the ACCEPTED queue
<Kamion> janimo: every hour, the publisher processes whatever's in the ACCEPTED queue
<Kamion> janimo: when the publisher finishes, newly-accepted uploads are visible in the archive
<janimo> Kamion, thanks I'll paste this to a file
<sivang> doko: okay, which means then that zope-zshell should be removed as well, as the dependency will never be satisfied.
<doko> sivang: no, please request a sync
<janimo> dholbach: hi, if  you think it's ok  I can handle the libgoffice + gnumeric patch. New abiword-plugins also need the separate goffice handling as otherwise they dep on gnome
<sivang> doko: okay, you mean then that zope is replaced with zopeX.X ? (by 'removed' , that is)
<ivoks> Kamion: there is no croat layout, only hr
<ivoks> Kamion: croat was for console-tools iirc
<Kamion> ivoks: yes I'm talking about the console layout
<Kamion> ivoks: for dapper, the installer (including ubiquity) deals in console layouts and relies on X code to convert
<Kamion> we'll be revisiting that after dapper
<ivoks> ok
<ivoks> i'll file a bug
<ivoks> quick fix would be linking croat with slovene keyboard, since they are the same
<Mithrandir> sladen: around?
<Kamion> anyone mind if I upload xorg to fix some keyboard configuration bits?
<ivoks> no :)
<Kamion> s/anyone/any X maintainers/ ;-)
<ivoks> Kamion: that would be great since we are in the middle of translation marathon and it would be a shame if everything is translated, but keyboard doesn't work on install :/
<infinity> mvo: nvidia-settings was never "required", but yes, nvidia-glx completely replaces it.
<infinity> mvo: Same for nvidia-xconfig.
<Kamion> ivoks: you can stop trying to persuade me to fix the bug now :)
<ivoks> Kamion: ok
<ivoks> Kamion: sorry :)
<mvo> infinity: thanks, i was looking over the upgrade logs and noticed that sometimes the dist-upgrade has trouble with it and removes nvidia-glx instead of nvidia-settings. I guess nvidia-settings is needed for people who prefer the "nv" dirver over the glx one?
<mvo> infinity: otherwise I could add a rule to auto-remove nvidia-settings on upgrade (but I guess that is not a good idea ...)?
<infinity> mvo: No, nvidia-settings and nvidia-xconfig are to configure the binary driver.
<infinity> mvo: The newest nvidia-glx just happens to include those apps in it.
<infinity> mvo: So, iff the user is upgrading nvidia-glx, make sure it wins over those two.
<ivoks> Replaces:
<infinity> mvo: OTOH, if they have nvidia-glx-legacy installed, there's no conflict there.
<infinity> ivoks: Replaces means "overwrites"... Conflicts is correct in this case.
<infinity> ivoks: "Replaces" just means "replaces one or more files from the other package"
<ivoks> i tought overwrite is wanted method... if not conflict is ok
<infinity> mvo: If it helps hint apt's problem resolver, I can change the conflict to a conflict/replace pair, but those are "wrong", IMO (and we only ever used them in the past to work around dpkg bugs)
<mvo> infinity: hmm, currently the apt problem resolver seems to cope well with the situation. I could add a new type of rule to the dist-upgrader: "if A is installed: remove B " sort of
<_ion> Cool, the new version of gajim uses notification-daemon.
<sivang> doko: are you going to change all zope2.8 dependencies away from python-*2.3 ? currently zope2.8 is not installable, so I can't even test if the sync would help. and I feel I must test it myself before requesting the sync, or can I just go ahead, and when zope2.8 is fixed, assume zope-zshell will be as well?
<sfllaw> When our kernel panics, does it leave anything to look at somewhere?
<doko> sivang: why should I change them from 2.3?
<sivang> doko: well, (excuse me I'm way wrong with this) - zope2.8: Depends: python2.3-xml but it is not installable
<doko> sivang: right, the joy of main/universe
<bddebian> Morning folks
<doko> copy the python-xml source to python2.3-xml, and build onl ythe python2.3-xml package. 
<sivang> doko: I thought zope in general (at least, current version) is supposed to be in main no?
<janimo> sfllaw: if it locks up and you reboot then there's no log of the panic
<doko> sivang: no, because it's not validated for 2.4
<sivang> doko: ah, I see. okay, thanks for the tip, will try it out.
<janimo> sfllaw: but if it's something you can reproduce and want to have written down it can be done
<doko> sivang, Kamion: bug #35998 (ajmitch says, this is in NEW)
<Ubugtu> Malone bug 35998 in zope2.8 "zope2.8 uninstallable" [Normal,In progress]  http://launchpad.net/bugs/35998
<sladen> Mithrandir: yes
<sivang> doko: ah ha! thanks.
<Mithrandir> sladen: https://launchpad.net/distros/ubuntu/+source/syslinux/+bug/31953 ; have you observed this on any machines yourself?
<Ubugtu> Malone bug 31953 in syslinux "isolinux/gfxboot should use 640x400 not 640x480" [Normal,Confirmed]  
<neutrinomass> sladen: (feel free to ignore this if you're busy) I'm the OP of #36353 and you were trying to track down the solution but we lost it somewhere. Thanks.
<sladen> Mithrandir: not directly.  I was based on bug reports for various Acers(?) that won't get past syslinux in that resolution.  I'd knock down the priority until somebody comes up with a direct report (or I'll cross-reference it when I next come across one)
<Kinnison> Mithrandir: I may be able to use hal's knowledge of the laptop lid state to augment g-p-m's understanding
* Kinnison is currently investigating
<sladen> Kinnison: there's a patch to hal (not sure whether I uploaded it) that refreshes the status of the lid/etc on unsuspend/unhibernate
<sladen> Kinnison: debian/patches/12_refresh_acpi_states.patch if I uploaded it
<ogra> infinity, ping
<bddebian> Heya ogra
<Kinnison> sladen: I'll just look
<Kinnison> sladen: looks like we lack that one
<Kinnison> sladen: can you mail me that patch so I can look at it?
<sladen> Kinnison: http://www.paul.sladen.org/ubuntu/upload/hal_0.5.7-1ubuntu12-refresh_acpi_states.debdiff  check that it applies okay
<coz_> the bug i reported was fixed.... thanks to all who were responsible... the bug was dapper not bboting reporting that Ubuntu-root did not exist....thanks again
<bddebian> Sheesh, even ogra doesn't love me anymore :'-(
* ogra hugs bddebian 
<bddebian> :-)
<bddebian> ogra: What's up with you lately?  You swamped with edubuntu?
<zakame> hmm I can still request syncs right? =)
<bddebian> zakame: Sure you can
<zakame> hi ogra , bddebian 
<ogra> bddebian, yep and some RL stuff
<bddebian> Hello again zakame :-)
<bddebian> ogra: Ah :-)
<zakame> bddebian: cool!
<zakame> elmo: ping, please sync kdrill from debian per bug 28810
<Ubugtu> Malone bug 28810 in kdrill "undeclared dependency on libXp6" [Major,In progress]  http://launchpad.net/bugs/28810
<bddebian> zakame: I think you have to move that bug to a synce request on LP?
<bddebian> s/synce/sync/
<elmo> zakame: I don't do syncs anymore, please read up on the wiki and/or u-d-a archives about the new procedure
<bddebian> elmo: Are you still the only one for @ubuntu.com e-mail though?
<sivang> zakame: https://wiki.ubuntu.com/DeveloperResources , "Syncs" section.
<Kinnison> sladen: I had to fix one of the hunks but I'm building a test package now
<elmo> bddebian: dude, already answered you about that
<bddebian> elmo: You said No Way
<zakame> elmo, sivang, bddebian: aye, thanks :D
<siretart> elmo: I'm curious, do backports still go via you or should requests go via ubuntu-archive as well?
<zakame> hmm I gather this sync also requires an UVF exception approval?
<bddebian> zakame: If its a new version and not just a release/bugfix, yes
* bddebian goes into raging mode
<Kinnison> sladen: well it didn't break my laptop's suspend/resume
<zakame> ok
<zakame> thanks for clarifying :D
<Kinnison> sladen: I'll upload it soon
* Kinnison wants to get the g-p-m patch done too first
<bddebian> Kamion: ping?
<slomo> ogra: any news with dia 0.95?
<ogra> slomo, oh, thanks for reminding 
<ogra> not yet ...
<slomo> ogra: np :) i would love to have this in...
<infinity> ogra: Quick ping before I head t obed.
<ogra> infinity, any idea to bug 39294
<Ubugtu> Malone bug 39294 in ltsp "No ldm login on the thinclient" [Normal,Confirmed]  http://launchpad.net/bugs/39294
<ogra> seems the initscript doesnt get that its on console 7 by whatever reason
<ogra> ldm starts up fine, i see the theme coming up and then the usplash script switches back to vt 1
<ogra> the hacksaw method would be to just blacklist the usplash initscript in ltsp-build-client, but thats rather a bad workaround to the prob i think
<Kinnison> Has anyone here noticed bizarre firefox behaviour on launchpad bug listings? My cursor keeps flickering between the link ptr and the normal arrow when moving over links on bug listings)
<Kinnison> s'not always happening, just sometimes
<infinity> ogra: Check /etc/init.d/gdm, which stops usplash before it runs GDM.
<Kamion> bddebian: yo
<bddebian> Kamion: Do you have a minute for a side conversation (or the patience to deal with me for that matter?) :-)
<Kamion> bddebian: sure
<ryan_rousseau> Hello everybody!  Are there any SoC mentors here that would be interested in mentoring a project aiming to replace KWordQuiz with a full featured quizzing system with a GTK interface? =)
<joelbryan> what's a mentor?
<phanatic> ryan_rousseau: a very last minute try :)
<joelbryan> what's a SoC mentor?
<ryan_rousseau> joelbryan: a google summer of code mentor
<lucasvo> joelbryan: Google Summer of Code mentor
<joelbryan> what's that? is like a project manager?
<ryan_rousseau> phanatic: well, I submitted my proposal yesterday, and I was talking to pygi and he gave me the hint to come hunting for a willing mentor
<phanatic> ryan_rousseau: okay, i wish you luck...
<bddebian> Kamion: Did you get my /query?
<ryan_rousseau> phanatic: thanks much
<joelbryan> I made some gtk+ apps over the last days, it's the Ubuntu Welcome Center. I got an screenshots
<sladen> Kinnison: yes.  It's not just on launchpad.net pages, and if you switch to a different tab and back, it'll disappear.  I reported it as a bug somewhere
<ogra> infinity, thanks
<ogra> :)
<joelbryan> anyone like to see it?
* ivoks hugs Kamion :)
<Kinnison> sladen: okies, ta
<ryan_rousseau> joelbryan: the mentor guides a student that is working on a project for their organization over the summer 
<joelbryan> ryan_rousseau: is it someone who provide the contents for the student to code it?
<sladen> Kinnison: bug #32448 if you fancy confirming it
<Ubugtu> Malone bug 32448 in firefox "Statusbar flashes between $url and "Done." hovering over links" [Normal,Needs info]  http://launchpad.net/bugs/32448
<joelbryan> check out the Ubuntu Welcome Center, https://wiki.ubuntu.com/joelbryan?action=AttachFile&do=view&target=Screenshot-Ubuntu+Welcome+Center.png
<joelbryan> other screenshots are the attachments
<ryan_rousseau> joelbryan: I don't believe so.  I think the main role for the mentor is to monitor the student's progress, to make sure they are keeping up their end of the bargain, and to give advise when needed
<neutrinomass> There's this problem with a usb modem here, made by a local company but based on an accessrunner chipset. The kernel driver exists, but needs binary only firmware. I want to phone them to ask permission for distribution with Ubuntu : What should I ask for exactly ? And in the unlikely case that they grant it (written), will it make it to the main cd (not neccessarily dapper)? Sorry if this is OT and please redirect me to the right cha
<ryan_rousseau> joelbryan: very cool screenshots
<joelbryan> ryan_rousseau: it's the half-done work, I got alot of progress with it, w/c I have not yet made an screenshtos
<ryan_rousseau> joelbryan: what language are you using, C?
<joelbryan> yeah
<joelbryan> GTK+ 2.0 and C
<ryan_rousseau> very nice
<joelbryan> thanks
<joelbryan> There's a lot of thing you can do with GTK+
<_ion> Btw., there's a typo: "X Windows System"
<joelbryan> you can do javascript mouse-over effects in GTK
<ryan_rousseau> yeah, GTK is very cool, I mostly do PyGTK development
<joelbryan> _ion: what's the right spelling for that?
<_ion> joelbryan: X Window System
<trappist> if I'm, say, a moron and I accidentally send an email to launchpad that was meant to go to an individual, and if that message contains sensitive information, is it possible to get the comment removed from the bug?
<Chipzz> _ion: I think the initial spelling was right
<_ion> :%g/Ubuntu is build on Debian/norm fdrt
<_ion> :%s/\<alot\>/a lot/
<trappist> _ion: that one is a pet peeve of mine
<_ion> Updates...ensures  drop the s
<Chipzz> _ion: X windows system yields 314 million reults on google, while X window system only yields 148 million
<_ion> Documentations  ditto
<_ion> chipzz: man Xorg
<_ion> chipzz: See the bottom.
<flapane> i have problems with flash and realplayer 32bit on my amd64
<flapane> <flapane> http://www.ubuntuforums.org/showthread.php?p=995208#post995208
<flapane> <flapane> who can help me?
<ogra> flapane, #ubuntu
<flapane> ok
<flapane> tnx
<joelbryan> some changes in Samba description too, "allows you to connect to networks using other operating systems" should I change it to "DOS based operating system"
<infinity> joelbryan: Uhm, "DOS based"?
<infinity> joelbryan: In whose world are all CIFS/SMBFS-using operating systems "DOS-based"?
<joelbryan> infinity: I change it to windows based, still couldn't decide if I'll use Microsoft Windows based
<infinity> joelbryan: It's not just windows-based, either.
<thom> joelbryan: people using CIFS all over the place
<infinity> joelbryan: Netware serves CIFS/SMBFS.
<thom> joelbryan: it's fine as is
<infinity> joelbryan: And most UNIX operating systems now do as well.
<mvo> siretart: hi! I noticed that you can reproduce bug #38958? could you please apply http://paste.ubuntu-nl.org/13630 and tell me what the ouput is then?
<Ubugtu> Malone bug 38958 in unattended-upgrades "spawning cron error messages" [Normal,Unconfirmed]  http://launchpad.net/bugs/38958
<joelbryan> I'll use Netware, Windows, and most Unix.
<sladen> joelbryan: fantastic work, I love the screenshots.  It should save journalists alot of work :)
<joelbryan> thanks, it's press information right into your desktop.
<joelbryan> lolz :-)
<joelbryan> I still got some problems with the netstatus-applet not displaying the right interface when boot from Windows, or change the modem from different NIC's. anyone can apply this fix? Bug #42100
<Ubugtu> Malone bug 42100 in gnome-netstatus-applet "Fix the wrong device registered in netstatus applet, and automatically set it to the first working network connection." [Normal,Unconfirmed]  http://launchpad.net/bugs/42100
<siretart> mvo: err, my file currently looks like this: http://paste.ubuntu-nl.org/13631
<siretart> mvo: your patch doesn't seem to match my version, I think
<mvo> siretart: *cough* thanks
<siretart> ;)
<siretart> mvo: just tell me if I can do anything else for you
<Kamion> any Greek users here? I'd like to know what the right X keyboard configuration for Greek is
<neutrinomass> Kamion: How can I help you ?
<Kamion> neutrinomass: is XkbLayout "us,gr" with XkbOptions "grp:alt_shift_toggle" (matching our configuration for other non-Latin languages, so that you can type Latin usernames and stuff) a reasonable keyboard configuration for you guys?
<Kamion> I noticed that our xserver-xorg package doesn't automatically configure Greek properly
<neutrinomass> Just a moment ....
<Kamion> people might prefer XkbVariant "nodeadkeys" or something like that as well, not quite sure
<neutrinomass> Kamion: Sorry, I'm not exactly sure what you're talking about. I remember that adding greek was simply a matter of adding a keyboard layout .
<Kamion> ok, if you've only ever done it by means of the GNOME keyboard configurator or whatever, fair enough
* neutrinomass is entirely unfamiliar with keyboard/xkb configuration stuff
<neutrinomass> Kamion: Ok, sorry that I can't be of more assistance. :(
<Kamion> never mind, I'll fumble along as best I can, I guess
<pitti> trappist: ping
<trappist> pong
<atincjon> have an issued with ia32-libs, and was recommended to talk to doko, or mithrandir.
<BenC> what's the issue?
<carlospc> Kamion?
<carlospc> sorry, after we got a problem at the office
<carlospc> aghh,
<atincjon> ia32-libs pthread version is different than 64bit version, and cancelation has changed, making code not compile correctly
<carlospc> i mean before
<atincjon> compiling for 64bit on x86_64 works fine, but compiling for 32bit target on same machine fails due to pthread_cleanup_push macros
<Burgwork> mako, you around?
<Keybuk> yeah, you want to speak to doko or Mithrandir :)
<Kamion> carlospc: yes?
<Kamion> carlospc: did you see my earlier comments?
<atincjon> key: any idea when that could happen?
<BenC> atincjon: how are you compiling for 32-bit, and do you have ia32-libs-dev?
<BenC> are you using the linux32 command prefix?
<atincjon> using gcc -m32 foo.c
<BenC> try linux32 gcc -m32 foo.c
<BenC> just for kicks
<atincjon> no linux32?
<atincjon> n/m got it, same thing
<carlospc> ouh
<carlospc> yes
<Keybuk> atincjon: what's the actual error you get from gcc?
<carlospc> about steve
<atincjon> test.c:(.text+0x78): undefined reference to `__pthread_register_cancel'
<carlospc> i've already talked to him
<carlospc> Raphael Hertzog point to you
<BenC> atincjon: gcc -m32 -pthread foo.c
<carlospc> maybe you are looking for new features
<atincjon> anyone know a paste link? cmd is gcc -m32 test.c -lpthread
<pitti> Hi BenC, how are you?
<carlospc> i'm doing a new spec
<BenC> pitti: hey, good...how about you?
<carlospc> kamion, you can found it here: http://wiki.debian.org/debian-cd-ng
<pitti> pretty fine :)
<BenC> atincjon: use -pthread instead of -lpthread
<Keybuk> atincjon: always use -pthread not -lpthread
<atincjon> no change.
<BenC> atincjon: email me the file, if you can, bcollins@ubuntu.com
<pitti> carlos: I just fixed buildd langpack import, mesa required an override (that's why there was no tarball today); doing now
<atincjon> ok, only 14 lines
<mako> Burgwork: yes
<mako> Burgwork: a little distracted but around
<carlos> pitti: ok, thanks
<Kamion> carlospc: ok, the biggest things we do to debian-cd are (a) rip out all its dependency-handling brains and tell it to just do what germinate says instead (probably wouldn't be appropriate for Debian because germinate doesn't have anything corresponding to the concept of multi-CD sets)
<atincjon> BenC: sent
<BenC> atincjon: ok, give me a second to try it
<Kamion> carlospc: (b) add a mode to rip out more of its brains so that it can build live CDs
<Kamion> carlospc: (c) standard stuff to add Ubuntu suites
<doko> BenC: thanks.
<carlospc> i've modified a little bit germinate for guadalinex purposes
<Kamion> carlospc: if you want to have a look through the changes I made, they're in arch, 'baz register-archive http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005; baz get colin.watson@canonical.com--2005/debian-cd--ubuntu--0'
<Kamion> it's a bit of a mess to be honest
<Kamion> but works :)
<BenC> root@phoenix:~# gcc -m32 -pthread foo.c -o foo
<BenC> root@phoenix:~# ./foo
<BenC> Hello World!
<BenC> Goodbye World!
<doko> atincjon: you won't find a complete 32bit development environment; if you really want to develop for ia32, please create a chroot use it for your development
<carlospc> thanks ;) i'm in charge of the generation of Guadalinex, so i know about this a long time ago :D
<BenC> atincjon: works perfect for me
<Kamion> ok
<BenC> atincjon: I'm running latest dapper
<atincjon> guess it's time to change up then. 
<BenC> # uname -r
<BenC> 2.6.15-22-amd64-k8
<carlospc> the live cd feature will be hard to integrate
<BenC> are you running breezy?
<atincjon> yes.
<BenC> ah, sorry, can't test that quickly
<Kamion> carlospc: yeah, no good ideas on that
<Kamion> ultimately it's "get big blob of data from somewhere, shove it on CD, don't worry about adding packages to the CD"
<atincjon> BenC: thanks for sorting that out.
<carlospc> anyway, i'm trying to design something that could be easy to hack
<carlospc> i've already thinked in use some code of germinate
<Kamion> the biggest problem I have TBH is the bootloader configuration
<Kamion> it's reimplemented in totally different ways for every architecture
<Kamion> which makes it hard to unify boot options etc. across architectures
<dholbach> Kinnison: you rock! I can't wait to test the new gpm
<Kinnison> dholbach: thanks dude
<Kinnison> dholbach: my finger hurts now, but I think it's worth it
* dholbach hugs Kinnison
<Kamion> Steve's concern is primarily making it efficient, so stuff like JTE, figuring out how to pack .debs onto CD sets in the most efficient way, integrating better with mkisofs to keep track of CD size on the fly so that we don't have to have hardcoded guesses at how much space will be taken up by bootloaders
<Kamion> that sort of thing
<carlospc> ok
<Kamion> hackability as such is not my biggest concern, although fixing the boot script nightmare would help hackability a lot more than the mere fact of a rewrite
<carlospc> of course
<Kamion> though the make/shell business isn't the easiest system in the world to handle well, I concede
<wasabi> Don't suppose anybody has used swapd?
<carlospc> Well, i'm sure that python business have a lot to say here
<wasabi> Looks interesting...
<carlospc> Thanks a lot Kamion
<Kamion> you're welcome
<carlospc> i'm going to continue writing the spec
<Kinnison> Kamion: Do you remember being asked about a UVF exception for powernowd 0.97 ?
<Kinnison> Kamion: back toward the end of march?
<Kinnison> Kamion: I was trawling through my bug lists and found the stuff I did back then for it. I'm just tidying up the changelog and wondered if it'd be okay to upload
<_ion> wasabi: From what i've read, swap files shouldn't have any real overhead compared to swap partitions nowadays.
<wasabi> Yeah, they shouldn't. Just curious about the actual software package swapd. Doesn't seem to be "working". Wondering if anybody actually knows/cares.
<wasabi> Or if there's an alternative.
<wasabi> I like the idea of it creating swap files on demand when memory gets low.
<ivoks> pitti: i have one issue with locales package
<Kamion> Kinnison: it's still in my inbox, yes
<Kamion> <mdz> Are there any other changes?  Is there a proper changelog?
<ivoks> pitti: i located the source of the problem and would like to talk about it with you when you have time
<Kamion> never saw an answer to that
<pitti> ivoks: fire away :)
<ivoks> pitti: problem with time-admin is that, when you select Belgrade, Zagreb or Ljubljana
<Kamion> <Kinnison> if you want to follow up to the mail with detail, please do
<Kinnison> Kamion: aah. I don't think there's a proper changelog
<ivoks> pitti: on next start it shows Sarajevo
<Kamion> er, s/<Kinnison>/Kinnison:/
<mdz> Kinnison: I already approved it; there's a bug open
<Kamion> aha
<Kinnison> mdz: I couldn't find which bug was the approval
<ivoks> pitti: problem is in locales package, not time-admin program
<Kinnison> mdz: last related bug I found was the question from paul
<mdz> Kinnison: https://launchpad.net/distros/ubuntu/+source/powernowd/+bug/41432
<Ubugtu> Malone bug 41432 in powernowd "Only scales one CPU" [Normal,Confirmed]  
<Kinnison> mdz: aye that's the one I mean
<mdz> Kinnison: it's assigned to you
<ivoks> pitti: in locales source, there is file debian/tzdata2006b.tar.gz
<Kinnison> mdz: I know, hence I was trying to get it fixed :-)
<ivoks> pitti: wich holds info about timezones
<Kinnison> mdz: If you say you've confirm it's oakay I'll go for it :-)
<ivoks> pitti: it links Croatia, Bosnia, Serbia, Slovenia and Macedonia
<Kamion> Kinnison: the second-to-last comment in that bug is an approval, as I read it
<pitti> ivoks: hm, they all seem to be in the same time zone?
<Kamion> right, I am officially bored of keymaps for today
<Kinnison> Kamion: okay, thanks
<ivoks> pitti: they are, but Vienna is too, but when you select Vienna, it stays Vienna
<ivoks> pitti: problem is in tzdata2006b.tar.gz in locales source
<ivoks> pitti: all these states are linked to Serbia
<ivoks> pitti: but when time-admin looks for timezone
<carlos> pitti: when do you think your script will be ready?
<ivoks> pitti: it catches first on alphabeticly
<ivoks> pitti: and that's Bosnia (Sarajevo)
<carlos> pitti: I need to leave soon and want to do some basic checks to improve the data for tomorrow's export
<pitti> carlos: buildd tarball is there; just started the merging script 5 minutes ago, give it ~ 30 minutes
<carlos> ok
<carlos> thanks
<ivoks> pitti: roughly speeking, we are all in one state with 6 capitals :)
<carlos> pitti: btw, I think you told me that you were preparing a gcompris package that generates the .pot file
<carlos> pitti: it's not yet fixed or I misunderstood you
<pitti> carlos: hm, I uploaded it, maybe it FTBFSed, lemme check
<pitti> ivoks: ah, I see; is there a bug about it?
<pitti> ivoks: I need to discuss that with jbailey
<ivoks> pitti: i don't think so :/
<pitti> carlos: hm, it built, I'll check the tarball
<ivoks> pitti: it is a cosmetic bug, but it's time to fix these mistakes (yugoslavia fall apart 16 years ago...) :)
<pitti> ivoks: so, they shouldn't be symlinks, but file copies, or time-admin should respect symlinks?
<ivoks> pitti: no, in file Europe, after you extract tzdata2006?.tar.gz (located in locales/debian) every country has it's timezone decription
<ivoks> pitti: all these countrys are linked to one (in that file)
<ivoks> pitti: that was ok 20 years ago, when we had YU (and not BiH, HR, SCG, SI, FYROM) :)
<pitti> ivoks: right, high time then :)
<pitti> carlos: ah, it's because I suck and forgot the intltool build dependency
<ivoks> pitti: that's langpack-locales-*/debian, not locales/debian
<carlos> pitti: :-P
<carlos> ok
<pitti> ogra: do you have a pending gcompris upload?
<ogra> pitti, nope
<ogra> go ahead :) thanks for asking 
<pitti> ogra: ok, I need to add a b-dep; I assume I can upload without disturbing you then?
<pitti> ok
<Kinnison> dholbach: the hal, g-p-m and powernowd stuff should all be building in this cycle and be published in the next
<dholbach> Kinnison: super!
<pitti> carlos: fixed package uploaded
<carlos> pitti: ok, thanks
* lamont considers the pros and cons of renabling nfsv4 support in mount now that the bug preventing it from working is fixed.
<lamont> mdz: thoughts?
<pitti> carlos: script finished
<carlos> pitti: ok, thanks
<carlos> pitti: you got 3 new translation domains?
<pitti> carlos: yes, for mesa, and probably from seb128's gnome fixes
<carlos> pitti: so you need to filter them out, right?
<mdz> lamont: what bug?
<_ion> Yay. \o/
* _ion managed to make notification-daemon open the notifications to the first xinerama screen.
<Keybuk> heh, for a second there I was reading that as a window manager bug ...
<lamont> mdz:   * Release NFSv4 support. Closes: #302420, #239031, #290873
<lamont> mdz: ubuntu 43581 and 27425
<lamont> which were rejected this AM by someone
<lamont> Laurent Bigonville <l.bigonville@edpnet.be> to be specific
<lamont> mdz: the bug that was keeping it out was that it broke nfs-user-server (v2) because of some sloppy error handling in probing for version 4, 3, 2.
<_ion> Do you think the best behavior for notification-daemon is to open the notifications on the first xinerama screen, or would it be necessary to make the screen configurable in order for the patch to be accepted?
* lamont gets dragged away to lunch.  back in a while
<LaserJock> anybody know anything about sponsorship for Paris?
<Surak> Hello
<Surak> I've been reading google SoC wiki - https://wiki.ubuntu.com/GoogleSoC2006 but there are no directions on how someone can apply to some project. 
<Burgwork> Surak, you have 7 hours, so start writing quickly
<Surak> it's not me, but someone here. He already has it written, but doesn't know where to apply
<sladen> Kinnison: ta for doing the upload
<Burgwork> Surak, ah, hmm. #gnome-hackers on gimp.net is currently talking about it
<Kinnison> sladen: no problem
<mdz> lamont: that sounds fine then
<mdz> lamont: nobody in their right mind uses nfs-user-server anymore anyway ;-)
<mdz> LaserJock: the wiki page should have information about sponsorship
<LaserJock> mdz: It seems to just have a signup sheet, no contact info or info on when the decisions will be made
<LaserJock> which is pretty important for people wishing to be sponsored
<mroth> BenC: The ipw3945 driver in -22 is currently with broken WPA support (not properly reporting card's capabilities to the system).  There appears to be a bug fix for it (and some other things) upstream (see bug 41214).  Think there is a chance to get the WPA patches in, or perhaps just the entire version of bug fixes?
<Ubugtu> Malone bug 41214 in linux-source-2.6.15 "ipw3945 WPA Patch" [Normal,Unconfirmed]  http://launchpad.net/bugs/41214
<sladen> mroth: if you can pull out the necessary patches (likely very simple if it is just changing the capabilities advertised by the driver), then that would make it easier to fix
* bddebian is glad he doesn't have a bcm4xxx wireless card :-)
<ogra> mdz, oh, sorry, my changelog entry was confusing, indeed i stop usplash it in the ltsp-client.init script (which i use to think of as ldm's initscript)
<ogra> in fact i just copied the code form the gdm initscript to the ltsp-client initscript
<bddebian> Why is libkwiki-perl arch all but only has an amd64 build?
<BenC> mroth: I'll see
<mroth> sladen: looks like everything else in the version bump is just a bug fix, it might be simpler just to go with the most recent version?
<Fjodor> Anyone looked at #40761?
<mroth> although if not, the patch is already at http://www.bughost.org/bugzilla/show_bug.cgi?id=1013 , it appears to be a massive 4 lines of code changed :-)
<sladen> mroth: can you file that analysis as part of the bug report
<mroth> sladen: its already in bug 41214 in the first two posts, thats where I found it myself
<Ubugtu> Malone bug 41214 in linux-source-2.6.15 "ipw3945 WPA Patch" [Normal,Unconfirmed]  http://launchpad.net/bugs/41214
<sladen> mroth: ah, okay
<mroth> if you look at the changelog I linked though, bumping up to 1.0.2 would probably be desirable, or at least 1.0.1 which seems to fix a few other capabilities bugs
<mroth> (1.0.2 and 1.0.3 are both single bug fix releases)
<bddebian> arrgh and why can't LP find the package libkwiki-perl?
<bddebian> Oh, it's NEW
<BenC> mroth: ok, 1.0.3 is in my tree now, so next upload
<mroth> BenC: neat.  is there a pre-build you want me to test, since the cycle for -23 binary upload will probably be a while.
<BenC> mroth: not really, but you are welcome to check out git and do a test build
<mroth> BenC: sorry, not familiar with the git process, but I'd be happy to help out and give it a try if someone points me towards the documentation
<mdz> ogra: ok, good
<BenM> seb128, ?
<seb128> hi BenM
<BenM> hey
<BenM> so, about gnome-panel, there's a nice new thing in g-s-m to help you measure
<seb128> ah, nice :)
<BenM> because of the new version Daniel uploaded, the `writable memory' column is an accurate measure of private rss
<BenM> i'll blog about this sometime tonight
<seb128> cool
<seb128> I've tried to patch gnome-panel for the applets yesterday
<seb128> but had some issues with the autotools patch
<BenM> oh, yeah
<BenM> that was nasty
<BenM> i hacked my install
<BenM> i did some serious manual tinkering to get a demo for myself
<seb128> (since we modify the Makefile.am...)
<BenM> it involved forcing dpkg
<BenM> to avoid figuring out how to work with debs :-)
<seb128> ;)
<seb128> running the autogen.sh should work (it does usually)
<seb128> I'll have an another try now
<BenM> cool, thanks
<BenM> i really appreciate you doing the work to get this into dapper
<BenM> btw, between this patch, and the icon cache work
<BenM> I think the default gnome memory usage is less than 100mb
<seb128> nice :)
<BenM> i was able to get it down to that at one point
<seb128> do you have a such patch for the trash applet?
<BenM> actually, no
<BenM> i mean, it should be copy&paste
<BenM> (the mixer applet might be another target...i don't know how far you want to go; the mixer applet sucks though because it loads the whole fucking gstreamer framework)
<seb128> I think we will keep it to that for dapper, I might have a try on the trash applet, but dapper is for soon and we have other bugs to fix too ...
<BenM> trash applet is surely doable
<BenM> that'd be a good win
<BenM> (agreed about other bugs though... there are a few major ui things. the tabs in pango is pretty visible, also the stupid metacity windows)
<BenM> hrm, thinking about the g-s-m thing. i wonder if Writable Memory should be made the default number
<seb128> BenM: so basically I look to the "Writable Memory" column of the new gnome-system-monitor?
<BenM> yes
<BenM> i'm 99% sure that's right
<seb128> cool
<seb128> looks like
<BenM> (my mirror hasn't updated yet, i'll confirm for you tonight)
<seb128> wnck-applet has 3.9MB
<BenM> if you run my smem.pl script
<seb128> which matchs what you described
<BenM> and the private dirty rss is the same
<BenM> yeah
<BenM> i owe whoever patched that a beer if he's at guadec
<seb128> what "tabs in pango"? for evolution mail compose you mean? or does it affect something else too?
<BenM> i think it may affect otherapps
<BenM> i could try
<seb128> dholbach and I will likely be at GUADEC :)
<BenM> or is it only gtkhtml
<seb128> I know about it for gtkhtml and pinged upstream about it yesterday
<BenM> it might be just that
<BenM> i saw the ping
<seb128> if that's an issue with an another app let me know
<BenM> i might be imagining things
<BenM> i'm a bit overloaded at the moment ;-)
<seb128> hehe
<seb128> we know that too (being overloaded) ;)
<BenM> if i had more time, i'd actually work more on gnome perf
<BenM> rather than just bitch :-)
<seb128> I'll ping behdad tomorrow about that gtkhtml issue to know where he suggests to do the change
<seb128> I would not call that "just bitch", you actually then patches too ;)
<BenM> i copied the patch from suse's rpm
<seb128> hum
<BenM> granted, i wrote it and gave it to federico
<seb128> is that supposed to drop the binaries for those?
<BenM> a while ago :-)
<BenM> hrm?
<seb128> it changes them to a .so, right?
<BenM> yes
<BenM> and another g-p package takes /usr/lib/*
<seb128> k, the package built correctly
<BenM> be careful :-)
<BenM> this is where i used --force :-)
<seb128> but I got the binaries dropped, so I was wondering ;)
<BenM> so, for g-p, would changing writable memory to be the default memory related column be in the realm of possabilities for dapper
<BenM> maybe with a name change
<BenM> the column actually *means* something
<BenM> (much more than can be said for other stats)
<tseng> hi BenM 
<BenM> hey!
<seb128> BenM: yeah, we changed the CPU column to use PU instead of CPU Time today, so no problem for that :)
<BenM> ok, i'll file a bug
<BenM> actually, we should really do Writable Memory + X Memory
<BenM> that  will help with say....firefox :-)
<lamont> mdz: OK.  uploading util-linux_2.12r-4ubuntu5 with just the nfsv4 support changed, unless you scream soonish.
<mdke> seb128: syntax highlighting not working in gedit for this: http://pastebin.com/705996 Do you need a bug report?
<BenM> ok, filed https://launchpad.net/distros/ubuntu/+source/gnome-system-monitor/+bug/43677
<Ubugtu> Malone bug 43677 in gnome-system-monitor "Meaningful default memory stats" [Normal,Unconfirmed]  
<BenM> that was quick
<seb128> mdke: what is wrong about it? how did you name it?
<seb128> BenM: thank you ;)
<BenM> np
<BenM> i should be around this week, if you need anything else
<BenM> next week i'll be really busy
<BenM> first week at google
<mdke> seb128: no syntax highlighting. I didn't name it, it's a file from docbook-xsl
<seb128> mdke: naming it .xml works fine
<Treenaks> :set syntax=xml
<Treenaks> works too
<mdke> seb128: try: /usr/share/xml/docbook/stylesheet/nwalsh/fo/pagesetup.xsl
<mdke> that was the file
<BenM> seb128, thanks again for all the work
<seb128> mdke: that's likely because application/xslt+xml is not listed as known type by gtksourceview, I'll fix it
<seb128> BenM: you're welcome, thank you for the patches for that ;)
<mdke> seb128: :)
<slomo_> j^_: ping?
<j^_> slomo_ pong
<slomo_> j^_: what name do you want in the changelog for your seahorse patch? :)
<Keybuk> heh, now this is an answer I've always wanted :)
<thom> heh
<Keybuk> "Thanks to j^ for" is lacking something
<j^> hehe, j^ or j is fine with me, if you need names Jan Gerber should do
<slomo_> ah Keybuk :) do you have an idea why nm-applet wouldn't really show up in the notification area but only a bit of space is reserved for it? maybe an icon problem but i wasn't able to find the cause on a friends laptop where this happens... i know of at least two people with this problem but don't have it myself
<seb128> mdke: gtksourceview fix uploaded
<Keybuk> slomo_: it doesn't start at all if there's a missing icon 
<Keybuk> could you install the -dbg version and figure it out?
<slomo_> Keybuk: i already did... everything wents fine and it runs the gtk main loop forever only the icon isn't shown (but you see that some place is reserved for it, maybe 10 pixels)
<Keybuk> no idea :-/
<mdz> lamont: fine by me
<Keybuk> seb or dholbach may be more help
<Keybuk> they know gnome
<seb128> slomo_: do you have a transparent panel?
<slomo_> seb128: nope... only more or less the default settings (and it isn't caused by the used gtk or icon theme)
<seb128> so no idea
<slomo_> ok *sigh* i'll try to continue debugging it tomorrow
<jlhamilton> are there jigdo files for the dapper live cds?
<Mithrandir> no, it wouldn't make any kind of sense.
<Lure> jlhamilton: but rsync is quite efficient on them if you have previous (older) live CD
<FunnyLookinHat> but how many people would that apply to?  ; )
<OetmetG> I want to develop an application that disables a synaptic touchpad when a USB mouse is attached to the laptop... what technologies should I learn? DBUS? HAL?
<Keybuk> X would be the first one you'd have to learn
<Keybuk> you'd have to rewrite it so that it's possible for X to react to new devices
<Keybuk> right now it can only use the devices plugged in when it starts
<OetmetG> X?
<Keybuk> X11
<Keybuk> the thing that lets you move the mouse and point it at windows, etc.
<Keybuk> Xorg if you prefer
<OetmetG> isn't HAL a hardware layer on the top of X11?
<tseng> no
<Keybuk> no
<Keybuk> HAL is just a list of the plugged in hardware
<tseng> its a hardware layer on top of hardware
<Keybuk> which is largely pointless in Linux ;)
<Keybuk> but it also does give dbus events for hardware changes
<OetmetG> I have developed using X11.. but it's horrible
<OetmetG> I don't want that
<tseng> there are higher level toolkits than libx11
<Keybuk> you wouldn't have to develop *using* X11, you'd have to develop X11 itself
<Keybuk> ie. make fundamental changes to the X server
<OetmetG> wait
<OetmetG> using synclient TouchPadoff=1
<OetmetG> disables the touchpad
<OetmetG> I just want to make a front-end to that
<mjg59> Only if the X config is modified
<Keybuk> that assumes a specific X configuration
<OetmetG> the main problem is detect when a USB mouse is connected
<mjg59> OetmetG: Hal is the right layer for that
<Keybuk> it assumes that there's an input device for /dev/input/mice with the standard driver
<OetmetG> yes, only if the x config has the right conf
<Keybuk> and it assumes the synaptics touchpad has a separate input device
<Keybuk> and that shmconfig is enabled
<Keybuk> etc.
<Keybuk> also I'm not sure that TouchPaddoff=1 actually really turns it off
<thom> and that shmconfig's not a gaping secuity hole
<OetmetG> so I just need to know if a usb mouse has been attached (using HAL?) and then execute the synclient in the "background"
<Keybuk> on some laptops it just turns off the driver
<Keybuk> and the touchpad still works, because it's sending ordinary mouse events through /dev/input/mice
<OetmetG> mmm
<OetmetG> well I don't want to develop a generic application.. only a front-end to synclient and synaptic touchpads
<Keybuk> anyway, all that aside, if all you want to do is run that command whenever a mouse is plugged in, and an opposite command when the last mouse is unplugged, then yes -- you want to use HAL
<OetmetG> nice.. HAL and GTK# would be right
<Keybuk> remember that you'd also need to set the initial state -- if there's a mouse plugged in when X starts, you don't get a HAL message for that
<OetmetG> yes
<OetmetG> you're right
<OetmetG> well I guess I'd have to learn HAL
<OetmetG> thank you Keybuk
<OetmetG> I have a clearer idea now
<mdke> seb128: thanks a lot, I'll check it works
<seb128> mdke: np
<dholbach> Riddell: so Ellen will be Kubuntu hacker soon? :)
<jlhamilton> i still think that jigdo is more convenient than rsync
<Riddell> dholbach: are you reading planet kde?
<dholbach> Riddell: yeah
<jcole> we want to provide a kernel (with corresponding restricted modules package) to our employees that has the infamous REGPARM enabled for our VPN software apani netlock to work... what is the "streamlined" and clean way to do this? i've looked at the wiki and it doesn't mention how to simply rebuild the restricted modules package and when i rebuild a kernel, it's name is kernel-image-... not linux-image-... like the stock ubuntu kernels
<jcole> ah, i think dpkg-buildpackage makes a linux-image-... and make-kpkg makes a kernel-image-...
<Riddell> Kamion: did you get my e-mail about the isolinux splash?
<jcole> "OpenLogic to Pay Open-Source Developers for Support Services" - http://www.eweek.com/article2/0,1895,1958756,00.asp
<dholbach> night
#ubuntu-devel 2006-05-14
<sfllaw> dholbach: Night.
<mdke> sivang: ping
<boubbiii111> could someone help me with installing driver for a network card please
<HrdwrBoB> not in here
<boubbiii111> where do you thing 
<HrdwrBoB> go to #ubuntu
<boubbiii111> please
<sivang> mdke: pong
<mdke> sivang: what font does hebrew use?
<sivang> mdke: there are a couple
<mdke> in Ubuntu?
<sivang> mdke: see 'culmus' in the repo
<sivang> mdke: in contains the fonts we use in ubuntu
<mdke> not installed by default?
<sivang> mdke: installed by default
<sivang> mdke: promoted to main and included since warty IIRC
<mdke> sivang: it is not installed by default here.
<sivang> mdke: ah, okay, but it's still in main. do you want it to be installed by default?
<sivang> :)
<mdke> no, no. I just wondered if hebrew works ootb
<sivang> mdke: well, I've been using dapper on this laptop, and it appears that culmus was not installed as well
<sivang> mdke: however, I used hebrew ootb before installing culmus now
<mdke> right, so there is something else
<sivang> mdke: with no problem (web sites, input, etc)
<sivang> mdke: yes , must be
<poimen> what is the diference in the flight releases and the beta LTS ???
<mdke> poimen: have a look at http://www.ubuntu.com/testing
<poimen> ok but why if we were on beta releses it went back to aplha?
<sivang> mdke: I wonder what are the bits who make it work nonetheless
<mdke> poimen: no, flight 7 is post-beta
<poimen> so it is almost a rc?
<mdke> poimen: it is a release, which is better than the previous one. That's the idea, anyway, I think
<poimen> ok
<LaserJock> it does seem sort of weird to have Flights after Betas
<LaserJock> I've been thinking of it like Flights -> Betas -> RC -> Release
<poimen> yeah that was whit I got confused
<poimen> why*
<LaserJock> it seems they are not chronological, but perhaps more related to how well tested the releases are
<ploum> who is in charge for Ubuntu SoC ? 
<ploum> (the admin of the SoC )
<mdke> JaneW, I believe
<bddebian> Howdy peoples
<HiddenWolf> anyone awake still?
<LaserJock> of course
<HiddenWolf> Happen to know how I can check if my mouseevents are coming in doubled?
<HiddenWolf> Singleclicks get treated like doubles half the time.
<HiddenWolf> ack
<HiddenWolf> upgrade messed with my doubleclick timeout. :)
<bddebian> heh
<sivang> HiddenWolf: ha! then I am not crazy!
* sivang hugs HiddenWolf 
* HiddenWolf hugs sivang
<HiddenWolf> *chuckle*
<sivang> night all
<HiddenWolf> Mithrandir: you asked me to see if the libnotify positioning bug was fixed, I guess so, lotsa popups play nice: http://hiddenwolf.org/media/files/notify-spam.png
<HiddenWolf> Mithrandir: closed it, just thought the picture might be funny. :)
<Mithrandir> HiddenWolf: heh. :-)
<fabbione> jdub: piiiing?
<jdub> fabbione: i'd say pooooong, but it sounds bad ;)
<fabbione> jdub: dude.. i did ask you about your G3 toilet seat test a few days ago.. so what can you tell me about it?
<jdub> fabbione: it's not starting up!
<fabbione> what is not starting up?
<fabbione> X?
<fabbione> or the entire cd?
<jdub> fabbione: i think there's something wrong with the power adapter - i'm going to borrow a friend's one to see
<jdub> the entire machine
<fabbione> ah crap
<fabbione> jdub: i really really need you to test that stuff yesterday
<fabbione> do you think you can speed it up?
<jdub> hmm; ok - i'll see what i can do
<fabbione> thanks
<pitti> Good morning
<pitti> fabbione: hm, so what shall this hal patch do again? in his own reply, the reporter seems to indicate that there is something wrong with his patch, and David didn't answer either
<fabbione> pitti: you want to talk with benh here on freenode
<fabbione> it's an endianess issue
<fabbione> pitti: benh in #xorg-devel
<pitti> fabbione: ah, I see that hal upstream applied parts of his patch, which looks like the endianess fixing part; that looks fine
<fabbione> pitti: ok great
<pitti> siretart: ping
<pitti> siretart: do you have some minutes to merge libphp-adodb from Debian? the new upstream version fixes a couple of vulns (but I can't request a sync, the dependencies differ in ubuntu)
<dholbach> good morning
<pitti> fabbione: tested the patch on my ppc, works nicely
<pitti> hi dholbach 
<fabbione> pitti: ok cool
<dholbach> hey pitti
<siretart> pitti: I can have a look at it, okay
<pitti> siretart: thanks
<pitti> hey hey carlos 
<carlos> morning
<siretart> pitti: ok. I merged the debian upstream. 
<siretart> err, the latest debian version 4.72-0.1, that is
* pitti hugs siretart 
<siretart> pitti: the thing is, I think this needs a uvf exception report anyway
<pitti> siretart: motu-uvf?
<siretart> dholbach: perhaps you can say something?
* pitti bats his eyelashes, looks at dholbach and kindly asks for libphp-adodb UVF exception
<dholbach> i have no idea what you are talking about?
<siretart> dholbach: it is basically a security update, do I need to create a complete report for that?
<pitti> dholbach: libphp-adodb, new upstream, fixes ~ 5 vulnerabilities
<dholbach> no, if it's reasonable and works for you
<siretart> dholbach: updating libphp-adodb from 4.64 to 4.72
<siretart> dholbach: see http://changelog.debian.net/libphp-adodb for changes
<dholbach> we don't need to create bureaucratical processes around it
<dholbach> I trust pitti with that - I said it before.
<siretart> all right. uploading in a sek
<pygi> Mithrandir: ping
<Mithrandir> pygi: yes?
<pitti> carlos: question about bug 39064 - since when you need .desktop files in Rosetta?
<pygi> Mithrandir: have you looked at n-a application then?
<pygi> and asked for mentorship?
<carlos> pitti: I don't need .desktop files in Rosetta
<pitti> carlos: so you mean the strings of the desktop file aren't in ubiquity's pot file?
<Mithrandir> pygi: yes, I've looked a bit at it.  I'm not done reviewing.
<pygi> Mithrandir: oki, just wanted to know :)
<pygi> thanks
<pitti> carlos: argh, I thought that bug was from you, sorry; so I guess the POT file is just incomplete then
<carlos> pitti: I don't mean anything, I don't understand the questions ;-)
<carlos> pitti: yeah, i didn't file that bug
<pitti> alright, nevermind then, I'll check this with Kamion 
<carlos> pitti: https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/40927
<carlos> pitti: that bug sounds like you forgot to fix something with the .desktop & gettext integration
<pitti> carlos: yes, seems so; I guess nautilus uses the patched libgnome correctly, but doesn't set the locale right
<carlos> pitti: perhaps nautilus is not using that .desktop parser?
<pitti> carlos: I doubt it; if it wouldn't use the patch, it would just ignore X-Gettext-Translation-Domain
<carlos> pitti: perhaps the portuguese translation comes from Ubuntu
<carlos> and is only available from the .mo files
<pitti> carlos: no, that bug is real, I just checked with the german one
<carlos> oh, ok
<pitti> Kamion: do you have a minute to talk about bug 40246?
<pitti> Kamion: erm, bug 39064, sorry
<pitti> Kamion: (ubiquity .desktop file translations)
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: i am not sure i understand bug #15076
<doko> bug 15076
<fabbione> the bot seems dead
<doko> ahh :-)
<doko> fabbione: it seems, that xresprobe get's it right now, at least xorg.conf is configured correctly, the current (related) problem is, that although nicely configured, X starts with 640x480, the driver claims that this is the (unconnected) analogue D-Sub output. I was unable to get anything higher than 640x480 with the ati driver, the fglrx driver does use the configured settings and works fine (although the kernel crashes with th
<doko> e fglrx driver when leaving X)
<fabbione> doko: can you try to add the HorizSync and VertRefresh entries to your xorg.conf?
<fabbione> i find it very strange that xorg.conf is configured properly
<doko> will do later, requires a reset :-/
<fabbione> doko: ok thanks
<Mithrandir> fabbione: fwiw, I can reproduce the "X is in 640x480 mode most of the time" bug with a Radeon 8500.  If there's anything I can do to help you debug it, please tell me.
<carlos> Riddell: hi, around?
<Riddell> carlos: hi, yes
<carlos> Riddell: any news about the kde translation domains I asked?
<carlos> Riddell: are those valid translation domains or should I just ignore them?
<siretart> mvo: hi. say, is it already possible to configure allowed origins in unattended-upgrades?
<Riddell> carlos: I'll look into them today, promise :)
<carlos> Riddell: ok, thanks
<mvo> siretart: hm, it was not designed for it, but thinking about it, it is a very good idea to add it (and makes me wonder why it wasnt discussed during spec writing)
<siretart> I added     allowed_origins.append((distributor,"%s-updates" % archive))
<siretart> locally for now. but I saw a comment about addind a apt.Config variable for that
<siretart> I've noticed also a 'blacklist' variable. perhaps it makes sense to make that configurable as well.. hm
<fabbione> Mithrandir: the last one i checked was due to missing Horiz and Vert info that triggers the issue when the monitor is turned off or doesn't answer a DDC probe in time (like from sleep or something)
<fabbione> Mithrandir: check your log and you will see that
<Kamion> pitti: sure, I hadn't got round to looking at that bug yet really
<mvo> siretart: do you mind to file a bug about it to remind me? that would be cool
<Mithrandir> fabbione: I see it on the live cd most often, and the display is most assuredly on.
<Kamion> suppose I need to look at it reasonably urgently
<pitti> Kamion: I know what needs to be done in principle, but I'm not terribly familiar with the packaging
<fabbione> Mithrandir: is it DVI?
<Mithrandir> fabbione: nope
<Kamion> pitti: what needs to be done? xgettext to generate a pot file?
<pitti> I /msg you
<viviersf> pitti, do you know if there is any security risks in running smbumount with setuid ?
<fabbione> Mithrandir: can you check in the Xlogs if there is any DDC failure or put it somewhere?
<pitti> viviersf: it should be pretty safe, unless you rip away a mounted file system underneath another user who wants to use it
<pitti> viviersf: but I hope that smbumount checks for that, similarly to umount
<viviersf> k thx
<siretart> mvo: I just filed 2 bugs about unatttended-upgrades and subscribed you to both
* mvo hugs siretart
* raphink hugs siretart && mvo
<slomo_> infinity: please give-back gajim on hppa... i don't know _what_ this error is but it should be solved be retrying ;)
* siretart hugs raphink and mvo back :)
<raphink> :)
<pitti> hi seb128_ 
<seb128_> re pitti ;)
<sivang> re folks :)
<enyc> Erm... are any dapper developers having trouble submitting print jobs to SMB printers? -- "Paused: /usr/lib/cups/backend/smb failed" happens where it did not in breezy... ?
<pitti> enyc: this should be the very well known samba bug, infinity is on it
<enyc> pitti: excellent... is theere a launhpad bug entry?
<pitti> enyc: bug 39484
<Ubugtu> Malone bug 39484 in samba "cups smb printing backend no longer works" [Major,In progress]  http://launchpad.net/bugs/39484
<enyc> Ubugtu: pitti: thankyou all... I can copy that address teo persons with problem and be confident it will be fixed ;-) thankyou for quick reply ;-)
* enyc is puzzled why theora library never got updated to  alpha5.. a bit late to fix now ;-(
<j^> enyc dapper has (0.0.0.alpha5-0ubuntu2)
<enyc> j^: oh hrrm *looks*
<enyc> j^: oh yes... oops.. I must have been looking at the replaced version ;-( sorry
<j^> would be nice to get theora-mmx in, but that can wait for the next release which will also work on amd64
<dholbach> Kinnison: upstream's first guess was that on_show() was not called with the installer patch - I forwarded him your script and will keep on asking him
<Kinnison> dholbach: of course it's not called
<Kinnison> dholbach: that's on_show for the window
<Kinnison> dholbach: and there's no window when it's in a pug
<Kinnison> plug even
<dholbach> hum
<Kinnison> hence when I was trying to fix it, I was concentrating on getting the routines called at the right time. Unfortunately with bunches of the menus etc not being present, calling the extant routines caused segfaults all over the place and I got very lost trying to fix it all up
<Mithrandir> uh, did we change to a gnome-foot-splash for gdm?
<Mithrandir> fabbione: ok, the 640x480 problem reproduced, http://err.no/tmp/Xorg.0.log is the log
<Mithrandir> fabbione: interestingly, casper/dpkg-reconfigure xserver-xorg detected the resolution correctly.
<fabbione> Mithrandir:
<fabbione> (II) RADEON(0): Generic Monitor: Using default hsync range of 28.00-33.00 kHz
<fabbione> (II) RADEON(0): Generic Monitor: Using default vrefresh range of 43.00-72.00 Hz
<fabbione> exactly as i said
<dholbach> Mithrandir: gnome foot splash for gdm?
<fabbione> either the monitor doesn't return DDC fast enough.. or something blocks the call
<ogra> dholbach, the gdm artwork dependencys were changed to suggests
<ogra> (dunno why)
<fabbione> Mithrandir: can you try to boot a few times without usplash and see if it that solves the issue?
<dholbach> ogra: ah yes
<Mithrandir> fabbione: see xorg.conf in the same directory; xresprobe gets it right.
<Mithrandir> fabbione: so it's just X being silly.
<Mithrandir> fabbione: sure, I'll try sans usplash
<Mithrandir> dholbach: blue thing, largish.
<ogra> gnome default theme ;)
<fabbione> Mithrandir: the ddc is probed when X starts.. xresprobe does it far away
<ogra> Mithrandir, is any artwork package installed ?
<enyc> hrrm that freq. range is only enough for 640x480
<dholbach> Mithrandir: i think mdz re-added ubuntu-artwork to the seed
<enyc> I use 1216x912 at 99hz using 96kHz h-sync....
<Mithrandir> ogra: unsure, I just rebooted.  It's the current live cd.
<Kamion> dholbach: I did
<ogra> Mithrandir, gdm only suggests the artwork packages now
<Kamion> s/suggests/recommends/
<ogra> so the seed might be a bit behind
<dholbach> Kamion: ah ok, thanks.
<ogra> ah, recommends even :)
<Kamion> I'm just preparing a -meta upload now
<enyc> Dapper -- uses ubuntu-desktop as the basi install package on desktop systems still? or is this now ubuntu-stardard or otherwise?
<ogra> -standard installs standard software, -desktop the desktop :)
<enyc> kk
<enyc> well
<Mithrandir> fabbione: fwiw, I couldn't reproduce it on i386.
<enyc> ubuntu-desktop installs pcmcia-cs now.. but ...  * Linux >= 2.6.13-rc1 requires pcmciautils instead of pcmcia-cs
<enyc> fpi: I just upgraded from breezy to dapper as-is at the moment and I had system crash (was still running 2.6.12-686-smp from breezy at the time) anh pcmcia loaded and crashed the system... I had to boot with   init=/bin/bash  and  chmod -x /etc/init.d/pcmcia  in order te get in and  dpkg --configure -a  to resume setup packages
<enyc> fyi not fpi ;-)
<enyc> this looks like an upgrade race-condition/crash ;-(
<Kamion> enyc: pcmcia-cs is there still because some older cards require CIS firmware that's only in pcmcia-cs at present
<enyc> Kamion: kk but sirely if ubuntu-desktop specifies pcmcia-cs it should also get pcmciautils in there?? as thats apparetly needed for the dapper kernel _anyway_
<Kamion> enyc: pcmciautils is in ubuntu-minimal
<Kamion> and pcmcia-cs is *not* in ubuntu-desktop
<enyc> thats interesting... maybe i dont have ubuntu-minimal installed
<Kamion> (I just uploaded it, so I'm certain of that)
<Kamion> AFAIK it has never been
<Kamion> it was installed by the installer if you had PCMCIA hardware
<enyc> i see ;-)
<enyc> i see ;-) but ubuntu-base installs the -minimal now anyway.. ;-)
<enyc> I idint have ubuntu-base installed!!! that doesnt help upgrades... 
<Kamion> ubuntu-base dates from hoary; we split it up in early breezy
<enyc> heh... to make diffirent base sysytem insatlls for different circumstances more convinient...
<enyc> yes...
<enyc> Ill leave you to it ;-)
<StevenK> -base got split into -miminal and -standard?
<Kamion> StevenK: yes
<tashiro_work> doko: Hi. Can you please try to execute gaphor and say if it works for you. It seems that it doesn't start http://rafb.net/paste/results/WoHStj82.html
<Mithrandir> fabbione: ta, managed to reproduce without splash too.
<fabbione> Mithrandir: sorry.. there is no way i can fix that.. really
<fabbione> Mithrandir: not without forcing syncs to everybody
<fabbione> and people will get upset for other reasons
<fabbione> there is no win2win situation here
<Mithrandir> fabbione: I'm considering forcefully writing the sync ranges for casper at least, but that'll be problematic with ubiquity installs. :-/
<fabbione> Mithrandir: up to you, it will break a lot of other stuff
<fabbione> or people will complain that their 200Hz monitor will go only 60/75
<fabbione> not that it makes any damn difference
<Mithrandir> fabbione: it will break monitor replugging, nothing else.
<fabbione> but i am not dealing to listen to them complaining either way
<Kamion> pitti: ok, ubiquity .desktop files should be i18ned in my bzr branch now
<pitti> yay, great
<Kamion> after running gettextize, intltoolize, everyfreakingize
<fabbione> Mithrandir: a bunch of bugs are all about our defaults being too conservative.. like running at 60Hz
<pitti> Kamion: could you figure out how to automakeify it, or the manual approach?
<fabbione> Mithrandir: i don't mind it.. since our eyes can NOT see more than 15pfs anyway
<pitti> Kamion: oh, even better :)
<Kamion> pitti: did it with automake
<Kamion> pitti: the po/Makefile thing you had was because gettextize needed to be run too
<fabbione> Mithrandir: people apparently do, because they still believe it makes a difference
<Mithrandir> fabbione: modern monitors at 60Hz or even 75Hz are painful to look at, though.
<Kamion> and gettextize and intltoolize sort of half-conflict (both install po/Makefile.in.in) so it was very confusing
<pitti> Kamion: . o O { do we need a meta-meta-script justdoitize? }
<pitti> ah
<fabbione> Mithrandir: that's why we don't force the syncs..
<Mithrandir> fabbione: uh, writing the sync ranges means you actually listen to what the monitor claims it can do and X then just uses that blindly.  That works quite well, except in the "I plugged in a new monitor" case.
<fabbione> Mithrandir: no it's the opposite.. when we get a ddc info back we don't write the range since we can detect it at real time. We write it down with safe defaults when we cannot detect it or in special cases.
<Mithrandir> fabbione: except that X for some reason fails to detect it while ddcprobe works, yes.
<fabbione> Mithrandir: oh yes.. i see what you mean
<fabbione> well for the live cd could be done.. yes
<fabbione> i am not sure i want to do that on normal install tho
<fabbione> because of the replug
* fabbione starts to radiate hates towards X
<fabbione> Mithrandir: hounestly at this point in time i am not sure there is a sane way to fix this.
<Mithrandir> fabbione: I'll poke the ATI driver to see how hard it is, at least.
<fabbione> Mithrandir: all this probe crap is just a mess and should be rewritten from scratch
<fabbione> Mithrandir: if you want to work on ati, please talk to airlied and benh on #xorg-devel
<fabbione> Mithrandir: here on freenode.. they are really friendly guys
<Mithrandir> I guess I should.
<Riddell> Kamion: did you get my e-mail last week about the cd boot loader kubuntu image?
<_ion> Yay. Vim7 is released. \o/
<Kinnison> gnerk
<Kamion> Riddell: yeah, will look at it now
<Riddell> Kamion: I've no idea if the colour palette is right
* freeflying is away: 
<Kamion> looks plausible
<zul> heylo
<janimo> Kamion, flight 7 install CD asked  to type in where to put grub (hd0) but it did not on previous CDs. Should I file a bug?
<Kamion> janimo: that code hasn't changed; it depends on what other operating systems you have installed though
<Kamion> if there's an OS on the disk that it doesn't recognise, it'll ask you
<Kamion> on the basis that installing grub might mean you could never boot that OS again, so you'd better check
<janimo> Kamion: there was a FAT32 XP, it did not recognize since it was not put in the menu
<HiddenWolf> Kamion: ping, I just added a bit on the /MigrationAssistance wiki page regarding issues with importing user settings from "messy" windows installations.
<Kamion> HiddenWolf: it's not exactly my page ...
<HiddenWolf> Hm, you had the last edit, sorry. :)
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | LP upgrade due at 13:30 UTC | Flight-7 released
<pitti> hi shackan 
<shackan> hi
<Huahua> hello, pitti 
<pitti> hey Huahua 
<bddebian> Morning peoples
<highvolt1ge> morning bddebbiaann
<pitti> fabbione: still here?
<fabbione> pitti: yes
<pitti> fabbione: I have a clean breezy install here and set up my printer
<pitti> fabbione: now I'm about to do apt-get install cupsys cupsys-client for dapper
<pitti> fabbione: did you do anything else when you noticed the cupsys preinst failure?
<fabbione> pitti: note that i had no printers installed
<pitti> fabbione: ok, then I'll remove it again
<fabbione> pitti: just from console: apt-get update && apt-get dist-upgrade.
<pitti> fabbione: so you used apt-get normally
<pitti> ok, so no update-manager of any kind
<pitti> thanks
<fabbione> nope
<fabbione> as i wrote in the bug.. plain apt
<pitti> fabbione: any other cups configuration? enabled browsing or so?
<fabbione> pitti: nothing.. it was plain install from breezy
<pitti> fabbione: alright, thanks
<fabbione> i literally installed breezy and upgraded to dapper
<fabbione> not even logged in
<bddebian> Damn xorg updates :-(
<fabbione> bddebian: go rant somewhere else please.
<bddebian> Bah
<pitti> fabbione: ah, I think I got it, too now
<jsgotangco> lol
<fabbione> pitti: coolio
<pitti> fabbione: but it disappears as soon as I try it again
* pitti restores his breezy
<pitti> brb
<fabbione> pitti: yes, it's  a one shot
<fabbione> meh
<Fjodor> Has anyone verified en_DK workable? My Xlib doesn't like it, and I don't think I've tinkered with it. Dapper install is dist-upgrade from breezy and fully updated
<Fjodor> s/en_DK/locale en_DK
<fabbione> Fjodor: i use locale en_DK and no, i have no idea why you get these messages.. everything else seems fine
<fabbione> if you have a patch good, otherwise please file a bug in malone
<fabbione> pkg libx11
<Fjodor> Ubugtu: bug 40761
<Ubugtu> Malone bug 40761 in libx11 "Most X apps warn about locale not supported" [Normal,Unconfirmed]  http://launchpad.net/bugs/40761
<fabbione> Fjodor: ok.. do you have a patch?
<Fjodor> Unfortunately not. I really can't see why it doesn't like it :-(
<Fjodor> Guess I just wait for someone to pick it up then. Sorry for bothering
<fabbione> Fjodor: neither can i. so there is no known fix atm
<Fjodor> Fair enough. Thanks anyway
<bddebian> fabbione: Having a bad day are we? :-)
<fabbione> bddebian: no. trying to improve the S/N ratio in this channel
<mvo> Diziet: could you please have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=7969? we have a older version of the patch in our ff, but the author suggested to update it 
<Ubugtu> Mozilla bug 7969 in Internationalization "need dictionary based Thai line breaker and intergrate into line/word breaker" [Normal,New]  
<Mithrandir> Fjodor: if you run locale-gen en_DK.UTF-8, does that help?
<fabbione> Mithrandir: meh dude.. was that simple?
<fabbione> locale-gen en_DK.UTF-8
<fabbione> Generating locales...
<fabbione>   en_DK.UTF-8... up-to-date
<fabbione> Generation complete.
<janimo> is there a 'reply to comment' in malone like in bugzilla I am not seeing?
<fabbione> made the error go awat
<fabbione> away
<janimo> or just plan add a comment mode?
<Riddell> Mithrandir, Kamion: how does update-notifier get added back to autostart on install?
<Mithrandir> Riddell: unsure
<Riddell> spooky
<fabbione> Mithrandir: so what is at fault for not running it on upgrades?
<Mithrandir> fabbione: unsure.  And it doesn't fix the problem for me.
<fabbione> it does for me tho
<fabbione> same en_dk issue
<bddebian> Why don't we have any of the libglib-data packages?
<bddebian> According to one website installing libglib2.0-data makes the Gdk warning go away for that X locales thing
<fabbione> Mithrandir: sudo locale-gen $LANG ?
<Mithrandir> fabbione: yes, I did that, and it made some of the messages go away, but not all.
<Mithrandir> fabbione: maybe I need to kick the X server or something
<fabbione> Mithrandir: i used xterm as test case
<Mithrandir> : tfheen@thosu ~ > LANG=en_DK.UTF-8 xterm
<Mithrandir> Warning: locale not supported by Xlib, locale set to C
<Mithrandir> Warning: Cannot convert string "vlines2" to type Pixmap
<fabbione> the latter is not locale associated
<fabbione> i have a report for it, but i don't understand what causes it exactyl
<fabbione> because i can't reproduce it here
<fabbione> try to start with a clean env??
<fabbione> env -i LANG=en_DK.UTF-8 xterm ?
<bddebian> Is the link in /usr/X11R6/lib/X11/locale correct?
<fabbione> bddebian: yes i fixed in ubunt7
<fabbione> ubuntu7
<bddebian> It looks weird on my machine
<fabbione> and i have the feeling somebody will report it as duplicate
<Mithrandir> fabbione: en_DK is missing from /usr/share/X11/locale/locale.dir
<fabbione> bddebian: dpkg -l libx11-6
<bddebian> Ah, I have ubuntu6 on this one
<fabbione> Mithrandir: that's odd..
<fabbione> Mithrandir: so why does it work here?
<Mithrandir> fabbione: do they exist in your file?
<fabbione> Mithrandir: nope
<fabbione> ahh hmmm
<fabbione> hold on 
<fabbione> the error disappeard only on the terminal i used to generate the locales
<fabbione> so probably the env needs to be fully reloaded
<pitti> fabbione: ah, found it; stupid me...
<fabbione> Mithrandir: ok i have the fix.
<fabbione> Mithrandir: adding to locale.dir does indeed help everywhere.
<fabbione> Mithrandir: and i think there was no need to regenerate with locale-gen at all since it was already up-to-date
<desrt> unattended-upgrades... pretty controversial stuff....
<Mithrandir> fabbione: yeah, it was just a shot in the dark
<pitti> hi desrt 
<Fjodor> fabbione: Sorry for not answering, I was fetching a coke. No, locale-gen just says up to date
<desrt> good morning :)
<desrt> pitti; where have you been hiding these days?
<bddebian> Hello desrt
<pitti> desrt: behind my TFT, as always :)
<desrt> bddebian; dword to your moms
<bddebian> uhm
<bddebian> :-)
<desrt> pitti; hm.  i thought most people usually sat in front of their tfts :)
<desrt> pitti; i haven't run into you for very much stuff this release cycle, unfortunately :/
<pitti> desrt: I bought a left-handed TFT where the display is on the backside
<fabbione> Fjodor: thanks. i am getting the fix uploaded right now. Thanks to Mith.. 
<fabbione> Mithrandir: nice work :)
<desrt> pitti; that's pretty awesome
<pitti> desrt: how are you these days?
* bddebian hugs Mithrandir
<desrt> pitti; up and down
<desrt> pitti; biggest problem currently is that i failed a mandatory course and the professor is being a dick about it
* Fjodor hugs Mithrandir too. Great work. And thanks to fabbione too!
<desrt> pitti; my department nastygrammed him yesterday though, and it looks like things are getting sorted quickly
<pitti> desrt: uh, sounds like some time of computer abstinence is required? good luck!
<desrt> pitti; heh.  school this term was insane.  i took a couple of overload courses
<desrt> 15 courses in 2 terms (7 and 8)
<fabbione> Dear Firefox, thanks for dieing on me while closing a bug...
<desrt> sounds like time to open a new one :)
<_ion> Me hugs SessionSaver
<pitti> desrt: hm, I also usually took about 7 courses per semester
<pitti> desrt: (but I agree that this meant serious work :) )
<desrt> pitti; normal engineering load is 5-6.  normal arts load is 4-5 :)
<fabbione> Fjodor: it will take about 3 hours for the packages to hit archive.. but it's there now
<desrt> (engineers love little else more than complaining about courseload and bitching about how easy the artsies have it) :)
<Fjodor> fabbione: Great! Thank you (and Mithrandir) _so_ much!
<fabbione> Fjodor: no problem. 
<fabbione> at the end i live in dk.. i can't totally ignore that
<Fjodor> Hehe :-) Where in DK btw.?
<fabbione> anyway.. 0 libx11 bugs as of now..
<fabbione> Fjodor: Brnshj
<Fjodor> Too bad it isn't Aarhus. I would have bought you a beer or something :-)
<fabbione> Fjodor: i did live in rhus for almost 3 years..
<fabbione> Fjodor: i pass by there once in a while
<fabbione> don't worry.. i will come and claim my beer :)
<bddebian> fabbione: That's awesome.  Too bad the xorg driver bugs could choke a horse :-(   :-)
<Fjodor> fabbione: Cool. Just say when
<fabbione> Fjodor: will do
<fabbione> bddebian: too bad you didn't even notice i fixed/closed/triaged over 200 bugs in the last week 
<fabbione> so we are down to 350
<fabbione> that's not bad at all
<bddebian> fabbione: I notice.  That isn't a slam on you man
<fabbione> considering that warty had 120
* jsgotangco salutes fabbione 
* HiddenWolf salutes fabbione
<fabbione> hoary around 250
<fabbione> and that our user base from hoary is 10 times bigger???
<fabbione> go nuts... we did great
* Fjodor salutes fabbione too
<HiddenWolf> fabbione: are you the resident X guru now?
<fabbione> HiddenWolf: only up to release
<StevenK> Heh.
<StevenK> Then someone takes over?
<bddebian> fabbione: I think it's awesome, I wish I could be more help.  You and infinity are to be commended.
<desrt> when you say down to 350 bugs is that like... the entire distro?
<bddebian> desrt: hahaha :-)
<fabbione> i hate X, i don't want X, X should die.. all back to console+fb
<desrt> ok.  just checking :)
<Mithrandir> desrt: the entire distro is around 10k open bugs. :-(
<HiddenWolf> desrt: 10270+ bugs 
<fabbione> desrt: tsk :P
<desrt> you guys need to go to IBM or something
<desrt> borrow 10000 of their employees for a day
<jsgotangco> lol
<desrt> and say to each of them "fix one bug"
<fabbione> desrt: that won't help..
<crimsun> desrt: classic mythical man-month problem.
<bddebian> hehe
<bddebian> You mean 9 women can't have a baby in 1 month?? ;-P
* desrt watches fabbione get 9999 emails with the subject "help"
<StevenK> Haha
<desrt> (the one guy called in sick)
<fabbione> desrt: die dude!
<StevenK> bddebian: You get 9 women pregant with the *same* baby, and then we'll see. :-P
<bddebian> A gene multiplexer?
<fabbione> poor baby
<desrt> StevenK; take this to #biology-devel, plz
* bddebian shuts up before fabbione yels at him
<bddebian> yells even
<fabbione> i am taking off
<mjg59> Does launchpad have any way to limit displayed bugs to main?
<fabbione> time to do some real life stuff
<HiddenWolf> fabbione: life, what is that?
<HiddenWolf> ;)
<mjg59> Oh, yes
<fabbione> HiddenWolf: when you a wife with a knife on your neck ready for use
<desrt> fabbione; life is waiting for you.
<StevenK> mjg59: Bah, I was about to answer.
<desrt> fabbione; death too, it seems...
<Fjodor> Oh no! He's about to enter the fabled "room without a roof"! It's said to be rather bright in there
<mjg59> There's only 6821 bugs in main
<HiddenWolf> "only"
<desrt> Fjodor; it's a pretty big room, actually
<desrt> Fjodor; it's a freakin' mess though... dirt and water all over the place
<Fjodor> Yeah. "outside the asylum" alright
<bddebian> Kamion: ping?
<Fjodor> Hmm, guess my last statement was a misquote, now that I remember where it was from. Guess I'll shut up and look forward to the new libx11 :-)
<crimsun> pitti: rock! (RE: alsa-utils, g-c-c, and g-v-m)
<pitti> crimsun: and to you for finding a way out of this mess!
<crimsun> pitti: anytime
<pitti> ivoks: I applied your patches, testing now; looks good so far, thank you!
<ivoks> pitti: for... g-c-m?
<pitti> ivoks: I did cups so far; g-c-m is built and waiting to be tested :)
<ivoks> pitti: you are welcome
<pitti> ivoks: hm, adding 'Allow @LOCAL' shouldn't hurt too much, I guess
<ivoks> it wouldn't for a default install
<pitti> people who change the Listen directive will probably want that anyway, and it doesn't change anything by default
<ivoks> that's right
<pitti> ivoks: also, it's a FAQ which would be solved
* pitti changes the default file
<ivoks> pitti: that would go in dapper?
<pitti> ivoks: the cups changes in any case, I guess -- it's just adding two files
<pitti> ivoks: I'll ask mdz about g-c-m
<ivoks> and .glade
<ivoks> ah, ok :)
<ivoks> pitti: it needs testing first
<ivoks> i'm not sure g-c-m was solved as good as it can :/
<pitti> mdz: would you be opposed to adding ivoks' patch to gnome-cups-manager which provides a GUI (menu entry checkbox) for calling a cups script to enable/disable printer sharing?
<pitti> ivoks: yes, I'm preparing the cups side first
<ivoks> ok
<seb128> carlos, mdke: who is moderator for the ubuntu-translators list?
<pitti> ivoks: do you have anything particular in your mind? (g-c-m patch flaws)
<ivoks> pitti: yes, if you enable sharing in g-c-m, and then disable browsing (in same run)
<Diziet> mvo: thai patch> I'll look into it.  It was quite a big patch and I'll have to think about whether now is a good time to be changing it lots.
<ivoks> pitti: sharing will stay enabled (marked), but will not work
<ivoks> pitti: on restart of g-c-m, everything would be fine
<pitti> ivoks: right
<ivoks> pitti: this is due something in .glade, if i'm not mistaken
<ivoks> i'm not so good programer :/
<pitti> ivoks: don't worry, I know next to nothign about GTK either
<ivoks> i was hoping you will take a look at that (or someone else)
<ivoks> :D
<carlos> seb128: jordi and I
<pitti> ivoks: I'll try to hug mvo or seb128 often enough so that he can give me some hints :)
<pitti> ivoks: I just won't have much time to care for it :/
<ivoks> pitti: if you need help, bug me and I'll hug them too :)
<mvo> Diziet: agreed, if you feel uncomfortable about it, its fine to not include it I think
<pitti> ivoks: there must be a function to disable the browsing menu entry if sharing is enabled?
<seb128> carlos: could you accept my mail about strings changes from the previous week and today?
<pitti> ivoks: i. e. enabling sharing should enable browsing and grey it out
<ivoks> pitti: the thing is that disabeled browsing doesn't mean that sharing is disabled
<pitti> ivoks: no, let me explain again
<Diziet> mvo: I'll take a look at the actual code I think.
<mvo> ivoks, pitti: do we have a bugnumber for that g-c-m problem?
<mvo> Diziet: thanks!
<ivoks> mvo: not yet
<seb128> carlos: "mails", they are like 5-6 now
<pitti> ivoks: if I enable sharing, then the browsing checkbox should be enabled as well and made inactive, so that the user can't disable it
<ivoks> pitti: right, that would be great
<Diziet> mvo: Do you happen to know which version of the patch was the one that was included ?
<ivoks> pitti: but...
<Diziet> The changelog doesn't say and knowing that would save me quite a bit of faff.
<pitti> mvo: it's more a missing feature; just a checkbox around two scripts in cupsys
<ivoks> pitti: you can disable browsing and still be able to share (darn cups)
<mvo> Diziet: checking, give me a sec
<pitti> ivoks: oh, how so?
<pitti> ivoks: that would be the most ideal solution in the first place
<mvo> pitti: let me know if you need help, that sounds managable
<pitti> ivoks: but after I disabled browsing locally, my laptop didn't get any ipp notifications any more
<ivoks> pitti: that's true
<ivoks> pitti: but go to http://disabled_server_IP:631
<pitti> mvo: we have a patch already (similar to the 'enable browsing' patch), it just needs some minor tweaks; thanks!
<mvo> Diziet: we have https://bugzilla.mozilla.org/attachment.cgi?id=218666&action=view (I did the upload)
<ivoks> pitti: and you will be able to access printers
<ivoks> pitti: browsing is browsing, and only that
<ivoks> pitti: sharing is something else
<pitti> ivoks: aaah, right
<ivoks> pitti: best option is sharing+browsing
<pitti> ivoks: indeed, I mixed that up
<pitti> ivoks: so why does your enable_sharing script enable browsing then?
<ivoks> pitti: anyway, I would be happy if sharing would enable browsing
<carlos> seb128: sure
<seb128> carlos: thank you ;)
<janimo> dholbach: ping
<ivoks> pitti: I tought that would be best option
<ivoks> pitti: since most of the users want browsing with sharing
<pitti> ivoks: I see my confusion now, I mixed up access privilege with the server advertising its printers
<pitti> ivoks: that shouldn't be hardcoded in the scripts then, just in the UI IMHO
<ivoks> fine with me
<mvo> ivoks, pitti: I'm happy to help once I know what to do, just let me know whats needed and I'll hack on it
<ivoks> mvo: sure
<ivoks> mvo: thank you
<pitti> mvo: alright, thanks a million
<ivoks> pitti: so, we should go with independent sharing and browsing or should sharing enable browsing?
<pitti> ivoks: my feeling is that the scripts should be orthogonal in cups
<jordi> woa, I think I've been neglecting ubuntu-translators quite a lot
<ivoks> pitti: i op for sharing enables browsing (that's what most of the users want)
<pitti> ivoks: and the UI should care for that
<ivoks> pitti: I agree
<ivoks> pitti: then cups need new scripts
<ivoks> needs
<pitti> ivoks: yes, easy enough to fix them (I just spotted some typos anyway)
<ivoks> oh :/
<ivoks> i wrote those scripts at 1AM :)
<mdke> seb128: looks like carlos/jordi
<jordi> mdke: ?
<carlos> jordi: just that we should pay more attention to ubuntu-translators
<seb128> jordi: I send "I've changed that strings" mails for 10 days but nobody cares to moderate ubuntu-translators so they never reach the list
<mdke> jordi/carlos: if you need a hand, I'm happy to do some moderating duties
<carlos> mdke: that would be really good, the main problem is the amount of spam we have there to discard
<mdke> yeah, I know from other lists ;)
<elmo> seb128: I just installed flight 7, did an update and now gdm is prompting me for which display manager should be the default
<elmo> and the choice is gdm... or gdm.
<seb128> elmo: weird, we got 1 other bug about that but I don't get the issue on my box and I'm not sure on how to debug it ... do you have any idea :)
<elmo> seb128: it isn't reproduceable after purging + reinstalling gdm?
<seb128> elmo: I'll give a try later
<elmo> I mean, this laptop isn't in use yet,so I could reinstall it, and run stuff you tell me to, if that'd be helpful
<seb128> (I don't try now because stopping gdm closes will close the running session :p)
<jordi> mdke: hmm, I think we can accept that offer
<mdke> jordi: ok
<jordi> I mean, I can do it. I do it for two other ubuntu lists, but every few days.
<seb128> elmo: I'll give a try on my laptop with flight7 and update and with purge reinstall and let you know if it doesn't happen for me
<seb128> elmo: thank you :)
<jordi> but, ubuntu-translators I sometimes get backlogged on
<jdub> jordi: i will help you
<pitti> ivoks: hm, the new g-c-m does not have any 'global settings' menu at all any more
<jordi> mdke: hmm, just got pointed at listadmin :)
<jordi> thanks jdub 
<pitti> ivoks: ah, I know; the current patch disables the entire menu if either _status script says 2
<ivoks> huh?
<ivoks> pitti: i didn't update wor a week
<mdke> jordi: I dont mind, if you need the help, Im here. I read that list anyway.
<jordi> ok
<carlos> seb128: done
<carlos> mdke: I just added your address to the admin list for that list
<seb128> carlos: thank you
<Diziet> mvo: Thanks, noted.
<Riddell> carlos: I've fixed the ones that can be, the rest are obsolete or from programmes that havn't been released yet so can be ignored https://wiki.kubuntu.org/MissingPotFiles
<carlos> Riddell: ok, thank you!
<Riddell> carlos: timezones and ppdtranslations in kdelibs are actally made by kdebase, will that be a problem?
<carlos> Riddell: I will need to import them manually, but that's ok. How is that those are stored in the wrong place?
<Mithrandir> Riddell: any chance you could take a look at https://launchpad.net/distros/ubuntu/+source/xorg/+bug/43276 wrt the kde device db?
<Ubugtu> Malone bug 43276 in xorg "Please include Dell UltraSharp 2405FPW 24-inch Wide Aspect Flat Panel LCD Monitor in hardware database" [Wishlist,Unconfirmed]  
<Riddell> carlos: they're generated by kdebase and put into kdelibs, I've no idea why
<carlos> ok
<BenM> seb128, <3
<seb128> hey BenM, noticed the upload? :)
<BenM> no, but i got bugmail :-)
<seb128> ah, right
<Riddell> Mithrandir: reassigned
<Mithrandir> Riddell: thanks.
<mdke> carlos: ok, thanks
<BenM> seb128, another win i just noticed
<BenM> gnome-cups-icon stays around
<BenM> forever
<BenM> once you pritn something
<BenM> ~1mb cost
<Kamion> bddebian: yes?
<Keybuk> seb128: xchat core dumps if you have xchat-systray installed :)
<seb128> Keybuk: don't install xchat-systray then ;)
<Kamion> Riddell: the installer's never touched update-notifier/autostart
<seb128> BenM: any patch around for that? :)
<Keybuk> seb128: *sulk*
<BenM> not yet :-)
<BenM> maybe after exams
<BenM> seb128, should i open a new bug for gnome-applets re: trash-applet
<Riddell> Kamion: does the installer copy the squishfs or the filesystem as it is on the running live CD?
<Mithrandir> Riddell: the squashfs.
<seb128> BenM: feel free yep
<Kamion> what he said
<Riddell> Mithrandir: ah, so that's how the notifier link gets copied
<Mithrandir> Riddell: oh, yeah, probably
<Keybuk> Kamion: is that retchmail sync yours?
<Riddell> Mithrandir: can you add  "rm /usr/share/autostart/adept_notifier_auto.desktop" to the Disabling update-notifier script then?
<Mithrandir> Riddell: can you mail that to me or file a bug?
<freeflying> Mithrandir:  bug 43806
<Ubugtu> Malone bug 43806 in casper "kubuntu livecd's update_notifier need been disable" [Normal,Unconfirmed]  http://launchpad.net/bugs/43806
<Mithrandir> freeflying: oh, that one.  Yeah, I meant to bug Riddell about that anyway.
<glatzor> Hi Riddell. I and mvo talked about the update notification a minute ago, too.
<Riddell> thanks freeflying :)
<glatzor> It would be nice if adpet and update-notifier could share the same config file.
<bddebian> Kamion: Sorry, is libkwiki-perl still hung up in NEW?
<Riddell> glatzor: apt configuration?
<freeflying> Riddell:  :)
<glatzor> Riddell: yes. currently u-m uses 10periodic and adpet 15adpet-periodic-update
<glatzor> I would like to see if the config file 10peridoic would be shipped with apt itself
<glatzor> Riddell: since the apt package also contains the cron job
<Riddell> enabled by default?
<mvo> we can't ship it with apt and enabled by default (because apt sets no policy on these things)
<BenM> seb128, this is even better, g-cups-icon seems to leak
<BenM> last night, it was around 1.5 mb or writable
<BenM> now around 4.7
<mvo> but I would like to have the same config file for both u-n and adept
<glatzor> Riddell: The kubuntu and ubuntu desktop metapackages could depend on a config package that would enable apt cache updates if the configurations was not changed by the user yet
<glatzor> Riddell: no. disabled by default.
<Riddell> sounds like we'd have to play around with postinst scripts
<glatzor> furthermore i would like to see a common option if the user should be notified of available updates
<glatzor> Riddell: mvo: perhaps "APT::Periodic::NotifyUser"
<mvo> glatzor: well, the cron thing only part of the problem. if a user runs apt-get update by hand (or if he has no gui runing at this point) we want to show the notification as well
<pitti> Kamion, Keybuk: can you please NEW mozilla-firefox-locale-all? (new deb mozilla-firefox-locale-ka-ge, please put it straight into main)
<Keybuk> sure
<pitti> Keybuk: great! I'll add the language-support-ka dependency then
<Keybuk> I was just looking at the immense NEW queue ;)
<pitti> oh, is it so bad?
<Keybuk> little larger than usual today
<Keybuk> some soname changes happened I think
<Kamion> Keybuk: no, I don't think so, and infinity says it isn't his either
<Kamion> bddebian: no
<glatzor> mvo: ok let's use "APT::UpdateNotification::NotifyAdminUsers" :)
<Kamion> bddebian: https://launchpad.net/+builds/+build/191492
<glatzor> mvo: Riddell: or "APT::NotifyUserOf Updates"
<mvo> glatzor: what would this option do?
<glatzor> I don't know much about the internal name space of apt config options
<Keybuk> pitti: all for main, right?  (m-f-l-a)
<pitti> Keybuk: yes, please
<pitti> Keybuk: they will be pulled in by language-support-*
<glatzor> mvo: Riddell: it would be used by update-notifier and adpet. if it is enabled the notification would be shown in the notifcation area.
<pitti> Keybuk: apart from -ka-ge, is there another one?
<Keybuk> pitti: dunno, the queue tool helpfully tells us all the binaries, not just the new ones :)
<pitti> lol
<Keybuk> I could grovel in the overrides to compare and find out which were new, etc.
<Keybuk> far easier just to check the destinations with you though
<pitti> Keybuk: don't worry, I'm reasonably sure it's just -ka-ge
<glatzor> mvo: but it could be too much noise, too.
<pitti> Keybuk: I already saw the other ones in anastacia yesterday
* Keybuk makes a mental note to delay anastacia processing for a publisher run or two :p
<tepsipakki> does anyone know of how to securely automate the signing of a repository (Release.gpg). http://wiki.debian.org/SecureApt doesn't have that info yet
<tepsipakki> -of
* _ion uses falcon
<glatzor> mvo: https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/43017
<Ubugtu> Malone bug 43017 in update-manager "Automatic Updates Don't Work on Xubuntu" [Major,Fix committed]  
<glatzor> Fixed this in my local repo
<jsgotangco> ciao good night
<tepsipakki> _ion: was that a reply to my question?-)
<_ion> tepsipakki: Kind of.
<tepsipakki> where can I find this falcon?
<BenM> seb128, i want to recommend that evolution-exchange be removed from the default gnome-desktop. when exchange is installed, it launches an extra daemon every time you use evo, using an extra mb
<BenM> where would i file this
<BenM> gnome-desktop, or in evo
<_ion> tepsipakki: http://www.kaarsemaker.net/files/Software/falcon/
<tepsipakki> ion: thanks, google wasn't that helpful ;)
<seb128> BenM: default gnome desktop or default Ubuntu installation? That will probably be rejected because we have one CD that should work out of the box for everybody
<seb128> BenM: ubuntu-desktop is probably the right place
<BenM> default install
<BenM> well, i'd figure exchange is something that would be deployed by a sysadmin
<BenM> in a customized exchange
<BenM> err
<BenM> customized install
<seb128> evolution should probably not start that daemon if there is no exchange account configured
<BenM> agreed
<BenM> but, it's evolution :-)
<BenM> on the evo wackyness scale
<BenM> that's actually somewhat low
<seb128> right
<Keybuk> BenM: hardly an extra MB
<Mithrandir> a gig here, a gig there.  Memory's cheap.
<BenM> its 1 mb of writable private memory
<Kamion> ! speaking of memory allocation
<Keybuk> 00002aaab3700000    132K rw---    [ anon ] 
<Kamion> the guy talking about ubiquity memory usage isn't kidding about localedef being memory-hungry
<Kamion> it takes up 50MB+ to generate a UTF-8 locale
<Kinnison> Kamion: cripes
<Keybuk> Kamion: yeah, I've encountered that before
<BenM> https://launchpad.net/distros/ubuntu/+source/gnome-desktop/+bug/43830
<Ubugtu> Malone bug 43830 in gnome-desktop "Remove evolution-exchange from ubuntu-desktop" [Normal,Unconfirmed]  
<Kamion> http://lists.debian.org/debian-glibc/2003/03/msg00314.html # yay goto
<BenM> how's that for rationale?
<Mithrandir> Kamion: uh, nice.
<Mithrandir> (or not)
<Kamion> it got reopened 'cos drow is sensible
<enyc> Hrrrm... in dapper currently... GTK libs do not find modules sometimes -- e.g. running 'drip' results in "(drip:6848): Gtk-WARNING **: Failed to load module "libatk-bridge.so": libatk-bridge.so: cannot open shared object file: No such file or directory" when /usr/lib/gtk-2.0/modules/libatk-bridge.so is there....
<enyc> as if looking in wrong place or something ;-(
<enyc> (noting that 'drip' is dynamic-linked to loooads of files!)
<elmo> ~.
<elmo> argh, god damn, cisco must die.  they took a perfectly supported wireless cardbus card and silently switched it to an atheros chipset without changing the major model number
<thom> elmo: yummy
<thom> elmo: when i saw cisco must die i was expecting rather more major explosions
<Mithrandir> elmo: they didn't leave the pci id unchanged too, for extra joy&profit?
<elmo> Mithrandir: nah, PCI ID correctly identifies it as atheros
<elmo> thom: well for major explosions like killing the DC usually also involve me being offline, so they're not so visible :/
<Keybuk> elmo: did they change the version?
<elmo> anyway, atheros is still madwifi or ndis, right?
<Keybuk> elmo: yes, always will be
<Keybuk> madwifi tends to "work"
<Keybuk> could be worse ... I know of a certain card manufacturer that likes to keep the PCI ID the same, even after they change the chipset
<elmo> hmm, why always?
<Lathiat> elmo: thats been quite popular with lots of manufacturers
<Lathiat> on the netgear stuff you get a nie little "v2" sidemarked somewehre
<Lathiat> Keybuk: haha, nice
<Keybuk> elmo: nobody seems to be moving in any particular direction towards a proper open driver for it
<elmo> ah ok, but it'd be technically possible right?  I mean, no one thought bcm43xx was likely a year ago
<Keybuk> yup
<Keybuk> probably some kind of softmac implementation would do the trick
<Keybuk> the bcm stuff only happened because linksys wrote their own drivers for it, and someone was able to reverse engineer them
<Keybuk> nobody's done that for atheros sadly
<Riddell> Keybuk: do you expect edgy to use initng?
<Keybuk> no.
<Riddell> someone has applied to SoC to write a config tool for it, so not much use unless edgy uses initng
<Riddell> thanks
<Keybuk> indeed
<Keybuk> I already looked at that :)
<Keybuk> initng has struck me repeatedly as one of the most pointless sysvinit replacements
<Keybuk> so even if we went with something !sysvinit, I doubt it would be initng
<Burgwork> BenM, you are a god, btw
<_ion> Ask Apple nicely to release their implementation under a free license. ;-)
<_ion> I heard it pretty much rules, albeit it uses XML config files.
<_ion> (It does the work of init, inetd, crond, atd etc.)
<_ion> It apparently launches stuff like cupsd on demand, instead of system startup.
<mdz> Kamion: what went horribly wrong with my seed commit?
<Riddell> carlos: what's the status of the .pot file for guidance?
<carlos> Riddell: ubuntu or upstream?
<Riddell> carlos: in ubuntu
<Riddell> it's not in rosetta (I'm told)
<carlos> Riddell: it is
<carlos> https://launchpad.net/distros/ubuntu/dapper/+source/kde-guidance/+pots/guidance
<carlos> Riddell: it's there since 2006-04-04
<carlos> Riddell: please ask to the guy that told you that is not there to file a bug describing how was he trying to get it, it sounds like an UI bug
* carlos -> out
<carlos> see you later
<Kamion> mdz: no idea, it simply wasn't there
<Kamion> no record of it at all; looked as if it hadn't been pushed
<BenM> Burgwork, thanks :-)
<BenM> i try
<bddebian> Kamion: Thx.  Do I need to try libspoon-perl or have you already brought it over/in?
<mdz> Kamion: it's still at sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/ubuntu/seeds/dapper, right?
<elmo> could someone demote the following packages: libgnutls11, libtasn1-2-bin, ifrename, libdb4.4 and libssl0.9.7?
<elmo> they're > optional but not installed by default, so dselect tries to install them on fresh installs for no good reason
<elmo> (tho libtasn1-2-bin is in universe but a recommendation of something (from the same source) in main - maybe it should be promoted at the same time)
<bddebian> No way :-)
<Kamion> bddebian: I haven't done anything to it
<Kamion> mdz: yep
<Kamion> elmo: those packages all appear to be in universe already
<dholbach> janimo: pong
<janimo> dholbach: hey
<janimo> wanted to ask if you're too busy to handle goffice/gnumeric
<janimo> I can take care of tjose if so
<Kamion> elmo: though hmm, I suppose everything that's not in main should be <= optional; I should teach jessica to check that
<dholbach> janimo: what was the final decision with those now?
<elmo> Kamion: sorry yeah, by demote, I meant demote to optional
<janimo> dholbach: Gauvain, updated the patches to be less hacky
<janimo> dholbach: per mdz's proposal
<dholbach> got the bug numbers?
<janimo> dholbach: goffice provides goffice|goffice-gtk in the shlibs
<janimo> dholbach: hmm don;t know offhand but can look
<dholbach> ok
<janimo> dholbach: I think it's against goffice 
<Kamion> ah, good, 'jessica -c universe' spots it
<Kamion> elmo: will do once this publisher run finishes
<dholbach> janimo: bug 42610 and bug 40122
<Ubugtu> Malone bug 42610 in gnumeric "Patch: gnome/gtk build" [Normal,Unconfirmed]  http://launchpad.net/bugs/42610
<janimo> dholbach: same, bug #40122
<Ubugtu> Malone bug 40122 in goffice "Patch: build 2 libgoffice variants (gnome and gtk)" [Normal,In progress]  http://launchpad.net/bugs/40122
<Ubugtu> Malone bug 40122 in goffice "Patch: build 2 libgoffice variants (gnome and gtk)" [Normal,In progress]  http://launchpad.net/bugs/40122
<janimo> yup
<janimo> dholbach: used some epi shortcuts ;) ?
<dholbach> sure :)
<elmo> Kamion: thanks
<Tonio_> hi everyone
<janimo> dholbach: so are you uploading goffice patch then?
<janimo> seen fix commited on the bug
<dholbach> janimo: oh, I thought you'd do that
<janimo> dholbach: I taught so too, just seen that you marked it as fix commited confued me
<elmo> sladen: did you ever have any luck with this damn numlock problem on thinkpads?
<janimo> I am trying it out right now
<dholbach> fix committed = will be uploaded :)
<janimo> dholbach: ok :)
<janimo> I taught it was usually (have it in a local branch or soemthing). vs in progress
<janimo> but ok anyway :)
<dAndy> can someone take a look at bug #31071 it should be a very easy fix, (it is actually a regression from breezy) and the bug is at least 3 months old
<Ubugtu> Malone bug 31071 in autofs "Unable to use NIS maps" [Normal,Confirmed]  http://launchpad.net/bugs/31071
<bddebian> Crap, too many packages to bring in for libspoon-perl
<Keybuk> dAndy: bug is against the wrong package
<Keybuk>   * Make autofs start at level 19 instead of level 20 during boot, to make
<Keybuk>     sure if comes before other dmons that might rely on it. (Closes: #252114)
<dAndy> so nis should be moved to 18?
<Keybuk> yup
<bddebian> Crap, I'm going to have to file UVF exceptions for all the libspoon-perl build deps?? :-(
* dAndy isnt sure he knows which malone incantation would be right to fix this, make a new bug against nis? or change that bug?
<bddebian> dAndy: Change the source package and add a comment please  (Quoting the above would be good too imo)
<dAndy> bddebian: will do thanks
<bddebian> No, THANK YOU :-)
<Keybuk> *shrug* no particular point :)
* Keybuk just uploaded fixed nis
<dAndy> yay!!! 
* dAndy hugs Keybuk 
<bddebian> heh
<Keybuk> anything to avoid looking at the NEW queue <g>
<bddebian> hehe
* bddebian assigns more bugs to Keybuk then :-)
<Keybuk> if the packages are in main, and they're that trivial to fix, go for it
<Keybuk> nothing wrong with getting that big number down a bit
<bddebian> I made a patch for xterm, let me find the bug #
<bddebian> Bug #38453
<Ubugtu> Malone bug 38453 in xterm "[Patch]  Changed man pages but not alternatives" [Normal,Confirmed]  http://launchpad.net/bugs/38453
<bddebian> Keybuk: Does that look OK?
<Keybuk> yup that kind of thing
<bddebian> Keybuk: Are you on ubuntu-archive team?
<Keybuk> yes
<bddebian> Keybuk: WOuld you mind looking over sear?  Bug #6527
<Ubugtu> Malone bug 6527 in sear "sear: merge new debian version" [Normal,Confirmed]  http://launchpad.net/bugs/6527
<Keybuk> bddebian: for that stuff, I'll get to it in turn, along with the others
<bddebian> Oh, OK, sorry
* Keybuk wonders whether the fact he now recognises vendors and even devices by their PCI ids means he's going mad
<zul> Keybuk: probably
<Keybuk> Intel still have the coolest
<elmo> is the fact that the language takes ages to come up, a known ubiquity thing?
<Kamion> the screen with the language selector on it?
<tseng> it takes a few seconds for me
<Kamion> no - it takes a while to get *off* that screen because it has to run locale-gen, but it's usually reasonably quick to appear
<Kamion> try with UBIQUITY_DEBUG=1 and see what it's doing
<Kamion> (tail -f /var/log/installer/syslog in another window)
<elmo> Kamion: it took a noticeable enough amount of time that I thought it was broken, once on the oldish quebicistani laptop but more damagingly once with a brand spanking new X41
<Keybuk> right
<Keybuk> I just love soname changes
* Keybuk makes a mental note to ask doko about the zope stuff after TB
<Keybuk> doko: consider that a 1-hour pre-emptive ping <g>
<bddebian> Isn't TB meeting in like 4 mins?
<bddebian> Oh, nm
<ogra> Kamion, Mithrandir, is there a way to prevent the liveCD to use an existing swap partition ? 
<Keybuk> yes
<mdz> infinity: right, so we could presumably safely unlink nvidia.ko but not nvidia_legacy.ko (unless we checked the bus as I proposed earlier)
<Fjodor> fabbione, Mithrandir: Probably not a surprise, but I just wanted to confirm that your work solved my problem, and that it was indeed that, which prevented me from entering Danish chars in emacs. Thanks again!
<fabbione> Fjodor: no problem.
<Keybuk> sabdfl: ping, TB time
<Kamion> mdz: I've asked joeyh for thoughts on the other bit of the casper/templates.dat problem, since I think I need to add more interface in order to solve it
<mdz> Kamion: eek
<Kamion> like a flag to dpkg-reconfigure, nothing huge
<Kamion> either that or some filthy workaround in casper
<elmo> Kamion: will that var make it past gtksu?
<Kamion> elmo: I think so, although I generally use 'UBIQUITY_DEBUG=1 sudo ubiquity' when I'm debugging
<Kamion> failing that, 'gksudo env UBIQUITY_DEBUG=1 ubiquity'
<elmo> I'm surprised it does, 'cos sudo seems to even kill $DISPLAY atm
<Kamion> if you have unrestricted sudo then it should let everything past
<infinity> mdz: -ECHAN?
<Kamion> I think that was the compromise solution we reached
<Kamion> and the live CD user has unrestricted sudo
<elmo> bah, now I can't reproduce it
<elmo> (even after a reboot)
<omeg> !@#$@# stupid fonts
<kmon> hi
<kmon> i continuosly get this error in /var/log/syslog: bcm43xx: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR
<kmon> it's probably known, but it's annoying when using the console because it get's on top of the text (example typing in nano)
<bddebian> kmon: There are several bugs posted on Malone about the bcm43xx driver :-(
<kmon> yes I know
<kmon> I imagine it's because it's not mature enough
<kmon> (could be wrong)
<kmon> but I wanted to know if this is known... if it has a fixed... it's status basically
<kmon> s/fixed/fix
<bddebian> kmon: Ah, that I don't know, sorry
<elmo> does LRM support hotplugged devices?
<Keybuk> no reason why not?
<Keybuk> all devices are "hotplugged" now, remember
<elmo> hmm, it doesn't seem to like this stupid atheros cardbus cisco
<Keybuk> on dapper?
<elmo> yah, flight-7
<Keybuk> paste me the lspci line for that card
<mjg59> elmo: Mark was seeing that as well
<mjg59> Do you have a pile of unresolved symbols in dmesg?
<elmo> uh, ok, so it's not actually appearing in lspci on this machine
<elmo> I swear it did on the X41
<mjg59> What machine?
<elmo> The Quebicistani Compaq
<Keybuk> cat /sys/bus/pcmcia/devices/*/modalias ?
<elmo> Presario V2000, it's a turion, but I'm using an i386 live/install
<mjg59> elmo: What cardbus bridge?
<elmo> TI PCIxx21/x515
<mjg59> Hm. Ok.
<elmo> Keybuk: ENOENT
<mjg59> Do you have any other cards you can check?
<Keybuk> elmo: anything in /sys/bus/pcmcia/devices ?
<elmo> yeah, the non-atheros aironet, one sec
<mjg59> Keybuk: Are you sure cardbus shows up in there?
<Keybuk> mjg59: yes
<Keybuk> I can't think of anywhere else it'd show up, anyway
<elmo> umm
<Keybuk> mjg59: if cardbus was handled by old cardmgr, that's where it should show up now
<mjg59> Keybuk: It wasn't
<Keybuk> what was it handled by?
<mjg59> The kernel
<mjg59> cardbus doesn't need manual resource management
<Keybuk> right
<Kamion> cardbus is just pci with a bridge to get to it
<mjg59> Yes
<Keybuk> that's what I thought
<mjg59> But the cardbus controller needs to be setup correctly for that to work
<Keybuk> so it should show up in either pcmcia or pci
<Keybuk> or probably both
<Kamion> Debian's pcmciautils has an 'lspcmcia' which is helpful
<Kamion> I've been meaning to get UVF
<Keybuk> Kamion: oh, what does that do?  iterate /sys/bus/pcmcia ?
* elmo wonders what the point of "your computer is about to shut down" appearing about 2 seconds before it does
<elmo> ANYWAY
<Kamion> /sys/class/pcmcia_socket/blah, print ioports/iomem, and I think some other stuff
<elmo> so, the old aironet cisco card works fine, but doesn't appear in lspci
<elmo> + either
<elmo> so I guess it's some quirk of this cardbus controller?
<mjg59> elmo: The aironet is probably pcmcia rather than cardbus
<Kamion> elmo: try pcmcia-socket-startup
<mjg59> Whereas the atheros will certainly be cardbus
<Keybuk> elmo: for when it doesn't
<Kamion> oh, sorry, thought you said the aironet *didn't* work
<Keybuk> I think it's there because someone filed a bug saying "my computer doesn't shut down, but I don't know that it's ok to do it myself"
<Keybuk> elmo: does the aironet appear under /sys/bus/pcmcia/devices ?
<elmo> Keybuk: something does, when I plug it in, yeah
<Kamion> check /sys/class/pcmcia_socket/ to see if there's a socket listed there, just in case; if not /lib/udev/pcmcia-socket-startup might help
<Kamion> some machines also need pci=assign-busses at the moment, I believe (there's a fix in 2.6.16 or 2.6.17 or thereabouts for that)
<BenM> i think dapper is *REALLY* close to being < 100mb for the default gnome install
<BenM> mine is at 102.4 mb
<BenM> but i have icons on the desktop, including pdfs
<elmo> there's a /sys/class/pcmcia_socket/pcmcia_socket0 dir, with a bunch of stuff in it, with the atheros in
<mjg59> elmo: Yeah, if you could check pci=assign-busses, that would be helpful
<elmo> ok, doing that now
<elmo> sigh, we need some non-freaky spare laptops in the office, I wanted to go home before the shops closed tonight
<Keybuk> pitti: finally done your syncs, btw <g>
<elmo> yikes, it's SOSing at me now
<pitti> Keybuk: saw it, thank you!
<Keybuk> elmo: what would be the point of having test laptops that actually work? :p
<omeg> Hey infinity
<Keybuk> pitti: thank elmo, not me
<omeg> Remember that I was going to do that font for usplash in BDF format? I'm still eager to do it, but I'd just like to know if you could give me any deadline.
<pitti> elmo: thank you!
<pitti> :)
<elmo> pci=assign-busses seems like a winner
<elmo> it's in lspci output now
<Keybuk> omeg: April 20th
<Keybuk> elmo: did that make it get loaded too?
<elmo> and networking works
<elmo> Keybuk: yep
<omeg> Er.
<mjg59> elmo: Ok. Can you file a bug - there's a patch for it
<mjg59> (somewhere)
<elmo> mjg59: against which package?
<mjg59> elmo: linux-source-2.6.15
<Keybuk> omeg: alternatively if you're preparing the font for Edgy, somewhere around September 14th
<mjg59> Keybuk: ? Changing the font to be non-butt-ugly is a bugfix
<Keybuk> mjg59: I would disagree ... it would require an exception to UserInterfaceFreeze
<Keybuk> and it's not "butt-ugly", it's just plain
<Keybuk> given the task of screenshots and documentation that include the startup screen, I'd err on the cautious side
<mjg59> Keybuk: I don't think we've ever regarded fonts as part of the UI freeze
<mjg59> Given that applications have still been changing them recently
<Keybuk> but that font affects a lot of things
<Keybuk> for example unless it's exactly the same size, we'll have to go through all the init scripts fixing the messages again
<Keybuk> so they don't word-wrap
<Keybuk> and I don't want to be doing that kind of thing right before RC
<mjg59> Wait, what?
<Keybuk> what do you mean, what?
<mjg59> When did we do that? Why didn't we just fix the word-wrapping?
<Keybuk> we did that this development cycle
<Keybuk> made sure all the messages fit onto one line
<Keybuk> otherwise it looked messy
<mjg59> Why? (They don't)
<Keybuk> even with proper word-wrapping
<Keybuk> they should
<Keybuk> blah blah  [ ok ] 
<Keybuk> looks better than
<mjg59> They certainly don't appear to, though I'd have to check which package it is
<Keybuk> blah blah  [ ok ] 
<Keybuk> blah
<Keybuk> blah blah  [ ok ] 
<Keybuk> which makes it look like blah failed
<mjg59> Keybuk: That's why you indent wrapped lines (and put the [ ok ]  after the last line)
<Keybuk> still didn't look nice
<mjg59> Where was this specced?
<Keybuk> you don't really get time to take in details like that when they're scrolling past so fast
<Keybuk> was discussed at UBZ
<mjg59> Keybuk: I'm a little frustrated that we didn't try to fix it in usplash
<mjg59> And that no bugs were raised to that effect
<Keybuk> why?
<Keybuk> we went for the easiest fix
* Keybuk doesn't see the problem
<mjg59> No, the easiest fix was to fix it in usplash
<Keybuk> fix what in usplash though?
<mjg59> Otherwise third party applications still look ugly
<mjg59> The word-wrapping algorithm
<Keybuk> the problem was that wrapped or indented lines made it look like there were failed services
<Keybuk> the only way to fix that would be to not word-wrap at all
<Keybuk> and then you have the problem of dealing with over-long messages
<mjg59> Keybuk: You produced code mock-ups?
<Keybuk> no?  why would I have?
<mjg59> I'm somewhat confused how you can claim that it made it look like there were failed services if the code was never tested like that
<Keybuk> it didn't need to be tested
<Keybuk> there were several examples in the ordinary boot and shutdown sequences
<elmo> mjg59: done
<Keybuk> so we fixed those
<mjg59> Keybuk: ?
<Keybuk> it was the spaces between the [ ok ] s that was the problem
<Keybuk> not how the stuff on the left was laid out
<omeg> Keybuk: well, I'm working on a font for usplash. I know it's past UI freeze, and if it doesn't get in before Dapper, then that's too bad. infinity said that he'd look into putting the font into usplash if it was easily possible. I hope it can be fixed since I really don't like that font (and the fact it's variable spaced).
<mjg59> usplash doesn't word-wrap properly. There's no way that you can use its current behaviour as a measure of how alternative behaviours would look
<Keybuk> any large gap between an ok made it look like a problem
<Keybuk> *shrug*
<mjg59> Keybuk: And it still doesn't help in the case of third-party applications
<Keybuk> like I said, easiest quick fix to the problem
<mjg59> Well, no, you could have filed a bug on the package causing the problem
<Keybuk> there already is a bug on usplash
<Keybuk> (that hasn't been fixed)
<elmo> mjg59: btw, bcm43xx still gives me no love, even with current dapper kernel.  well that's not true, it associates now, but I can't dhcp
<mjg59> elmo: What does tcpdump show while you're trying?
<Keybuk> long-term, I'm actually with the guy suggesting we shouldn't display boot messages
<Keybuk> I think the progress bar is sufficient
<Keybuk> elmo: got firmware for it, right?
<elmo> mjg59: err, good question.  not sure, I'll check again while I still have the laptop
<elmo> Keybuk: heh, yeah
<Keybuk> elmo: just checking
<joelbryan> yeah!, it should display boot messages
<omeg> Which one? I'm one of them, Keybuk. Hold on, grabbing a link to an alternate proposal I made...
<Keybuk> joelbryan: you appear to be simultaneously agreeing and disagreeing there, how diversive of you ;)
<mjg59> Keybuk: Bug number?
<omeg> https://wiki.ubuntu.com/Usplash/Artwork#preview <-- My proposal at the bottom.
<joelbryan> I mean, progress bar is sufficient
<Keybuk> mjg59: don't recall, I don't pay attention to usplash bugs
<Keybuk> it was in the list when I looked
<omeg> Basically, it's just the progress bar plus a message that states what's happening and some aesthetic additions.
<joelbryan> boot messages is too much
<Keybuk> omeg: yeah, that
<Keybuk> perfectly sufficient imo
<Keybuk> will probably try that for edgy for a bit, see how it feels
<mjg59> Keybuk: Having checked them, I can't find any bug opened on this
<Keybuk> mjg59: check the rejected ones ?
<omeg> I think that boot messages are cool, but not really of any use to the people that Ubuntu seems to be positioning itself for. They're kind of a geek toy, maybe.
<joelbryan> I remember filing a bug report on usplash, to display only 1 line
<Keybuk> mjg59: it may not be under usplash anymore, it may have got rejected and filed back on the init script package
<Keybuk> was before we switched to malone
<mjg59> Keybuk: Nope
<omeg> Keybuk: it'd be very cool to see that in an Edgy alpha (plus if enough people like it then I might have just made a design that's seen on millions of computers worldwide everyday during startup...)
<Keybuk> I don't have my bug mail archived from before my server change I'm afraid
<Keybuk> but it was there
<mjg59> Keybuk: I don't recall ever seeing a bug on this filed against usplash
<Keybuk> omeg: easy enough to test, just comment out the usplash_write stuff from lsb/init-functions
<joelbryan> mjg59: Bug #32327
<Ubugtu> Malone bug 32327 in usplash "Crop all the text into 1 single line." [Wishlist,Unconfirmed]  http://launchpad.net/bugs/32327
<mjg59> joelbryan: No, that's an entirely different bug
<Keybuk> mjg59: I'll have a look later
<omeg> Yeah, but I mean including that progress bar that I made. It'd be pretty cool to see that one in action.
<omeg> I really should make an interactive example of that.
<_ion> Argh, a blinking Ubuntu logo. https://wiki.ubuntu.com/Usplash/Artwork?action=AttachFile&do=get&target=usplash2_mockup.gif
<omeg> Isn't that blinking logo just because of a fault in GIF encoding?
<omeg> Oh wait, I'm now reading that entry.
<omeg> Yeah, I really would not like a glowing (or animating in any case) logo.
<Keybuk> heh, not even have the threesome spinning? :p
<omeg> Well, that (plus <blink> tags for all the boot messages).
<omeg> I also think that the entire screen's palette should have a continuous full hue shift since you just can't make a cool operating system without it.
<omeg> (</sarcasm>)
<joelbryan> how about BOML
<omeg> What's BOML?
* _ion predicts the Windows logo in Visva will blink during bootup, and after a year Windows users say Ubuntu sucks because its logo doesn't blink while booting.
<omeg> Well, that's already going to happen with the UI in Ubuntu not being transparent (and sucking up 80% of that cool new CPU you just bought).
<Keybuk> Vista's boot logo looks mostly like the current XP one, doesn't it?
<Keybuk> just a bit "shinier"
<omeg> Although I do think it would be rather nice if Ubuntu's UI could have anti-aliased edges in themes that have rounded edges.
<Keybuk> the early betas had the windows logo in B&W, which looked kinda cute
<ogra> omeg ++
<ogra> thats why i *hate* rounded metacity themes
<fabbione> mdz: btw.. the X bugs are going down and LP tells you lie!
<fabbione> mdz: the subscribed thing is tricky.. because all non-X bugs that gets reassigned will still keep ubuntu-x-swat as subscribed..
<omeg> Yeah. Well, I don't hate them. But I think that it'd be nicer with anti-aliasing. It looks really good in the Mac OS UI.
<fabbione> mdz: i did speak with LP guys to have a button to unsub a team (as team leader/or part of the team)
<_ion> Window opacity is one of the most distracting effects the composite extension makes possible. :-)
<mdz> fabbione: there's already a bug open
<omeg> Window opacity?
<mdz> fabbione: if the +packagebugs had totals, that would be good
<fabbione> mdz: yes the feature should be ready relatively soon
<_ion> On the other hand, window shadows are among the useful effects.
<fabbione> mdz: yeps...
<omeg> I think any kind of transparency (barring shadows, which seem to be very useful) in UIs aren't good practice.
<omeg> Shadows seem to help discern what the active window is. They also just look really cool. I wonder if that's possible in future releases without being a performance hog.
<_ion> It isn't a performance hog if the GPU handles it completely.
<omeg> So then the GPU drivers are the limiting factor?
<_ion> If the hw and the driver support OpenGL acceleration, compiz should generally work.
<omeg> I really don't know much about technical stuff, by the way. I only know ActionScript coding (although I do know that well enough for advanced stuff as far as possible with it). I mainly just like watching the development and discussing things from a designer's point of view.
<_ion> Xgl+compiz that is.
<ogra> but there are still more systems out there in the world that dont support GL 
<ogra> so you cant easily make it a default
<mdz> fabbione: it is definitely going down though; that much is easy to see even with the error rate
<fabbione> ehehe
<_ion> You can make it a default on hardware that can handle it. :-)
<joelbryan> software rendering can solve all the GPU issues.
<omeg> That would be great. I'm sure that every nVidia and ATi card in existence supports it. Are the onboard cards that you're worrying about?
<omeg> *what you're
<ogra> mdz, german and turkish edubuntu ubuiquity installs finished without any issues, no swap, 265M, amd64 and i386 tested
<_ion> You really don't want to use CPU time for rendering shadows as a default.
<mdz> ogra: great, thanks
<mjg59> How often are windows being re-rendered when the CPU is at 100% anyway?
<joelbryan> with software rendering, you don't need an AGP, it will work even for old hardware.
<ogra> we had issues with a laptop with only 200M in #edubuntu before
<mjg59> Kamion: Is there any reason we don't enable swap during a ubiquity install?
<mjg59> Surely the locale generation is after partitioning?
<mjr> The thing isn't as much that plenty of hardware couldn't handle shadows by default. It's that plenty of it can't, using free (and stable) drivers.
<mjr> the r300 dri gives some hope at least
<mjg59> The fact that lots of hardware is produced by unfriendly companies shouldn't prevent us from spending time on supporting the hardware that /is/ well supported
<mjr> obviously
<mjr> just that nvidia owners can't really complain about not getting razzledazzled by default
<mjr> does any free dri driver support pbuffers/fbo tho?
<mjr> (required for opengl/xvideo clients on Xgl)
<mjr> ah well, I digress from the channel topic
<Keybuk> mjr: why can't we complain?
<mjr> well, to Ubuntu, anyhow. Complain to nvidia all you like.
<Keybuk> I can complain to the Xorg authors for not improving their free drivers?
<_ion> We should do what RMS does. ;-)
<ogra> ranting until we die ? 
<mjr> Keybuk, well yes, you are undoubtedly capable of that, but it won't do you much good
<mjg59> mjr: We're unlikely to be going with Xgl
<_ion> ogra: Google for RMS+ATI+protest.
<ogra> doesnt help in his case :)
<highvoltage> declaring wars on ATI?
<fabbione> Keybuk: that would go back to nvdia or ati fro not releasing all their spec pubblicaly..
<Keybuk> I maintain what I've always said, until we (Linux, Open Source, etc.) have a significant portion of the customers of big vendors; they don't care a monkeys
<kmon> mjg59: may I ask why?
<Keybuk> and for us to get that significant portion, we need to support them
<Keybuk> so that means dealing with hardware, even if the vendor is uncooperative
<ogra> kmon, because we'd exclude a huge amount of users ? 
<Keybuk> if we stick our head in the sand and claim it's all their fault, then we're not going to win
<mjr> mjg59, yes well, last I checked AIGLX didn't do either of those things at all, but perhaps things change ;)
<kmon> ogra: ok.
<mjr> Keybuk, win what?
<Keybuk> mjr: customers, users, etc.
<mjg59> mjr: Mm? Xv works fine with aiglx
<mjg59> You lose the ability to do shaped or translucent video, but, well
<fabbione> night people
<mjr> mjg59, well, I just read that it doesn't work with the composite manager, so I assumed it meant "at all if the manager is running"
<mjr> ('course, you can always turn it off, but seems kinda heavy to have to do that for watching video)
<mdke> jdub: eia
<Kamion> mjg59: we do enable swap
<Kamion> mjg59: and yeah, good point, that makes the later locale-gen not a problem
<mjg59> Kamion: So why is the memory usage of localegen an issue?
<mjg59> Heh
<Kamion> mjg59: we run locale-gen immediately after the language screen, so that ubiquity can setlocale()
<mjg59> Kamion: Ah!
<Kamion> this is necessary in order to display translations of ubiquity itself
<mjg59> Right
* Kamion goes back to the TV :)
<dholbach> i'm off to bed - good night guys
<mdke> night dholbach 
<dholbach> night mdke
<mdz> sfllaw: would you join us over on #ubuntu-kernel for a bit?
#ubuntu-devel 2007-05-07
<Solarion> what was the link to how to capture debugging info from OOo 2.2?
<jbj^> hello
<jbj^> is this relevent for Fiesty? https://help.ubuntu.com/community/LiveCDCustomization/6.06
<crimsun> where applicable.  See reconstructor.
<jbj^> reconstructor hasn't been updated for fiesty
<jbj^> I managed to hack it to work with fiesty but it's still kinda weird
<crimsun> it's probably best that you address that in their contact channel (if they have one), then.  Sorry, but it's off-topic for this channel.
<jbj^> ok
<linitrofe> How can I get involved in the ubuntu mobile/embedded development?
<crimsun> http://people.ubuntu.com/~cjwatson/uds-sevilla/track-mobile.html  and https://wiki.ubuntu.com/UDS-Sevilla/Participate
<linitrofe> Perfect, thanks
<concept10> crimsun, Im glad you post that link
<concept10> I think that information should have been included with the recent announcement or maybe I missed it.
<crimsun> you missed it.  https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-May/000290.html
<concept10> crimsun, thanks again.
<norman> Hi all
<norman> I'm one of the PMC for james mailserver (james.apache.org). And we want to ask about include james in ubuntu. Where I should start to ask about it ?
<Treenaks> norman: is it in Debian?
<norman> If there whould be any intressed I whould start to prepare the packaging
<Treenaks> norman: if possible, we prefer to take the Debian package, instead of our 'special' own package
<norman> Treenaks: No.. Its is included in none OS yet... We just thought about to build debs now ;-)
<norman> Thats why i asked 
<Treenaks> norman: You really should ask Debian then -- to avoid conflicts when Debian adds it themselves and we sync it in :)
<norman> Treenaks, ok so you think debian is the best place to start. I just ask because its a "java" app and debian not include the java bins.. Just java-comon
<Treenaks> norman: they do have java, maybe not _sun_ java..
<Treenaks> but they do have java :)
<norman> Treenaks, Well we need sun java.. Thats the point 
<norman> At least im not 100 % sure it will work quite well with other java stuf
<Treenaks> norman: they'll help you debug it, probably ;)
<Seveas> Treenaks, they have sun-java as well, in non-fre
<Treenaks> Seveas: sure, but 'non-free is not part of Debian', so it's not "in debian" :)
<Seveas> so 'james' should go in contrib
<Seveas> nitpicking :p
<Mithrandir> Treenaks: we can sync out of contrib, though
<norman> LOL.. Ok i will ask on debian . Thx for all your help
<Treenaks> Mithrandir: sure
<Mithrandir> norman: if you can't find anybody there who wants to package it, please do get in touch and we'll get it in directly in ubuntu
<Seveas> Mithrandir, not from non-free to multiverse?
<Mithrandir> the reason we ask you to try Debian is just to avoid double work if there's interest for it in Debian
<Mithrandir> Seveas: sure, from non-free too
<norman> Mithrandir, thx .. BTw, I did debian packaging ( own builds) in the past, so i think we whould be able to maintain it by our own. Whould this be a problem
<Mithrandir> norman: you would then either become a Debian or Ubuntu developer which is a process to go through; I would not recommend it unless you want to maintain more software for the distros; it takes some effort to keep up with policies and such.
<norman> Mithrandir, well I think my aviable time is not enough to mantain more then a few packages. So this will be very unlikly :-/
<StevenK> cjwatson: There is a typo in your tags for the UDS Sevilla pages. You have a 'community' tag, and a 'commmunity' tag.
<Seveas> StevenK, commmunity is community for commmies ;)
<Treenaks> "We put the mmm in Commmunity!"
<StevenK> Hah
<Mithrandir> norman: then I would rather recommend you work with a maintainer who is already a DD or UD.
<StevenK> I should have known that would start a flurry of bad jokes.
<norman> Mithrandir, thx for all your help.. I will try to start with debian. If there is no intressed i will come back
<Mithrandir> great. :-)
<Hobbsee> morning all
<Fujitsu> Hi Hobbsee.
* Hobbsee looks for some small pebbles or something.
<Mithrandir> hiya Sarah
<Mithrandir> there's candy here, use that?
<Hobbsee> hi Fujitsu 
<Hobbsee> Mithrandir: heh.  that'd work :)
<fabbione> hey Hobbsee 
<Hobbsee> Mithrandir: you *do* know it's to throw at you, dont you....
<Hobbsee> hiya fabbione 
<Mithrandir> Hobbsee: as I was typing earlier.. if you do that you might find yourself tickled during the day.
<Hobbsee> oh dear...
<Hobbsee> Mithrandir: thanks @ the spec
<Mithrandir> oh, np
<Hobbsee> (yay, launchpad email nto dying)
<seb128> gaim
<seb128> ups
<Seveas> Hobbsee, will probably find herself tickled anyway
<Hobbsee> *glare*
<Mithrandir> Seveas: shh! lull her into a false sense of security. :-P
* Hobbsee wonders....
* Hobbsee has enough lollies here to throw at both of them
<Hobbsee> ice cubes would be better though
<Mithrandir> they'd melt
<Hobbsee> not before they went down your neck.
<tepsipakki> while airborne?
<tepsipakki> ah :)
<fabbione> the air friction will make them melt
<Seveas> Hobbsee, ask jono yo join IRC, I need to show him something
<fabbione> ballistic missile from au!
<tepsipakki> air must be thicker down there ;)
* Hobbsee isnt *in* au
<fabbione> Hobbsee: we know.. we can see you..
<Mithrandir> Hobbsee: what, you're not carrying a small bit of .au around with you, so you don't feel homesick? :-P
<fabbione> but do you have ice cubes here? ;)
<jono> fabbione: she is in .au
<Hobbsee> Mithrandir: no..i'm only missing the chocolate :P
<fabbione> jono: ?!?
<jono> fabbione: this is her evil twin
<Mithrandir> Hobbsee: they have chocolate here too.
<fabbione> jono: ROFL
<Hobbsee> proper chocolate?
<Mithrandir> jono: sure it's not the angel twin?
<Fujitsu> jono: You sure this is the evil one?
<jono> heh
<Fujitsu> Damnit.
<Seveas> (with apologies to Elton John): http://paste.ubuntu-nl.org/19584/
<Seveas> for jono ;)
<Hobbsee> Mithrandir: you'll keep...
<Keybuk> doko: you need more discussion about python-roadmap?
<jono> Seveas: you do know I could throw something at you from here
<Seveas> yes I do
<jono> Seveas: maybe I could throw sarah, she is small and nimble
<Hobbsee> hey!!!
* Hobbsee is unthrowable.
<Treenaks> Hobbsee: let's test that hypothesis
<Mithrandir> she's a fairly bad approximation of an ice cube, though
* Hobbsee looks around suspiciously...
<Hobbsee> hah.  true that.  although i'm usually cold enough
* Hobbsee looks for someone to poke Seveas, or ponders throwing things at him
<sladen> Hobbsee: *projectiles*
<Hobbsee> sladen: i got his attention. but yeah
<shawarma> I've got user-mode-linux working in gutsy. The package is based on the Debian one, but it's on the sync-blacklist. Also, the Debian package will ftbfs (for starters it depends on 2.6.18) so should I just upload my version and have it removed from the blacklist afterwards or will that mess stuff up? (Yes, BenC said it was ok to un-blacklist it).
<Mithrandir> shawarma: I'm happy to remove it from the sync blacklist if you have something that works sensibly.
<shawarma> Mithrandir: Ok. Should the upload and unblacklisting happen in any particular order?
<Mithrandir> shawarma: probably not important, but please upload first and then I'll unblacklist it.
<shawarma> Mithrandir: Will do. thanks!
<jdub> have fun, uds folks!
<rdonkin> hi i'm another JAMES developer 
<rdonkin> (Apache JAMES is a java mail server) 
<Mithrandir> hiya jdub 
<seb128> jdub: we do ;)
<rdonkin> norman chatted with you guys a little earlier
<rdonkin> i was wondering about your attitude to apache harmony
<rdonkin> AIUI debian are unlikely to declare any java package free unless it runs on classpath/kaffe
<Mithrandir> rdonkin: any java package that runs on stuff in debian main is going to be considered free.  There are other options, like gcj too.
<rdonkin> the debian java guys don't like the apache license
<rdonkin> free but not GPL
<rdonkin> apache harmony is free software but not GPL
<thom> rdonkin: um, there's a lot of apache licensed stuff in debian main
<Mithrandir> yeah, given it's apache it's probably under the ASL.
<rdonkin> AL2
<rdonkin> (we dropped the 'S' for version 2.0)
<rdonkin> the java guys seem to be very GPL
<thom> rdonkin: do you have mailing list posts you can point to for this?
<rdonkin> nope
<rdonkin> was a few year back 
<rdonkin> their policy documentation hasn't changed and doesn't mention harmony as an acceptable free java
<thom> the only problem with java in main is the lack of free JVM. because harmony fixes that, i don't see where the problem is
<thom> well, go ask them?
<rdonkin> life's too short :-/
<thom> basing your policy on something that preexists harmony seems, um, a little silly :-)
<rdonkin> sun should have open sourced java by then
<rdonkin> just wondered whether it would be worth out effort asking harmony to verify that james works
<rdonkin> out -> our
<thom> well, i obviously can't speak for anyone else but AL2 is DFSG free (otherwise a2 wouldn't be in main), so yes, i think it'd be worth the effort
<thom> it was good to meet you on friday, btw
<rdonkin> hi
<rdonkin> didn't know you ubuntu'd
<Keybuk> thom: so, err, aren't you supposed to be here?
<rdonkin> had hoped that debian would update their java policy stuff
<rdonkin> by now
<thom> Keybuk: didn't get it sorted :( (and last week was too horrible for words)
<rdonkin> thom: good to meet you too
<bryyce> dholbach: for setting up an xorg triage team, do you have a url describing good things to do to prepare for the team?  info to gather, etc.?
<dholbach> bryyce: we already have https://wiki.ubuntu.com/XSwat - I started that, when fabbione and infinity were still taking care of X
<Keybuk> thom: shall I compare thee to JD?
<dholbach> bryyce: it'd probably make sense to gather ideas what a new X team could work on
<Keybuk> X/
<dholbach> bryyce: and then announce a public meeting to gather people who are interested and hear what they expect
<bryyce> dholbach: ok cool
<thom> Keybuk: hah :-)
<dholbach> bryyce: maybe we should gather up all people who did X in the past here at UDS, then brain storm a bit :)
<bryyce> dholbach: may be good; lets see who comes to the upcoming xorg sessions
<dholbach> yeah
<rdonkin> thom: seem to have a lot more of the apache java stuff packaged in main now :-)
<dholbach> bryyce: also get a mailing list for the team - maybe even two (one to route bugs there and one for discussion)
<rdonkin> thom: should have checked first and ranted later
<bryyce> dholbach: ok; maybe an appropriate list already exists?
<dholbach> at least it's not on https://lists.ubuntu.com/mailman/listinfo/
* bryyce todos
<bryyce> dholbach: joining the xswat team appears to route all the X bugs to you (apparently whether you want the mail or not *grin*)
<dholbach> rt at admin.canonical.com :)
<bryyce> heh, nah I just did some procmail hackery and all is good now :-)
<tepsipakki> if a xorg-bugs -list is made then the bugmail settings for the team could/should be adjusted
<bryyce> tepsipakki: are you going to call in for the xorg uds sessions today?
<tepsipakki> bryyce: let me check the schedule
<zyga> morning
<bryyce> tepsipakki: if not, let me know if there are any topics you'd like me to bring up
<tepsipakki> bryyce: partly yes, but I need some hardware :)
<tepsipakki> the xorg7.3 session is too late for me
<bryyce> ah too bad, we could really use you there -- but I'll take notes and pass along
<tepsipakki> sure, thanks
<pygi> hi dholbach 
<iXce> hey pygi :)
<tepsipakki> bryyce: it seems that inbound UDP is blocked by our beloved firewall, so no VOIP for me
<bryyce> :-(  bummer!
<tepsipakki> yep.. well, they can't take my irc! :)
<tepsipakki> +away
<tepsipakki> funny how one word can totally change the meaning of a sentence :P
<bryyce> hehe
<tepsipakki> but they both hold true
<bryyce> tepsipakki: do you know whether very many projectors provide EDID information?
<bryyce> tepsipakki: I've heard one of the principle issues in improving projector support is that they don't provide EDID
<bryyce> however, I'm wondering if this is true for all projectors or just some
<tepsipakki> that could be true.. I don't know how it is
<bryyce> hmm
<bryyce> another question is if it would be sufficient to get and test a small number of different projectors, or if we'd need to test a large variety
<tepsipakki> gah, lunch. I'll get back to you ->
<bryyce> cya
<jackie> window refresh
<pitti> ajmitch: btw, I didn't get your email with the session notes yet
<ajmitch> pitti: ok, I will email it from my box at home
<phaidros> is ubuntu-embedded limited to intel plattform?
<phaidros> what about mips, arm ..
<lifeless> u/win 22
<shawarma> win 2
<Burgundavia> heh
<cbx33> hey Burgundavia 
<Burgundavia> hey cbx33
<Treenaks> 
<bddebian> Heya
<Hobbsee> cjwatson: i'm not sure where keybuk is, i think he does MOM - it seems updated now, but the target in debian/changelog of the merges still seem to be feisty, not gutsy.
<Mithrandir> Hobbsee: iz fixed as of next run
<Hobbsee> Mithrandir: yay, thankyou :)
<JohnFlux> anyone see scott?  the upstart dude
<Mithrandir> JohnFlux: yes, why?
<Mithrandir> he's a the back in the main hall
<Mithrandir> at the, even
* Mithrandir ponders upgrading to gutsy.
<Hobbsee> Mithrandir: do it.  i just did.  nice fast connection
<Mithrandir> yeah, I got about 5Mbit upstream when uploading my photos this morning
<Hobbsee> nice :)
<Hobbsee> i'm jealous
<shawarma> Mithrandir: I uploaded the uml package, by the way. Just in case you felt like ACCEPTing some packages. :-)
<Mithrandir> shawarma: I'll get to it after I've done the 1086 other items in NEW. :-P
<shawarma> Mithrandir: Oh, dear. Debian had that many new ones waiting for Etch release?
<Mithrandir> shawarma: most of it is binary NEW
<Mithrandir> but it still requires inspection
<Mithrandir> I'll get to it when I get bored.
<Mithrandir> Hobbsee: and nothing has broken majorly for you yet?
<shawarma> Mithrandir: Have fun! :-)
<shawarma> Mithrandir: I'm also running gutsy.
<Hobbsee> Mithrandir: dunno.  havent rebooted
<shawarma> Mithrandir: It's working like a charm.
<Hobbsee> Mithrandir: but seveas is evil.
<Mithrandir> Hobbsee: what else is news?
<pygi> Hobbsee, tell us something we don't know? :)
<Hobbsee> Mithrandir: he tried to break my wrist!
<Mithrandir> that's a bit over the top.
<Hobbsee> yes.  he got belted.
<lifeless> Hobbsee: who?
<Mithrandir> I hope you have a video of that.
<Mithrandir> oops, did I say that out loud?
<Hobbsee> lifeless: seveas.
<Hobbsee> Mithrandir: hah.  unfortunately not
<mc44> Hobbsee: he hasnt pushed you into the pool yet? :)
<lifeless> mc44: its elkbuntu that is in line for the pool
<Hobbsee> mc44: that's what he was trying to do - drag me into the pool
<mc44> haha
<Hobbsee> lifeless: according to seveas, we both are
<lifeless> Hobbsee: sounds kinky
<Hobbsee> lifeless: i dont want to know what your idea of kinky is...
<lifeless> Hobbsee: clearly :)
<Hobbsee> Mithrandir: oh, i did get a trippy, broken effect...
<Hobbsee> apparently my battery was removed, and is not present.
<Hobbsee> (and my power cord is upstairs)
<Hobbsee> so, i appear to be running on magic.
<iXce> or on drugs.
<lifeless> sweet
<mc44> Well that should be included in the reduce power usage spec :p
<Hobbsee> hahahhaha, yes!
<iXce> Hobbsee kde is so full of crack
<Riddell> ?
<iXce> ^ racarr
<iXce> (tentatively trying to use an AZERTY keyboard)
<shawarma> Mao-BOF tonight, anyone? 
<robertj_> https://blueprints.launchpad.net/ubuntu/+spec/simplesamba is marked drafting but has no drafter assigned, is this normal?
<Hobbsee> still, i want to know if the battery will keep going forever, rather than dying
<Hobbsee> shawarma: YES!!!
<ajmitch> shawarma: sounds good
<shawarma> rock
<shawarma> Fun fact: I don't quite remember the rules. This should be fun.
<Hobbsee> hahaha
<Hobbsee> even better
<shawarma> robertj_: No, I don't think so. Someone should pick it up.
<iXce> what's Mao-BOF?
<shawarma> A BOF where we play Mao. 
<iXce> sounds sensible.
<shawarma> Just like the people outside who have smoking-BoF's from time to time.
<iXce> ><
<shawarma> robertj_: We talked a bit about it, and we have a pretty good idea about how to go about. We'll probably play cards tonight, and whoever loses has to draft the spec..
<robertj_> shawarma: Unfortunately my pygoocanvas cardtable is still WIP, otherwise I could be elligible ;)
<robertj_> shawarma: any major concerns?
<highvoltage> iwj: will there be meau (spelling?) games again at this UDS? I really don't want to miss it if it happens :)
<lifeless> in all probabilty
<lifeless> 'mao' As in the chairman
<highvoltage> great! I've been looking forward to the next rounds since UDS paris was over :)
<iwj> highvoltage: I should imagine so, yes :-).
<shawarma> robertj_: Well, it requires changes to base-config and pam, but apart from that, it's not that bad.
<shawarma> highvoltage: If you payed attention, I asked about it not 20 minutes ago, both here and in #uds-sevilla. :-)
<shawarma> highvoltage: Me, Hobbsee and ajmitch are in.
<ajmitch> shawarma: gambling on the outcome of mao? brave
<shawarma> ajmitch: Not necessarily.
<shawarma> ajmitch: One could define the winner of a game of Mao as the person who has the most fun, since that is in fact the true object of the game.
<Hobbsee> shawarma: woo :)
<robertj_> shawarma: as long as people think of the spec as pre-samba prep, instead of "can't we use the better proven and more versatile xxx to do this instead" everything should be ao-k
<shawarma> robertj_: I don't remember what was originally in the spec, but what we're going to do is make libpam-smbpass add itself to the pam auth and passwd stack and *possibly* make it installed by default.
<shawarma> robertj_: I'm not quite sure about that last bit, since adding it to the  auth stack with the migrate keyword set, is "good enough". The hard part is really to add it to the pam stack, and that's why I'm patchin pam right now.
<robertj_> shawarma: adding it as a default dep is fairly important because otherwise people have to go back and reset passwords after installing samba and people just don't know to do that
<robertj_> it seems like half of samba problems are answered with "set a smbpasswd"
<robertj_> and it will be those some people asking except the response will be "reset your password"
<robertj_> shawarma: what do your pam patches do?
<highvoltage> Riddell: so people refer to you as "John" these days?
<highvoltage> Riddell: you do realise that's a betrayal of Jonathans?
<Solarion> when is the new bibliography stuff expected to land?
* Solarion would love to cut his mom free from RefMan
<shawarma> robertj_: No, they won't. check out libpam-smbpass's migrate option. All they'll have to do is log in as usual.
<shawarma> robertj_: About the pam changes:
<shawarma> robertj_: right now you can add an include directive to a pam config file and it will include that one file.
<shawarma> robertj_: I'm add an option to include a directory so that packages easily can add stuff to the pam stack without patching existing files.
<shawarma> robertj_: That makes it possible for the libpam-smbpass package to just dump a config file in something like /etc/pam.d/common-auth.d/ and hence will be in the pam auth stack. 
<shawarma> robertj_: (since it's considered bad form to alter other package's configuration files)
<Mithrandir> shawarma: shiny
<shawarma> Mithrandir: :)
<Solarion> is there any chance there'll be official feisty vmware player images put up on ubuntu.com?
<Solarion> 'cause there really outta be.
<pochu> !info vmware-player
<ubotu> vmware-player: Free virtual machine player from VMware. In component multiverse, is optional. Version 1.0.2-2 (feisty), package size 11602 kB, installed size 31336 kB (Only available for i386 amd64)
<Solarion> not at all what I mean.
<Solarion> how about I rephrase: there really ought to be official ubuntu vmware player appliances up on ubuntu.com
<jdong> infinity: idn if you got the message, but can you look at ktorrent 2.1.4-0ubuntu~feisty in build queue for me? it seems stuck.
<Solarion> livecds are great, but require rebooting
<jdong> Solarion: http://isv-image.ubuntu.com/vmware/
<Solarion> jdong: are these official?
<jdong> Solarion: umm.... they're on ubuntu servers....
<jdong> I would expect them to be as official as it gets
<Solarion> what is this isv-image server?
<pochu> Solarion: sorry, I didn't undertand you :)
<jdong> Independent Software Vendor, I think....
<Solarion> pochu: I wasn't all that clear.  Sorry.
<Solarion> jdong: I can grok that myself, but the question is what is the server for?
<Solarion> where did you get the link for that?
<jdong> Solarion: I got the link from cdimage.ubuntu.com/vmware
<Solarion> what is cdimage.ubuntu.com?
<pochu> Solarion: where the .iso images are :)
<jdong> it's the server where all the ISO image spins are kept
<Solarion> so how is it the same/different from releases?
<jdong> releases are where final release ISO's are kept
<jdong> cdimage has all kinds of other images...
<jdong> such as DVD's, nightly builds, unsupported architectures, etc
<Solarion> would be nice to have a link to the various things from the "Download" area then
<Solarion> also, putting them in the vmware marketplace would also be great.
<Solarion> I had no idea about isv-image and friends
<jdong> Solarion: agreed; I don't know why it isn't more prominently advertised
<jdong> I only know about it because I've explored around the cdimage server a lot
<Solarion> suppose I could put something in the wiki, but it's not exactly the same
<Riddell> highvoltage: who does that?  that is a crime to be dealt with
<\sh> d-i showed  problems setting up eit gpt tables on >2TB devices, attached storage device....(feisty server install)
<\sh> 32)
<\sh> or fdisk is too stupid to give me the right answer...(setup via parted as eit gpt tables, fdisk tells me it's an efi table)
<\sh> grmpf...and d-i partitioner finds the unused smartarray p800 port and grumbles with an error
<jcole> where can i learn more about this? -> http://www.infoworld.com/article/07/05/07/ubuntu-mobile-linux_1.html
<bluefoxicy> I'm curious, how exactly do the Ubuntu install CDs get made
<Keybuk> usual CD manufacture process
<Keybuk> laser-printed foil glued between two pieces of plastic
<bluefoxicy> There's a lot of remastering docs and customization utilities out there, but you can't just remaster an existing LiveCD every time; the underlying technology on the LiveCD has changed over time, some use SquashFS instead of cloop, Ubiquity now allows you to do LiveCD install...
<bluefoxicy> Keybuk:  I'm not one for the physical world, it is a world of games and meaningless actions taken only for self-enjoyment ;)
<bluefoxicy> The world of data is more pure
<mjg59> Launchpad does shit.
<desrt> mjg59; missing you in sevilla
<mjg59> It's ok, I'm in the pub
<desrt> mjg59; i guess that's the 2nd best place that you could be
<ant30> Hi all, I proposed two blueprint on launchpad, about network-manager and other bluetooth about 
<wasabi_> Looks like it's about time to package Zimbra.
<zul> heh good luck on that
<wasabi_> Yeah, already gave it a try once.
<wasabi_> I know it's going to be a bitch.
<wasabi_> Their entire goal is to make it take over an entire machine heh
<shaya> did something happen w/ font sizing in gutsy over the past few days?
<\sh> Mithrandir, do you know why we don't support dial-up devices in network-manager?
<giskard> because nm doesn't support them?
<giskard> mayne 0.7 will support dial-up dev
<\sh> giskard, NM does support them....suse is doing that e.g. and rlove wrote on 2006-04-06 something about modems in his Changelog
<giskard> how?
<Mithrandir> \sh: nobody took the time to make them work?
<giskard> dial-up as in ppp?
<giskard> hello Mithrandir 
<\sh> yepp
<giskard> \sh, are you sure?
<\sh> Mithrandir, k...let me check if I can port the suse patch towards 0.6.5 ;)
<Mithrandir> hiya giskard 
<\sh> giskard, yepp...I just have the suse src rpm from opensuse 10.2 here 
<\sh> nm-0.6-branch patch 
<highvoltage> Riddell: http://blog.notsosoft.net/2007/ubuntu/live-from-uds-sevilla-jeglagged-in-spain.html
<highvoltage> he calls you "John Riddel"!
<giskard> \sh, why it's not in the main tree?
<sn0> shaya yea the font dpi seems to have dropped 
<\sh> giskard, well, reading the source of 0.6.5 there are some things about modems/isdn/dial-up ppp devices 
<\sh> giskard, I have to check more carefully...what is in...
<sn0> change it back to 96 if you prefer the old method in system > pref > fonts > details
<\sh> giskard, backends/NetworkManagerDebian.c 
<giskard> \sh, and?
<giskard> i don't see your point :(
<shaya> sn: it doesn't seem to help me for firefox
<sn0> shaya restart firefox :)
<shaya> I did
<\sh> giskard, it should work....it reads the entries from /etc/network/interfaces e.g. iface ppp0 inet pppo
<shaya> firefox content is fine
<\sh> aeh ppp
<shaya> the menus are still small
<shaya> still small that is
<shaya> hmm, and content is getting cut off in xchat
<shaya> maybe have to restart that too
<sn0> do you have firefox-gnome-support installed, not sure if i did anything extra to change mine back
<sn0> doh
<\sh> let me reboot
<\sh> brb
<\sh> argl...it's so stupid ;)
<\sh> giskard, it works
<giskard> :)
<\sh> also with ubuntu, if you know that you have to reload NM to catch your modems
<giskard> ? why?
<\sh> but this have to be done, when you enter your ppp configuration in gnome-network settings
<\sh> giskard, NM checks your /e/n/i for inet ppp devices and catches it, but only after you stop NM and restart it
<\sh> then you can see an entry for dial-up connections.
<giskard> uh, didn't know this :) 
<\sh> but it's not reloaded when you configure your stuff via g-n-s
<adam0509> hi, who is in assurance of the cannonical commercial repo ?
<\sh> adam0509, canonical...
<adam0509> err... thank you :] 
<adam0509> but where can I ask why there are so few packages in commercial repo...?
<\sh> adam0509, it meant canonical is responsible for the commercial app repos
<geser> tepsipakki: are there any plans to update xserver-xorg in gutsy?
<ant30> I see the some spec for xorg 7.3 geser 
<JohnFlux> Is there a uds channel?
<JohnFlux> or are people just hanging in here?
<geser> JohnFlux: #uds-sevilla
<tepsipakki> geser: bryce is your man nowadays. 7.3 is not released yet, though
<geser> I have some xserver-xorg-input-* package on my merge list. And at least one depends on xserver-xorg-dev (>= 2:1.2.9
<geser> 9.902)
<tepsipakki> merge?
<tepsipakki> which one?
<geser> xserver-xorg-input-joystick (universe)
<tepsipakki> I've been working on getting them sync'able
<tepsipakki> joystick should be syncable
<geser> the versioned B-D on xserver-xorg-dev is a problem
<tepsipakki> when the new server is in
<tepsipakki> right, sync when xserver 1.3 is in
<geser> so I should wait with merging/syncing them?
<tepsipakki> yes
<geser> any timeframe when xserver 1.3 will be available?
<tepsipakki> I don't know, haven't discussed about it with bryce
<tepsipakki> it would break fglrx/nvidia, though
<geser> ok, I put them at the bottom of my merge/sync list for now
<geser> thanks
<tepsipakki> np
<pochu> tepsipakki: as long as it doesn't break the intel driver... ;)
<pochu> btw, isn't 2.0 out yet?
<tepsipakki> yep, since a couple of weeks
<tepsipakki> released the same day as xserver 1.3
<pochu> then it would be fine to update it
<tepsipakki> same thing as with the rest of the drivers; wait for xserver 1.4
<tepsipakki> uh
<tepsipakki> 1.3
<tepsipakki> since they can be synced then
<tepsipakki> but that's _my_ opinion ;)
<pochu> I trust you, and 1.94 is working fine
<tepsipakki> are you using gutsy?
<pochu> yeah
<tepsipakki> brave soul..
<pochu> heh, it's working fine
<pochu> (atm) :)
<tepsipakki> yep, the breakage starts after UDS :)
<pochu> heh
* pochu waits patiently for a kernel panic :)
<highvoltage> 8/win 11
<micahcowan> Would somebody like to look at/sponsor my patch for gawk, bug 58256?
<ubotu> Launchpad bug 58256 in gawk "length() memory error " [Undecided,In progress]  https://launchpad.net/bugs/58256
<pochu> !info gawk
<ubotu> gawk: GNU awk, a pattern scanning and processing language. In component main, is optional. Version 1:3.1.5.dfsg-4build1 (feisty), package size 468 kB, installed size 1956 kB
<Keybuk> http://www.youtube.com/watch?v=JDisnYe38io
<jmg> is that you?
<Keybuk> no
<Keybuk> lol
#ubuntu-devel 2007-05-08
<jmg> anyone familiar with udev rules?
<eddmul> anybody can help me? How to upgrade from Ubuntu Edgy to Feisty?
<eddmul> :-D
<bimberi> eddmul: please ask in #ubuntu
<eddmul> where is it? can you help me bimberi?
<bimberi> eddmul: sure, just type    /join #ubuntu    in your IRC client
<Hobbsee> morning all
<bhale> good "morning" Hobbsee 
<Hobbsee> hi bhale!
<cbx33> mornin
<bhale> Hobbsee: hugs
* cbx33 yawns
* Hobbsee hugs bhale back
<bhale> its not even 2am
<cbx33> 5:30am was a silly time to get up to code
<Hobbsee> bhale: it's 7.39am here
<Hobbsee> haha
<cbx33> esp as sqliet3 wasn't all it was cracked up to be
<bhale> cbx33: sql92 ftw?
<cbx33> sqlite3
<cbx33> python module
<bhale> nevermind.
<cbx33> oh
<cbx33> sorry
<cbx33> i dunno what to use
<cbx33> but the concurrent connection usage is lousy
<cbx33> and i have to have multiple concurrent connections as it's single thread only
<cbx33> so then I'd have to start caching data
<cbx33> *bah*
<bhale> right.
<cbx33> any suggestions?
<bimberi> Hi Hobbsee.  But does it feel like 15:43 (the time here) :)
<bhale> joe shaw has been bemoaning the same thing for years
<bhale> ever since switching from sqlite2
<bhale> there is no cure
<cbx33> :(
<cbx33> it doth suck as I don't want a whole complete database server
<cbx33> just enough
<pitti> good morning
* StevenK waves to pitti.
<StevenK> pitti: Do you mind if I steal your ucf merge?
<pitti> StevenK: I just merged it about a week ago, but go ahead
<StevenK> pitti: I had a two minute look earlier, I think it can now be synced.
<pitti> StevenK: oh, did Debian accept the 'show diff in debconf' patch? nice
<StevenK> pitti: Mostly.
<StevenK> pitti: Manoj took the patch and dropped the control changes.
<pitti> StevenK: sweet; what were the control changes?
<StevenK> pitti: mvo dropped the debconf-2.0 alternative. Manoj didn't like it, and so kept it.
<pitti> StevenK: hm, that's bad; cdebconf doesn't support the debconf option mvo used
<pitti> (allegedly)
<StevenK> Ah ha.
<StevenK> In which case, the Ubuntu changes only touch changelog and control, then.
<pitti> StevenK: well, it's something that should be fixed in Debian as well, so I'd just report it as a Debian bug and sync it
<pitti> it's not like it would actually hurt most people
<StevenK> pitti: How are you actually coherent this early in the morning? :-P
<pitti> StevenK: strong tea :)
<StevenK> * Left in the debconf-2.0 as is, since I am assuming anything that provides debconf-2.0 should be a drop in replacement, or that should be considered a bug. This is a change from Michael Vogt's patch.
<StevenK> pitti: Ah, don't like coffee?
<pitti> StevenK: no, not at all
<StevenK> pitti: Same. :-)
<StevenK> cdebconf doesn't support dynamic questions?
<pitti> StevenK: no, it was the extension that supported escapes in debconf
<pitti> StevenK: extension -> option
<StevenK> Escape being "I don't want to answer" ?
<mario> hi folks
<StevenK> Ah, escape not being that at all.
<StevenK> pitti: I daresay if cdebconf supports capabilities, it shouldn't be hard to add it.
<pitti> StevenK: no, returning strings like 'a\nb'
<pitti> StevenK: NB that I haven't verified if that's still true with the current cdebconf
<StevenK> pitti: Neither.
<StevenK> pitti: I'm more than happy to look into it, and file a sync or upload a merge as required.
<pitti> StevenK: ah, don't worry about the merge; it would be nice if you could grep the cdebconf source for that option, and if it doesn't have it, file it as a Debian bug against ucf
<StevenK> pitti: I daresay Manoj would just reassign it against cdebconf.
<pitti> StevenK: that would even sound right :)
<StevenK> pitti: Okay, the latest cdebconf in Feisty and Gutsy does not support the escape capb.
<StevenK> The question is, is escape mentioned in the debconf 2.0 specification...
<Mithrandir> I don't think it is
<pitti> StevenK: so ATM it should drop the alternate dependency then
<StevenK> pitti: Yes.
<StevenK> In which case ucf now uses debconf-only calls. Neat.
<Hobbsee> lets see how bad *this* wifi is, compared to upstairs
<Hobbsee> being disconnected is always fun.
<pitti> Hobbsee: apparently you are connected now :)
<StevenK> Hah
<Hobbsee> pitti: for now, yes
<ajmitch> Hobbsee: at least you can connect
<Hobbsee> ajmitch: true that.  you should be able to, as of this morning, too
<Hobbsee> depending on when you trie
<Hobbsee> d
<tarzeau> can i somehow help w/ #105996 ?
<crimsun> tarzeau: #ubuntu-motu
<tarzeau> crimsun: thanks
<Mirv> I drafted a new spec about fitting more language support on the CDs which is quite important for non-English people for a positive out-of-the-box effect: https://blueprints.launchpad.net/ubuntu/+spec/better-desktop-cd-language-support
<Mirv> enthustiastic people with lots of free time welcome :)
<Hobbsee> Mirv: what are you willing to drop off the cds, to make it fit, then?
<Mirv> Hobbsee: possibly documentation translation, or nothing if 7-zip is used for compression
<Mirv> Hobbsee: or having an automatic translations download already before installation
<Mirv> those three options I've found so far
<Hobbsee> wait for the archive admins to see it
<Hobbsee> most people are at UDS
<Mirv> yeah, I know, that's why I got up to do that spec
<Mirv> and I was just going to update my Gobby document with the info that there's now a spec about it :)
<Hobbsee> gobby's broken atm
<Hobbsee> wait 10 mins?
<Mirv> yeah, I created that document where it was documented that you (or MagicFab, both red) ate the documents, heh
<Hobbsee> hehe :)
<iwj> ./~ Every bug is sacred, every bug is good ./~
* pitti hands iwj some more goodness
<keescook> Keybuk: can you flip MoM's changelog generator to gutsy?  :)
<Mithrandir> keescook: done yesterday.
<Mithrandir> but it doesn't regenerate all the patches
<keescook> Mithrandir: ah, very good.  thanks
<Keybuk> it's regenerating them atm
<StevenK> keescook: Do you mind if I do the aolserver4 merge?
<keescook> StevenK: help yourself!  :)
<StevenK> keescook: Thanks. :-)
<keescook> There have been problems with building the aolserver4 components due to aolserver4's init script not working on amd64 for something reason.  be warned!  :)
<StevenK> Leet.
<thom> people still use aolserver?
<thom> the tcl, it burns!
<Seveas> it's tickly...
<StevenK> "The requested URL /a/aolserver4/REPORT was not found on this server."
<StevenK> Yay, I broke MoM!
<StevenK> Or something...
<StevenK> Oh, I so know what's going on.
<StevenK> It's doing main, and then it will go through and do universe.
<StevenK> Actually, only main seems to exist anywhere.
<StevenK> Mithrandir: ^
<Mithrandir> StevenK: looking.
<Mithrandir> StevenK: it's still running, I believe
<persia> Mithrandir: Are you accepting give-back requests this week?
<Mithrandir> persia: sure
<Mithrandir> I'll be in bofs and such so I might not be too responsive, but please just tell me and I'll get to it
* Fujitsu kicks the sparc buildds.
<persia> Mithrandir: Please give-back hydrogen on powerpc, ia64, i386, and amd64 (docutils is fixed)
<StevenK> I'm still waiting for kat to build on sparc.
<Mithrandir> persia: given-back
<persia> Mithrandir: Thank you.
<Mithrandir> sparc's slow, blame sun
<Fujitsu> LyX doesn't take 23 hours to build.
<Fujitsu> And I'm sure I saw it building a couple of days ago too.
<StevenK> Mithrandir: A build waiting 3 days, though?
<Fujitsu> That's what I thought.
<Fujitsu> sejong has been building lyx for well over 2 days, and there's no log.
<StevenK> Not any more.
<Fujitsu> Hm, maybe there was another upload...
<StevenK> "NOT OK : Exception (<Fault 8002: 'error'>) when setting up to new job (AUTO)"
<Mithrandir> I'll get James to poke it with a sharp stick
<jmg> 'error'
<Fujitsu> I know I saw LyX building on sejong a few days back.
<jmg> nice.
<Fujitsu> Very useful fault description, I see.
<StevenK> Mithrandir: artigas and sejong have the same issue.
<StevenK> And vivies is MANUAL, so there are no sparc buildds.
<Mithrandir> yeah, elmo is poking them now
<StevenK> Actually, why is vivies MANUAL?
<StevenK> There is no LiveCD for sparc!
<Fujitsu> Security?
<Mithrandir> sure?
<StevenK> I am sure? Not now.
<Mithrandir> let me check
<Mithrandir> I just have to nuke some bits off lithium first
<StevenK> Mithrandir: I can't see a Desktop CD for sparc on cdimage.u.c
<StevenK> Fujitsu: I doubt security uploads use MANUAL buildds.
<TheMuso> Mithrandir: If you're not busy, would you mind giving back rosegarden on sparc, ia64, and powerpc please?
<Mithrandir> StevenK: true dat.  Oh well
<Mithrandir> TheMuso: given-back
<TheMuso> Mithrandir: Thanks.
<StevenK> Mithrandir: Does that mean you'll get elmo to throw it back to AUTO, or you don't care enough?
<Mithrandir> StevenK: I'll poke adam about it.
<StevenK> Heh. Now both sparc's admit to building something, but something that started just about a day ago.
<Fujitsu> At about the same time, too.
<StevenK> Yes. It still smacks of fishyness.
<Fujitsu> Ah, they seem fixed now!
<Fujitsu> They're idle.
<Mithrandir> they'll be voluntold to build something soon, then.
<Fujitsu> They are now, yes.
<Fujitsu> voluntold, I like it.
<StevenK> They're volunteerly commanded to?
<TheMuso> heh
<persia> Mithrandir: Please give-back jackbeat for ia64 and powerpc
<Mithrandir> persia: given-back
<persia> Mithrandir: Thank you.
<Fujitsu> What's the rationale behind not giving us the give-back button?
<Mithrandir> Fujitsu: it allows you to do some bits you shouldn't, like disable the buildds.
<Mithrandir> but I'd generally be fine with core-dev, or maybe dev too having give-back privleges.
<StevenK> Mithrandir: Oh, do you mind if I deal with your bsd-finger merge?
<adrian15> Hello... any ubuntu grub package developer around here or someone that can give me some clue about technical details of gfxboot ? Thank you.
<\sh> hmm...what do I have to do, to tell dbus to restart an application, e.g. network-manager backend
<hunger> when will ubuntu-desktop become installable again on gutsy?
<StevenK> \sh: /etc/dbus-1/event.d/25NetworkManager {stop,start}
<\sh> StevenK, yeah...but we need to do it from gnome-system-settings (especially, when you configure a dial-up device)
<\sh> StevenK, so I wonder, if I can send a dbus signal to something, which restarts the app
<StevenK> \sh: Ahh. No idea, sorry.
<mjg59> \sh: ?
<mjg59> You don't want to restart the n-m backend. It'll tear down any existing connections.
<\sh> mjg59, I configured yesterday a dial-connection with gnome-system-settings (the network app) ... and you have to restart the network-manager backend (/etc/dbus-1/event.d/25NetworkManager restart) so that the nm-applet is reloading the devices...
<mjg59> \sh: That's clearly a bug.
<mjg59> Or a design flaw.
<mjg59> Fix that, don't restart n-m.
<\sh> mjg59, I would say the second
<mjg59> It's not acceptable to restart people's network connections just because they've configured a modem
<\sh> mjg59, how? how can I tell the nm-backend to reload it's devices and tell nm-applet that it has to show up with that ;)
<\sh> mjg59, I thought it would work with dbus messages
<mjg59> Why is the modem getting configured with gnome-system-settings, anyway?
<Fujitsu> Why not write PPP support into debian-backend?
<mjg59> I suspect that, if anything, this should be information that's going into hal
<mjg59> Not something that's just written out to a static text file somewhere
<\sh> mjg59, how do you configure a ppp device with gnome?
<\sh> not touching /e/n/i
<mjg59> Currently, with gnome-system-settings. But it's designed for static configurations in a way that network-manager isn't
<mjg59> Integrate things with the new world order rather than trying to hack stuff back into the old setup
<\sh> mjg59, well, after the backend restart, you can see the dial-up device appearing in NM...and it works :) 
<\sh> mjg59, debian-backend of NM is reading /e/n/i ... (not "auto"ed ifaces) 
<\sh> mjg59, and manual configuration from nm-applet is calling g-s-s / network-settings
<mjg59> This doesn't make it the right answer
<mjg59> n-m gets devices from hal
<mjg59> So, make sure the devices are in hal
<Fujitsu> Surely NM can do a little better for Gutsy.
<\sh> mjg59, how would you do it, when you have to configure your modem first via /etc/ppp/peers/<connection name>
<mjg59> Parse that, inject information into hal
<mjg59> But you're conflating things
<mjg59> There's two concepts - the device (which should be in hal) and the profile (which should be applicable to any modem device)
<\sh> mjg59, and nm is working with the profile
<\sh> the device is configured in the ppp-profile
<mjg59> As I said, you're conflating things
<\sh> mjg59, so you mean, we need to have a directory notifier, when /etc/ppp/peers has changed it has to send a signal that a new ppp device/ppp peer is available? I'm just trying to understand how we can come around this mess, just because the mix of hardware (modem device) and a software configuration with a "virtual" device (pppX)
<\sh> mjg59, or adding ppp configuration support for serial devices which are managed through hal
<mjg59> I think you need to stop thinking in terms of /etc/ppp/peers
<\sh> hmm..freedesktop.org is down?
<mr_cha0s> I have what's probably a weird question, but i'm a dev for a project ok... well this guy's been coming around, saying he's gonna make a .deb package for us, since it's cross platform. Well now he's saying he isn't using our binaries, he "made his own" etc and I couldn't possibly know the integrity of the package he wants to put up. My question is, when people upload packages, is it checked with the developers of the project? Or could a
<mr_cha0s> dunno if that was a whole message or it got cut off...
<Nafallo> cut off
<mr_cha0s> where at?
<mr_cha0s> well here
<Nafallo>  Or could a
<mr_cha0s> Or could any dude just upload a package with our name on it?
<mjg59> mr_cha0s: In general, packages are uploaded to Ubuntu as source code and then binaries built on the distribution build servers (which most developers don't have direct access to)
<mjg59> But yes, someone can add a package to Ubuntu without asking the upstream developers, assuming that the software license allows that
<mr_cha0s> that's kind of crappy ;S
<mr_cha0s> i thought it was a .deb package that got uploaded
<mjg59> No
<mjg59> For GPL-compliance reasons, we need to be sure that we can build the binaries we distribute
<mr_cha0s> thing is, it's a self-hosting BASIC compiler
<mr_cha0s> it's all GPL'd
<mjg59> How's it bootstrapped?
<mr_cha0s> it was started in VB-dos like 2 1/2 years ago lol. 32-bit ever since
<mr_cha0s> it's the best BASIC since QB hey
<mr_cha0s> now i know lots of people don't take basic seriously but i could care less ;p
<mjg59> When it's not possible to build a compiler in anything other than itself, I think we may accept binaries for the purpose of bootstrapping
<mjg59> But there'll still be a source upload for the shipped binary
<mr_cha0s> yeah, i just don't want this guy uploading some binaries he built. i don't even know him. i'm like "Use our binaries" and it's like i'm talking to a wall or something
<mr_cha0s> we have linux binary releases, we just do tar.gz for now
<mjg59> The binaries shipped will be binaries we build
<mr_cha0s> yeah, that's totally cool.
<mjg59> But as I said, that's all automated - whoever uploads stuff doesn't have access to the systems that do the building, so it's not easy to subvert them
<mr_cha0s> but like i said, there's ognna have to be those binaries to bootstrap it, not to mention he's uploading 2 minor versions back from current >.<
<Fujitsu> Is `he' related to Ubuntu at all?
<adrian15> do you know if cjwatson begins to be online on about 10 minutes or 15 minutes or is it later?
<adrian15> I have to talk to him but seems not being here.
<mr_cha0s> oh well i'll just hope for the best :P
<mr_cha0s> thanks for the input
<Mithrandir> StevenK: bsd-finger> feel free
<StevenK> Mithrandir: Right, thanks.
<adrian15> it does not matter I send him an email
<Mithrandir> asac: what do you think we should do about ice* packages when syncing from Debian?
<StevenK> Oh, twitch.
* StevenK had forgotten about that whole mess.
<asac> Mithrandir: going to session ... will talk to you then :)
<Hobbsee> Mithrandir: scream and run around
<Mithrandir> Hobbsee: oh?
<Hobbsee> [22:51]  <Mithrandir> asac: what do you think we should do about ice* packages when syncing from Debian?
<Mithrandir> oh
<Hobbsee> (screwy timezones)
<Mithrandir> yeah, I guess.
<Mithrandir> yeah, you're clearly from the future.
<Hobbsee> yep
<StevenK> Mithrandir: iceweasel should clearly be blacklisted, but I have NFI about the others.
<Hobbsee> and you're stuck in the past.  again.
<Mithrandir> I like it in the past.
<Hobbsee> but why?
<lifeless> Hobbsee: your time zone is clearly correct.
<lifeless> 23:00 < Hobbsee> [22:51]  <Mithrandir> asac: what do you think we should do about ice* packages when syncing from Debian?
<Hobbsee> lifeless: indeed.
<StevenK> I concur.
<Mithrandir> Hobbsee: because then it's so much easier to predict the future.
<Hobbsee> Mithrandir: good luck with that.
<Simira> Hobbsee: wow, are you online? :p How's Spain?
<pbn> hello
<Hobbsee> Simira!!!!
<Hobbsee> Simira: no. i'm offline, and manage to communicate via brainwaves
<Hobbsee> it's fun :)
<pbn> Hobbsee: is that you heh ? :)   http://www.notebookmagazine.com/people/images/h-people-sarahhobbs_145137b14e7516.jpg
<Hobbsee> i doubt it
* Hobbsee looks
<Mithrandir> Hobbsee: that's just like when your machine ran off magic yesterday.
<Hobbsee> Mithrandir: indeed!
<Hobbsee> pbn: she's kinda pretty.  i think i should say yes :P
<Mithrandir> I think we should disassemble Hobbsee and steal the technologies powering her.
<pbn> Hobbsee: heh :)
* Hobbsee does not wish to be broken or disassembled
<pbn> heh, like in Robocop ?
<Simira> Hobbsee: it's all for our common goals!
<Mithrandir> Hobbsee: we'll reassemble you afterwards.  Us being geeks, we're good at both disassembling and reassembling technical inventions.
<pbn> yeah
<Hobbsee> Mithrandir: right...just dont attempt to break me, please
<pbn> I like doing that with old hardware
<Treenaks> Hobbsee: he's been trying all week, didn't you notice?
<Hobbsee> Treenaks: of course i have.  
<Simira> Hobbsee: you might even get some extra bu^features being reassembled!
<StevenK> Treenaks: Mithrandir is always trying.
* StevenK hides.
<Hobbsee> Simira: oh wonderful.
<StevenK> Simira: You're missing a W.
<StevenK> It's ^W
<Hobbsee> Simira: what would they be?
<Simira> StevenK: it's just you who can't see it
* Hobbsee pictures a Hobbseecompositor
<Simira> Hobbsee: that's a surprise for you to discover
<Treenaks> Hobbseecopter?
<Hobbsee> mmm...cool
<Hobbsee> Treenaks: you mean i'd get the ability to fly???  COOL!!!
<StevenK> Simira: Fair enough
<Treenaks> Hobbsee: you might..
<Mithrandir> Hobbsee: anything flies given enough velocity.
<StevenK> And trust
<StevenK> Er
<StevenK> Thrust
<Treenaks> StevenK: or both 8)
<Mithrandir> StevenK: you sven.
<Mithrandir> or antisven
<StevenK> Uh huh
<StevenK> I don't particulary like that nickname.
<StevenK> So don't use it.
<Hobbsee> Mithrandir: that's...not good.
<Hobbsee> Mithrandir: just dont give seveas ideas...
<Mithrandir> Hobbsee: the velocity, trust, thrust or sven bit?
* Hobbsee looks for the trust part
<Treenaks> Hobbsee: 'trust me'
<Treenaks> "it'll work"
<Hobbsee> Treenaks: nah, dont think so :P
* Hobbsee snorts
* Treenaks shows the log to Seveas
<Hobbsee> Mithrandir: the idea of me with velocity, yes.
<Simira> Treenaks: hey, how's the videoing coming along?
<Treenaks> Simira: sladen has my camera
<Simira> Treenaks: is that really safe?
<ajmitch> he's not videoing anyone right at this moment
<ajmitch> so it's safe enough
<Treenaks> Simira: safe enough
<Hobbsee> mmm...cameras...must eat cameras...
<Hobbsee> s/eat/destroy/
<Treenaks> Hobbsee: because of http://foodfight.org/fotos/2007/05-07%20UDS%20Sevilla/ ?
<Hobbsee> Treenaks: that's one lot, yes.
<Treenaks> Hobbsee: but.. but.. you're on there only once!
<Hobbsee> Treenaks: that's once too many!
<ajmitch> Hobbsee: why?
<Hobbsee> ajmitch: because i look awful in photos
<Mithrandir> it really doesn't help when you take pictures of people at 18mm or thereabouts.
<Mithrandir> they look like they're in a fish bowl.
<Hobbsee> yes, well...
<Treenaks> Mithrandir: yeah :) I did that on purpose
<ajmitch> Hobbsee: you just look like you're about to hit him
<Hobbsee> ajmitch: my arm isnt long enough.  and i'm not quite sure where he is.
<Hobbsee> ajmitch: maybe later.
<Treenaks> Hobbsee: who? me? look on your right and up
<Hobbsee> Treenaks: ahh.  i was actually thinking of Mithrandir, but maybe both of you
<thom> Mithrandir has been buying more camera stuff i see
<Mithrandir> thom: yeah, but my 50mm didn't arrive before I left for .es
<Mithrandir> so I don't have any really nice and bright portraity lenses.
<Mithrandir> 50mm f/1.4
<Treenaks> Mithrandir: I have a 50mm/1.4 for my canon
<Treenaks> it _rocks_
<Mithrandir> yeah, I played with a friend's some time ago.
<torkel> oh, stop it. I getting jealous :-P
<Treenaks> (rocks: http://foodfight.org/fotos/2006/05-12%20Fear%20Dark%20Festival/img_0112.jpg.html)
<Hobbsee> Treenaks: TWITCH!
<Treenaks> Hobbsee: twitch? why?
<Treenaks> Hobbsee: it's just a scary long-haired metal guy..
<bddebian> Heya
<thom> Mithrandir: yeah, i got my 50/1.4 a couple of weeks back
<Hobbsee> oh wait, wrong link
<Mithrandir> thom: got a domke f-2 bag though.  Lovely, lovely bag.
* Hobbsee just saw one of the planet photos
<thom> Mithrandir: ooh, nice
<infinity> jdong: I'll fix that up for you first thing in the morning, don't stress about it.
<Mithrandir> hiya Adam
<mario> hi folks
<robertj_> I was told that a drafter would be assigned to simplesamba based out on the outcome of a card game? Did this not occur? What must I do to facilitate further gambling (and presumably drinking) on this matter so that this situation can be resolved??
<mario> robertj_, :P
* Hobbsee ponders what to attend next sessoin
<mario> Hobbsee, what's on schedule?
<mario> Hobbsee, btw. when you see mvo ... grab him, and tell him that I need him
<Hobbsee> http://people.ubuntu.com/~cjwatson/uds-sevilla/2007-05-08/
<mario> so he can come to irc
<Hobbsee> i...think he's still upstairs
<Hobbsee> cant see him, sorry
<mario> no problem ^_^
<mario> mvo, !
<shawarma> seb128: Around?
<seb128> shawarma: sort of, in the middle of a meeting
<shawarma> seb128: It can wait.
<seb128> shawarma: why?
<shawarma> seb128: It *can* wait.
<seb128> shawarma: just ask
<seb128> k
<shawarma> seb128: ah, ok.
<shawarma> I just saw this spec https://blueprints.launchpad.net/ubuntu/+spec/gaimlibnotify-by-default being scheduled twice now. Since you seem to be generally caring for gaim (or pidgin or whatever), perhaps you could handle it? It seems silly to have it take up space in the schedule several days in a row with noone showing up for the BoF's since there's really nothing to discuss.
<shawarma> The title says it all. They want a Depends or Recommends or something on gaim-libnotify. That's it, really.
<seb128> shawarma: that's nothing for a spec, I'll change it to drafting so it's not scheduled again
<shawarma> That's all I'm asking.
<shawarma> Thanks!
<seb128> shawarma: np
<seb128> it was already in drafting, maybe somebody else changed it today already
<shawarma> Oh, possibly.
<shawarma> I'm amazed how long the spec is, really. I've read through it, and there's nothing else in it, so don't bother. :-)
<shawarma> It still shows up here as "New"?
<Hobbsee> fabbione: boo.
<fabbione> Hobbsee: ahhhhh!
<Hobbsee> :P
<fabbione> heheh
* Hobbsee wonders where everyone is - seems so quiet downstairs today
<fabbione> Hobbsee: into meeting rooms?
<Hobbsee> fabbione: maybe...
<fabbione> Hobbsee: or just hiding from you because you are too scary :P
<Hobbsee> fabbione: heh.  true that
* Hobbsee might just be hiding from everyone else.
<shawarma> seb128: It still shows up as "New" here.
<seb128> shawarma: url?
<shawarma> https://blueprints.launchpad.net/ubuntu/+spec/gaimlibnotify-by-default
<seb128> shawarma: try again
<shawarma> seb128: There it goes! 
<shawarma> seb128: Cheers!
<seb128> you're welcome
<concept10> Have they posted any notes or info on the ubuntu-mobile part of the summit anywhere?
<zul> nope
<concept10> zul, thanks .. :(
<\sh> I wonder if we can compile now sun java from source and put those packages into main, restricted or universe....that would be a jump 
<zyga> \sh: I guess restricted is out of the question
<zyga> \sh: if you are talking about core which is 100% GPL now :-)
<\sh> zyga, the compiler is 100% gplv2 :)
<zyga> I don't know really, I'm not sure what sun calls 'core'
<zyga> heh
<zyga> I remember asking sabdfl about sun gpling java last year
<zyga> he said who knows, unlikely :-)
<\sh> I think the problem is more the runtime (JVM) ;)
<zyga> and now look :D
<zyga> hmm? the runtime is open already, no?
<zyga> (not the classpath)
<zyga> just the java vm
<zyga> I mean it was open way before anything else, no?
<shirish> zyga: I'm no developer but it would be cool if we used the gnu java as much as we could
<zyga> gnu java as in gcj?
<shirish> right, gcj
<zyga> shirish: IMO the sun vm is better at this stage
<zyga> if anything both should merge
<zyga> nothing against that now
<shirish> zyga: that I think is a long shot till the classpath doesn't become gpl
<zyga> the last thing I'd like is kde vs gnome in java world with *compatible* license :-)
<shirish> the libraries
<\sh> ah they call it "hotspot" 
<zyga> shirish: yeah that's a different case but the classpath is less important right now
<zyga> the core vm is the critical point, everything else will follow
<zyga> \sh: hotspot is the vm for desktops
<shirish> I actually made a mail in gnu java mailing list listing out what all stuff uses sun java using galternatives as a guide.
<\sh> zyga, hmm...what's the name on openjdk.dev.kava.net/ for the server jvm? ,-)
<zyga> \sh: hmm, I don't know really
<zyga> I'm not familiar with kava 
<shirish> java@gcc.gnu.org
<\sh> shirish, problem is, that most people are using sun jvm and jdk for their development...and a jvm compiled on the running system is quite better then mass binaries...I know the problem...because our product is java based ... the whole bunch of code crap ;-)  
<shirish> http://gcc.gnu.org/ml/java/2007-05/msg00022.html
<shirish> \sh: do understand what you are saying, but do feel its better to give more focus to people/groups who already have gpl'ed software
<zyga> \sh: my company is looking into writing and deploying a largish java server app due to lack of any other language that would suffice, care to elaborate on that issue if you have a moment?
<\sh> zyga, sure
<\sh> zyga, query :)
<alecjw> hi. im interested in getting involved in the ubuntu mobile project. does anyone know who i should contact?
<SoftIce> good day, how would i find out who supports the kernel-patch-vserver for dapper?
<concept10> SoftIce, launchpad?
<alecjw> SoftIce, https://beta.launchpad.net/ubuntu/dapper/+source/kernel-patch-vserver - "Drivers:  	  Ubuntu Core Development Team"
<SoftIce> so out of intrest, as we all know kernel-patch-vserver isn't supported in debian anymore, but would dapper make sure its up to date? 
<concept10> SoftIce, security updates maybe.. if it's in main, or check backports 
<SoftIce> i dont like the sound of the maybe :)
<SoftIce> isn't all security updates taken care of?
<concept10> SoftIce, I said maybe because I dont use dapper and havent researched that package
<concept10> SoftIce, plus, im not a developer/maintainer
<concept10> SoftIce, what version do you have currently?
<concept10> SoftIce, looks like edgy has the same -v as dapper and hasnt been released since a year ago.. maybe talk to #ubuntu-motu since its in universe
<Draconicus> brb
<Solarion> what do I need to do to get openoffice debug info when it crashes?
<Solarion> (I remember seeing a link; I just can't find it
<micahcowan> Would anybody like to sponsor a patch for multiple frees in gawk? :)
* Hobbsee muhahahahaha
* Nafallo hugs Hobbsee *
* Hobbsee hugs Nafallo 
<Nafallo> Hobbsee: why are people scared of you? :-)
<Hobbsee> Nafallo: dunno.  i'm sweet and innocent :P
<Nafallo> Hobbsee: you'll have to prove that ;-)
<Hobbsee> Nafallo: i am. at UDS
<bhale> yay Hobbsee 
<Hobbsee> er, except for the odd bit of beating people up
<Hobbsee> heya bhale 
<Nafallo> Hobbsee: hehe. so I'll ask Mithrandir when he's around then ;-)
* Mithrandir tickles Hobbsee 
<Mithrandir> (a little bit)
* Hobbsee tickles Mithrandir back, and falls over
<Nafallo> oh! he's around :-)
<Hobbsee> Nafallo: yes.  
<Nafallo> hej Mithrandir :-). r Hobbsee snll och oskuldsfull? ;-)
<Nafallo> oops :-)
<Nafallo> baah. you understand Swedish anyway :-P
<Mithrandir> yeah, she is.
<Nafallo> :-)
* Hobbsee wonders what that translates to
<Mithrandir> whether you're kind and innocent.
<Hobbsee> ahh
<Nafallo> :-)
<Nafallo> Hobbsee: told you I would ask him :-P
<Hobbsee> Nafallo: so it seems.
<micahcowan> Would anybody like to sponsor a patch for multiple frees in gawk? :)
<Hobbsee> bribes accepted.
<micahcowan> ... :(
#ubuntu-devel 2007-05-09
<StevenK> Mithrandir: artigas and sejong are both showing as NOT OK again.
* Starting logfile irclogs/ubuntu-devel.log
<bddebian> Thx seb128
<seb128> bddebian: you're welcome
<bddebian> Who has NEW duty these days, anyone?
<shawarma> bddebian: Mithrandir said he'd do it if he felt bored.
<bddebian> shawarma: Ah, thx
* bddebian wonders if Mithrandir is bored? :-)
<Mithrandir> no, I'm not
<shawarma> Mithrandir: charger?
<bddebian> Bah, I get no love :-)
<Simira> sorry guys, Mithrandir is busy for a little while now ;)
<bddebian> Hmm, Mithrandir has honey-dos? :-)
<welshbyte> do ubuntu kernels have blktrace support?
<welshbyte> specifically the feisty generic kernel
<sladen> welshbyte: I think so.  
<sladen> welshbyte: or maybe I'm thinking of the crash handler patch
<welshbyte> sladen: i'm getting "BLKTRACESETUP: Inappropriate ioctl for device"
<welshbyte> (from: # blktrace -r /debug -d /dev/hda1 )
<sladen> welshbyte: guess not then :)  As BenC et al
<welshbyte> sladen: ok, thanks anyway :)
<sivang> smurf: hi there
<sivang> smurf: just got your email, thanks
<lemsx1> is anybody working on Pidgin package for Feisty/Gutsy ? I was able to compile the package from unstable in Feisty by doing a few modifications (using gnutls instead of libnss)
<ScottK> jdong was working on it.
<lemsx1> ScottK: thanks. i wonder if jdong has a test package somewhere... 
<lemsx1> jdong: if you need help testing let me know
* jdong was contacted about this twice wihtin the past hour :D
<jdong> ScottK: lemsx1 at last check yesterday Pidgin was not in Gutsy. However, from my testing with the Unstable package, it is good to backport as soon as it shows up in Gutsy
<lemsx1> jdong: keep in mind that Pidgin from unstable disables TLS/SSL and that brakes a lot of the accounts 
<jdong> so all that's needed is someone to deal with it in Gutsy.... :)
<jdong> lemsx1: that's not a decision I can make
<jdong> Backports is not authorized to change compliation options to deviate from development Ubuntu branches
<ScottK> jdong: Speaking of backports...  How long from when you confirm it to something is in the backports repo?'
<jdong> ScottK: ask the archive managers
<ScottK> OK.
<jdong> ScottK: depressingly... maybe a month unless I poke them regularly :)
<ScottK> OK.  Can I go ahead an request a backport for something that depends on a backport we are waiting on?
<jdong> I'm fine with it :)
<ScottK> OK.  Thanks.
<jdong> brb.... gonna apply a Unicode console here.
<robertj_> lemsx1: does Pidgin require openssl for TLS/SSL?
<lemsx1> robertj_: you can use libnss or libgnutls
<robertj_> lemsx1: so why is it disabled?
<lemsx1> robertj_: the preferred method is gnutls, but, the debian package turns that off and uses libnss because it was trying to fix a bug. but the bug wasn't related to gnutls, it was something else, and the "fix" they applied stayed like that
<lemsx1> robertj_: check the changelog and the bug it was closing, you will understand
<robertj_> lemsx1: will do
<Lutin> tepsipakki: around ?
<\sh> geser, can I take your merge of libapache-mod-auth-mysql?
<geser> sure
<\sh> geser, cool, thx :)
<geser> is it for apache 1 only?
<geser> the module
<\sh> apache2-threaded-dev, so no
<\sh> for both
<geser> Debian is going to drop apache 1.3 soon
<geser> are we going to drop it too?
<\sh> geser, you dropped it already, when I read the MoM output correctly
<\sh> (apache1 module)
<\sh> geser, you dropped it for feisty...
<geser> then I forgot already :)
<\sh> hehe...I'll go with the apache2 module only...
<geser> I didn't forget: pitti disabled the apache 1 module
<geser> I fixed the build for apache 2 module
<\sh> ah
<geser> as apache 1 is in universe and the module is in main
<thom> apache1.3 must die
<\sh> 32bit must die ,-)
<\sh> oh not again...20:52 UTC+2 and I'm still sitting in the office doing some work :(
<SoftIce> hi, quick question, ubuntu has stopped the release of the kernel-patch-vserver patch and doesn't have a vserver kernel by default
<SoftIce> any idea why ubuntu decided not to release a vserver kernel? or import one from debian?
<mdke> Riddell: "The Fridge editors are being slow"? We haven't had anything to the list, would you resend it?
#ubuntu-devel 2007-05-10
* Hobbsee BOO!
<Ksosez> anyone know of/or working on overheating on laptops in Feisty? my thinkpad z60m is overheating badly..and if there is anything I can do to help i would like to :)
<Ksosez> okay back into ubuntu to see if i can track this overheating issue down
<pitti> Good morning
<ion_> Morning
<pitti> hello ion_ 
* StevenK waves to pitti.
<pitti> hey StevenK 
<StevenK> Mithrandir: I have this feeling that tig and lyx seem to do bad things to the sparc buildds -- both artigas and sejong are spinning with no logs.
<ajmitch> morning
<desrt> word.
<desrt> anyone know how long before we have a schedule?
<shawarma> desrt: It's usually around 9:20, I think.
<Treenaks> keybuk just arrived..
<fabbione> StevenK: send me a mail and i will look at them
<StevenK> fabbione: <nick>@u.c ?
<fabbione> yes
<desrt> hmm
* desrt needs to know if his session is scheduled ultra-early or if he has time for a breakfast :)
<desrt> schedule is up.
<fabbione> StevenK: got the mail.. will look at them sometime next week
<dholbach> good morning
<shawarma> iwj, lifeless: I'm clearly an idiot.
<Treenaks> shawarma: </duh>
<dharrigan> Mithrandir: elmo : I have a question re: legal stuff that dholbach recommends I ping you about.
<dholbach> dharrigan: best to say what you actually want to do - so they can reply back, when they see your message
<dharrigan> dholbach: Ah, umm, best if I send them the email that I sent you?
<dharrigan> It's quite long, perhaps too long for here.
<dholbach> dharrigan: ok, let mw follow up on your mail and include them in the loop
<dharrigan> Okay, that would be great daniel. I appreciate it. Just want to clear things up :-)
<alleyoopster> mjg59: hi, madduck (debian) mentioned that you *may* know something of black screen problems on resume on a dell laptop
<Mirv> pitti: do you think https://blueprints.launchpad.net/ubuntu/+spec/language-packs-for-documentation could be resurrected? by moving non-english documentation to be downloaded (like language-support-NN is already done), there would be more space for UI translations. (you're the first in the list of subscribers)
<Mirv> I'm aiming for... https://wiki.ubuntu.com/BetterDesktopCDLanguageSupport (the title says it all)
<pitti> Mirv: resurrected in the sense of giving it an assignee and an UDS slot?
<Hobbsee> [20:15]  <siretart> http://www.stil-his.no/brukerfiler/Innebandy/He-man%20-%20She-ra%2004.jpeg
<Hobbsee> [20:15]  <dholbach> ^ Treenaks said: "Is that jono?"
<Hobbsee> [20:15]  <siretart> "he sould be"
<pitti> Mirv: right, we do consider 7zip and friends
<Mirv> pitti: yeah.. if there were a bunch of people interested in the documentation separation before, to try to find time to consider implementation too. it's linked to from this new spec where I'm gathering other ideas.
<Mirv> pitti: sladen and pkl_ are people who could perhaps help with the 7zip/lzma/squashfs stuff, they were in the discussion just a moment ago (I'm via VoIP). I'm not really into kernel myself too much, but I'd like to look into the desktop side mentioned in the spec.
<Mirv> though probably mvo would be better at that, too :)
<StevenHarperUK> Hi, I have recently finished my first release of USB Speedtouch 330 driver support, I have registered a launchpad project, but now i'm stuck. I have a SVN repository and have queued an import in launchpad, but id like some Ubuntu Development Veterans to help me out
<Treenaks> StevenHarperUK: are you at UDS?>
<pitti> Mirv: I agree that doc separation is low-hanging fruit; it's not the best solution, but certainly works
<StevenHarperUK> Sorry whats UDS?
<Treenaks> StevenHarperUK: the Ubuntu Developer Summit, in Seville, Spain
<StevenHarperUK> No im at work atm :P
<StevenHarperUK> My launchpad entry is https://launchpad.net/speedtouch-usb-modem
<StevenHarperUK> I have a working app, that connects version 04 of the Speedtouch USB modems
<StevenHarperUK> over PPPoa
<StevenHarperUK> What I need now is help Packaging and for people to review my Python code 
<StevenHarperUK> As im Mainly a Java developer : it my first stab at Python
<StevenHarperUK> Its on an OPen SVN server if anyone fancies a look
<pitti> StevenHarperUK: TBH I don't think that providing a separate application for a specific type of hardware is a good solution
<Mirv> StevenHarperUK: you might want to co-operate with the subscribers of the specification https://blueprints.launchpad.net/ubuntu/+spec/usb-adsl-modems and add to the https://wiki.ubuntu.com/EasyUsbAdsl page
<pitti> StevenHarperUK: there should be some shim which makes that modem work with the standard network setup/configuration tools
<StevenHarperUK> Yes that would be great, there so many, in the UK nearly all ISP's gave the Speedtouch 330 free iwth most ADSL subscriptions
<StevenHarperUK> The code I have worked on should work with other modems
<StevenHarperUK> But I only have acces to 3 speedtouch ones
<Lutin> tepsipakki: around ?
<tepsipakki> Lutin: yep
<Lutin> tepsipakki: just curious.. I was xondering why glw has been disabled in mesa
<tepsipakki> Lutin: no idea
<tepsipakki> look at the changelog for clues
<Lutin> tepsipakki: ok :) . I was asking you because you uploaded this change ;)
<tepsipakki> well, I didn't make that patch
<tepsipakki> it was there before
<Lutin> tepsipakki: ok
<tepsipakki> check the changelog from edgy
<tepsipakki> ah, yes.. GLw needs lesstif
<tepsipakki> which is in universe
<pygi> dholbach, around?
<dholbach> pygi: YES
<pygi> dholbach, nice ^_^
<dholbach> anything you want from me?
<pygi> ah, nothing important ... you're probably busy
<Clem92> I've got a question... will Pidgin 2 come in Feisty or only in Gutsy?
<Burgundavia> Clem92: possibly a backport ot fiesty
<Hobbsee> Burgundavia: cant see why though.  although backports isnt updates, i guess
<gnomefreak> Burgundavia: congrats
<pygi> Hobbsee is here again :P
<Hobbsee> pygi: it seems so
<Burgundavia> Hobbsee: people are asking for it, thus they are using crackish 3rd party stuff
<Burgundavia> better to have them using our crack than random crack off the forums/blogs
<Hobbsee> Burgundavia: true
<iwj> Conflict adding file debian/changelog.BASE.  Moved existing file to debian/changelog.BASE.moved.
<iwj> I love bzr.
* Treenaks registers bizarre-vcs.org and redirects to bazaar-vcs.org
<pitti> iwj: hmm, did you use 'mv' instead of 'bzr mv' or so?
<iwj> No, nothing like that.
<iwj> mvo told me to say `bzr resolve --all' which made it magically go away.
<pitti> iwj: aah, right;
<pitti> iwj: you had a conflict earlier, and the .BASE file was still around
<iwj> But why oh why oh why does it mind ?  It should get a grip.
<seb128> pitti: do you mind if I promote libavahi-compat-howl0 to main?
<pitti> erk, erk, erk
<pitti> seb128: actually I do; why do we need that?
<seb128> pitti: the avahi source is already to main
<pitti> right
<pitti> but I thought we could do without the old howl compat stuff
<Lathiat> its not old
<Amaranth> What uses it?
<pitti> well, old in terms of Ubuntu usage
<Lathiat> the reason it wasn't promoted was because at some point there was plans to pull those out into separate sources upstream
<Lathiat> we haven't really got to doing that
<seb128> pitti: would make gaim bonjour thing work
<seb128> pitti: looks like quite some users would be happy to use the gaim feature
<seb128> and ogra would like to get gobby to edubuntu
<pitti> seb128: well, the only reason I have against it is APIs we don't need for anything else; no hard arguments against it, so go ahead if it makes folks happy
<ogra> \o/
<pygi> ogra, ^_^
<seb128> pitti: thanks
* ogra hugs pitti exstatically
<slomo> i wonder why gaim and gobby still can't use the real avahi api... it's not like it's a difficult api ;)
<Lathiat> slomo: it was just ported upstream iirc
<seb128> slomo: you are welcome to port it to avahi
<seb128> slomo: we did say that during the dapper cycle
<seb128> slomo: nothings changed upstream since
<seb128> slomo: let me know if you want to work on it, so maybe we don't need to promote it ;)
<bddebian> Heya
* Mithrandir waves to bob_ 
<psusi> how do you get the maintainer of a package changed in launchpad?
<Hobbsee> psusi: upload a new vesrion of it
<psusi> ohh, do you just need to change the Maintainer field in the control file?
<psusi> ok....
<psusi> hrm...
<Hobbsee> i think so
<psusi> I'd like to change it to another launchpad group, but what should I set the maintainer email addy to?
<psusi> the group is ubuntu-dmraid
<Hobbsee> i wonder if you need to set the debian changelog address, or the maintainer address, to list it in LP.
<psusi> must be maintainer... changelog lists whoever made the changes
<psusi> who often is not the maintainer
<psusi> or even a developer ;)
<seb128> psusi: subscribe the team to the package
<psusi> it is subscribed, but it is not the maintainer
<seb128> what does maintainer mean to you?
<psusi> I'd like it to be the maintainer instead of the generic motu group
<seb128> what difference would it make?
<psusi> well, for one, the maintainer gets to set the priority of the bugs
<seb128> the package contacts can do that I think
<psusi> says only maintainer can... what's package contacts?
<seb128> hum, I see what you mean
<seb128> just subscribe to the bugsquad ;)
<psusi> huh?
<bashelier> psusi: I think you should put you as XSBC-Original-Maintainer, and let the MOTU as Maintainer, and also change the adress/name in changelog
<seb128> bashelier: I'm not sure tweaking the Maintainer is the way to do that
<seb128> psusi: ^
<psusi> the changelog contains the name of the person who made that change.... not related to this discussion
<seb128> psusi: there is no granularity by package
<psusi> since i made the last change, my name is there... that's not the issue... the issue is that the group that was made specifically to deal with bugs on this package can't prioritize those bugs
<bashelier> psusi: sorry, I've said that without knowing what do you want exactly
<seb128> psusi: you need to be busquad member to change Ubuntu packages settings
<psusi> hrm... launchpad just says only the maintainer can set the priority
<seb128> psusi: what page is that?
<psusi> any bug page
<psusi> expand the affects item to show the importance and there's a lock icon next to it... hover the cursor over it and it says only the maintainer or bug contact for the project can set this
<seb128> psusi: that's a question for #launchpad
<psusi> the team ubuntu-dmraid is set as a bug contact for the dmraid package, and I'm a member, so I get email about all bugs filed against it
<psusi> but can't set the priority
<psusi> hrm... ok
<ogra> Riddell, http://www.arbitraryuser.com/blog/wp-content/uploads/2007/03/howtospellandtypejonathan.png
<ogra> ;)
<highvoltage> there's also a simpler howto at http://jonathancarter.co.za/files/jonathan.pdf
<Riddell> ogra: what the naach?
<highvoltage> LaserJock!
<pkern_> How could I set "Fix Released" only for Gutsy on a bug? Currently it shows only "gobby (Ubuntu)"
<ScottK> If it's fixed in Gutsy, it's considered Fix Released.
<pkern_> k
<ScottK> If it's potentially SRU worthy, then tasks need to be set for the appopriate releases.
<pkern_> And those tasks could only be added by more powerful people? (Not that's it's needed in this specific case.)
<ScottK> Yes.
<pkern_> k
<ScottK> ubuntu-qa and I think some others can nominate for releases, but I believe only devs can approve them.
<pkern_> How could I set bug contact / security contact on a project in LP?
<ScottK> pkern_: I'd ask in #launchpad
<bddebian> Are we going to bring PHP5 5.2.2 from Debian?
<sharms> did anyone get a chance to look at https://wiki.ubuntu.com/Spec/EnhancedBash ?
<sharms> I have been stuck all week with a bunch of deadline work :(
<ion_> Enhanced bash  ah, you must mean zsh. ;-)
<sharms> ha
<blueyed> Does anyone know what's up with vbetool? There are quite a lot of crashes in launchpad.
<mjg59> Due to the way it works, it's inevitable that it'll crash on some machines
<blueyed> mjg59: unfortunately I don't know how it works. So the related reports should be rejected as "expected"? all of them?
<mjg59> apport should be taught to ignore them
<xst> Currently audiophile 2496 audio devices are broken in feisty. Does anyone know the current status of bug #108288 (https://bugs.launchpad.net/bugs/108288)? Is anyone actually working on it?
<ubotu> Launchpad bug 108288 in linux-source-2.6.20 "Audio is played in "slow motion"" [Medium,Confirmed]  
<crimsun> xst: yes, I am, but I'm swamped ATM.  I'll attempt to look tomorrow.
<crimsun> xst: at this point, I need to know if alsa-driver 1.0.14rc4 fares better.  That would be a starting point for testing.
<xst> ok, sounds awesome with some progress :-)
<poningru> anyone know why vmware-server or vmware-tools is not available through the repos?
<stgraber> poningru: they are on canonical repo IIRC (it should be a licence problem for them not to be in multiverse)
<poningru> canonical repository?
<poningru> found it
<poningru> thanks
<stgraber> np
<avb> hello all
#ubuntu-devel 2007-05-11
<avb> why #113780 is exist for more then two days?
<avb> a problem with usplash dependencies 
<avb> usplash-theme-debian must be changed to usplash-theme-ubuntu
<avb> and the problem will be fixed
<avb> or usplash-theme-ubuntu must provide usplash-theme
<gnomefreak> avb: it was reported 12 hours ago not 2 days ago from what LP says. everyone is at UDS so things may not get fixed right away.
<avb> ah, I see
<j-dizzle> infinity2: poke... fix ktorrent pretty please?
<_MMA_> Hi all. Ubuntu Studio 7.04 has been released. http://ubuntustudio.org Thanx to everyone. :)
<pitti> Good morning
<geser> Morning pitti
<pitti> hey geser!
<ion_> Hi pitti
<tepsipakki> what is the equivalent for "Depends: foo (= ${binary:Version})" for dpkg in dapper?
<tepsipakki> dpkg-deb complains that the version string is empty
<geser> (= ${Source-Version}) if I'm not mistaken
<crimsun> dapper's dpkg is older than 1.13.19, which is needed for ${binary:Version}.  ${Source-Version} AFAIK.
<tepsipakki> yeah, thanks.. I'll try that
<Hobbsee> morning all
<Mithrandir> hiya Hobbsee 
<keescook> mornin'
<Hobbsee> :)
<ajmitch> morning 
<pitti> keescook: running 'bt' or 'bt full' in a built source tree does not show any source lines, only the initial 'breakpoint hit' or 'crashed' message
<pitti> keescook: and I think it's good that way TBH; convoluting source and variable values would be too confusing
<pitti> keescook: so I guess I'll spec it to just simply read it out from the source files manually
<keescook> pitti: hmmm... I will try it again shortly
<infinity> pitti: Does anyone hanging out there know why the buildd sequencer appears to be stopped?
<keescook> hiya infinity
<pitti> infinity: hm, I didn't notice and didn't hear anything from Tollef/Colin/the other suspects
<pitti> infinity: but that might just be us being busy talking and not watching the archive at all
<pitti> infinity: I can poke cprov, he's sitting 2 m away
<Mithrandir> pitti: please do, and point him to #soyuz
<infinity> Kay.  I'd restart it myself, but if there was a reason, and it's unsafe to restart it, I'd rather not.
<pitti> keescook: if you have a minute, maybe you can have a review of https://wiki.ubuntu.com/ApportBetterRetracing ?
<keescook> pitti: sure, one sec
<keescook> pitti: add "useless for Mono" too, since you have Wine in there already?
<pitti> keescook: I deliberately didn't, since we have a separate spec for that
<keescook> ah!  very good.  :)  Perhaps link to it?
<pitti> right
<keescook> pitti: do you think adding a coredump checksum for corruption-detection is useful?  (it was in the gobby list of possible solutions for #3)
<infinity> pitti: I realise this is a bit late in the game to suggest it, but has there been any interest in revisiting ReducingDuplication to try to clean up again?
<keescook> pitti: rest looks good.
<pitti> keescook: I couldn't see an immediate need for it
* keescook nods
<pitti> keescook: that's why I didn't add it; it's one of the cases where I rather leave it out and add it as needed
<pitti> keescook: mono spec linked
<keescook> sounds good.  as long as the upload truncation can be "proven" as solved with the contentlength, I'd agree.  If that can't be shown, then I think the crc is useful.
<pitti> infinity: right, that's an ongoing effort; I do want to have a look at it again, for gutsy+1 at latest (since that's LTS)
<pitti> keescook: right; thanks for revierw
<pitti> s/rw$/w/
<infinity> pitti: Yeah, I'd like to clean a bit now, and then get fascist about it for gutsy+1.
<infinity> pitti: Where "now" is "sometime in the next few weeks", obviously no big rush.
<pitti> infinity: sounds good
<infinity> j-dizzle: feisty-backports is all sorted and happy now.  Sorry about that.
<lifeless> http://www.0xdeadbeef.com/weblog/?p=288 <- ati + opensource ?
<Treenaks> solution: http://tirdc.livejournal.com/3766.html
<Saied> all, hi
<Saied> how can i disable boot messages?
<Saied> how can i disable boot messages?
<ion_> saied: Try #ubuntu for support.
<dholbach> keescook: heya - where are you hanging out?
<ajmitch> dholbach: mdadm/lvm fun
<keescook> dholbach: hiya.  I'm in the mdadm/lvm session atm
<Sp4rKy> hi
<Sp4rKy> is there something to add during build of iso to use gfxboot ?
<Sp4rKy> something other than conf files in isolinux/ ?
<tepsipakki> new hal in feisty-backports is broken
<tepsipakki> oh
<tepsipakki> hal-info didn't make it in our mirror, so maybe that's what broke it
<tepsipakki> nope, hal-info for feisty-backports isn't in the archives, since it's new
<tepsipakki> could an archive admin please accept hal-info for feisty?
<Hobbsee> Mithrandir: ^
<Mithrandir> tepsipakki: I voluntold kylem to do it.
<tepsipakki> Mithrandir: thanks!
<Hobbsee> Mithrandir: skipping work, again... :P
<StevenK> Hobbsee: No, "Delegation", an important part of work.
<Mithrandir> I'm such a slacker
<tepsipakki> :)
<mjg59> He's a manager now
<Mithrandir> mjg59: I am?
<Hobbsee> StevenK: hah.  yes.
<StevenK> mjg59: Have you bought him a tie?
<Mithrandir> actually, this is so kyle gets to make mistakes when I'm here so I can whack him over the head if he tries to make the archive blow up
<Hobbsee> hehe
<Hobbsee> always fun
<StevenK> Heh
<StevenK> Mithrandir: Like a "Oh crap, I just managed to clean out dapper" ?
<StevenK> Actually, that would be fairly impressive.
<kylem> tepsipakki, backport accepted.
<Mithrandir> that'd be bad, yes.
<tepsipakki> kylem: rock
<robertj> on resume, my laptop shows a black background, the cursor is present, and the area where the cursor starts has some corrupted graphics, what package do I need to file the bug against?
<ScottK> robertj: #ubuntu-bugs is a probably a better channel to ask that question.
<robertj> thanks, done
<Mithrandir> doko: is that ooo doesn't work correctly on gutsy know?
<Mithrandir> /usr/lib/openoffice/program/soffice.bin: symbol lookup error: /usr/lib/openoffice/program/libspell680li.so: undefined symbol: _ZN8Hunspell5spellEPKc
<doko> Mithrandir: yes, known
<Mithrandir> is there a workaround
<Mithrandir> ?
<doko> don't upgrade libhunspell
<pochu> bug 111940
<ubotu> Launchpad bug 111940 in hunspell "libhunspell-1.1-0 1.1.5-6: Incompatible ABI change" [Undecided,Confirmed]  https://launchpad.net/bugs/111940
<Mithrandir> oh well, I could downgrade I guess.
<Mithrandir> pochu: cheers
<pochu> yw
* StevenK does evil and nefarious things to a manual merge.
<ScottK> Mithrandir: Looks like the sparcdd that's running is actually getting stuff done now.  I can mark some bugs fix released.  Thanks for kicking/having them kicked.
<ScottK> err sparc buildd
<Mithrandir> ScottK: yeah, I just prodded the right people; thanks for your persistency in telling me, I just haven't been attending to the buildds this week due to uds
<ScottK> NP.  I certainly understand being distracted.
<pygi> hi folks
<asac> Mithrandir keescook mvo dholbach http://people.ubuntu.com/~asac/funkymonkey.xpi ... please try and tell me if things work proper for you ... had to do some hacking in greasemonkey user script management dialog. Now it should be as easy as dropping global scripts to /usr/share/firefox/defaults/gm_scripts/
* pitti hugs asac, sounds promising
<keescook> nce
<keescook> er... nice too
<dholbach> asac: works great
<gumpa> Howdy. I want to make a liveCD for collecting hardware info.
<gumpa> Upon boot it should accept telnet, run lshal and Python scripts, be able to ftp .. not much else
<gumpa> Any suggestions?
<bluefoxicy> wtf is going on with launchpad
<bluefoxicy> https://blueprints.launchpad.net/ubuntu/+spec/livecd-creator
<bluefoxicy> people are fiddling with the white boards for asinine purposes
<mjg59> I suspect that this is the wrong place to ask
<bluefoxicy> mjg59:  where IS the right place to ask about random wiki/launchpad/etc vandalizing and such?
<mjg59> Unsure. Not here.
<j-dizzle> bluefoxicy: probably #launchpad
<bddebian> Heya
<ion_> Hi
<bddebian> Hello ion_
<gumpa> bluefoxicy: thanks for the LP link, doesn't appear that there's much interest in a liveCD tool
<gumpa> can anyone comment on Reconstructor or Ubuntu Customization Kit ?
<bluefoxicy> gumpa:  I was more pointing out the whiteboard junk, people are changing it to draw smilies and say "my turn my turn eee!"
<bluefoxicy> I don't know if they're screwing with other specs
<bluefoxicy> but as mjg said, not here.
<gumpa> bluefoxicy: but you _did_ provide the link germane to my query. thx for that :-] 
<bluefoxicy> gumpa:  nods
<Husio> hello
<Husio> I have a question about the pilot in macbook (intel 2.0)
<Husio> what patch allows to use it?
<Husio> can't find any info how to make it works
<StevenHarperUK_>  Hi : I have just registered my lauchpad project https://launchpad.net/usb-adsl-modem-manager   I have a working application, but I need someone who's used to the processes in getting Ubuntu packages made (debian) and other processes to help me
<StevenHarperUK_> Cany anyone help - or point me in the right direction
<mc44> StevenHarperUK_: #ubuntu-motu can help you with packaging, but a lot of the people are in spain at the development conference at the moment
<StevenHarperUK_> do you know the steps - in order I should be doing things
<mc44> well, making a package is a good first step :)
<StevenHarperUK_> I have never done that before
<StevenHarperUK_> Is there a WIki page?
<mc44> http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
<soundray> I reported a bug back in February (#84026). Additional information was requested. I supplied that, and after that nothing ever happened any more. "Importance" is still "undecided". Have I just wasted my time reporting the bug?
<mc44> soundray: there are 17594 undecided bugs in Ubuntu...
<soundray> mc44: so the answer is yes...
<mc44> That wouldn't be my interpretation
<soundray> I would have thought that frequency scaling is important, especially on CPUs where the savings potential is so big.
<pygi> hi G0SUB 
<pygi> Gman*
<Gman> hi
<soundray> Anyway, thanks mc44 for the info. I'll be patient.
#ubuntu-devel 2007-05-12
<cycom> There is apparently an update for the kernel for bluetooth (according to https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/92111).  Any idea when the new release will be?
<ubotu> Launchpad bug 92111 in linux-source-2.6.20 "Feisty: Bluetooth does not until 'hciconfig hci0 reset'" [Medium,In progress]  
<Saied> can anyone help me in usplash?
<minghua> Saied: if you want help for installing or configuring usplash, please go to #ubuntu
<Saied> minghua: OK
* enyc would like to know if people still seem to run into problems with #!/bin/sh  bash-dependant-scripts... particuarly with 3rd-party-software... or if this "is rarely a problem any more" ;-)  thanks..
<enyc> I suspect that a lot of upstream people have fixed their scripts  and that there are still  problems about some places..
<Hobbsee> hi all
<geser> Hi Hobbsee
<geser> back home?
<Hobbsee> geser: nope - flying out in ~ 5.5 hours
<Kmos> Hobbsee: turn off laptop and do a little travel :)
<Hobbsee> Kmos: soon :P
<Kmos> Interview with Sebastian Trug lead developer of k3b
<Kmos> http://club.mandriva.com/xwiki/bin/view/Main/TruegInterview
<pygi> hi giskard 
<giskard> hey :)
<pygi> how goes it?
* Treenaks home from UDS \o/
<sladen> Treenaks: that was fast.  I have your DV cable
<Treenaks> sladen: oh. oops :)
<Treenaks> sladen: you can keep it
<Treenaks> I have more here :)
<sladen> Treenaks: handy.  spares!  I'll use it now and keep it in my bag
<sladen> Treenaks: NL right?
<Treenaks> sladen: yes
<Simira> http://tellus.err.no/files/IMG_0979.jpg
<Simira> who wants one?
<Treenaks> Simira: or http://www.cafepress.com/cp/prod.aspx?p=foodfight.132171648
<Treenaks> Simira: (you mean the penguin?)
<Simira> the penguin, yes :)
<ompaul> one single little comment - that was awesome thanks to those of you I met
<Treenaks> ompaul: np ;)
<ProN00b> someone told me that ubuntu has no kernel upstream at all, is that true ?
<pygi> ProN00b, ergh, ofcourse it does
<ProN00b> can i have numbers ?
<pygi> don't listen to "someone", whoever that may be
<pygi> numbers? o.O
<ProN00b> well, how many patches it contributed since like kernel 2.6.16
<mjg59> Many
<pygi> I don't know the figures, but ... :)
<ProN00b> i need some figures
<mjg59> Why?
<ProN00b> to slap them in this guys face
<pygi> ProN00b, ah, dude
<pygi> there's no point in fighting on such things
<ProN00b> he is so proud of "21 kernel patches from 2.6.16 to 2.6.21"
<mjg59> It really depends on what you mean.
<hile> just W%# unbelievable, just checked the gutsy package for cryptsetup and it STILL does not wait for the block device on boot and will fail miserably with SATA disks on fast laptops
<mjg59> Nobody working on Ubuntu is paid full-time to do upstream development work on the kernel.
<mjg59> And the amount of code that Ubuntu contributes to the upstream kernel is tiny compared to Novell and RH.
<hile> ... a bug for which multiple patches have been suggested, which was reported 8 months ago and which makes the package unusable on many systems (just fails booting)
<hile> I just #%&3 give up trying to get it fixed, ty
<Ng> hile: the gutsy package is the same as the feisty one at the moment. It's still very, very early in gutsy development - the summit only just finished!
<hile> no it's not same one, it's got patches from debian side (which is here to blame, not ubuntu pkg)
<pygi> patience, patience :)
<Ng> hile: *shrug* they have identical version numbers according to packages.u.c
<hile> oh? well then there are changes made to the package after a working fix was reported for a problem preventing booting
<hile> I just thought the package does not get updated in general.. sigh
<hile> as I said - I give up
<hile> sorry for the rant, but the #&# bugfix is a oneliner....
<mjg59> ProN00b: However, any patches to the Ubuntu kernel do go upstream. The issue is that most diverging code in the Ubuntu kernel is already upstream in one form or another, so there's no point in feeding it back
<Ng> ah, packages.u.c must be behind, LP is showing a newer version in feisty
<Ng> err, gutsy
<Ng> hile: giving up isn't a good solution though, it would be better to find someone who maintains the package and talk to them about getting the fix in
<Ng> (which is unlikely right now since people are probably still returning from UDS)
<hile> I have talked many, many times, that's why I give up
<ProN00b> mjg59, you still have any idea how to get numbers ?
<mjg59> ProN00b: 30 or so sounds like an entirely plausible number.
<pygi> hile, what package is it?
<hile> cryptsetup
<pygi> and one advice for you: never, *NEVER* give up ^_^
<hile> there's the patch in all it's complexness (actually 2 fixes, only one is critical): http://ner.dy.fi/deb/cryptsetup/edgy/cryptsetup-edgy.patch
<pygi> hile, ok, and what's stopping you from creating a debdiff? ;_
<pygi> ;)
<mjg59> Maybe 100 or so
<pygi> I'm actually perfectly capable of helping you re-create package, create a debdiff and introduce you to the upload process
<mjg59> pygi: The fact that it's not his job? If people submit patches and they never get applied, that's our failing, not theirs
<hile> I just don't care anymore, I'll continue with the unofficial packages and shutup
<pygi> mjg59, that is true :-/
<pygi> hile, please point me to the LP bug where I can see attached patches ... I'll try to make sure to get them up
<mjg59> We simply don't have anywhere enough people handling bugs
<Ng> I see what looks like several bugs relating to lvm and cryptsetup, so there should probably be some merging and confirming
<hile> the boot bug is reported at least 3 times
<Ng> hile: do you have the bug numbers?
<hile> i can dig yeah
<Ng> I appreciate you're frustrated though, so thanks :)
<mjg59> ProN00b: If his assertion is that Ubuntu makes relatively little contribution to the upstream kernel, then he's absolutely right. That's slowly changing as the company get bigger.
<hile> well, at least 21878 72517 - everything started with breezy already, but those numbers are not valid anymore
<hile> I think there are others, those are ones I've been tracking (went through my Bugs folder, that's why it took some time :)
<hile> there are still lvm/evms handling scripts in cryptsetup, which are not needed in the new async initramfs images (and my feisty patches did exactly that)
<pygi> hi phanatic and mdz 
<phanatic> hey pygi
<pureDesi> How would I make an if statement that checks if $0's length is greater than  3?
<pureDesi> in bash
<ion_> Please see the topic.
<pureDesi> bleh
<pureDesi> mind answering it though, I assume it has a simple answer
<pygi> ion_, :)
<ion_> Hi pygi
<pygi> hi, how are you?
<ion_> Okayish. :-) How are you?
<pygi> good, good, working on some nice newish stuff :)
<ion_> For libburn?
<pygi> libisofs
<adam0509> I think launching "system monitor" with CTRL + ALT + DEL could be usefull for people comming from windows...
<adam0509> I got a friend trying to make CTRL + ALT + SUPPR when his firefox crashes
<adam0509> it's a natural shortcut for everyone ^^
<adam0509> (gnome-system-monitor)
<psusi> anyone know d-i fairly well?
<Fahuadai> crtl+alt+del is a shortcut i set to sysGuard anyways. be nice to have it defaulted for new windows ppl though...
<Fahuadai> (super slow reply lol)
<adam0509> I can even set the shorcut in gnome, the "keyboard shortcut" doesn't allow custom command... :/
<adam0509> even XFCE can do it !
<geser> it's possible but you have to use gconf-editor
<adam0509> the regedit of linux ? ;)
<geser> sort of :)
<adam0509> :D
<adam0509> do you know exactly where to add the thing geser ?
<adam0509> (and I'll add it to french wiki ^^)
<geser> adam0509: for metacity it's /apps/metacity/global_keybindings/run_command_1 to run_command_12 to specify the key to trigger it and /apps/metacity/keybinding_commands/command_1 to command_12 for the corresponding commands
<geser> you need to set both to get it working: the key and the command which should get bind to it
<adam0509> geser => k thank you ! run_command_1 to <Ctrl><Alt>Delete   then run_command to "gnome-system-panel"
<`23meg> adam0509, it's not a good idea as a default
<adam0509> why ?
<`23meg> del is very close to backspace on many new keyboards; it would lead to disastrous ctrl + alt + backspaces
<adam0509> ROFL
<adam0509> yeah you are right...
<adam0509> didn't think about it...
<adam0509> so
<adam0509> CTRL + ALT + ESCAPE ?
<adam0509> it calls xkill in KDE and XFCE...
<adam0509> it seems it already do something, but that shorcut don't seems usefull...
<`23meg> it selects between the GNOME panel and the desktop
<adam0509> that's what I say, it's useless
<`23meg> it's a GNOME default and has been so for quite a while; people used to navigating with the keyboard must be used to it
<`23meg> useless for you, perhaps
<adam0509> :)
<adam0509> in fact that shorcut is ALT + ESPACE
<`23meg> defaults affect everyone, not just you
<adam0509> so CTRL + ESCAPE is still possible
<`23meg> no it's not
<adam0509> ? why ?
<`23meg> I mean, it's not alt + esc
<adam0509> it's ALT + escape that select between GNOME PANEL and desktop
<`23meg> and when you make it something like ctrl + esc, you lose the basic premise, that ex-Windows users will find it comfortable, right?
<adam0509> not CTRL + ALT + ESCAPE
<`23meg> no, alt + esc selects between windows in the same workspace
<adam0509> well in fact in windows CTRL + ESCAPE is like the SUPER (M$ logo)
<adam0509> ah, right...
<adam0509> so what shorcut do we have left ? :)
<`23meg> so again, the "advantage" is lost
#ubuntu-devel 2007-05-13
<ion_> http://www.bangkokpost.com/090507_Database/09May2007_data05.php "The Free Software movement is dead. Linux doesn't exist in 2007. Even Linus has got a job today." Controversial statements from the head of Microsoft's Linux Labs, Bill Hilf. Speaking on the last leg of a tour of Singapore, the Philippines, Malaysia, Indonesia and Thailand, Bill Hilf, more formally known as Microsoft's platform strategy director, was in the region to "be descriptive and ...
<ion_> ... intelligent in giving people an understanding of open source and debunk a lot of the mythology around open source."
<riczho> Hi!  Hopefully this is a good place to report that ubuntu.com and http://www.canonical.com/ seem to be down now. 
<jmg> not the correct place, and the people that need to know already know
<riczho> Aha- thanks.  Just wanted to make sure :)
<riczho> Good luck!
<YokoZar> Does anyone know why when I point pbuilder at a .dsc file (alongside a .orig.tar.gz and a .diff.gz) and tell it to build, the resulting .orig.tar.gz and .diff.gz files have different md5 sums?
<Chipzz> YokoZar: wild guess: because they're compressed with a different level of compression? ;)
<YokoZar> Chipzz: hmm...possibly...how do I test that though?
<YokoZar> I guess the point is pbuilder isn't just copying them, but is rebuilding them
<Chipzz> no idea; except maybe trying the different compression levels by hand?
<Chipzz> but do you mean they have the same content when decompressing, or not?
<YokoZar> They should have the same content when decompressing
<YokoZar> I have a more urgent question though
<YokoZar> and that is what this error means with apt-get update:
<YokoZar> Failed to fetch http://wine.budgetdedicated.com/apt/dists/feisty/Release
<YokoZar> Unable to find expected entry  main/source/Sources in Meta-index file
<YokoZar> (malformed Release file?) 
<shawarma> YokoZar: Try apt-get update again..
<YokoZar> shawarma: No it's a problem with my repository
<YokoZar> I think is screwed up reprepro
<shawarma> YokoZar: You're the wine guy?
<YokoZar> Yeah
<shawarma> YokoZar: Ah, ok.
<YokoZar> The problem stems from having pbuilder give different md5sums for the source package after pbuilder plays with it
<YokoZar> so I build an amd64 package and an i386 package, and reprepro throws a fit with the second one because the source package has a different md5sum
<shawarma> YokoZar: Try putting "DscIndices: Sources Release . .gz .bz2
<YokoZar> shawarma: where?
<shawarma> YokoZar: Try putting "DscIndices: Sources Release . .gz .bz2" in your reprepro distributions flie.
<shawarma> file
<YokoZar> ok one moment
<YokoZar> You mean as a new line under the one for feisty right?
<shawarma> Yes
<YokoZar> ok done.  What will that do?
<shawarma> http://wine.budgetdedicated.com/apt/conf/distributions   is that your conf file?
<shawarma> Ah, there it is.
<YokoZar> yes
<shawarma> never mind.
<shawarma> Just rerun reprepro
<shawarma> "reprepro export feisty" or something.
<YokoZar> k one moment
<YokoZar> ok done
<shawarma> YokoZar: Good. Then apt-get update and see if it's happy.
<YokoZar> now I need to resign the release
<shawarma> YokoZar: Your reprepro doesn't help you do that?
<YokoZar> nope I have to do it by hand
<YokoZar> this is the dapper reprepro
<YokoZar> looks like apt-get update is happy
<YokoZar> Thank you so much shawarma
<shawarma> YokoZar: The one in Dapper should be able to do the signing, too.
<YokoZar> Hmm, guess I need to configure it to set that up then.  All I've been doing is just navigating to the release file and signing it by hand
<shawarma> YokoZar: Add "SignWith: e8bda4e3" where e8bda4e3 of course should be your gpg key id.
<YokoZar> shawarma: to the config file?
<shawarma> YokoZar: and the either use gpg-agent or remember to add "--ask-passphrase" very early on the reprepro command line. It will show you a *very* cryptic prompt, but just type your passphrase, and it should be happy.
<shawarma> YokoZar: Yes.
<shawarma> YokoZar: I got to run for half an hour...
<YokoZar> I need to add it to every distribution right?
<YokoZar> Thanks for your help again
<shawarma> YokoZar: Did you figure it out?
<YokoZar> shawarma: well everything is signed already so I'm gonna wait 2 weeks to see if the signwith thing made a difference
<YokoZar> But apt-get update is happy now
<shawarma> YokoZar: Made a difference? You were trying to solve a specific problem?
<YokoZar> shawarma: err we already solved that problem ;)  I was just talking about not having to sign the release file by hand anymore
<shawarma> YokoZar: Ah, right. You can test it by just running "reprepro --ask-passphrase export feisty" or something.
<YokoZar> ahh I guess that will work too
<YokoZar> heh, thanks
<shawarma> YokoZar: No problem.
<YokoZar> So do you keep your own reprepro repo?
<shawarma> YokoZar: Used to. 
<shawarma> YokoZar: I used to use it to prerelease proposed bug fixes.
<YokoZar> shawarma: Ahh, good idea.
<rgl> hi
<sladen> hello rgl 
<rgl> I'm trying to rebuil bind9, but its faling with some errors that I dunno how to fix: http://pastie.caboo.se/61190   can you please help me?
<sladen> rgl: I think everyone else is relaxing by the pool or travelling
<sladen> rgl: sudo apt-get build-dep bind9
<rgl> sladen, I though it already has the deps resolved, because it started to build fine.
<rgl> sladen, yeah, the build-dep returned: 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<sladen> rgl: are you running under fakeroot
<sladen> rgl: with the source installed *without* sudo
<sladen> rgl: have a look for the file(s) it is complaining about
<rgl> sladen, oh, sorry, I forgot to include the build command I'm using: dpkg-buildpackage -rfakeroot -uc -b
<ion_> sladen: I think you mean *with*
<ion_> You probably have files owned by root there.
<rgl> sladen, yes, I did apt-get source bind9 inside my user account (non-root)
<sladen> ion_: no, I mean *without*
<ion_> In that case, im trying to figure out why would it complain about permissions.
<sladen> ion_: otherwise the files will be owned by root, and building as a user will file, because there aren't the permissions to modify them
<ion_> If you sudo apt-get source ..., the files will be owned by root, right? If you just apt-get source ..., they will be owned by your user.
<sladen> rgl: try doing 'ls' on the files and directories it is complaining about
<sladen> ion_: correct.  and you want the second (owned by the user)
<ion_> sladen: Ah, i had misread your line. I thought you meant you have the source installed without sudo.
<rgl> sladen, I'm not sure from where should I resolve the relative path ../../../..
<rgl> from bind9-9.3.2 ?  (where I've run dpkg-buildpackage)
<ion_> rgl: sudo chmod -R youruser:yourgroup .
<rgl> ion_, I've already mention the files are inside my $HOME with my used:group ;)
<rgl> can you please see: http://id.ruilopes.com/typescript.txt
<rgl> I've run: fakeroot debian/rules binary
<rgl> and in that file, you can see the full output :|
<Kmos> rgl :)
<rgl> hey Kmos :D
<rgl> Kmos, ever build the bind9 package?
<Kmos> nop
<rgl> its failing, and I'm not seeing how to make it work :|
<Kmos> rgl: it doesn't exist an updated .deb version ?
<Kmos> calipo has edgy ?
<Kmos> rgl: try #ubuntu-motu
<rgl> Kmos, I need to add some configure switches to it.  the default .deb package does not do the trick for me.
<rgl> Kmos, I did.  all asleep/parting somewhere
<Kmos> rgl: i've done ddclient new version for gutsy
<rgl> Kmos, maybe you can figure out the problem from:  http://id.ruilopes.com/typescript.txt
<Kmos> rgl: how about to do dpkg-buildpackage -S -rfakeroot
<Kmos> inside bind9 directory
<rgl> -S?  /me check the man
<sladen> rgl: is this on fiesty/gustsy?
<rgl> Kmos, I've used dpkg-buildpackage -rfakeroot -uc -b
<rgl> sladen, no, its edgy (6.10)
<Treenaks> ok.. I have this PCI device, which has 4 4k blocks of memory.. how can I dump the contents of those memory blocks to disk? I can't figure out how to make dd do it for me..
<Treenaks> (oh, and the device is driverless currently)
<jdub> it's gusty time!
<bhale> jdub: oh?
<Treenaks> jdub: Had a spicy dinner then?
<jdub> bhale: looks like gusty has 2.6.22 (will work with powertop)
<Treenaks> jdub: (or should we call this release cycle 'hurricane season'?)
<bhale> jdub: you also get the very latest "finger" technology
<jdub> ooh, lots to upgrade
<Treenaks> heh.. I saw the Intel guys use that at UDS 'We need to release this soonish...'
<Treenaks> 1 day later, they did, apparently
<Treenaks> bhale: http://www.linuxpowertop.org/
<bhale> pochu even merged muine already
<bhale> pochu: hugs
<pochu> bhale: slomo_ told me to do it :)
<bhale> ah
<bhale> this iceweasel business in debian is unhinged
<bhale> more and more deltas coming into beagle packaging to just s/firefox/iceweasel... for Justice
<jdub> bhale: haw haw :-)
<bhale> oh
<bhale> Xorg blue screen of death
<Spads> It's a real pity, because iceweasel is such a better name than firefox anyway
<Treenaks> Spads: Lightningyak rules even more (yay firesomething extension :)
<ompaul> Treenaks, they were we need to edit the same information at the same time and some lame irish person pointed them at gobby they were happy after that
<ompaul> Treenaks, the intel guys
<azeem> did somebody look at the Liberation fonts license terms?  Are they fine for Ubuntu?
<tepsipakki> should be, if they are fine for redhat/fedora
<jdub> azeem: gpl+font exception
<azeem> jdub: well, plus some "Intellectual Properties" asserting their Trademark rights
<azeem> +clause
<azeem> I'm a bit dissapointed by their lawyer-speak
<azeem> "Subject to the following terms, Red Hat, Inc. ("Red Hat") grants to the user ("Client") a license to this work pursuant to  the GNU General Public License v.2 with the exceptions set forth below and such  other terms as our set forth in this End User License Agreement."
<ion_> I just granted some fecal property rights to a porcelain container.
<bhale> jdub: oooh powertop
<jdub> bhale: doesn't work with current gusty kernel tho either :
<jdub> :|
<bhale> jdub: you forced it to install 2.6."22"? it isnt in linux-meta yet
<jdub> ja
<bhale> "when running a gnome desktop 3 wakeups per second is acheivable"
<bhale> gnome mobile drives the desktop (again)
<mjg59> bhale: CONFIG_TIMER_STATS isn't set in 22 yet
<bhale> mjg59: are we going to try NO_HZ?
<mjg59> It's on already
<bhale> i'd better give that a run on the laptop
<mjg59> I'm working through some of the fixups
<jdong> how are the real-world power savings on CONFIG_HZ?
<mjg59> There's going to need to be some kernel work for several machines
<mjg59> jdong: Varies heavily
<mjg59> jdong: Optimally, a couple of watts
<jdong> ok
<mjg59> So if your machine is drawing 25 to start with, it's not a huge win
<mjg59> If you're under 10, that's obviously not the case
<jdong> I'd expect the savings to become more significant wit h the next gen CPU's that can enter a much deeper sleep?
<mjg59> As CPUs improve there's more potential for improvement, yeah
<jdong> cool
<TeKnoW> Attention:  private conflicts with christel lead to netwide bans. And complaints are to be taken to the PDPC lawyer. That is how your donations are used.
<jdong> umm... intreesting....
<pygi> join #edubuntu
<KHatfull> greetings...
<KHatfull> I come by way of #ubuntforums...is mjg59 around?  
<mitsuhiko> is it possible that pycentral randomly breaks on ubuntu?
<TomaszD> anyone knows the date for next language-pack upload for feisty?
<pureDesi> I want to start developing under ubuntu but not sure what language I should dedicate myself to, any suggestions?
<pygi> pureDesi, dunno, python? :)
<pureDesi> sounds good
<pygi> great then
<pureDesi> I know PHP/MySQL couple of other minor languages, do these relate to python in any way?
<pochu> cjwatson: hello! are you ok if I merge base-files?
<av16ar> hello everybody
#ubuntu-devel 2008-05-05
<ogra> simply by restarting all the dowwnloads and deleting everything before
<ion_> You should have uninstalled the RIAA plugin.
<ogra> i cant belive we ship that
<ion_> (That was a (poor attempt at) a joke.)
 * jdong looks
<jdong> ogra: what did you click to cause that to happen?
<ogra> so i have a ton of torrents that already were downloaded startig to DL again and wiping my folders
<jdong> (not trying to imply PEBKAC, just trying to understand what happened)
<ogra> jdong, i added another torrent without wiping the list *indisde* of transmission (the .torrent files were long gone)
<jdong> ogra: oh did that other torrent contain same files or something?
<ogra> jdong, well, might be PEBKAC that i didnt wipe the list in tranmission
<ogra> nope
<ogra> that one was a short movie
<jdong> ogra: that's weird
<ogra> i simply didnt use trasmission since the last DLs
 * jdong hasn't seen that happen yet
<jdong> and I've used transmission pretty regularly.
<jdong> hmm...
<jdong> if you can reproduce the workflow that causes this to happen, that'd be awesome
<jdong> it sounds like a pretty nasty bug
<ogra> yup
<ogra> 'm quite shocked
<jdong> or "usability unfeature"
<wgrant> I've never seen it delete anything.
<ogra> heh
<Nafallo> god thing you have backup :-)
<Nafallo> good even
<jdong> hardlinks, man. hardlinks.
<ogra> Nafallo, i copied them all to my server
<jdong> they sound sexy and prevent bad things from happening :)
<ogra> but the actual dirs were emptied
<JohnPhys> I haven't seen it delete anything either, though I've never gone through those steps.
<jdong> ogra: so you simply added a torrent and data disappeared?
<ogra> well, step 1 download someting to your desktop ... step 2 dont touch transmission for two or three weeks after DL has finished ... step 3 delete the .torrent files step 4 DL a new torrent, notice that transmission has all the old ones listed, note it starts over with the old ones as well, find the dire empty just being refilled with some kb
<ogra> *dirs
<ogra> its no harm. i copied all the old stuff, but its still quite weird
<jdong> ogra: odd... I swear I do that all the time and don't witness data loss
<ogra> do the torrents get listed in tranmission after they finished for you ?
<Nafallo> that sounds like logic :-)
<jdong> yes
<wgrant> ogra: You sure you haven't previously removed those folders?
<ogra> yes
<jdong> ok I've attempted to reproduce it
<jdong> minus step 2 of course
<jdong> nothing seems to have happened
<ogra> heh
<Nafallo> no torrent files == empty torrent files == no files :-P
<ogra> Nafallo, hmm
<jdong> this sounds like a REALLY nasty bug and I'm interested in finding it
<jdong> perhaps talk to charles next time he appears
<JohnPhys> jdong:  Not to distract you, but you mentioned I could remind you to take a look at bug #195052 once hardy was released.  So...here's a reminder :)
<ubottu> Launchpad bug 195052 in inkscape "Latex formula does not work on Ubuntu Hardy" [Low,Confirmed] https://launchpad.net/bugs/195052
<jdong> JohnPhys: yes, thanks for the reminder.
<JohnPhys> jdong:  No problem, thanks!  I believe a debdiff has been attached to that bug report lately to take care of the issue.
<ogra> jdong, well, i didnt lose anything since i copied to my mediaserver yet and its 1am here and i have a conf call in the morning, i'll try to investigate that tomorrow later
<jdong> ogra: thank you
<jdong> JohnPhys: I commented on the bug... the debdiff is only slightly incorrect for an update
<jdong> JohnPhys: I assume the person who prepared the debdiff would like upload credit for it, so I've asked him on the bug to update his debdiff to reflect stable versioning policies
<JohnPhys> jdong:  Thanks!  It's much appreciated!
<jdong> JohnPhys: sure thing :)
<TheMuso> crimsun: I'm creating ~ubuntu-core-dev/pulseaudio/hardy for hardy pulseaudio development, so that intrepid development can occur concurrently with fixing issues in hardy.
<crimsun> TheMuso: ok.  So "trunk" can have revs 20-24 reverted.
<kimbrel> Does anyone know if anythingâs being done about the IO/scheduling problem?
<TheMuso> crimsun: Ok.
<jdong> kees: do you know if Gutsy is vulnerable to CVE-2008-0007?
<jdong> i.e. git http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=f5871b9016c0ebce8acc58f7a230adcb9bd89577
<jdong> kees: i.e. bug 187275; looks like it's still open :-/
<ubottu> Launchpad bug 187275 in linux "[linux-source] several local vulnerabilities" [Medium,Triaged] https://launchpad.net/bugs/187275
<kees> jdong: yeah, still open -- we've been planning a kernel update for this coming week, which will include that fix.
<jdong> kees: Ok, cheers :)
<dholbach> good morning
<LaserJock> morning
<LaserJock> just the man I wanted to see
<dholbach> hi LaserJock
 * jdong wonders the thoughts going through dholbach's mind...
<dholbach> jdong: hm?
<jdong> 01:41 < LaserJock> just the man I wanted to see
<jdong> that should trigger the fight-or-flight thing ;-)
<dholbach> jdong: oh... I'm sure it's going to be fine :)
<dholbach> bdmurray: do you know about recent pylpbugs breakage?
<dholbach>   File "/usr/lib/python2.5/site-packages/launchpadbugs/tasksbase.py", line 283, in get_current
<dholbach>     raise AttributeError, "There is no row of the info-table linked to this bugreport (%s)" %self._url
<dholbach> AttributeError: There is no row of the info-table linked to this bugreport (https://launchpad.net/bugs/123456/+text)
<ubottu> Launchpad bug 123456 in xine-lib "podcast crashes amarok" [Undecided,Confirmed]
<warp10> Good morning
<dholbach> bdmurray: I think it'd make sense to get the fix for bug 215043 SRUed - it fixed the breakage above too
<ubottu> Launchpad bug 215043 in python-launchpad-bugs "comment.attachments crashes in HTML connector" [Undecided,Fix committed] https://launchpad.net/bugs/215043
<dholbach> bdmurray: nevermind what I just said
<dholbach> bdmurray: it's just a very weird bug happening - check out http://paste.ubuntu.com/10161
<dholbach> no, it's not weird - please just ignore what I said
 * dholbach gets more coffee
<pitti> Good morning
<warp10> good morning pitti
<dholbach> hi pitti
<dholbach> hi Tonio_
<Tonio_> hey dholbach :)
<geser> Hi pitti
<jscinoz> hmm
<jscinoz> Teeworlds still hasnt shown up in the new queue yet >_<
<jscinoz> Been in unstable for a while now
<soren> Any particular reason why perl's priority was dropped to standard?
<soren> Hmm... Maybe debconf's lack of Depends: perl is the actual culprit.
<pitti> hi soren
<pitti> soren: btw, do you plan to merge dpkg again?
<soren> pitti: cjwatson's doing it this time.
<pitti> soren: Guillem Jover offered to help with this
<pitti> soren: ah, ok; just wanted to make sure you knew about Guillem's offer
<soren> Oh, sure.
<soren> pitti: So... about perl. IIUIC, changing packages' priority is a manual process, correct?
<StevenK> pitti: Stupid question, how do I list sessions for polkit?
<pitti> soren: yes, I think so; but it has been standard in hardy already
<pitti> StevenK: ck-list-sessions
<pitti> StevenK: (it's ConsoleKit)
<soren> pitti: Hmm.. You're right. apt-cache show here shows it as important. That's odd.
<soren> *
<soren> *very* odd indeed.
<StevenK> pitti: Oh, duh. That would explain why I couldn't find it. :-/
<soren> Perhaps the package itself says it's important, but it's overridden in the archive's Packages file..
<soren> No, that says standard, too.
<soren> What on earth could make "apt-cache show perl" say "priority: important"?
<StevenK> perl-base is Essential: yes, I didn't think perl was
<soren> The problem is that debootstrapping Intrepid fails right now, because libc6's postinst ends up failing due to lack of Utils/Hash.pm.
<soren> (it uses debconf)
<soren> Oh!
<soren> perl-base contains fields.pm, which seems to need Utils::Hash.
<soren> and the latter is in perl-modules.
<pitti> that's a bug in perl packaging itself then
<soren> Indeed.
<soren> man debootstrap
<soren> doh...
<StevenK> pitti: I'm trying to determine why USB keys don't automount on UME -- can you just spit out a few hints for me to check?
<pitti> StevenK: do you use nautilus on those beasts?
<pitti> StevenK: in hardy, nautilus now does the automounting, not g-v-m any more
<StevenK> pitti: Ahhhh. No nautilus.
<pitti> StevenK: can you mount them manually? with gnome-mount?
<StevenK> pitti: gnome-mount -m /dev/sdb doesn't mount it
<pitti> StevenK: try gnome-mount -vbd /dev/sdb
<StevenK> Right. -m is the wrong option.
<StevenK> gnome-mount -d /dev/sdb does work
<pitti> ok, so it's really just the lack of an automounter
<StevenK> pitti: So UME should use g-v-m?
<pitti> StevenK: well, that's the problem; automounting was disabled in gvm, since it conflicts to nautlus
<pitti> StevenK: I think you might want to take a look at ivman
<StevenK> pitti: Ah, we could enable it specifically for lpia?
<pitti> StevenK: either that, or you guys are happy with ivman; drops a few gnome dependencies, too
<lool> pitti: MSG people moved back to gvm
<lool> They reenabled it
<lool> And they fixed it for the new HAL :)
<pitti> ah, I see
<pitti> lool: how do you mean? current version should work fine with 0.5.11?
<lool> It does not; let me grab their changes
<lool> pitti: http://people.ubuntu.com/~lool/96_fix_for_new_hal.patch
<pitti> lool: hm, that looks like basically reverting 00_disable_media_handling.patch ?
<pitti> there are no hal specific changes in that patch
<pitti> lool: btw, the latest upstream version  has this 'disabling' patch applied already
<pitti> meh, intltool/libxml-parser-perl dependency issue in intrepid seems to cause FTBFS all over the place
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> pitti, can you upload system-config-printer and foo2zjs for me (see your mail)/
<pitti> tkamppeter: yes, I'll do it
<tkamppeter> thanks
<lool> pitti: Yes, it reverts the disabling and fixes a couple of things
<lool> pitti: They should have used two patches instead of one
<lool> And I also said to remove patches they want to disable instead of adding a reverted patch IIRC
<lool> pitti: I think this part is the relevant one:
<lool> -       { "block",                 block_device_added        },
<lool> +       { "volume",                 block_device_added        },
<lool> I think they sent that upstream now
<lool> In fact we did it with Michael while I was sitting next to him
<lool> Hmm no, we sent the hal changes not the gvm ones
<lool> pitti: Anyway, StevenK tried ivman out and it worked for him; we're likely to stick to that if we're happy with it
<lool> pitti: You can check with Michael Frey if you want more details on what they changed in gvm for the new hal
<pitti> lool: ah, thanks for the heads-up
<StevenK> ivman looks lighter than gvm.
<StevenK> It's what to do about unmounting that escapes me
<lool> Good point
<pitti> StevenK: but g-v-m doesn't do that either
<lool> In all cases we need some UI that will call pmount/gnome-mount to umount devices
<pitti> unmounting needs to happen manually
<StevenK> Right, exactly. We have no UI.
<lool> \o/
<lool> StevenK: MSG has been evaluating pcmanfm and rox (rox-filer); we should poke them on the topic, perhaps it's related
<StevenK> lool: Okay.
<lool> pcmanfm has "# Built-in volume management (mount/umount/eject through HAL)"
<lool> Rox doesn't look like it has that
<cjwatson> soren: depends: perl from debconf is *wrong*; please don't do that. This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479202.
<ubottu> Debian bug 479202 in perl-base "fields tries to use Hash::Util" [Unknown,Open]
<soren> cjwatson: Oh, I wasn't going to :)
<cjwatson> pitti: yeah, I know about Guillem's offer, though in the event I didn't need it (I found Ian and got him to explain a couple of obscure triggers bits)
<cjwatson> anyway, bank holiday today, so ...
<pitti> cjwatson: ah, thanks; enjoy!
<pitti> cjwatson: I thought triggers were in sid now?
<cjwatson> pitti: they are, but I had to verify the merge as it wasn't byte-for-byte
<cjwatson> and in fact I did find one or two things left out, which I'll be forwarding to Guillem
<ogra> cjwatson, go away ! its your free day
<cjwatson> don't worry, I'm going to be not at home for much of the day :)
<ogra> :)
<pitti> tkamppeter: new s-c-p> yay, that looks much cleaner now!
<norsetto> pitti: about bug 221399: even though only 3 days have elapsed, we have 5 acks and it is just a rebuilt; can we shove it already to -updates?
<ubottu> Launchpad bug 221399 in rkward "Not working in hardy x64" [Medium,Confirmed] https://launchpad.net/bugs/221399
<pitti> norsetto: yes, that's fine
<norsetto> pitti: thanks!
<\sh> pitti, do you have any paperwork why pybaz was removed in hardy?
<pitti> norsetto: does Debian have a new version
<pitti> ?
<norsetto> pitti: yes
<pitti>     rkward |   0.4.9a-1 | intrepid/universe | source, lpia
<pitti> norsetto: ah, so that should be fixed in intrepid, too (once it actually builds, that is)
<\sh> argl...
<norsetto> pitti: ok, I'll open a new task and verify that it builds correctly
<norsetto> pitti: even though its a different issue, for Intrepid we have R 2.7
 * \sh blames people just filing removal reports, without having a proper notification in the real source package
<pitti> norsetto: it already had an intrepid task, I closed it
<norsetto> pitti: ah, I guess LaserJock opened it
<pitti> \sh: bah, I wonder where soyuz stores/displays the removal log
<\sh> pitti, is it possible to improve canonicals remove package script from archive to let it search for reverse-build-deps, and warn even before removal of a package? ;)
<\sh> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/bazaar/+bug/214955 <- here
<ubottu> Launchpad bug 214955 in vcs-load-dirs "remove bazaar package from hardy" [Undecided,Fix released]
<pitti> \sh: neither bigjools nor cprov are online ATM :/
<\sh> pitti, I found it via google
<pitti> \sh: we often do search for reverse dependencies
<pitti> it's not integrated into the actual soyuz script, though
<\sh> pitti, it would be good to do so ... and to resolve those buggers before the actual removal ;)
<pitti> agreed
<wgrant> pitti: Do you want http://people.ubuntu.com/~ubuntu-archive/removals.txt, or is there another one?
<pitti> wgrant, \sh: ^ that's the one that was used up to a few months ago
<wgrant> There's something there from two weeks ago...
<wgrant> I thought they made it log there again after that feature was removed a couple of months back.
<\sh> wgrant, it's not correct this file ;)
<crimsun> asac: I recommend for hardy-proposed that we build nspluginwrapper on i386 and readd its libflashsupport dependency.  That seems to be the least invasive change.
<asac> crimsun: tough decision
<berzerka> hi there ubuntu-devs. nice work you are doing ;)
<asac> i agree that we want nspluginwrapper for i386 though.
<asac> but for -proposed :/
<berzerka> i am trying to rebuild the libusb-0.1.12 source package using dpkg-buildpackage. i installed all build deps (especially jade), but get a lot of jade errors of "undefined elements". what is going on here? might the build dependancies of the package be wrong? any idea how to fix it? (asked on #ubuntu some minutes ago, but no answer as expected)
<crimsun> asac: well, we could go with -backports, then
<berzerka> (please just tell me if this is not the right place to ask..)
<pitti> berzerka: does the package actually stop building, or does it just spit out the errors?
<berzerka> pitti: it aborts. dpkg-buildpackage: failure: debian/rules build gave error exit status 2
<emgent> morning
<pitti> berzerka: eww, that sounds like a genuine bug then
<berzerka> the errors are of the kind: jade:../../doc/manual.sgml:12:17:E: element "BOOK" undefined
<berzerka> for a huge bunch of elements (he stops after 200 since this is the maximum numbers of jade errors reported)
<asac> berzerka: is that hardy?
<berzerka> i think there is some jade-module build-dep missing..
<pitti> berzerka: weird, though, it built just fine in intrepid some days ago: https://edge.launchpad.net/ubuntu/+source/libusb/2:0.1.12-10
<berzerka> asac, yes
<pitti> and it built fine in hardy as well
<wgrant> pitti: It's not unheard of for packages to go crazy with a dirty build environment...
<pitti> but last time it was built on hardy was 2007-11-23
<pitti> right
<berzerka> pitti: hmm maybe you have (pre-)installed the dep i am missing?
<pitti> might be a missing build-conflicts: perhaps
<pitti> berzerka: the buildds just install Build-Depends: (and Build-Depends-Indep:), nothing else
<berzerka> build-deps were either jade or openjade, tried both with the same result
<berzerka> pitti: i don't get you, you mean the automated build bots?
<pitti> berzerka: yes
<berzerka> i see..
<berzerka> strange, then
<berzerka> can i confirm wether i have an up-to-date, "clean" hardy install here?
<asac> berzerka: you could try to build using pbuilder to be sure
<berzerka> asac: never heard of it. i will read up...
<berzerka> i have only "hardy" references in sources.list, lsb_release tells me 8.04 hardy and aptitude full-upgrade returns nothing, so i conclude i have an up-to-date hardy installation.
<berzerka> what's going on? i did pbuilder --create, and he began installing a hube bunch of system-packages? err... the man-page said nothing about that. well hopefully the required deps are installed at least.
<berzerka> ah i see, this is for the chroot environment, right? they are not installed on my system but in the base.tgz chroot-environment..
<pitti> berzerka: it just creates a tarball for a chroot environment
<pitti> berzerka: exactly
<ogra> is a virtualbox module rebuild planned for the kernel in -proposed ?
<ogra> (assuming that has to go through SRU as well etc)
<norsetto> hmmm, anyone understand what the problem is here: http://launchpadlibrarian.net/14215953/buildlog_ubuntu-intrepid-amd64.gnomeradio_1.7-5ubuntu1_FAILEDTOBUILD.txt.gz
<norsetto> I built before uploading and it was fine. I rebuilt now and its fine, those deps all install ok in my pbuilder intrepid chroot
<jpatrick> norsetto: I think intltool or one of its dependencies cannot be installed
<pitti> norsetto: intltool/libperl-blabla? yes, that seems to hit pretty much every intrepid upload ATM
<Hobbsee> tasty, because i just uploaded dput.
<norsetto> pitti: arghhh
<Hobbsee> pitti: what's hte problem with them?
<pitti> I haven't checked
 * pitti is on hardy and will stay for another 3 montsh
<norsetto> pitti: lucky you :-)
<Hobbsee> pitti: wuss :P
<Hobbsee> pitti: where's your sense of adventure?
<soren> Yeah. Intrepid's fun.
<pitti> Hobbsee: I am on the 'fix hardy harder until 8.04.1' team :)
<Hobbsee> pitti: oh yeah, that's right.  i guess you're exempt, then....
 * pitti spends about two hours on the SRU queue per day these days...
<Hobbsee> ouch!
<pitti> well, that includes sponsoring, etc.
<megabyte405> FYI - the new AbiWord package is up
<megabyte405> assuming nobody sees further problems, it should be ready for hardy and intrepid
<wgrant> intrepid and hardy-backports?
<ogra> likely
<wgrant> Or is there some evil plot to do huge version bumps in -updates?
<pitti> hardy-backports is a good choice at first, and after some time we should discuss moving to hardy-updates
<pitti> wgrant: well, this case is a bit spethial; it didn't get finished in time for hardy final
<ogra> pitti, please only with enough testing
<megabyte405> Before hardy it was discussed 8.04.1
<ogra> pitti, the classmate ships it by default
<pitti> ogra: absolutely
<wgrant> pitti: So I saw.
<wgrant> It was happening sos close to the end :(
<ogra> and it shouldnt add deps different des as well
<ogra> *deps
<pitti> ogra: not without your consent then :)
<ogra> gracias :)
<berzerka> using pbuilder the package builds successfully! (but i am unable to locate the resulting .deb files)
<ogra> look in /var/cache /pbuilder/result
<ogra> (without space indeed)
<berzerka> how can this be? is my base install broken?
<pitti> berzerka: /var/cache/pbuilder/result -> .debs
<pitti> berzerka: you probably have a lot more packages installed, teh build might conflict with one
<berzerka> this was a gutsy install which i upgraded to hardy.
<berzerka> but shouldn't dpkg-buildpackage have told me so when checking the build-deps?
<pitti> berzerka: yes; packages can create Build-Conflicts:, but apparently this one does't
<broonie> berzerka: Build conflicts are moderately unlikely to get noticed; many people always build in a chroot and even if they don't they may never run into the issue.
<berzerka> pitti: soo, this seems to really be a (minor) bug in the package.. i guess you guys would like it fixed. now i got to find out what the difference between my install and the chroot base system is..
<pitti> berzerka: thank you!
<berzerka> how can i check which version of jade has been installed in the base.tgz?
<pitti> berzerka: there's probably a lot, but not so many java related ones
<pitti> berzerka: the versions are probably identical, but your normal system has a lot more packages installed
<pitti> berzerka: you can 'pbuilder login' and play in the chroot
<pitti> berzerka: (changes won't be preserved by default)
<berzerka> pitti: nice, thanks
<berzerka> pitti: inside the pbuilder shell, where do i find my source-package directory?
<berzerka> pitti: i want to try to dpkg-buildpackage from in here, first.
<pitti> berzerka: normally it's not there; you can apt-get source it again, or use some mount --bind tricks
<berzerka> pitti: alright
<pitti> berzerka: it's not a very comfortable chroot for interactive working; pbuilder is mainly designed to build packages automatically
<tkamppeter> pitti, thank you for uploading, but it seems that the buildds is currently not able to build s-c-p due to one of the dependencies not getting installed:
<tkamppeter> The following packages have unmet dependencies:
<tkamppeter>   libxml-parser-perl: Depends: libwww-perl but it is not going to be installed
<tkamppeter>                       Depends: perlapi-5.8.8 but it is not installable
 * norsetto wonders where he did see that already ....
<norsetto> tkamppeter: [12:19] <pitti> norsetto: intltool/libperl-blabla? yes, that seems to hit pretty much every intrepid upload ATM
<pitti> tkamppeter's looks slightly differnet, but it might be related to the perl issue
 * pitti cnat' tpye toady
<\sh> we have also other issues ... tried to upgrade from hardy to intrepid chroot..and it fails for libpam-foosomething and other stuff
<berzerka> pitti: if i try to dpkg-buildpackage, i get unresolved build dependancies in the chroot env. dpkg -l doesn't list them too... Unmet build dependencies: debhelper (>= 5.0.22) autotools-dev pkg-config docbook-dsssl jade | openjade. those are about the same deps i was missing in my install.
<pitti> berzerka: yes, you need to do apt-get build-dep <sourcepackagename>
<berzerka> ah i see
<pitti> berzerka: the pbuilder chroot only has the minimal package set (essential and required)
<pitti> ScottK: http://launchpadlibrarian.net/14092249/unison_2.27.57-1~hardy1_source.changes -- (1) new unison is in intrepid now, (2) the bug number is wrong, and I can't find a matching one, (3) if hardy final's version is totally broken, this should be an SRU, not a backport
<pitti> ScottK: I rejected the package for now
<norsetto> I guess we will have kde4 only in intrepid?
<\sh> will kde4.1 will be released in time?
<berzerka> pitti: i resolved it...
<berzerka> pitti: as i see it, docbook has to be added as an explicit build dependancy.
<ScottK> \sh: That's the plan.
<berzerka> pitti: i had docbook not installed. libusb has only docbook-dsssl as build-dependancy. docbook-dsssl depends on docbook | docbook-xml. since i had docbook-xml installed (don't know why), docbook hasn't been installed transitively.
<ScottK> pitti: It's not a question of unison being broken as incompatible.  With what's in the repositories, you can sync among Dapper through Hardy machines, but not with any boxes with the current version.
<ScottK> unison has a history of incompatible on the wire protocol changes.
<pitti> ScottK: ah, I see; but shouldn't it be an automated backport still?
<berzerka> pitti: after installing docbook, it works now. does one of you take care of adding docbook to the build-deps of libusb or should i file a bug for it? or do you see another problem/solution? :)
<ScottK> pitti: Now yes, but last week we didn't have it yet.
<pitti> berzerka: I don't know exactly, but IIRC there was some weird problem with the docbook dependencies; asac, do you remember?
<ScottK> pitti: If you could do an automated backport of unison Intrepid -> Hardy that would be great.
<pitti> ScottK: 2.27.57-1~hardy1 ?
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<tkamppeter> pitti, slangasek, about bug 219999
<ubottu> Launchpad bug 219999 in foomatic-filters "[Hardy SRU request] foomatic-rip does not handle enumerated-choice options with choices "True" and "False" correctly, leading to Duplex on most Ricoh printers not working" [High,Fix committed] https://launchpad.net/bugs/219999
<ScottK> tkamppeter: Did you see Debian Bug 479397
<ubottu> Debian bug 479397 in wnpp "RFA: gutenprint -- printer drivers for CUPS" [Normal,Open] http://bugs.debian.org/479397
<ScottK> I thought you might be interested.
<tkamppeter> pitti, slangasek, is it needed to have this fixed in Intrepid before it get an SRU for Hardy? I am thinking about replacing the current foomatic-filters already by version 4.0 which is written in C and not in Perl (and also fixes the bug). So it will take some time to the next foomatic-filters package.
<\sh> ScottK, or the wish ;)
<ScottK> Someone ought to pick it up it seems and the more print stuff is managed in common between Debian/Ubuntu the better off both distros will be, IMO.
<tkamppeter> ScottK, thenkas for the info. I am not an official Debian Developer, so I cannot upload directly into Debian. What I can do is to have the packaging managed in a common SVN repo where I make the Ubuntu packages from and someone of Debian only takes snapshots from there to have Debian packages. This way it works with HPLIP currently. The rpos are hosted at Debian.
<ScottK> tkamppeter: You don't need to be a DD to maintain stuff in Debian (I maintain several packages there).
<ScottK> That sounds sane though.
<berzerka> pitti: will you take care of the bug or shall i commit a report for now?
<berzerka> pitti: i mean, docbook seems to be definitely required, so i don't see why one shouldn't just add it as an explicit build dependancy.
<berzerka> hm maybe i'll just wait for asac to respond....
<pitti> berzerka: re (sorry, was at lunch)
<pitti> berzerka: the most effective place to report that would be a Debian bug IMHO
<pitti> tkamppeter: well, the package is already in hardy-proposed, so that should be answer enough :)
<pitti> tkamppeter: ideally the patch would be uploaded to intrepid right now, then that bug is done, and doesn't block on the rewrite
<pitti> tkamppeter: but for #219999 the important blocker is now to collect testing feedback
<pitti> tkamppeter: there is none at all so far, so we cannot move it to -updates
<berzerka> pitti: i am really not confident with reporting a bug which i encounter in ubuntu to the debian devs. does ubuntu completely mirror the debian repositories, or are versions/dependancies managed on its own? if yes, this is a ubuntu bug i would say. one could check wether the same problem exists in the debian repositories, then there would, by chance, exist the same bug in debian as in ubuntu.
<norsetto> berzerka: for what you said the bug is not the missing build-dep on dokbook, is the alternative build-deps that doesn't work
<berzerka> norsetto: docbook-dsssl depends on docbook | docbook-xml. you mean the error is the dependancy on docbook-xml? (since the package doesn't seem to fully supply what is required..)
<norsetto> berzerka: yes, note also that our libusb and docbook-dsssl are unchanged from Debian
<berzerka> okay the error seems to exist in debian unstable, too..
<berzerka> docbook-xml only suggests docbook and not requires it, but (falsely) satisfies the build-dependancy of libusb.
<norsetto> berzerka: yes, if it is really required for dokbook to be a build-depends, than yes, it should be added as an explicit dependency and not to be relied upon being dragged in as a secondary one
<berzerka> okay then. i will report a bug at bugs.debian.org. i hope they won't recognize that this error actually stems from a ubuntu system, cause i fear to (rightly) get flamed in that case...
<norsetto> berzerka: why should you? We even have usertags for that
<jdong> you're unlikely to be flamed for reporting a Ubuntu bug to Debian
 * berzerka doesn't know about usertags
<berzerka> but okay, if you say so.
<berzerka> thank you all very much, i'm glad this issue is resolved, and i can go on debugging libusb :)
<norsetto> berzerka: https://wiki.ubuntu.com/Bugs/Debian/Usertagging
<berzerka> norsetto: thanks. so i should tag with origin-ubuntu and hardy?
<pitti> berzerka: thanks a lot for your effort!
<berzerka> hardy doesn't seem to be really relevant here..
<pitti> (right)
<pitti> berzerka: the packages are mostly straight imported from Debian
<pitti> docbook-* and jade*, that is
<asac> hmm ... whats the problem? building libusb* still?
<berzerka> alright. very helpful you are in here. next time i have a real, distro-related problem i will check back here, #ubuntu is not that helpful in those respects, busy with explaining the user interface..
<berzerka> asac: everything resolved, i guess.
<tkamppeter> pitti, thanks for the info, testing is so far based only on my daily printing which does not show any regression (I use the patched Hardy package currently and not foomatic-rip 4.0).
<pitti> tkamppeter: there must be someone else who also has an affected printer?
<asac> berzerka: ok thanks.
<berzerka> asac: problem was: i had docbook-xml installed. docbook-dsssl is a build-dep, which depends on docbook OR docbook-xml. but docbook seems to be actually required (and is only suggested by docbook-xml). i will file a bug at debian, the problem exists also in sid.
<pitti> tkamppeter: anyway, if you are using the actual binaries from hardy-proposed, please state your own test results in the bug
<pitti> tkamppeter: (thanks)
<tkamppeter> pitti, I do not have a printer which is affected, I have tested the fix itself by printing into a file when I did the fix for upstream and also when I tested whether the patch has applied correctly to the Ubuntu packages.
<pitti> tkamppeter: I guess we'll just wait for the bug reporters then?
<tkamppeter> My daily printing is a regression test and shows up to now that the patch does not break anything else in the printing workflow.
<pitti> tkamppeter: if none of them answers, the problem can hardly be so pressing
<pitti> tkamppeter: ah, that's a good data point to have, though; can you mention this in the bug, please?
<pitti> tkamppeter: I mean the regression testing on other modesl
<tkamppeter> The original reporter is George Liu from Ricoh (the author of the affected PPD files).
<tkamppeter> I have sent mail to him asking to test, but he did not answer yet.
<alex-weej> i used ubuntu-bug -p hal
<alex-weej> and it didn't attach a device tree dump or anything
<alex-weej> who do i nag to fix that?
 * soren kicks apt-cacher
<soren> It seems to be racy somewhere. I use it to maintain a partial, local mirror, and apt fails with "E: Method http has died unexpectedly!" almost every time if the cache is hot. If there are just a few cache misses in there, or if I strace it (which slows it down a bit), it works great.
<pitti> \sh: FYI, we can sync emacs21 next time; libungif4-dev is a transitional package to libgif-dev
<pitti> \sh: it should be fixed in Debian (did you report a bug?), but that's not worth keeping a delta for
<e-gandalf> hi all. I'm looking for someone who could help me with my plans for UDS in Prague. I'm a local community manager in mozilla, and wanted to meet you and learn from your example. :)
<dholbach> e-gandalf: https://wiki.ubuntu.com/UDS-Intrepid has more information on how to get there and when it is, etc
<e-gandalf> dholbach: I went through it. What I miss is a schedule (what's on day 1, what's on day 2)
<e-gandalf> to choose when it's best for me to be there
<dholbach> e-gandalf: the schedule is not up yet but will be generated from the topics that are handed in on LP
<dholbach> https://wiki.ubuntu.com/FeatureSpecifications
<dholbach> https://wiki.ubuntu.com/TimeBasedReleases
<e-gandalf> dholbach: :( Hard to say if I prefer to be on Mon-Wed or Wed-Fri without it :(
<dholbach> e-gandalf: I understand
<dholbach> maybe you're interested in http://fosscamp.org/ - it will happen before UDS
<e-gandalf> could you suggest me? I want to see how you're operating in the community/localization/internationalization field
<asac> e-gandalf: i think monday and tuesday will be most active mozilla related discussion.
<asac> e-gandalf: actually most upstream related discussion ... we will have more mozilla related discussion the other days too
<e-gandalf> asac: unfortunately I can't stay the whole week :(
<asac> e-gandalf: ok. i think mon-wed are the better days then. but maybe prod me in a few days, then i can tell you for sure
<e-gandalf> asac: great! Thank you. Can you give me your email so that I can poke you? :)
<asac> e-gandalf: at best ping me here online.
<e-gandalf> ok
<asac> e-gandalf: otherwise asac@ubuntu.com
<asac> i hopefully will know by wed (day after tomorrow)
<asac> cool
<e-gandalf> thanks for help. I will :)
<\sh> pitti, ahhh....
<\sh> pitti, sry well, actually there are only security NMUs somehow, but noted for the next rev: "emacs21 to be synced" :)
 * \sh is more annoyed of removing some functionality from config-manager, pybaz removed means no real "bazaar/baz" support
<ogra> mvo, do you have any reports about compiz emitting a second keypress on changig workspaces ? its really hard for me to get to the even numbered ones, it always skips one here
<mvo> ogra: I can't remember that, but I'm behind the compiz bugs
<mvo> ogra: what card is that?
<ogra> intel
<ogra> ogra@osiris:~/Devel/packages$ lspci|grep -i vga
<ogra> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
<ogra> i see it switching to number two in the workspace applet and then see it skip a millisecond later to switch to number three
 * soren just had a thought (you heard it here first)
<soren> Why the need to subscribe ubuntu-sru to bugs? When the bugs are uploaded to -proposed, they should have the same bug numbers referenced, so it seems a bit redundant.
<ogra> looks like a second keypress but thats definately not happening according to xev
<seb128> soren: because the sru team doesn't get upload notifications?
<soren> seb128: Ah, right. ubuntu-release != ubuntu-sru.
<soren> seb128: Good point :)
<Hobbsee> correct.  (thank goodness)
<seb128> soren: u-r doesn't get mail notification for upload either
<seb128> soren: somebody needs to look at the queue to know what is there
<soren> But... Hm... So if someone's in ubuntu-sru, but not ubuntu-release, how do they do the SRU thing? They tell someone from u-r to move stuff from -proposed to -updates?
<StevenK> soren: u-a
<StevenK> soren: -archive does the actual moving
<Hobbsee> u-a + canonical employees.  But yeah.
<soren> Hobbsee: Eh?
<Hobbsee> soren: the subset of ubuntu-archive and canonical employees.
<Hobbsee> (as in, don't ask me, i can't do it)
<soren> Ah, the intersectin between the two sets?
<Hobbsee> er, yes, that.
<soren> Ok, I though you meant the union.
<soren> I got confused :)
 * Hobbsee doesn't have that symbol of her keyboard
<Hobbsee> no :)
<seb128> soren: the archive tasks are processed regularly usually, there is no need to send notifications
<seb128> soren: the sru team benefit from being notified though
 * soren goes to subscribe ubuntu-sru to a stack of bugs, then.
<seb128> soren: no need to subscribe it to all the bugs, one by upload is enough
<calc> seb128: bug 221834
<ubottu> Launchpad bug 221834 in dbus "inotify regression in dbus 1.1.20 (with patch)" [Undecided,New] https://launchpad.net/bugs/221834
<seb128> calc: ?
<calc> seb128: you work on dbus right? i was pointing you to that bug that someone brought to my attention :)
<seb128> calc: no
<calc> oh sorry
<seb128> calc: pitti does work on dbus usually
<calc> ah, thanks! :)
 * calc should read changelog before annoying other devs ;-)
<calc> pitti: ping
<pitti> hi calc
<calc> pitti: bug 221834 :)
<ubottu> Launchpad bug 221834 in dbus "inotify regression in dbus 1.1.20 (with patch)" [Undecided,New] https://launchpad.net/bugs/221834
<calc> pitti: someone from synce team was asking me about that bug earlier today
<pitti> calc: oh, sure, we can fix that
<calc> pitti: ok
<ogra> pitti, could we add vitrualbox-ose-modules to the auto exception for rebuild uploads for SRUs ?
<pitti> calc: I'll assign it to me and to the hardy SRU stuff
<calc> pitti: ok thanks :)
<pitti> ogra: sure, that's sort of implicit for kernel ABI bumps :)
<ogra> seems silly to have all the paperwork every time the kaernel changes
<ScottK> We do the same thing every time the flash-nonfree md5sum changes.
<ogra> pitti, seems blueyed has something ready
<seb128> ogra: hey, can you confirm bug #220564?
<ubottu> Launchpad bug 220564 in nautilus "regression: unmount options in nautilus are shown on LTSP" [Medium,Fix committed] https://launchpad.net/bugs/220564
 * ogra checks
<ogra> seb128, yes, i dont have anything in my context menu :)
<seb128> ogra: can you comment on the bug then?
<ogra> i could even check if i had vbox modules for the unning kernel :P
<ogra> commented
<LaserJock> pitti: are you the one that cleared -proposed?
<pitti> LaserJock: define 'cleared'?
<pitti> I process the queue every day, yes
<pitti> and copy stuff to -updates once it's verified
<LaserJock> yeah, but all of a sudden there's nothing for Universe at http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
<LaserJock> maybe the update script isn't done running :-)
<LaserJock> yep, that's what happened
<LaserJock> anyway
 * LaserJock hugs pitti for rocking the SRU processing
<pjoul> hi! where we store settings of gnome-appearance-properties's desktop effects? thank
<Artemis_Fowl> LaserJock: you around?
<LaserJock> I am
<Artemis_Fowl> LaserJock: good. nixternal told me the other day that he told you about KGRUBEditor
<Artemis_Fowl> hmm my syntax sounds strange
<Artemis_Fowl> LaserJock: anyway. has there been any process concerning a GNOME counterpart?
<LaserJock> well, I mentored a Google Summer of Code project on a Bootloader Manager
<LaserJock> https://launchpad.net/ubuntu-bootloader-manager/
<LaserJock> there is a bzr branch for it there
<LaserJock> I'm not sure how similar it is to KGRUBEditor
 * Artemis_Fowl is checking out
<LaserJock> I would say it's still pretty alpha-stage
<LaserJock> but I thought it showed a lot of promise if development get fired up
<LaserJock> *gets
<LaserJock> pitti: SRU archive admining question. Do you have a 7-day "aging" requirement?
<DktrKranz2> but if a fix is good, it can be
<DktrKranz2> (sorry....)
<pitti> LaserJock: ah, right, seems you just caught the page update then
<pitti> LaserJock: yes, 7 days is the normal maturing period
<pitti> LaserJock: for high-urgency bugs, and well-tested packages we shortened it, though
<LaserJock> pitti: the SRU policy does not require 7 days though, just 2 positive acks and no negative ones
<LaserJock> pitti: we should resolve that discrepency
<pitti> LaserJock: it's documented on the linked page: https://wiki.ubuntu.com/ArchiveAdministration#head-1f27dc12ab1558ec21b31ac44e4c86a87a4cd053
<ogra> hmm, intresting, running update-manager through ssh -X omits the embedded terminal window option ...
<LaserJock> pitti: yes, it's documented there but not on StableReleaseUpdates
<LaserJock> I would assume StableReleaseUpdates is the canonical source of SRU policy
<pitti> what's the KDE GUI way to edit something as root?
<Arby> pitti: kdesu kate or kdesudo kate
<pitti> Arby: right, that's what I proposed, but it's far from discoverable
<Arby> fair point
<infinity> pitti: There's a discoverable way to do it in GNOME?
<pitti> infinity: there is nautilus-gksu, if only it wouldn't be broken in hardy final :/ (SRU is in progress)
<infinity> pitti: Not installed by default, mind you, which isn't all that "discoverable". :)
<pitti> right
<infinity> pitti: Looks cool, though.  I mean, assuming I didn't live in a shell/ls/vim world, and liked to click on stuff.
<pitti> yeah, it's only at the time when you try to explain "how to configure dual-head under Kubuntu" to an absolute Linux beginner over ICQ
<pitti> my great experience with KDE at large, and GUI configuration tools in particular are a great help here
<pitti> *cough*
<infinity> I'm thinking "how to edit the text file" would be the least of your worries there...
<pitti> it requires you to modify xorg.conf (virtual screen size)
<infinity> Yeah, it also has the potential for aspoloding X to the point where they might never connect to ICQ again. :)
<infinity> (Unless they're on another machine...)
<infinity> Does nautilus-gksu just append gksu to any "open" action?  (ie: I could "open as root" an image in /usr/share with The GIMP to mangle my icons directly?)
<infinity> Cause the potential for user stupidity every time they get "you don't have permission to edit that" to then just "open as root" and try again would make it a poor candidate for inclusion in -desktop.
<infinity> s/append/prepend/
<infinity> Gets dangerously close to the Windows "everyone just runs as Administrator, cause it's easier" way of life.
<pitti> not sure
<ogra> infinity, well, calling the default user root and not setting a password would save us three questions (at least !!) in the installer
<infinity> ogra: :P
<pitti> infinity: btw, any idea about the intltool/perl issue that causes tons of FTBFS?
<pitti> mjg59: for intrepid's pm-utils, at this stage, I'd like to drop 98-unload_network_modules.patch
<pitti> mjg59: to give people a chance to report bugs early and get them fixed properly in the kernel; ok with you?
<infinity> pitti: Nope!  Example log?
<infinity> pitti: (I've been pretty much completely ignoring FTBFSes, as I tend to do during a merge, while things "shake out"...)
<pitti> so we just need to give-back packages occarionally?
<infinity> pitti: When the queues approach 0, I'll do a mass-give-back.
<jeromeg> jdong, ScottK : it seems that during the glest backport to Gutsy glest-data was forgotten which makes this package uninstallable at the moment
<jeromeg> could one of you two give an ack if I file a backport request for it ,
<jeromeg> ?
<ScottK> jeromeg: What's the original backports bug for glest?
<jeromeg> ScottK: just a second, I'll find ity
<jeromeg> *it
<jeromeg> ScottK: or maybe glest-data is still sitting in NEW
<jeromeg> ScottK: bug 201182
<ubottu> Launchpad bug 201182 in gutsy-backports "Please backport glest from Hardy" [Undecided,Fix released] https://launchpad.net/bugs/201182
<jeromeg> looks like only glest was backported
<gnomefreak> whats with the backport everything the past few days
<gnomefreak> omg i see more backport this than anything
<jeromeg> gnomefreak: everything ?
<gnomefreak> jeromeg: your name has been attached to most of them
<gnomefreak> maybe 10 or so a day
<jeromeg> gnomefreak: 10 ?
<RainCT> gnomefreak: well, backports are cool :)
<jeromeg> mmm maybe because there is a gutsy and a hardy bug task
<gnomefreak> give or take unless you are telling them its not in intrepid yet more than once per bug
<gnomefreak> ah good point
<jeromeg> gnomefreak: i'm just contributing to backports because i don't like to see links to getdeb and funky ppa packages in most ubuntu releated websites
<ScottK> jeromeg: Lookst like glest-data was not asked for.
<ScottK> jeromeg: And it's appreciated.
<jeromeg> ScottK: shall I open a new bug report ?
<gnomefreak> jeromeg: i dont blame you im just wondering why having the latest is so needed
<ScottK> jeromeg: Yes.  Also would you please get in touch with the original reporter and explain about what went wrong so they know better in the future.
<jeromeg> ScottK: ok thank you
<ScottK> gnomefreak: The why isn't (I think) so important beyond users want it.  I'd rather we support them in official repositories with -backports than they go elsewhere.
<jeromeg> gnomefreak: i personnally don't need them and will not use those backports most of the time
<jeromeg> ScottK: +1
 * gnomefreak thinks some are ok but if you backport too many packages from unreleased/unstable it brings bugs into stable (some that have security mixed with new features i could understand
<gnomefreak> im assuming we still dont "support" in any way backports
<ScottK> gnomefreak: I can see that, but then what's too many?
<ScottK> gnomefreak: It's as unsupported as Universe.
<gnomefreak> ScottK: anything that cant fit into SRU do to a couple of new feature
<gnomefreak> s
<gnomefreak> ummm universe is supported
<ScottK> gnomefreak: Not by Canonical.
<gnomefreak> right
<ScottK> Backports is not supported the same way Universe is not supported.
<ScottK> i.e. supported by the community on a best effort basis.
<jeromeg> ScottK: i got to go, the package is building at the moment, i'll fill the bug tomorrow
<ScottK> OK.
<jeromeg> see you
<Caesar> tjaalton: (wrt to #113679) can you try a build with the patch I've attached?
<hwilde> !seen Keybuk
<ubottu> Factoid seen keybuk not found
<Company> [21:39] <-- Keybuk has quit (Read error: 104 (Connection reset by peer))
<tjaalton> Caesar: I don't have a dapper machine to test on, but maybe my PPA would do
<tjaalton> Caesar: thanks for the fix btw, I've just been too busy to do anything with it
<jpatrick> hwilde: /msg SeenServ help
<hwilde> jpatrick, cool.   i thought ubottu did that too
<tjaalton> does a give-back mean that a FTBFS'd package is allowed to get fixed and re-use the FTBFS'd version?
<RainCT> tjaalton: only if re-building it without changes to the source will fix the FTBFS
<RainCT> (ie, because it was a problem with the buildd, the archive, or something)
<tjaalton> RainCT: ah right
<tjaalton> thanks
<tjaalton> makes sense
<mjg59> pitti: Sure
<emgent> There is a big problem with requestsync script SMTP server
<jpatrick> emgent: worked fine for me today, what's wrong with it?
<emgent> i dont know, script print to me "Sync request mailed" but dont work fine.
<emgent> i cant see in launchpad bug.
<jpatrick> just filed?
<cjwatson> (a) there's probably a delay in mail processing (b) if you want to post over HTTPS then use the --lp option
<emgent> no, script say "done", but i dont see this sync request in launchpad.
<jpatrick> Wait a while, I had to wait about 10 minutes for my bug to show up
<emgent> jpatrick: i know, but i was request it some hours ago.
<jpatrick> emgent: Which package?
<emgent> sympa
<emgent> From: emgent@emanuele-gentili.com
<emgent> To: new@bugs.launchpad.net
<emgent> Subject: Please sync sympa 5.3.4-5 (universe) from Debian unstable (main).
<emgent> ..snip..
<emgent> Sync request mailed.
<emgent> emgent@amnistia:~$
<emgent> argh, dont work..
<emgent> anyway i go to sleep now, i will try tomorrow
<emgent> night peaople
<emgent> s/peaople/people/
<jpatrick> night emgent
<hwilde> any acpi experts ?
<mjg59> hwilde: in what respect?
<hwilde> what would cause phantom power button pressed messages?
<hwilde> system randomly just reboots itself
<mjg59> reboots?
<hwilde> yep.  it invokes /etc/acpi/powerbtn.sh
<hwilde> it says "Power button pressed"  and it reboots
<hwilde> i blame the hardware... some type of electrical issue... but the EE people have commented out /etc/acpi/powerbtn.sh and it no longer reboots, so they blame the OS :(
<hwilde> but I think it's just going to lock up on them and then they won't be able to turn it off at all
<mjg59> Some hardware will do it if it thinks that a thermal trip has occured
<hwilde> it seems to be related to usb devices... strange as that sounds
<hwilde> plug in a logitech rumblepad controller and the thing reboots repeatedly...
<calc> http://blogs.zdnet.com/BTL/?p=8703 <- title of article is funny
 * calc would rather spend eternity using windows than one day of solaris (again)
<hwilde> careful what you wish for :/
<calc> hwilde: i've had the misfortune of having to manage solaris machines before, it was beyond horrid
<hwilde> lol it calls opensolaris "an enterprise-class UNIX desktop and server with an Ubuntu-like flavor"
<hwilde> i've tried it, it does not taste like ubuntu whatsoever.
 * calc wonders if solaris has gotten useful programs like... top, yet
<calc> when i last used it (which was a while ago) it had nothing useful installed even with a full install
<hwilde> I don't think it's intended to be used....   much more stable that way.
<hwilde> but this random rebooting issue has seriously slowed down my development.   uninstall acpi and it's fine...  do I really need acpi ?
<rockets> Out of curiosity, and I'm not sure if this is the right place to ask, so I apologize in advance if it isn't, is there any chance of the firefox/flash/youtube crash bug being fixed on "our" side, or is something Adobe has to take care of?
<hwilde> do you have a bug #
<rockets> hwilde, are you referring to me?
<hwilde> i'll take that as a no
<rockets> hwilde, actually, I think I do.
<crimsun> 192888, probably.
<hwilde> thnx i've hit my google quota for the day...
<crimsun> and the answer is most likely, look for some nspluginwrapper love from -backports.
<rockets> 209442, and a similar bug I think would be 81212
<hwilde> wow that's an old one
<rockets> hwilde, either way, its pretty widely known that firefox randomly crashes on youtube using the nonfree flash plugin
<calc> the nonfree flash plugin doesn't even work well on windows
<rockets> calc, speak for yourself.
<calc> it constantly is screwing up on my wifes computer
<hwilde> sorry I was busy working :/
<rockets> calc, It "works for me TM"
<calc> she has to restart firefox every few days to get flash working again
<mtaylor> is there a wiki page somewhere about the process for proposing something for hardy-updates?
<rockets> calc, Anyway, I wasn't complaining. I was just curious.
<ScottK> !SRU | mtaylor
<ubottu> mtaylor: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<mtaylor> ScottK: thanks
<crimsun> rockets: please see 192888.
<calc> i looked at her computer yesterday and asked her why she was using IE, and it was because flash stopped working again, and she didn't want to have to restart firefox
<ScottK> No problem.
<rockets> thanks crimsun
<calc> hopefully the docs adobe released are good enough to implement a free non-buggy oss flash plugin :)
<rockets> calc, thats what im hoping too.
<rockets> calc, gnash plays youtube videos just fine without crashing, but not much else.
<calc> yea
<rockets> crimsun, i see it says a fix was released? hope to see that soon.
<ajmitch> running plugins in the same process would tend to be slightly unsafe for that reason
<ScottK> Work with YouTube and not for ads would be a feature in my book.
<crimsun> rockets: for /which/ source package?  :-)
<rockets> flashplugin-nonfree, which doesnt seem possible lol
<rockets> since we have no access to the source for that
<crimsun> rockets: no, that's correct.  It no longer depends on libflashsupport, which apparently caused more harm than good.
<rockets> ahhh
<rockets> thats not a fix hehe
<rockets> crimsun, it may not depend on it, but at least on my system, WITHOUT libflash support, after a flash movie plays with sound, no other apps can play sound even if i close firefox.
<crimsun> rockets: I know full well and addressed that.
<rockets> so libflashsupport is somewhat vital, as far as im concerned.
<mtaylor> ScottK: I've got a fix on the way for a package which has a regression from gutsy to hardy because of a patch applied in the debian upstream package... I'm not sure if it qualifies as a "severe regression" - but it is a loss of functionality
<crimsun> unfortunately, my workaround is a bit too zealous.
<mtaylor> ScottK: should I go through the whole process - or is there a way to quickly vet whether or not I'd be wasting tons of people's time?
<rockets> crimsun, addressed that as in a fix was released and an update was pushed out? or addressed it as in something is in the works but not done yet.
<ScottK> mtaylor: Is the package Main or Universe?
<mtaylor> Universe
<crimsun> rockets: the latter.  There are two approaches: change pulseaudio's default config, or build an i386 nspluginwrapper package.
<rockets> ah
<rockets> crimsun, by the way, thank you. of all the ubuntu devs ive spoken to, i think over the last year youve been willing to spend far more time answering my inane questions then was really necessary
<ScottK> mtaylor: Then I'd suggest head over to #ubuntu-motu and ask if there is someone from motu-sru who is available to give you an opinion.
<mtaylor> ScottK: great. thanks again
<rockets> crimsun, and i appreciate it
<crimsun> rockets: thanks, but you need not thank me.
<rockets> crimsun, i remember you said you maintain alsa for ubuntu, do you maintain pulseaudio as well?
<rockets> or you just work closely with them because its obviously a highly related package
<crimsun> rockets: no, I no longer maintain them, but I poke once in a while.
<rockets> ah.
<Pupeno> Hello.
<Pupeno> How do I get the same package built for other versions of Ubuntu on PPA?
#ubuntu-devel 2008-05-06
<LaserJock> Pupeno: you should be able to use the package copy UI in PPA
<bryce> ogasawara: for linux bugs, should they now be filed against just 'linux' or 'linux-source-2.6.24' or ...?
<ogasawara> bryce: against "linux" now
<bryce> ok
<bryce> ogasawara: bug #223870 looks like it may be a kernel issue rather than an "ordinary" x crash, but needs some additional kernel-oriented triaging work.  Mind taking a look?
<ubottu> Launchpad bug 223870 in linux "x-server crashes on startup with intel GMA3000" [Undecided,Incomplete] https://launchpad.net/bugs/223870
<ogasawara> bryce: np, looking right now
<bryce> ogasawara: that also might be one to have Intel test
<Hobbsee> damn compiz
<RAOF> To a lifetime of driver bugs?
<Hobbsee> it crashed.  again.
<Hobbsee> screen froze.
<RAOF> :(
<RAOF> Apparently there was a cycle in the animation plugin that could do that, but I think it's fixed in -updates.
<Hobbsee> RAOF: it's still in proposed, i have it installed, and i ithink it's hanging more than usual
 * Hobbsee had been testing it from mvo's ppa for a while though
<RAOF> Sucks.
<Hobbsee> hmm, there's some more updates, including an intel driver
<pranith> hello
<pranith> hello... when i do an objectdump of a binary, what are those addresses i get?
<pranith> are they relative addresses of some kind??
<giggidyy> I have a general question concering the USB Architecture as it exists on a PC: can a USB Host emulate a USB device?
<jscinoz> ugh, where on launchpad was the intrepid new queue again?
<StevenK> jscinoz: https://edge.launchpad.net/ubuntu/intrepid/+queue
<jscinoz> ah thanks
<jscinoz> how long of a delay is there normally between a package being uploaded to Debian Unstable, and it being imported to Ubuntu's new queue?
<StevenK> Depends on when -archive runs the autosyncer
<jscinoz> If i remember correctly, the freeze for importing packages from unstable is considerably earlier than the other freezes? Some time in june i believe?
<jdong> jscinoz: yes, the auto-sync stops at an earlier point
<jdong> jscinoz: but until the actual upstream version freeze it's very simple to request a sync anyway
<jscinoz> alright
<jdong> Dear Compiz Overlords:
<jdong> I suggest that for Intrepid we include some Compiz games.
<jscinoz> Should i give it a bit longer for the auto-sync to do it, or file a syncrequest now?
<jscinoz> compiz games?
<jdong> yes.
<jdong> I've invented a few good ones while I've been bored in lectures.
<jdong> open up 20 or so windows...
<jdong> hit super-M to invert the entire screen's colors
<jdong> then randomly hit alt-tab and super-n to de-invert individual windows.
<jdong> Now, uninvert the whole screen and start a stopwatch
<jdong> time how long it takes to get all windows back to the correct color.
<jscinoz> >_<
<jdong> (yes, I was really bored during lecture)
<jscinoz> speaking of lectures and education, i really should get back to studying for my preliminaries tomorrow >_<
<jdong> or, a random desktop plugin that shuffles your windows across all your desktops
<jscinoz> thanks for the clarification on the autosync thing
<jscinoz> *away*
<jdong> sure thing
<pitti> Good morning
<tjaalton> Caesar: seems that the patch worked, you can find the package here https://edge.launchpad.net/~tjaalton/+archive
<Caesar> tjaalton: thanks
<Caesar> So is it in dapper-proposed now?
<dholbach> good morning
<tjaalton> Caesar: not yet, it would be nice to test that the patch does what it's supposed to do first :)
<seb128> soren: hello
<seb128> soren: do you care about gtk-vnc?
<soren> seb128: I do.
<seb128> soren: do you know about bug #206227? I think that's something we should try to get fixed for 8.04.1
<ubottu> Launchpad bug 206227 in gtk-vnc "vinagre fails to connect" [High,Fix committed] https://launchpad.net/bugs/206227
<seb128> soren: http://gtk-vnc.codemonkey.ws/hg/outgoing.hg/rev/e1b964facd65 seems to be the upstream fix for the issue
<seb128> soren: also bug #207205
<ubottu> Launchpad bug 207205 in gtk-vnc "vinagre crashed with SIGSEGV in memcpy()" [Medium,Fix committed] https://launchpad.net/bugs/207205
<soren> You seem to have done all the work already? :) What do you need me for?
<seb128> soren: no, I'm just reading bug mail, I don't want to do the actual testing and update ;-)
<seb128> soren: you are better placed than me to make sure it doesn't create issues for the virt stack
<soren> seb128: The problem is that the virt-stack is very well behaved (in this context at least). I have very little clue about all the quirks of commercial vnc servers and all that jazz.
<soren> seb128: pochu has been very interested in this in the past. Maybe we can get him to drive it.
<seb128> soren: well, the idea is basically to backport the change, verify it fixes the issue (trying to connect to a dapper box should be enough to test apparently) and that virt things are still working correctly and upload
<seb128> soren: ok, will talk to him, thanks
<seb128> soren: he commented on the bugs already
<seb128> soren: bug #218667 mentions that the new version creates virt-manager issues that's why I want somebody to test it after patching
<ubottu> Launchpad bug 218667 in gtk-vnc "Please allow gtk-vnc 0.3.5 into Hardy" [Undecided,Invalid] https://launchpad.net/bugs/218667
<seb128> pochu: ^ do you think you could try to prepare a gtk-vnc sru fixing those issues?
<soren> pochu: In particular, it seems that Jonh knows exactly which commits would fix this, so if we could just cherry-pick those (instead of importing new gtk-vnc and vinagre versions wholesale), that would be great.
<foka> Hi!  I have a question: Is there a concerted effort to translate package descriptions into local languages?  :-)
<Ademan> hey this might be a little out of place, but does apt/can apt download multiple packages concurrently? if apt-torrent or something similar were to ever mature, that might be a desirable feature
<Company> Ademan: if you use multiple mirrors in your sources.list, it already downloads multiple packages at once
<Ademan> Company: ah, cool
<cjwatson> Ademan: we don't want it to hammer our mirrors like that, as a general rule ...
<cjwatson> when you multiply that sort of thing up by millions of users it starts to turn into serious server abuse
<Ademan> cjwatson: well, i'm curious more in terms of apt-p2p and debtorrent, as i'm really big on the idea of RELIEVING repository stress, and I think peer to peer apt would certainly go a long way to doing that.  But since it's rather unlikely that you will max out your connections download speed downloading from a handful of peers, it would be useful to concurrently download multiple packages via a peer to peer system
<Ademan> download multiple packages concurrently*
<cjwatson> just saying that's why it doesn't do that at the moment
<\sh> Ademan, how does the trust model work for apt-p2p? actually, who can someone achieve, that peer X doesn't inject malicous packages?
<Ademan> cjwatson: ah, so is the functionality there though? just disabled?
<cjwatson> Ademan: I doubt it
<\sh> s/who/how/
<cjwatson> Ademan: (but I'm not an apt developer)
<cjwatson> \sh: AFAIK it still checks against (signed) archive checksums afterwards
<Ademan> \sh: the way i envision it existing packages.gz files would provide hashes for the files in question, plus packages are signed, correct?
<cjwatson> individual packages are NOT signed
<Ademan> ah
<Klessou> Is it normal when edit the gnome-terminal LAUNCHER (in the panel) and I add "sudo" (or "gksudo") before "gnome-terminal" command. I'm using directly the root user without password ... ??
<cjwatson> each package's checksum is in Packages.gz, Packages.gz's checksum is in Release, and Release is signed
<Klessou>  ... in a terminal when I do "sudo gnome-terminal", at the same time I hate to put my password ...
<cjwatson> so you don't need to go around separately verifying signatures from however many developers are involved
<Klessou>  ... in a terminal when I do "sudo gnome-terminal", at the same time I have to put my password ...
<Ademan> that makes sense
<pochu> seb128, soren: I prepared gtk-vnc, although it was 0.3.5, but a user reported quite a few regressions so I'm afraid of breaking the virt stuff
<pochu> seb128: soren: bug 218667
<ubottu> Launchpad bug 218667 in gtk-vnc "Please allow gtk-vnc 0.3.5 into Hardy" [Undecided,Invalid] https://launchpad.net/bugs/218667
<Ademan> anyways, it certainly feels less secure, but i don't believe it should be a problem
<seb128> pochu: I've nominated 3 bugs for hardy, do you want to backport the corresponding changes?
 * \sh is just afraid about the chain of trust...I trust the *.ubuntu.com infrastructure more then I trust any temp source of download for packages ;)
<Ademan> lol
<Mithrandir> \sh: uh, the Packages file is signed so that doesn't matter.
<seb128> pochu: the crash on closing, the compatibility mode and the powperpc color issue
<seb128> pochu: those have no reason to break keyboard, etc, and hardy-proposed is there to test changes before pushing to updates
<cjwatson> the only thing that apt-torrent would change is that it would become much easier to attack checksums
<Ademan> plus i like the idea of using /var/cache/apt for 'seeding' packages, since that means the most popular packages will theoretically be fastest
<cjwatson> at the moment you have to take over a full-scale mirror to try that kind of attack
<cjwatson> with apt-torrent, you'd be able to attempt collision attacks on individual packages
<cjwatson> which does scare me a bit (not as much as \sh's description, but a bit)
<Ademan> wouldn't adding another simple metric like file size make a hash collision nearly impossible? (with malicious code anyways)
<\sh> cjwatson, which is quite easy with a small ammount of criminal energy
<cjwatson> Ademan: not in the slightest (anyway, size is already checked)
<cjwatson> Ademan: if you read the literature on collisions they're normally if anything easier to construct with the same file size
<Ademan> cjwatson: interesting, i would have assumed that adding a second constraint of any sort would make it tougher to do
<cjwatson> not that one
<Ademan> lol
<cjwatson> the biggest constraint that makes a difference is that the result still has to be a valid .deb
<cjwatson> which I think means we probably aren't in serious danger right now
<Ademan> cjwatson: ah, true
<cjwatson> but I would not bet money on that continuing to be the case
<cjwatson> Ademan: the thing is that you have to add an *independent* constraint, and it turns out that size and checksum are not as independent as you might think; as a rough unmathematical demonstration, think of the structure of the hash algorithm - the number of iterations of the hash you perform is very much related to the file size
<cjwatson> Ademan: similarly, other hash algorithms with a "sort of similar" structure aren't independent either; it turns out that MD5 + SHA1 gives you about 6 extra bits of security over SHA1 alone, which is much less than many people expect
<Ademan> cjwatson: ah true, this may fall into the same category, but would having two independent hash algorithms help?  say SHA-1 and MD5 work?
<Ademan> ahah
<cjwatson> no :-)
<cjwatson> you're much better picking a single good one
<cjwatson> concatenating hashes is a waste of time
<Ademan> hrm
<cjwatson> unfortunately, right now, there are no good hashes
<pitti> argh argh argh intltool
<cjwatson> in the sense that there are none that cryptanalysts aren't on a path towards breaking
<Ademan> do *.debs preserve file attributes like creation and modification dates?
<cjwatson> .debs contain a tarball for the actual filesystem data, so yes
<Ademan> well that might be effective, even if it's not included in Packages.gz, a file manifest with creation and modification dates sounds effective
<cjwatson> not really; bear in mind that metadata is a minority of the content
<cjwatson> I suggest not worrying about it for now; armchair cryptography is usually a lot harder than it looks. :-)
<Ademan> lol
<Ademan> well i really am interested in working on apt-p2p, but the last thing i want to do is create a gaping security hole lol
<cjwatson> I don't think you really are - it's a concern but not a gaping one
<cjwatson> as in, it lowers the bar to attacks that aren't yet feasible, but maybe will be some day - but if they are then we'll have to address that *anyway*
<cjwatson> and this sort of thing has been improved lately by switching to SHA256 in Packages
<Ademan> hrm, well i suppose i'll heap apt-p2p on my giant list of crap i want to contribute to
<Ademan> lol
<jeromeg> ScottK: hello
<jeromeg> I tested with glest-data, everything works fine
<pitti> doko: did you see slangasek's questions on bug 222876?
<ubottu> Launchpad bug 222876 in gcc-3.3 "package gcc-3.3-doc 1:3.3.6-15ubuntu4 failed to install/upgrade: " [High,Confirmed] https://launchpad.net/bugs/222876
<jeromeg> ScottK or jdong: could one of you ack bug 227225 please ?
<ubottu> Launchpad bug 227225 in gutsy-backports "Please backport glest-data from Hardy" [Undecided,New] https://launchpad.net/bugs/227225
<emgent> someone can add tmp execption in fiordland.ubuntu.com?
<cjwatson> emgent: why not use the --lp option?
<cjwatson> as I suggested last night, but you didn't respond
<emgent> i used it, but dont work
<\sh> emgent, did you install this lp-support  python package?
<emgent> yes
<cjwatson> then you need to talk to #canonical-sysadmin if you want changes to fiordland
<emgent> \sh: python-launchpad-bugs ?
<\sh> emgent, yes...
<emgent> yes is in
<\sh> or python-launchpad-integration something like this
<emgent> i use p-l-b for anteater (u-whitehat) and work fine
<emgent> only requestsync dont work to me..
<\sh> hmm....but I thought the public smtp server is open to everyone, even without having an ubuntu.com address?!
<emgent> DktrKranz2: say to me that fiordland accept only @ubuntu.com address
<\sh> emgent, nope...I don't use my @ubuntu.com address, it's at least attached to my lp account....but first used email is my sourcecode.de address...
<emgent> oh ok
<\sh> emgent, it even works when you use a local smtp server which sends the email from your local system
<\sh> emgent, important is only the gpg sig to the mail, your key needs to be known to lp...anyways...going back to work :)
<emgent> yes i know
<emgent> anyway i'm talking with canonical-sysadmin
<emgent> thanks for all now :)
<doko> pitti: replied and fixed, please reject the package, to be honest ... I think fixing this was a waste of time
<emgent> cjwatson \sh
<emgent> (11:57) ( Ng) emgent: well from our MTA logs it looks like your mail was delivered fine, so we'll need  to check with the launchpad guys for what their code did with it
<pitti> doko: ok; nothing to reject, though, it's not in the queue
<pitti> doko: ah, now it's there, uploaded 33 seconds ago :)
<victory747> ArneGoetje, asac I should ask you about font substutition in gnome/firefox/etc regarding Chinese fonts
<victory747> I have long had problems when using simplified chinese that first a traditional chinese font is chosen and if the glyph fails in there it falls back to a simplified chinese font
<victory747> but the two fonts used have different typefaces and sometimes the simplified font is hard to read.  This often happens to me in thunderbird.
<ArneGoetje> victory747: which font settings do you use?
<victory747> in thunderbird, or in gnome, or in what?
<ArneGoetje> victory747: in Hardy WQY ZenHei is the default font for sans-serif and monospace and therefor the default on the desktop. And this one is a Simplified Chinese font which is fairly complete in the CJK Basic area. For Serif, AR PL UMing CN is used in the zh_CN locale, which does not follow any shape standard yet and therefor you will see mixed HK and CN style glyphs. This is work in progress. Otherwise we don't have any free purely simplified 
<ArneGoetje> victory747: ok, other question: did you do a fresh hardy install or did you upgrade from a previous version? Also, which locale setting do you use?
<victory747> ArneGoetje, this was on a fresh gutsy install
<ArneGoetje> victory747: try upgrade to hardy
<victory747> ArneGoetje, my hardy machine was upgraded, but I'm not sure if it has that problem or not
<ArneGoetje> victory747: which locale do you use?
<victory747> ArneGoetje, The menus don't have problems, it's more things like web pages or text messages in thunderbird.  using zh_CN
<victory747> zh_CN.UTF-8
<ArneGoetje> for firefox and thunderbird you may need to tweak the font settings yourself in the Preferences dialog.
<ArneGoetje> victory747: although, on my hardy machine the fonts are chosen correctly for Chinese.
<victory747> ArneGoetje, I'll look at it more in hardy and see if I can't find problems there.  I just remember being disapointed that it still was not working as expected but I don't have any specifics.
<victory747> Where is the order of font substitution set?
<ArneGoetje> victory747: what does fontconfig-voodoo -l show ?
<victory747> zh_TW
<victory747> ja_JP
<victory747> ko_KR
<victory747> zh_HK
<victory747> zh_SG
<victory747> zh_CN
<victory747> zh_MO
<victory747> ka_GE
<victory747> I wish we could change that for zh_CN locale.
<ArneGoetje> victory747: change what for zh_CN locale?
<victory747> ArneGoetje, where is the list of fonts used.
<victory747> change the order of font substituion
<victory747> I mean where is the order of font substitution specified.
<ArneGoetje> victory747: the order of font substitution is correct for zh_CN. the question is just if your system picks it up or not
<ArneGoetje> victory747: /etc/fonts/conf.d/
<victory747> oh?  But I would want to use a simplified font before a traditional font in ALL situations
<ArneGoetje> victory747: that;s the default setting
<victory747> oh, even in gutsy?  maybe it's just my thunderbird that's messed up
<ArneGoetje> victory747: we just don't have any purely simplified Song style font available.
<victory747> right, you said that
<ArneGoetje> victory747: in gutsy we don't have any purely simplified font available.
<victory747> ArneGoetje, mabye I should do a clean install in vmware to test because my systems are always such a mess anyway
<ArneGoetje> victory747: that';s why I suggest to upgrade to hardy
<victory747> ArneGoetje, I'll try to find some good cases - I have nothing specific right now that I can give to you
<ArneGoetje> victory747: as I said, on gutsy there is no purely simpplified font available. Therefore you can't change it.
<victory747> ArneGoetje, ok, i'll upgrade my other computer to hardy soon and see how it works
<ArneGoetje> victory747: ok
<victory747> ArneGoetje, do you suggest a fresh install instead?  I would probably do that anyway.
<ArneGoetje> victory747: depends on if you've messed around with fontconfig or not...
<victory747> ArneGoetje, I'll try a fresh install I think - mostly i'm interested in the experience of chinese nationals
<ArneGoetje> victory747: ok
 * ArneGoetje gotta go now...
<ogra> asac, my FF cashes if i use and close gmail (i rarely use the web interface so i didnt notice yet)
<asac> ogra: start ffox in -safe-mode
<asac> and see if you still get that
<ogra> one sec
<ogra> woah, a million password popups
<ogra> asac, http://paste.ubuntu.com/10491/
<ogra> silent segfault
<asac> ogra: i think its -safe-mode not --safe-mode
<ogra> oh
<ogra> well, it looked quite different and opened the granparadiso startpage
<ogra> (didnt use the stored window size etc)
<ogra> but i can try again
<asac> ogra: how can you reproduce? for me it doesn't crash
<creAtion> any idea when the intrepid web forum will open up?
<ogra> asac, open gmail, go to the spam folder let it sit there for some seconds, close the tab and see ff vanishing with it
<asac> ogra: running -proposed? or intrepid?
<ogra> are you crazy ? i wouldnt run intrepid :)
<ogra> running -proposed
<ogra> http://paste.ubuntu.com/10494/
<ogra> one dash gives a bit more output :)
<ogra> wonders if anyone is really mad enough to run intrepid before UDS :)
<asac> mozillateam folks are all on intrepid already ;)
<asac> not my idea :)
<dholbach> asac: does X run for them? :)
<ogra> wow, thats what i call couraged
<asac> haven't asked that much in depth ... but i think so ;)
<dholbach> it doesn't run in my kvm session
 * ogra wouldnt run intrepid for money
<jussi01> just FYI, we now have intrepid supported by the bot package lookup ;)
<pitti> ogra: why not, it's certainly fun?
<ogra> pitti, i have work to do :)
<emgent> cjwatson: i saw now, if i use requestsync with --lp script give a little output with "Could not find Firefox cookie file
<persia> ogra: Not even enough to purchase a test box?
<emgent> "
<pitti> ogra: in a way, you *do* get money for it :-P
 * pitti hugs ogra
<ogra> pitti, lol, indeed :)
 * ogra hugs pitti 
<emgent> but seems strange, anteater use l-p-b and work fine.
<emgent> (with firefox cookies)
<pitti> actually it's the first release where I did *not* upgrade to the new dev release immediately
<seb128> same for me
<asac> ogra: are you in the SRU team? otherwise you must upgrade now ;)
<ogra> yeah, there is crazy breakage ahead
<soren> ogra: I distinctly remember back in the Edgy days when your machine was broken in so many ways and all you had to say was "Edgy is so much fun". :)
 * pitti hugs seb128, the fix-hardy-harder companion
<seb128> I'm pondering installing it somewhere though
 * seb128 hugs pitti
<soren> ogra: Oh, google remembers, too: http://irclogs.ubuntu.com/2006/07/07/%23ubuntu-devel.txt
<soren> :)
<ogra> asac, oh, u-m didnt tell me yet
<seb128> I think I'll get a vm running it to upload GNOME srus to intreprid too at least
<cjwatson> emgent: ah, right, well that should be easy to fix I guess
<asac> ogra: can you install -dbgsym for xulrunner-1.9 and firefox-3.0 and get a backtrace please?
<cjwatson>     try:
<cjwatson>         cookiefile = glob.glob(os.path.expanduser('~/.mozilla/*/*/cookies.txt'))[0]
<emgent> i will try to paste path ?
<cjwatson>     except IndexError:
<cjwatson>         print >> sys.stderr, 'Could not find Firefox cookie file'
<cjwatson>         return False
<soren> ogra: But of course you were younger back then. Slightly. :)
<cjwatson> aha
<asac> ogra: and try with a fresh profile (keep a backup of the old one in case its that)
<cjwatson> it's cookies.sqlite in firefox 3
<ogra> soren, haha, yeah the old times :)
<cjwatson> emgent: the version of requestsync in ubuntu-dev-tools trunk fixes this
<emgent> ok thanks cjwatson  i will take a look
<cjwatson> bug 208808
<ubottu> Launchpad bug 208808 in ubuntu-dev-tools "requestsync crashed with LPUrlError in _safe_urlopen()" [Medium,Fix committed] https://launchpad.net/bugs/208808
<ogra> asac, btw, nothing ff related in proposed for me ... sadly i cant compare before and after the xulrunner update i got yesterday, i didnt open gmail in this ff at all since the machine was installed until today
<asac> ogra: in -proposed there is a xulrunner-1.9 upgrade
<ogra> asac, yes, got that yesterday
<emgent> true
<cjwatson> asac: FWIW (and it's highly subjective) the I/O problems seem a lot better now
<cjwatson> with that xulrunner-1.9
<asac> cjwatson: comment on bug :)
<cjwatson> will do at some point :)
<asac> cjwatson: bug 215728
<ubottu> Launchpad bug 215728 in xulrunner-1.9 "[MASTER] Committing to urlclassifier3.sqlite causes excessive CPU usage and disk I/O" [High,Fix committed] https://launchpad.net/bugs/215728
<asac> ok, ill try to remember to remember you in a few days.
<cjwatson> ah, never mind, I'll do it now
<asac> thanks
<emgent> cjwatson: http://bazaar.launchpad.net/~ubuntu-whitehat/ubuntu-whitehat-project/uwht.dev/revision/emgent%40emanuele-gentili.com-20080408225722-t2k7o6n8z4ztz43l?start_revid=emgent%40emanuele-gentili.com-20080409012057-5lmtoh9tc6cim8wu#anteater/anteater.py-s
<emgent> i will try to fix with: glob.glob(os.path.expanduser("~/.mozilla/firefox/*/cookies.sqlite")).pop()
<siretart> pitti: if you happen to be working on NEW, I'm happy to answer questions on the ffmpeg-free package if necessary. it replaces the current 'ffmpeg' source package which is in main.
<pitti> siretart: Riddell's archive day today, I'll get to it on Friday
<dholbach> asac: it's bug 226156
<ubottu> Launchpad bug 226156 in xorg "After update in intrepid branch Xorg " [High,Confirmed] https://launchpad.net/bugs/226156
<siretart> pitti: Ah, never mind then
<emgent> cjwatson: solved, now work fine.
<siretart> Riddel: if you happen to be working on NEW, I'm happy to answer questions on the ffmpeg-free package if necessary. it replaces the current 'ffmpeg' source package which is in main. :)
<cjwatson> emgent: excellent
<cjwatson> pitti,evand: does encrypted-filesystems need another session at UDS (for ubiquity support)? it's on my roadmap, but I'm inclined to think it probably doesn't need a session
<asac> dholbach: "branch" == crash?
<ogra> asac, same issue with a fresh profile, installing dbgsym now
<asac> ogra: what kind of spam do you have ;)
<pitti> cjwatson: I agree; the discussion bits are done, it's a "simple" matter of programming now IMHO
<cjwatson> pitti: ok
<cjwatson> I generally try to keep things that didn't get done on the roadmap so that they don't get forgotten about
<dholbach> asac: Xorg does not find fonts with the new libxfont - that's why it bombs out
<ogra> asac, well, there seems to be about over 20000 msgs (as i said i never use the web interface, i only pop my mail into evo from there so i only clean thatup once every decade :) )
<asac> ogra: all on one page?
<ogra> nope
<ogra> default setting (100 per page i think)
<cjwatson> ogra: you added "stripped-down lightweight kernel flavour" to the platform roadmap. Extra kernel flavours generally give me the willies because they increase build time a lot - is this just removing unnecessary modules, or is there more to it?
<ogra> cjwatson, its more about the core image, i was thinking about handling the modules in the initrmfs profiling spec (they somewhat belong together)
<cjwatson> what is in the core image that could be stripped down to improve performance?
<cjwatson> bearing in mind that simply removing features generally only improves size, not performance
<cjwatson> or is performance not what you meant?
<ogra> thats what i want to determine in the process of that spec :)
<cjwatson> I have indeed put modules in the initramfs profiling spec
<ogra> well, ram hunger rather
<cjwatson> ogra: could you discuss this one with BenC? I don't feel it really belongs in platform, but perhaps he has room for it
<ogra> archlinux uses our ltsp implementation using a 2.6.24 kernel as we do, but their kernel manages to boot in 16M
<cjwatson> and can stick you in <person/> on his agenda so that you can be pulled in
<hunger> ogra: Who? me?
<ogra> thats my main pointer here, i'd like to compare our default setup to theirs and whatever else i find booting in such a setup
<ogra> hunger, do you have ram for breakfast usually ? else no, not you ;)
<hunger> ogra: Nope I usually have cornflakes, so not me, great:-)
<ogra> :)
<ogra> cjwatson, that spec would also go hand in hand with the compcache one
<BenC> ogra: Any way you can use MODULES=dep for initramfs on the clients?
<BenC> ogra: or am I missing what you want to do?
<ogra> BenC, my core kernel (before using the intramfs) already needs more than 24M (32M if it should even be able to uncompress the initramfs)
<ogra> BenC, and thats with netboot (i.e. only NIC drivers in the initramfs)
<ogra> BenC, modules=dep is already a good way, but i think that can be improved as well
<ogra> BenC, my focus in that spec is on the kernl image itself and the space it needs to load, independently of the initramfs
<BenC> ogra: Then you are suggesting a custom flavor kernel for ltsp to use?
<ogra> BenC, generally for low ram systems
<BenC> or maybe that we can improve our current -generic config
<ogra> not tsp specific
<ogra> right, either
<BenC> gotcha
<BenC> ogra: sounds like a good spec...can you email me a reminder?
<ogra> it will also be relevant for subnotebooks etc
<ogra> BenC, will do
 * ogra would love to get back to the sizes bootfloppies used to need ...
<pitti> Riddell: https://bugs.edge.launchpad.net/ubuntu/+source/kaffeine/+bug/226475/comments/6 ??
<ubottu> Launchpad bug 226475 in kaffeine "remove dvd code install" [Undecided,Fix released]
<Riddell> pitti: just a jest for the chap who closed the bug
<sivang> mneptok: ping
<Hobbsee> sivang!
<laga> pitti: thanks for your mail regarding the mythbuntu-control-centre SRU. IMHO it's not necessary that the first upload is promoted to -updates, i'd rather see the second one there. or is that against policy?
<mok0> Does anyone here know something about the mesa package?
<mok0> I'd like to know why glw was removed
<mok0> ... which annoys me a great deal since I am looking at source code that needs it
<ogra> mok0, check the changelog, it should tell you
<mok0> ogra: it tells me that it has been removed, not why
<ogra> for sure it does
<mok0> ogra: lesstif?
<ogra> look closer
<mok0> to remove lesstif deps?
<ogra> if it says so
<mok0> ogra: is lesstif deprecated?
 * ogra doesnt do anything with mesa, but knows we write proper changelogs usually .-)
<mok0> I still don't understand the reason for removing a software component that is needed by several programs
<mok0> Unless there's a working replacement, which there isn't in this case
<ogra> very likely because it would pull lesstif into main if it did build dep on it
<mok0> ogra: well, then it should move to universe
<ogra> so you that would lose 3D support all over in ubuntu ?
<StevenK> mesa needs to be in main -- other things in main require it.
<mok0> ... or another source package could build the missing bits
<ogra> StevenK, well, i guess it would be possible to drop it and go back to fvwm2 as default desktop :P
<mok0> Sorry to sound uptight, but I just a wee bit annoyed to get stuck at this point
<ogra> mok0, the optimal solution would be to convince upstream to release it in a separate tarball, then it could build on its own in universe
<StevenK> To be completly honest, this is like the first time I've seen someone actually miss GLw.
<mok0> StevenK: I just googled for it, and there are many people wanting it
<StevenK> I meant on IRC
<pitti> laga: no, it's not against policy, it just makes testing increasingly more difficult
<mok0> Perhaps I am looking at old code, but I don't have a whole lot of motivation to spend days with it
<mok0> I just need to compile this code and get on with it
<azeem> mok0: use Debian?
<azeem> or just locally rebuild the Debian mesa package against Ubuntu
<mok0> azeem: yeah
<mok0> azeem: will be interesting to see what then breaks
<azeem> StevenK: I think I complained once, when one of my packages got stripped of its OpenGL features in Ubuntu
<azeem> never realized this was because of the main/universe split, I assumed some technical/maintainance issues
<mok0> azeem: probably because only very few packages deal with 3D graphics
<StevenK> GL isn't the problem, GLw is.
<mok0> azeem: ... and Ubuntu aims to be a 2D graphics distribution.~
<StevenK> mok0: Sigh.
<mok0> StevenK: Sorry :-)
<StevenK> And I think GLw affects like what, five packages.
<azeem> mok0: eh yes, that was some pretty stupid reasoning here
<azeem> StevenK: there might be tons of legacy code, dunno
<mok0> StevenK: plus an unknown number of tarballs and locally developed software
<ScottK> What it would need is some interested MOTU who would make an appropriate package ...
 * ScottK looks around at who that might be ....
 * mok0 hides
<mok0> :)
 * mok0 sighs
<mok0> This is not the digression I am looking for at the moment
<StevenK> So, you'd like us to demote mesa and re-enable GLw in Hardy?
<StevenK> (Or something)
<Hobbsee> he actually wants to start developing for breezy
<StevenK> Bwahaa.
 * Hobbsee is surprised that this is the first time it's clearly come up where it might get changed in intrepid, since breezy.
 * StevenK still has a breezy chroot around somewhere.
 * Amaranth doesn't even know what GLw is :P
<ogra> Amaranth, it involves brick like button shapes .... (lesstif)
<Amaranth> so an old crappy toolkit using GL
<azeem> it's to embed OpenGL into Motif apps
<azeem> AFAICT
<infinity> Or, rather, allows you to draw Motif widgets on a GL canvas.
<infinity> It's dead code.  Very dead code.
<ogra> probably not on irix :)
<ogra> (which might be dead code itself though :) )
<infinity> IRIX is also dead code at this point.
<mok0> StevenK: No
<mok0> But perhaps create another source package the will build the missing glw  bits
<azeem> mok0: just a warning - the mesa packaging isn't one of the friendliest
<azeem> at least the Debian one, dunno if Ubuntu repackaged it
<StevenK> It's liable to bite limbs off
<Amaranth> mesa is not friendly
<ScottK> From what I've seen, a lot of science packaging is pulling stuff from the mists of time into the modern age.
<azeem> <vorlon> also, is there anyone alive who understands && doesn't hate mesa's debian/rules? * ejka . o O ( you can write fortran program in any language... )
<mok0> azeem: Ubuntu just disabled a few packages AFAICT
<azeem> bah, line break
<ScottK> mok0: You might want to look at how I split amavisd-new into amavisd-new and amavisd-new-milter for an example then.
<mok0> ScottK: ok, thanks for the tip
<mok0> ScottK: yeah, I can see that the orig.tar.gz are identical
<ScottK> The packages are virtually identical.  I just don't build all the .debs in the two packages.
<ScottK> The idea is each is a minimal diff from Debian to build stuff for Universe or Main.
<ScottK> My alternative was to get Sendmail in Main, so split the package I did.
<mok0> ScottK: very smart
<ScottK> slangasek: You touched pinentry last.  I'd be glad to take the merge off your hands unless you want it for some reason?
<asac> tjaalton: if i get something like http://paste.ubuntu.com/10516/ ... what could be the reason? are those codes in the error message meaningful?
<mok0> ScottK: How do you define the inheritance of both amavisd-new and amavisd-new-milter on the same Debian package?
<tjaalton> asac: was that all you got?
<asac> tjaalton: no i also get something about using --sync
<asac> tjaalton: http://paste.ubuntu.com/10517/
<ScottK> mok0: My plan is to remember to to the second when I merge the first.  I've filed a bug against MoM to have it special cased to have MoM look to the one common parent for both.
<asac> tjaalton: funny thing is that its when starting midbrowser ... it works on my desktop though
<mok0> ScottK: In fact, it is a problem that could arise often: splitting a debian multi package into several
<asac> tjaalton: can you install midbrowser package (should be quite small) and see if you get the same when starting it?
<tjaalton> asac: ok I'll try
<ScottK> mok0: Historically stuff has just been dropped, but I wasn't comfortable with that since we'd provided the package for a long time.
<tjaalton> I think the serial* stuff varies
<ScottK> mok0: I agree though.
<mok0> ScottK: It's a bad idea to drop stuff without a working replacement
<asac> tjaalton: for me the serial stuff is always the same (at least in the same X session)
<tjaalton> asac: fails here too.. serial is different, rest is the same
<ScottK> mok0: I agree, but sometimes with limited resources it's the best you can do.
<tjaalton> and to reply the original question, no I don't know where those come from ;)
<mok0> ScottK: that's always a restriction, of course. But if distributions only want to be "self-contained", and forget that people have their own software that also has dependencies, it is a problem
<ScottK> mok0: Fortunately motivated volunteers show up to solve the problem. ;-)
<mok0> :-)
<asac> tjaalton: ok thanks for testing ... intel chip?
<tjaalton> asac: yes. here's another with the same codes: http://fixunix.com/xwindows/90854-received-x-window-system-error.html
<asac> tjaalton: wierd. i guess its compiz then
<asac> i have metacity on the other system
<asac>   gdk_window_set_events (gdk_get_default_root_window (),
<asac>                         (GdkEventMask) (gdk_window_get_events (gdk_get_default_root_window ())
<asac>                                         | GDK_ALL_EVENTS_MASK));
<asac> tjaalton: i dont understand why i cant listen for all events :(
<tjaalton> asac: that's from compiz?
<asac> tjaalton: no from midbrowser
<tjaalton> ah
<asac> we listen mainly for Matchbox Events ... and key events
<asac> tjaalton: maybe if WM doesn't support an event i am listeing for it makes X choke?
<asac> but metacity doesn't have the events either
<kirkland> pitti: hey, i had a few questions about some filesystem encryption work you've done previously, according to kees
<pitti> hi kirkland
<kirkland> pitti: howdy ;-)
<pitti> kirkland: well, personally I did very little, but what's your question?
<tjaalton> asac: hm, mystery
<asac> tjaalton: anyway, thanks for the inof ... at least i have a new pointer now ;)
<tjaalton> asac: cool :)
<kirkland> pitti: we're kicking around intrepid ideas in the server team, and i threw out a suggestion for creating an encrypted mountpoint in each user's home directory, say ~/Confidential using ecryptfs + PAM
<kirkland> pitti: see http://ecryptfs.sourceforge.net/ecryptfs-pam-doc.txt for more detailed instructions
<pitti> kirkland: ah, I think I read about it
<pitti> kirkland: is this per-file or a block device?
<kirkland> pitti: ecryptfs is built in Ubuntu kernels, ecryptfs-utils is presently in universe as of hardy
<kirkland> pitti: per-file/per-mount
<hunger> kirkland: Does that reencrypt on PW-changes?
<kirkland> pitti: it's a vfs
<pitti> ah, cool
<pitti> hunger: well, I hope it has a long random key, and the password just decrypts the key
<pitti> (what LUKS does)
<hunger> pitti: Yes, looks like it does.
<kirkland> pitti: right
<hunger> pitti: Key is stored in a file... not as good as luks does it.
<pitti> kirkland: I'm not too convinced about per-file encryption, but it might be handy in some situation, yes
<lucent> folder-level encryption would be interesting
<kirkland> pitti: ecryptfs was just a suggestion.  i'm open to other encryption technologies
<Caesar> tjaalton: okay, we'll do some testing internally
<kirkland> rather than encrypt everything, i was thinking a per user folder to put your important stuff
<hunger> kirkland: LUKS is better, but I don't see how to include that properly as a per-user setup.
<lucent> kirkland: what I'm really missing in Ubuntu (Desktop really though) is support for file-based luks
<lucent> when I pop in my encrypted USB partition thumbdrive, it works like a champ
<pitti> kirkland: oh, I wasn't criticizing the actual implementation of ecryptfs
<kirkland> pitti: k
<pitti> kirkland: I just prefer to encrypt the entire fs, since it gives away less information and, more importantly, data does not leak to /tmp, swap, backup files, etc.
<lucent> why must it only work for partitions?   is loop in a file too hard?
<tjaalton> Caesar: thanks, I haven't been able to reproduce it here
<pitti> lucent: loop files are a pain to setup by default, since you need to know the size in advance, etc.
<kirkland> pitti: encrypted swap is essential, IMHO, if we start doing encryption by default at all
<lucent> uhm,  swap is not encrypted?
<lucent> my laptop system I use here was installed with alternate CD, and I put LVM-on-luks
<hunger> lucent: I think that is because udev does the luks magic... and having udev check each file as it becomes visible might be a bit expensive.
<pitti> kirkland: I have used an entirely encrypted LVM for half a year on my laptop without problems
<ogra> pitti, nbd loopmounts might help ;)
<kirkland> pitti: but encrypt everything approach wastes a lot of cpu cycles on stuff like /lib, /usr,
<lucent> hunger: ah
<kirkland> pitti: soren said earlier, try doing a massive compilation on an encrypted filesystem
<ogra> pitti, makes every file you like a blockdevice
<hunger> kirkland: Swap and tmp, too. /var/tmp as well.
<pitti> kirkland: true, but in practice it doesn't matter so much IMHO
<soren> pitti: Your laptop must be beefier than mine was.
<pitti> kirkland: I guess it really depends on what your aims are
<Robot101> you have to have swap encrypted if you want encrypted files to be meaningful at all
<tjaalton> how to summon ubotu on a channel?
<lucent> LVM-on-luks works better than I expected
<tjaalton> (ubuntu-x
<tjaalton> )
<pitti> if you just want to protect your office documents and encrypt swap, ecryptfs might be good
<Hobbsee> tjaalton: ask in #ubuntu-ops)
<hunger> kirkland: If you want to do it right, then every user-writeable FS needs to be encrypted.
<Robot101> or you'll just leak data onto your other partitions
<Robot101> including /tmp
<soren> pitti: Most of the time, I got by by logging into my machine at home and compiling kernels on that, but when I was stuck on the outskirts of the internet (i.e. in the US), either option *sucked*.
<pitti> kirkland: but if you are concerned about a lot of differnet things (email, swap files, gpg keys, log files, everything that leaves trails), you quickly loose with that approach
<kirkland> pitti: I use LVM encryption of my whole FS too...  but I don't think the run-of-the-mill Ubuntu user is ready for that.  I'd think a /home/user/Confidential directory might be more palatable
<hunger> Robot101: Right. Every user-writeable FS needs to be encrypted if you want to do it right.
<lucent> kirkland: "LVM encryption"  are you referring to a feature of LVM, or LVM-on-luks PV ?
 * Robot101 LVM's his entire HDD just because in practice, separating system data from mutable data is quite hard, particularly when you upgrade often too
<pitti> kirkland: the problem I see with that is that people might feel protected by that and stop being careful
<soren> lucent: The latter.
<Robot101> LVM on LUKS, rather
<hunger> Robot101: do you have one of those encrypting HDD drives?
<pitti> kirkland: TBH I'd rather do it the other way around: encrypt the entire /home, /, etc., and just put /usr and some other explicit stuff on an unencrypted partition
<lucent> LVM on LUKS works but the PVs must all be encrypted, it's a flawed concept for server space
<pitti> lucent: how do you mean?
 * hunger would like to get one, but unfortunately his laptop is still using PATA for the drives (even though the control itself is SATA already).
<Robot101> hunger: no its software, using LUKS
<lucent> I mean that if you want to expand storage, you'd have to set up another partition with LUKS, and make that a PV
<Robot101> (and dm-crypt)
<lucent> so it means more passwords
<pitti> lucent: you can of course also encrypt the LVs, but by encrypting the PVs you might need fewer passwords
<Robot101> you could stack them... :P
<pitti> lucent: right, if you have 50 PVs and 3 LVs, you'd rather use an unencrypted LVM and encrypted LVs, I guess
<lucent> pitti: it's kind of unclear how to grow encrypted LVs
<hunger> Robot101: Had that setup for a while, too. But LUKS kept on losing the key. Dunno why... got a new drive after the first time.
<kirkland> pitti: so i like the idea of encrypting /root, /etc, /tmp ...  but for /home, I'd think on a per-user basis, and tied to PAM would be preferable
<pitti> lucent: but I do see that this is a problem, yes
<Robot101> hunger: ... ouch!
<pitti> kirkland: libpam-mount and per-user encryption of ~ is great indeed
<hunger> Robot101: I do have backups:-)
<pitti> kirkland: however, you still need a global password for the swap partition (or live without suspend-to-disk)
<kirkland> pitti: ecryptfs has one other nice benefit for homedirs, that you can do incremental backups of the underlying encrypted files
<pitti> yeah
<realist> I only do encrypted swap and home
<kirkland> pitti: i use that for securely storing sensitive data on my co-lo's
<pitti> kirkland: I think the biggest problem with all that is that the requirements of users are all differnet, and thus it is hard to come up with a default schema that suits most people
<realist> Not sure of the benefit in crypting the system files?
<kirkland> pitti: true dat
<pitti> realist: encrypting /usr etc. is indeed a waste
<pitti> realist: but encrypting log files and other stuff in /var isn't
 * realist nods
<pitti> and /etc as well, for obvious reasons
 * wgrant installs a trojan on pitti's machine.
<pitti> (secret SSL and SSH keys, shadow, etc.)
<hunger> pitti: Depends... with encrypted /usr you can make sure nobody messes with those files.
<wgrant> Yep.
<pitti> not really
<lucent> there's two motivations to encryption:  A)  Making it unclear what your data is  B)  preventing read access to unauthorized users
<pitti> encryption is solely an offline protection
<pitti> it does not protect you *at all* from Trojans
<realist> If they crack the live boxes, they still get an unencrypted view of all your filesystems
<pitti> encryption is defence against stealing your (switched off) laptop
<hunger> pitti: Well, when I am online /usr is mounted ro anyway:-)
<pitti> if it's still in suspend-to-ram, or running, you lose
<lucent> pitti: there's legal ramifications to this too
<pitti> lucent: yes, unfortunately
<lucent> I mean to the point where you cannot be pursued because your data is indistinguishable from random data
<wgrant> pitti: Right, but if I grab your laptop while you're away for a bit, I can boot into a live CD and alter some binary in /usr to grab your keys or similar.
 * StevenK is reminded of a netgod quote.
<realist> pitti: suspend to disk also
<pitti> lucent: for people who are concerned about those, you need complete encryption of the entire hard disk, without metadata like LUKS
<lucent> ah yeah
<pitti> then you can plausibly deny the existence of anything; 'just unpartitioned HD space'
<realist> Or a recently powered down laptop (frozen memory hack)
<lucent> I think my point is, which use case are we going for?
<lucent> people encrypting financial saved data
<pitti> lucent: right, my point also
<lucent> or people who are running stuff that's illegal under law
<pitti> i. e. hard to find a default setup which suits everyone
<kirkland> offline protection + protection of remotely stored/backed-up data (see incremental backups to co-lo's)
<pitti> since the encryption goals vs. the price you're willing to pay (convenience, performance) vary
<realist> I only encrypt /home for my gnucash data
<realist> Some keyrings too, but keys can still be revoked
<pitti> kirkland: what would really be great is to offer setups for different use cases (complete encryption, /home encrypted, per-user ~/Confidential, etc.) and the installer would ask you
<pitti> kirkland: then we need to support all of those, of course
<kirkland> pitti: ;-)
<lucent> uh
<pitti> with the alternate installer, you have some flexibility at least
<lucent> if I'm root uid, can I not just su into people's homes and read their Confidential?
<pitti> and per-user ~/Confidential can be set up at post-install time
<pitti> lucent: not if those people aren't logged in
<wgrant> lucent: If they're mounted, yes.
<kirkland> lucent: yes, as pitti said, this is about offline protection of the data
<pitti> lucent: if you use libpam-mount, and ~/Confidential is unlocked at login time (with your password), that's reasonably ok
<kirkland> and by offline, that can mean "if the user isn't online, logged in"
<pitti> lucent: of course root can just install a daemon which just waits
<lucent> root will...  oh okay  it will have normal root rights
<pitti> and as soon as he logs in, copies it over to somewhere else
<lucent> but it won't be able to unlock the store
<pitti> lucent: eventually root will
<pitti> root controls the hardware, user's don't, so there is nothing that users can do to defend against root powers when they are online
<pitti> s/user's/users/
<Caesar> tjaalton: it's very difficult to reproduce
<wgrant> Our root can lie in wait and catch the user's passphrase, and unlock the volume at their leisure.
<lucent> IMO "encryption" should be handled much the same way "root uid" access via sudo is
<lucent> you'd do like, ideally,  crypdo
<kirkland> pitti: however, i don't have root on my remote backup system...  i rsync the encrypted underlying fs, and I have no concern about that root reading anything of mine
<lucent> enter password,
<lucent> now have access
<lucent> and it times out
<kirkland> it's as secure as a few thousand gpg files
<pitti> kirkland: right, on the backup server your stuff is safe
<tjaalton> Caesar: ah, ok.. I remember there was someone who said he could reproduce it always
<kirkland> pitti: right, just emphasizing that use case
<pitti> kirkland: right, my co-lo server provider also offers 10 GB on a central FTP backup server; I just pipe the backup tarball through gpg -e and ftp that
<kirkland> pitti: whole tarball everytime, or are you able to do it somewhat incrementally?
<pitti> kirkland: I have a pretty simple system (weekly complete plus daily incremental)
<pitti> kirkland: it's not actually a tarball, it's an afio archive
<pitti> kirkland: that's still my ancient backup solution
<kirkland> pitti: heh, if it works :-)
<pitti> at home I am now using rsnapshot, that works less conveniently with gpg
<pitti> kirkland: it does, that's why I don't bother to change it :)
<pitti> (it's just the /etc/.bzr, the psql dump, and some wiki data, a mere 25 MB compressed)
<kirkland> pitti: hmm, so that's more "system" type data, than "user" type data...  which leads us back to your suggestion that defining particular use scenarios in the installer
<lucent> Hardy ships AFAIK with a pretty useless combination of Server choice for encryption
<pitti> kirkland: maybe we should do that step by step
<kirkland> pitti: okay, well thanks for the feedback.  sounds like this is a bigger beast than i might have initially thought
<lucent> no encrypted swap I think
<kirkland> pitti: i'm all for doing this incrementally
<pitti> kirkland: we have supported by-block-device with LUKS for two releases, so we can additionally support one technology for per-file (such as ecryptfs)
<kirkland> pitti: encrypted swap is a great start
<pitti> kirkland: so we should provide some integration bits to setup such a thing post-install (ecryptfs)
<kirkland> pitti: good to hear you're open to this then....  ;-)
<pitti> like a GUI to do it, and think about sane key handling, as well as getting the pam-mount bits right
<ogra> encrypted swap would become difficult with hibernating i think
<pitti> kirkland: oh, I am (I love encryption)
<pitti> kirkland: my pain starts when we'd want to set it up by default
<wgrant> ogra: Works fine as long as you don't use a random key.
<ogra> (at least it forces twp PW prompts)
<ogra> *two
<wgrant> Not if all volumes are on one encrypted PV.
<kirkland> pitti: so, like i said, the kernel part is already built into Ubuntu kernels (have been for some time)
<pitti> our default LUKS setup doesn't require two keys
<kirkland> pitti: ecryptfs-utils would need to be promoted from universe -> main
<lucent> I think, that pain is avoided when having LVM on LUKS
<kirkland> pitti: and the pam-mount bits, as you said
<ogra> pitti, well, you would have to give a pw for resume to read from swap, no ?
<pitti> kirkland: MIR doesn't scare me
<ogra> plus the pw we ask for anyway from gnome-screensaver
<lucent> LVM on LUKS hibernate works for me here
<realist> encrypted swap (using random key) should be the default
<pitti> ogra: right, you just need one password to decrypt the entire LVM (which includes swap)
<pitti> realist: no, that breaks suspend-to-ram
<pitti> realist: erm, to-disk
<realist> pitti: make the two mutually exclusive?
<pitti> realist: it might not be a concern on servers, but it sucks on laptops, and many desktops, too
<pitti> realist: then you'd suspend to disk in an unencrypted way, there goes your data security
<lucent> realist: what sucks on laptops?
<cjwatson> kees: just to check, you guys are aware of bug 227322 (or at any rate the CVE behind it), aren't you?
<ubottu> Launchpad bug 227322 in openssh "[openssh] [CVE-2008-1657] possibility to bypass global "ForceCommand" directive" [Undecided,Fix released] https://launchpad.net/bugs/227322
 * kirkland points cjwatson to jdstrand (kees doesn't appear online yet)
<jdstrand> cjwatson: yes
<cjwatson> jdstrand: ^--
<cjwatson> aha
<lucent> oh I goofed the nickname hilight
<lucent> pitti: what sucks on laptops?
<lucent> I'm using LVM on LUKS for a laptop, it's been fine, I think?
<jdstrand> cjwatson: it's funny, I *just* looked at it a couple minutes ago :)
<kirkland> pitti: you have anything regarding encryption on tap at UDS?
<cjwatson> jdstrand: I get desktop notifications of new bugs coming in now, so if I happen to be online at the time, I notice pretty quickly
<pitti> kirkland: not ATM, no
<kirkland> pitti: we've discussed it a little on the Server team, but realize that we probably need to involve the platform and desktop folks too...
<pitti> kirkland: incidentally, cjwatson just asked me this morning whether there was anything further to discuss
<pitti> kirkland: I said no for the ubiquity bits
<jdstrand> cjwatson: oh yeah, that irssi thingy I saw you posted-- is it working out well? (I use irssi too)
<cjwatson> jdstrand: yeah, it's really good
<pitti> kirkland: and frankly I think that "encrypted LVM" and "manual partitioning" are the only sane fs encryption bits that we can put into the installer
<jdstrand> I need to check it out
<azeem> what irssi thing?
<pitti> kirkland: but I'd like to discuss the ecryptfs stuff further if you want
<StevenK> azeem: I was about to say that
<cjwatson> azeem: http://people.ubuntu.com/~cjwatson/notifications/
<kirkland> pitti: you bet ;-)
<cjwatson> no instructions on that page (I'll put them up at some point) - you need the fnotify irssi script as well
<cjwatson> but with that you can have desktop notifications of people addressing you on IRC, even if you use irssi on a different machine via ssh and screen
<pitti> kirkland: can we combine it with thinkfinger? my left index finger is my real system, my right index finger unlocks a virgin and dull standard Ubuntu instlalation, for presenting at the customs? :-P
<Hobbsee> cjwatson: irssinotifier is good, too
<cjwatson> (it's not original, I modified stuff I found on the web to make it work better)
<azeem> oh that's awesome
<jdstrand> cjwatson: oh excellent-- that is my configuration
<kirkland> pitti: :-D
<Robot101> cjwatson: *rad* :)
<azeem> now I just wished it worked on oldstable - I'm trapped with sarge at the uni
<realist> pitti: they actually ask you to boot up your laptop?
<StevenK> realist: I've had Singapore customs ask me to
<cjwatson> Hobbsee: cool, though I haven't quite figured it out from that page - how does that get the notifications back to your desktop?
<pitti> realist: not so far
<StevenK> All that did was annoy me, and presumably, everyone behind me.
<ogra> pitti, ++ for thinkfinger support (my new lappie has that too, sadly the yet unsupported device)
<realist> wow, next they'll be asking you to take your shoes off!?
<StevenK> realist: The US already does
<cjwatson> Hobbsee: I quite like mine since I can really easily piggyback other things on top of it, like notification of new LP bugs via procmail
<pitti> ogra: Keybuk hacked that in for hardy
<Hobbsee> realist: i had that.  in every airport i went through.
<realist> I've never been asked to boot mine.
<Hobbsee> and was frisked in almost all of them.
<azeem> cjwatson: hrm, that only works if you can directly ssh to your desktop, right?
<Hobbsee> (the shoes, not the laptop)
<ScottK> US customs explicitly claims a right to take an image of any digital media moving through customs.
<ogra> pitti, he wrote a driver ?
<kirkland> pitti: what about a package, that requires ecryptfs-utils, pam-mount, etc. and does the setup for you?
 * ScottK doesn't plan to bring his secret key to UDS.
<cjwatson> azeem: no, mine is the other way round, you initiate the ssh connection *from* your desktop and it pulls notifications
<ogra> pitti, my device ID is yet unsupported by the driver
<lucent> realist: United States plane goers walk shoeless through the security checkpoints
<pitti> ogra: no, thinkfinger has been there for a long time; I have used it for a while, too
<azeem> cjwatson: ah, didn't get that bit, that's gold
<realist> ScottK: they can take a copy of my encrypted partition then.
<pitti> ogra: he just fixed some integration bits
<StevenK> realist: Last time I flew to the States, it was. "Laptop out. pockets empty" for Australia, and it's "Jacket off, shoes off, laptop out, pockets empty, belt off" for the States
<cjwatson> azeem: I'll htmlify my instructions for it in a bit
<lucent> yeah
<lucent> StevenK: but you can have 7 inch knitting needles
<Hobbsee> cjwatson: ssh tunnel and the notify stuff, i think.
<lucent> go figure
<StevenK> I didn't try that.
<Hobbsee> cjwatson: i didn't check it out too much, as i then switched across to bip.
<Hobbsee> (meaning that i rarely used irssi)
<StevenK> I didn't want to be in prison for UDS.
<StevenK> :-P
<cjwatson> the only slightly irritating bit is that you get notifications even if you're watching the channel
<lucent> StevenK: my auntie likes to knit on the plane
<Caesar> tjaalton: yeah we've got users internally who can reproduce it reasonably reliably, but it's never affected me personally for example
<lucent> they made her throw out a paperback book because it was not "appropriate"
<StevenK> lucent: I've heard about US Customs snapping knitting needles.
<ogra> pitti, well, according to upstream "its being worked on to get that devies into the driver as well" last time i looked
<lucent> but she was cleared to bring her knitting needles
<lucent> ha, no customs for her
<lucent> that's a different kind of personal abuse
<kirkland> yeah, my wife brought knitting needles on the plane, and they seized my 3" screwdriver
 * lucent laughs
<lucent> that's exactly true
<lucent> some stupid country I live in
<lucent> sorry to herd this off-topic
<lucent> I just wanted to confirm the shoe thing is true
<lucent> I was waved through with a 5lb snowboard iron
<lucent> of all the things that could be a lethal weapon, my shoes definitely are not
<lucent> that iron was.
<lucent> it sounds silly but that is how it goes, I checked my laptop through a few times and the worst that's happened is some fat woman or man sprinkles dust on the top and pretends to look concerned about your safety
<hunger> When I went to the UK last they even took the time to vacuum clean my laptop at the custom area. That is service!
<lucent> hunger: vacuum it...with drug-snorting dogs?
<wgrant> They have these great bomb-detecting vacuum cleanerish things.
<hunger> wgrant: Whatever the reason... it did clean my keyboard pretty nicely.
<wgrant> Heh.
<hunger> wgrant: The guy didn't like being asked to vacuum around the screen once more though:-(
<wgrant> Not surprising.
<jcwinnie> Help! Ubuntu. Help! Wubi has fallen down the well again.
<StevenK> Okay then
<soren> pitti: xgettext seriously doesn't scan for _("foo")? Only _('foo')?
<pitti> soren: the quotes don't matter, of course
<pitti> soren: but not _(var)
 * soren exhales, relieved.
 * pitti apologizes for his inconsistent quote style in the bug reply
<pitti> soren: in python I generally prefer ', since it doesn't need shift
<ogra> pitti, depends on your keymap, really
 * ogra needs shift here on a german keymap
<ogra> oh, sorry i just noticed i have the ' key twice ....
 * ogra shuts up
<soren> pitti: So, how does this work, then? print _("foo %s") % bar ?  print _("foo %s" % bar) ? Something else?
<cjwatson> _("foo %s") % bar
<soren> cjwatson: Thanks.
<cjwatson> the translatable thing needs to be (roughly) a constant string and translators are expected to do sensible things with format string markup inside
<tjaalton> is archive.u.c having some issues? I get hash sum mismatches
<ogra> its slow at least
<tjaalton> it is that
<tjaalton> is there a place to sync a mirror from
<ogra> i just switched to the de mirror here for chroot building, that helps
<lucent> _("foo") + bar
<lucent> heh
<soren> tjaalton: It's horribly slow, and I keep getting checksum errors and shit, too.
<tjaalton> soren: ok, I'll change to another mirror then
<soren> tjaalton: apt-cacher was acting up at the same time, so I blamed that.
<azeem> cjwatson: it shouldn't fire for highlights in the current chan/window, IMO
<pitti> soren: btw, if you fix the _() thing, please reupload with the same version number
<pitti> soren: otherwise -changes@ and my SRU watch pages will just get the _() update changelog, and not the original one
<cjwatson> azeem: yeah, I'm sure that's fixable in irssi/fnotify, just haven't spent time figuring it out
<soren> pitti: Already done.
<soren> pitti: ~5 minutes ago, so it should be in your queue now.
<pitti> soren: great, thanks
<ogra> could https://wiki.ubuntu.com/SecurityUpdateProcedures be linked from the development wikipages ? it took me quite a while to find it by searchig
* ubottu changed the topic of #ubuntu-devel to: 06 May 21:00 UTC: Community Council | 07 May 21:00 UTC: Server Team | 08 May 13:00 UTC: Desktop Team | 09 May 04:00 UTC: MOTU | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team
<tjaalton> whoops? :)
* Hobbsee changed the topic of #ubuntu-devel to: Archive: Intrepid open, go wild! | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Hobbsee> nice work.  that would have changed all channel topics that weren't locked
<Hobbsee> until it crashed, anyway
<realist> cjwatson: is there anything special I need in order for fnotify to work?
<cjwatson> realist: I have proper instructions on http://www.chiark.greenend.org.uk/~cjwatson/code/notifications/ now
<tjaalton> hmh, apt-mirror refuses to work with !a.u.c
<psusi> bdmurray: my ubuntu-bugcontrol membership is about to expire, could you renew it please?
<tjaalton> Hobbsee: changed the topic on #u-x again
<realist> cjwatson: it doesn't appear to be writing out to ~/.irssi/fnotify for some reason
<Hobbsee> tjaalton: i don't have control, i'm just watching -ops
<tjaalton> darn
<cjwatson> realist: dunno about that, sorry, it just worked for me
<cjwatson> realist: you may need to explicitly /hilight things you care about
<Hobbsee> tjaalton: i've been staying quite deliberately away from it
<tjaalton> Hobbsee: :)
<realist> cjwatson: not even working for privmsg :-(
<ogra> seb128, do you think david will put any more time into gnome bug 526320 ? he doesnt sound like he would
<seb128> ogra: no, you want the change backported right?
<ubottu> Gnome bug 526320 in gio "should not list mounts that the user doesn't have permission to use" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=526320
<seb128> ogra: it's on my todolist
<ogra> i have lots of ltsp users complaining, yes
<ogra> wow, ubottu is slooow :)
<ogra> seb128, ok, thanks, but he doesnt seem to really care which is really sad imho
<seb128> ogra: not really true, he's usually responsive but I think he has lot of other issues on his plates already and there is no obvious way to get that one work better easily
<ogra> yeah, fedora is nearing the release, i understand he's busy
<emgent> dholbach: thanks for ACKs, sympa fixed and ready when you have time. :)
<Hobbsee> ogra: they're trying to fix the meeting stuff
<ogra> meeting stuff ?
<jdavies> ogra: the automatic topic update in #u-meeting
<dholbach> emgent: I guess I'll get to it tomorrow if nobody else does before - thanks
<emgent> thanks to you dholbach
<ogra> Hobbsee, ah, youre referring to my bot comment ... took a while to make click :)
<Hobbsee> ogra: yes :)
<azeem> cjwatson: ok, took me one irssi segfault, but here it is: http://paste.debian.net/2301/
<azeem> doesn't notify for current chan anymore
 * cjwatson applies the same to priv_msg
<azeem> good point
<cjwatson> azeem: looks good, I think
<cjwatson> azeem: updated http://www.chiark.greenend.org.uk/~cjwatson/code/notifications/fnotify, thanks
<LaserJock> azeem: is there a reason you're going nuts in #debichem? :-)
<Savago> @all: it seems that Hardy has some problems with Bluetooth services (# 148712 and others).
<Savago> Is anyone actively working on this?
 * Savago wants to help if possible.
<azeem> LaserJock: euh
<azeem> LaserJock: well, see above, I was testing cjwatson's fnotify script
<azeem> I totally thought I was alone with CIA in there
<LaserJock> azeem: no problem, just wondered if you were having mental problems and started talking to yourself ;-)
<azeem> cjwatson: I've now modified it further to only notify if I'm away (which means screen detached when using screen_away), but this is probably not everybody's facourite
<cjwatson> yeah, I don't use that ...
<cjwatson> though I sort of like the idea, not sure
<realist> cjwatson: I found the bug in fnotify
<slangasek> ScottK: I have no attachment to pinentry, feel free to take the merge
<ScottK> slangasek: OK.  Will do.
<Keybuk> asac: is network-manager-applet supposed to be missing a build-dep on libnotify-dev?
<ScottK> Is CDBS generally broken right now or is my upload special?
<ScottK> http://launchpadlibrarian.net/14261790/buildlog_ubuntu-intrepid-i386.pinentry_0.7.5-2ubuntu1_FAILEDTOBUILD.txt.gz
<norsetto> scottk: is that inttool?
<ScottK> Yes
<norsetto> scottk: its broken right now
<ScottK> norsetto: Thanks.
<norsetto> ScottK: np
<mario_limonciell> mvo_, ping
<mvo_> hello mario_limonciell
<mario_limonciell> hi mvo_ .  i was speaking to Amaranth about a fix for bug 160264
<ubottu> Launchpad bug 160264 in dell "[nvidia] compiz displays white screen when locked" [High,Confirmed] https://launchpad.net/bugs/160264
<mario_limonciell> and he had said to bring it up to you so it can get into intrepid before going the SRU route on it
<mvo_> mario_limonciell: intrepid is in a bit too much flux
<mvo_> mario_limonciell: if it needs testing I think the compiz ppa is a good candidate
<mvo_> mario_limonciell: but we can sru it directly if the patch is reasonable small (let me check)
<mario_limonciell> yeah its very small
<mario_limonciell> i've attached a debdiff to the bug
<mvo_> mario_limonciell: hm, it just drops 30_fix_screensaver ? is that 100% sure that the xserver is now fixed ? otherwise we open a huge security hole
<mario_limonciell> mvo_, yes
<mario_limonciell> i linked the rationale
<mario_limonciell> in my comment
<mvo_> mario_limonciell: yeah, I have seen the changelog - I will give it a test run tomorrow morning, ok?
<mario_limonciell> but widespread testing will of course be necessary per the SRU
<mario_limonciell> mvo_, sure
<mario_limonciell> i've also built it on my PPA if you want to save yourself a test build
<mvo_> mario_limonciell: nice, thanks
<mario_limonciell> no prob
<stgraber> Who's ubottu's owner ? We would like it on #ubuntu-testing, we are really missing ubotu there :)
<dsas> stgraber:  You need to speak to seveas
<_MMA_> stgraber: #ubuntu-ops might be able to help.
<stgraber> _MMA_: right
<hmuller> I'm looking for a pointer to information that explains the purpose of "build-stamp" in a makefile.  I've searched both the manpage and manual, and googled.
<LaserJock> hmuller: I believe it is to make sure that the build only happens once
#ubuntu-devel 2008-05-07
<hmuller> LaserJock: thanks, does make check for build-stamp, or is it gcc?
<blueyed> hmuller: make does so. The stamp file gets used as intermediate build target.
<hmuller> blueyed: thanks, I see I have to understand the inner workings of make, much more than I do now
<xerohg> btw
<xerohg> hi
<xerohg> i just wanted to say great work
<xerohg> ubuntu is just fucking neat, ease of use
<xerohg> thats just for the developers, not every other dick in here
<xerohg> good day
<fta> anyone having issues with cvs on intrepid ? it goes crazy sucking all my 4G of memory in a few seconds, dumping tons of "*** %n in writable segment detected ***" before it crashes
<fta> 100% reproducible
<ogra> fta, i doubt anyone uses intrepid ....
<ogra> not even ubuntu devs would yet
<fta> i guess some devs have at least a chroot
<ogra> i have one, yes
<ogra> but we usually use bzr for merging
<fta> could you please try something for me ?
<ogra> if libc6 isw installable again i can
<ogra> my current chroot is broken today
<fta> install mozilla-devscripts then try: make -f /usr/share/mozilla-devscripts/firefox-3.0.mk get-orig-source DEBIAN_DATE=20080506t1400
<fta> oh, i don't have any libc6 issue here
<ogra> give it 5 mins to rebuild, libc6 was broken today and trashed mine
<ogra> W: Failure trying to run: chroot /home/ogra/Devel/chroots/intrepid dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10ubuntu3_i386.deb
<ogra> meh
<ogra> still broken
<ogra> sorry, you need to find someone who didnt upgrade his chroot today i guess
 * gnomefreak uses it ;)
<ogra> fta, its very likely you are using the hardy cvs still there were no merges yet for it
<fta> it's a sync from debian, i've even rebuilt it on intrepid, all the same
<gnomefreak> fta: have you tried rebuilding -9 for intrepid see if it fixes it?
<ogra> a egre you did manually?
<ogra> *merge
 * gnomefreak not sure fta did the merge
<ogra> i dont think the autosync is running yet and cvs isnt on the merge list
<fta> autosync has been running for a few days now
 * ogra womders where the mails for that go then ... 
<fta> have a look, there's still plenty in the queue: https://edge.launchpad.net/+builds
<fta> http://merges.ubuntu.com/main-trend.png
<ogra> hmm, i used to get derscher mails for that before
<ogra> *drescher
<ogra> anyway, i did my obligatory one merge already (to feel like i started) and like most others in the distro team wont touch intrepid before UDS much anyway ....
<ogra> we're all focused on hardy SRUs so intrepid might be a shaky ride
<blueyed> It would be nice, if hardy-proposed packages get build with higher prio then intrepid packages. virtualbox-ose-modules is sitting for 18 hours in the queue and its estimated build date is in 23 hours..!
<nxvl> jcastro: around?
<ogra> blueyed, poke infinity, he can probably do something about it (given that many of us use vbox on hardy for testing)
<blueyed> infinity: ^^
<jjt009> hey guys i just have a general question here
<jjt009> i'm working on cheese (gnome project), and i need to save data when cheese opens so that if the user tries to open another instance of cheese, the second instance can figure out that another one is already running and shut down
<jjt009> how and where should i save this data
<jjt009> i know a few methods, but i was looking for the conventional way to do this
<jjt009> any kind of shared memory scheme in linux accessible by multiple, unconnected processes?
<_MMA_> jjt009: Might be a little late for now. But hang out. Might get someone.
<johanbr> jjt009: http://live.gnome.org/LibUnique
<jjt009> _MMA_: late?
<jjt009> _MMA_: where do you live?
<jjt009> johanbr: thanks man
<_MMA_> jjt009: East-coast of the states. After 9pm atm.
<jjt009> johanbr: ah, beautiful man...just what i was looking for
<jjt009> _MMA_: yeah, i'm in california
<Amaranth> jjt009: #gnome-hackers on gimpnet isn't helpful for such things?
<jjt009> Amaranth: i was blocked from the channel
<jjt009> for some unspecified reason
<Amaranth> You're a GNOME developer and can't get into #gnome-hackers?
<jjt009> yeah, i use channels like gnome-love and gtk+
<Amaranth> Oh, you're not the main developer :p
<jjt009> i just got banned, so i'll be talking to some guys to see if they can unban me
<jjt009> Amaranth: of course not, then i'd be the one banning other people
<Amaranth> No, not really
<jjt009> i'd probably be an op
<Amaranth> I 'own' a module in GNOME and can't ban people
<jjt009> oh, i see what you're saying...main developer for a certain project
<jjt009> right
<jjt009> which one?
<Amaranth> alacarte
<Amaranth> it sucks, i know
<jjt009> let me check it out
<jjt009> that looks pretty cool
<jjt009> what are you talking about? it's part of the freaking release
<Amaranth> lots of bugs
<jjt009> it can't suck if it's included standard in gnome
<Amaranth> because the menu system has a million and three edge cases and no one follows it completely
<jjt009> are you travis watkins?
<Amaranth> yeah
<jjt009> cool
<jjt009> you have your own wikipedia article
<jjt009> nice
<Amaranth> heh
<jjt009> did you make that?
<Amaranth> nope, just added my birthday
<jjt009> cool
<jjt009> when did you start working on open source?
<Amaranth> don't remember
<jjt009> younger than 15?
<jjt009> alright man, got to go
<jjt009> nice talking to you
<jcastro> nxvl: around now
<LaserJock> phew, just got done putting new brakes on my car
<LaserJock> sometimes you realize why people get paid to do this :-)
 * ajmitch is glad that he's not in any city near LaserJock :)
<Treenaks> LaserJock: This is how people feel when you fix their computer :)
<LaserJock> it took me over 3 hours to do the brakes and rotate the tires
<LaserJock> put a new starter in over the weekend
<LaserJock> this car was doing great and then all of a sudden I've had to do a ton of work on it
<Treenaks> LaserJock: blame the moving parts
<tonyyarusso> LaserJock: I know the feeling - most I've managed is replacing a thermostat, and that took most of a morning.
<LaserJock> my dad and older brother are mechanics
<Amaranth> LaserJock: ABS?
<LaserJock> I think they laugh at me
<tonyyarusso> Amaranth: psssh, who needs such things?
<LaserJock> Amaranth: yeah
<tonyyarusso> </sarcasm>
<LaserJock> I think so
<Amaranth> yeah, i don't touch those
 * tonyyarusso doesn't have ABS _or_ airbags...
<Treenaks> Both my brothers take their motorcycles apart almost every weekend
<Treenaks> replacing parts all over the place
<tonyyarusso> I can however strip your bicycle down to bare frame and rebuild it.  Get paid for that.
<LaserJock> I'm the one that went into the academic world to study Chemistry
<LaserJock> but I think I can do alright
<LaserJock> I've done a fuel pump, 2 alternators, starter, and now brakes
<LaserJock> there's something motivating in being too broke to pay somebody else to do it :-)
<ajmitch> ah, the life of a student
<Treenaks> LaserJock: I'm going to cycle 1200km around the Netherlands next month.. that's a good incentive to learn how to fix your bike ;)
<LaserJock> Treenaks: very much so
<LaserJock> ajmitch: yeah, been doing it a decade and getting tired of it
<Amaranth> i've done a bunch of work on cars but all on older rear wheel drive ones
<Amaranth> now they've gotten all advanced and weird
<LaserJock> I have a 2000 Jimmy and a 1994 Safari
<LaserJock> I'd rather work on the Jimmy usually
<LaserJock> some of the new-fangled stuff is a pain
<LaserJock> I wonder what kind of proc it's got in there
<Amaranth> arm? :)
<tonyyarusso> I think my camera is arm-based.
<RAOF> I've only ever pulled cars apart, never fixed em.
<nxvl> jcastro: did you see my mails?
<Amaranth> does it run linux?
<Treenaks> Amaranth: my _tv_ comes with a GPL source offer and a notice that it runs Linux 2.6.*, Nanox and busybox
<Treenaks> (yay LG)
<Amaranth> cool
<tonyyarusso> Amaranth: the camera?  No idea.  Canon.
<dholbach> good morning
<nxvl> :D
<dholbach> hi nxvl
<pitti> Good morning
<LaserJock> hmm, did Germany change timezones?
<LaserJock> seems like you guys are up awfully early
<StevenK> pitti is an early bird ...
<StevenK> I should know, I was his roomie for Boston UDS
<pitti> why early? I got up at 7, it's 7:40 now
 * TheMuso usually gets up at 6:30 and walks, and is at the computer by about 8.
<LaserJock> hmm, it's only 22:40 here
 * TheMuso is very much a morning person.
<LaserJock> uggg
<LaserJock> I very much am not
<LaserJock> I kinda roll out of bed at 9am
<StevenK> I roll out of bed at 10am if I'm lucky
<LaserJock> usually at work before noon
 * StevenK has a 15 second commute, though
<LaserJock> mine is about 1/2 hour between driving and walking
<Treenaks> 45 minutes.. but I'm at the computer in 10 seconds after I wake up at 6 ;)
<Treenaks> Eee++, UMTS++
<Mithrandir> hi Treenaks, been a while.
<tonyyarusso> LaserJock: I'm lucky if I manage 9.
<tonyyarusso> (It's 01:00 here right now)
<pitti> asac: bug 215728 status looks good; I'll wait for your answer to the last comment, then we can copy this if it's not a problem
<ubottu> Launchpad bug 215728 in xulrunner-1.9 "[MASTER] Committing to urlclassifier3.sqlite causes excessive CPU usage and disk I/O" [High,Fix committed] https://launchpad.net/bugs/215728
<cjwatson> ugh, autosync is unhappy today
 * cjwatson blacklists the second contrib package
<StevenK> cjwatson: Which package did the autosync fall out of love with?
<cjwatson> aterm and aufs so far; I haven't investigated
<asac> morning pitti ... ill look after the meeting
<pitti> asac: thanks
 * calc heads off to bed
<stgraber> moin
<asac> pitti: commented
<pitti> asac: thanks
<cjwatson> note to self: 'sync-source.py -a contrib' produces much more confusing output than 'sync-source.py -a -C contrib', especially when you just ran 'sync-source.py -a'
<cjwatson> the result of the former is to try to sync all of main again and then produce exceedingly confusing DB conflict errors
<cjwatson> (so false alarm on aterm and aufs)
<Mithrandir> I was slightly confused as to why aterm and aufs would be in contrib.
<cjwatson> I have ceased to be surprised by component mappings, which is perhaps a problem ...
<ogra> is anyone able to build an intrepid chroot atm ?
<ogra> W: Failure trying to run: chroot /home/ogra/Devel/chroots/intrepid dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10ubuntu3_i386.deb
<ogra> is there a workaround ?
<mvo> ogra: that one is known since a couple of days, inherited from debian iirc
<ogra> meh
<ogra> hard to testbuild merges ....
<cjwatson> ogra: no workaround as yet, a Debian NMU is forthcoming and we'll sync that as soon as it's available
<ogra> yay, movement at least :)
<ogra> (i already had an intrepid chroot, but trashed it while playing ... :/ )
<cjwatson> create a hardy chroot and upgrade it as far as possible
<ogra> indeed ...
 * ogra isnt awake yet ...
 * LaserJock slaps ogra around a bit to wake him up
<ogra> hey !
<ogra> LaserJock, i think i'll rather take a nap  later :) 5h is not enough ...
<ogra> but the CC meeting was so intresting i couldnt resist last night
<ogra> (and i didnt attend one for ages)
 * ogra wonders how that apt bug ended up on ubuntu-users https://lists.ubuntu.com/archives/ubuntu-users/2008-May/145399.html ... she is clearly using debian sid 
<ogra> hum, but apt with ubuntu versioning
<StevenK> And libc6 looks like the Dapper version
<ogra> weird mix
<StevenK> ramdison agrees with me.
<StevenK> What makes you think it's sid?
<ogra> -- System Information:
<ogra> Debian Release: testing/unstable
<ogra> or is that hardcoded in reportbug ?
<StevenK> /etc/debian_version says testing/unstable on my Dapper server
<ogra> the kernel looked wrid too until i noticed dapper
<ogra> *weird
<StevenK> reportbug always reads /etc/debian_version
<ogra> ah
<StevenK> So it isn't Debian at all :-)
<\sh> hmm..does anybody has problems using debmirror and complaining about a bad signature? (mirroring from a.u.c.?)
<\sh> (for all releases that is?)
<ogra> heh, yeah, i *really* should go back to bed ... oh man
<pitti> soren: why does the virt-manager SRU upload remove src/graphWidgets/pysparklinemodule.defs and help/virt-manager/C/virt-manager-C.omf.out?
<pitti> soren: are these just temporary byproducts from the build, and the hardy final package was unclean?
<pitti> soren: it also drops debian/patches/connection.py.patch without documenting it in the changelog
<pitti> soren: oh, it was renamed, nevermind
<Mithrandir> sigh, is it just for me that security.u.c is very, very slow?
<StevenK> Mithrandir: Nope. Took it 30 seconds to return a 404
<Mithrandir> oh, ooo vulnerability.  That explains it.
<soren> pitti: They're just noise, that I apparantly didn't clean up properly in the final hardy build.
<soren> pitti: I suppose I can shove them back in, if that makes you more comfortable?
<pitti> soren: nah, that's fine
 * Hobbsee waves
 * pitti throws a gummybear at Hobbsee
 * Hobbsee throws it back
<Hobbsee> pitti: after reading that CC meeting, i'll need chocolate, thanks!
 * Mithrandir grabs it and eats it
<soren> Aw... I really wanted that.
 * pitti throws candy to soren
 * soren loves gummy bears
 * pitti too
<seb128> hello Hobbsee
<pitti> argh, none of my intrepid uploads build, they all fail on intltool
<Hobbsee> hey seb128!
 * pitti hugs Monsieur GNOME
 * seb128 hugs pitti
 * Hobbsee finds some more gummy bears, and throws some to Mithrandir and soren
<Mithrandir> yum, yum
 * Mithrandir eyes them warily, in case they are poisoned
<seb128> I was going to ask if it's normal than hardy updates are not installable using "upgrade" (ie, needs to use the dist-upgrader in update-manager)
<seb128> but that's another "dbgsym are not available for the updates" case
<soren> pitti: I just got a reject mail for virt-manager.. What gives?
<pitti> soren: that was the old upload you did
<pitti> soren: I'll look at the recent one
<soren> pitti: Oh, ok then :)
<Hobbsee> Mithrandir: no, i don't feel like poisoning you.
<Mithrandir> mvo: what's the rationale for the update-manager using more rather than a sensible pager?
<mvo> Mithrandir: probably a oversight, I'm happy to fix that
<Mithrandir> mvo: want a bug?
<mvo> Mithrandir: I can change it now, that should be quick - sensible-pager, pager, more will be tried then, does that sounds good?
<Mithrandir> mvo: sounds fine, though if sensible-pager fails, pager shouldn't work either.
<soren> mvo: $PAGER?
<Mithrandir> soren: handled by sensible-pager
<soren> If present..
<Mithrandir> # dpkg -S /usr/bin/sensible-pager
<Mithrandir> debianutils: /usr/bin/sensible-pager
<soren> Oh, it's required.
 * soren crawls back under his rock
 * Mithrandir ruffles the little rock
<soren> Mithrandir: Mean!
<Mithrandir> ruffling the rock?
<Mithrandir> I didn't stomp on it!
<StevenK> ... Yet
<mvo> Mithrandir: commited
<Mithrandir> thanks!
<thom> i'm sure ruffling the rock must be euphemistic
 * Hobbsee beats thom
<Hobbsee> is there any more chocolate?  or a very large drink?
 * Mithrandir gives Hobbsee a bottle of beer
<Hobbsee> Mithrandir: thanks!
 * Hobbsee happily drinks, gets well adn truly sozzled, and forgets about the pain of irc.
<pitti> StevenK: can I leave the fnfx merge to you? I have no idea about this package (I just did the Maintainer: rebuild)
<StevenK> fnfx? :-)
<Ng> is it just me or does mutt fail to build in hardy?
 * pitti creates an intrepid chroot -- let's see where this *$# intltool thing breaks
<\sh> pitti, is the libc6 issue resolved (perl hash module problem)?
<cjwatson> not yet
<pitti> \sh: those are two differnet problems, aren't they?
<pitti> perl Hash: not being in perl-base, and libc6 not being installable?
<\sh> pitti: yes
<cjwatson> pitti: Hash::Util not being in perl-base causes libc6 not to be installable in the context of debootstrap
<cjwatson> libc6 uses debconf which uses the perl fields module which uses Hash::Util
<pitti> ah
<pitti> well, I debootstrapped hardy and was going to upgrade it
<pitti> either way, I can reproduce the intltool uninstallability
<\sh> pitti, which fails for me 2 days ago, too ;)
<pitti>   intltool: Depends: libxml-parser-perl but it is not going to be installed
<\sh> s/fails/failed/
<pitti>   perl: Depends: perl-base (= 5.10.0-9) but 5.8.8-12 is to be installed
<pitti> aha
<\sh> yay
<pitti> ah, no, red herring (and bad apt message)
<pitti> indeed it seems to be the very same problem; perl is not installable (conflicting with debconf-i18n, etc.)
<pitti> mvo: hm, apt just tells bogus to me
<pitti> stuff like
<pitti>   base-files: Depends: libpam-modules (>= 0.79-3ubuntu3) but it is not going to be installed
<pitti> but both arre already installed
<seb128> pitti: use aptitude it's better at displaying correct errors
<seb128> pitti: well, might mean there is a base-files upgrade available not installable, what do you run?
<cjwatson> doko: hmm, chasen (in NEW) has reverted from libchasen0c2a to libchasen0c2; do you happen to know if that's deliberate/OK?
<cjwatson> gosh, djbdns in Debian main
<pitti> cjwatson: I synced that
<StevenK> Argh! Run away!
<pitti> cjwatson: it does not have any rdepends except itself
<cjwatson> err, you did?
<pitti> cjwatson: so I figured it would be ok, it was the only delta to Debian
<cjwatson> that's confusing, I'm doing intrepid autosyncs
<pitti> cjwatson: it wasn't an autosync, it was -f
<cjwatson> oh, you meant chasen not djbdns
<pitti> right
<cjwatson> pitti: ok, well, the point of the rename was also to alert users
<cjwatson> but if you're sure, feel free to new it yourself ;-)
<pitti> cjwatson: well, but Debian didn't adopt that rename in 3 years; seems pretty obsolete to me, and safe in Ubuntu (yet another soname change, but it doesn't affect anything)
<pitti> cjwatson: sure
<cjwatson> fair enough I guess
<pitti> Ng: test building
<pitti> cjwatson: NEWed
<cjwatson> pitti: maybe Debian did two C++ transitions at the same time and thus didn't need the a
<cjwatson> thanks
<cjwatson> I'm about to flood NEW with new source packages, but I'll deal with it
<doko> cjwatson: not immediately, have to find out what is meant by "libstdc++ new allocator trans"
<pitti> doko: see scrollback; AFAICS it is alright
<pitti> Ng: builds fine for me; how does it fail for you?
<Ng> pitti: I think I messed up, sorry
<doko> pitti: ok
<Ng> pitti: I've been getting segfaults from it talking to our imap server and I managed to infect the pristine source with a typo ;/
<pitti> heh
<Ng> yep, just rebuilt properly with my debugging statements :)
<seb128> ogra: btw the glib update doing unaccessible mounts filtering is available for testing now
<ogra> seb128, yeah, someone in #ltsp just told me that he doesnt see the prob anymore :) i was about to ask him what he did :) seems he has -proosed enabled :)
<seb128> ok, so it works, good
<ogra> great, getting user feedbeack before being pinged by the maintainer is a good sign
<seb128> please tell him to comment on bug #210379 to say that
<ubottu> Launchpad bug 210379 in glib2.0 "should not list mounts that the user doesn't have permission to use" [Low,Fix committed] https://launchpad.net/bugs/210379
<ogra> i'll try myself as soon as we have virtualbox drivers so i can run my vbox setup
<ogra> gah, he left a min agon from #ltsp
<seb128> ok, no hurry anyway
<ogra> *ago
<ogra> yeah
<ogra> i wont wave it through without having tested myself anyway
<seb128> sjoerd: how did you figure that the gtk debug symbols were for the udeb in the debian build?
<sjoerd> seb128: by running around screaming for a while and figuring out how gdb picks up debugging symbols
<sjoerd> The .so has a entry in it with the hash of debugging symbols file that belongs to it
<seb128> sjoerd: and how does it do?
<seb128>  23 .gnu_debuglink 00000020  00000000  00000000  00375780  2**0
<sjoerd> that one indeed
<seb128> somewhere in this line?
<sjoerd> yeah
<sjoerd> i had a nicer command line to get that
<seb128> I don't know how to do the matching between those number and the actual lib
<sjoerd> but in there is a crc32 (iirc) hash of the debugging file
<seb128> in fact that should be the other way around
<seb128> this line is a objdump on the actual lib
<seb128> sjoerd: you don't have a magic command to give the lib corresponding to the dbg then?
<sjoerd> seb128: one moment, i'm looking it up again
<sjoerd> (Things one should have written down...)
<sjoerd> seb128: right do -> eu-objdump -j .gnu_debuglink  -s /usr/lib/libglib-2.0.so.0.1600.3
<sjoerd> (eu-objdump is from elfutils)
<soren> Whose archive day is it?
<seb128> soren: technically mine I guess
<sjoerd> seb128: that gives you the filename of the debug lib and the last 32 bits is the crc32
<sjoerd> So that should match up with  crc32 /usr/lib/debug/usr/lib/libglib-2.0.so.0.1600.3
<soren> seb128: Could you sync perl 5.10.0-9.1 from Debian, please?
<soren> seb128: That would make debootstrapping intrepid work again.
<soren> ...which is good :)
<seb128> soren: I think other people were on those issues so I will them deal with that
<cjwatson> soren: I'll do it shortly
<soren> cjwatson: Lovely, thanks.
<sjoerd> seb128: and as your probably on a little-endian arch, you need to byteswap it ofcourse.. :)
<seb128> sjoerd: thanks
<sjoerd> np
 * sjoerd writes it down somewhere so he doesn't have to figure it out again :)
<soren> cjwatson: Are you grabbing libxml-parser-perl, too?
<cjwatson> the sync queue is busy with new packages at the moment
<cjwatson> soren: it's unmodified in Ubuntu, so it should get autosynced in the next run ...
<soren> cjwatson: Ok...
<soren> cjwatson: Yeah, but it'd be nice if it could get to the front of the queue somehow. cdbs seems to be uninstallable due to libxml-parser-perl depending on perlapi-5.8.8.
<cjwatson> I don't want to ctrl-c it now. I'll do it when it's done and ask for the build priority to be increased.
<soren> cjwatson: That's fine. Thanks.
<cjwatson> it won't take that long, it's just not right-now-this-minute :)
 * soren will grab some lunch in the mean time then
<cjwatson> and actually all I'm doing at the moment is filling up NEW, so I can just leave stuff there for a while
<soren> Which NEW queue are we talking about here?
<cjwatson> the intrepid one
<soren> Source? Binary? Some other one I don't know about?
<soren> I'm just struggling to figure out why syncing stuff from Debian would fill up any of those two.
<Hobbsee> soren: if it's not already in ubuntu?
<soren> Sure, but..
<Hobbsee> (source and binary new appear in the same place)
 * soren decides that he'd better to lunch before he makes more of an arse of himself
 * Hobbsee hands soren a carrot
<soren> ta :)
<cjwatson> soren: there's only one NEW queue per pocket
<cjwatson> soren: and, yes, as Hobbsee said, syncing packages from Debian that aren't yet in Ubuntu means that they land in the NEW queue until an archive admin deals with them (which is usually fairly scriptable, but even so)
<\sh> grmpf
<\sh> can somebody explain what "Archive-Update-in-Progress-leningradskaya.canonical.com " on a.u.c. means? every time I see this, I'm always getting bad sigs on release.gpg files...
<soren> cjwatson: Yeah. I just somehow misread what you said as though you were syncing stuff from Debian (both new packages and packages we already had) and that all of that somehow landed in a NEW queue.
<soren> I was clearly wrong.
<cjwatson> soren: packages we already have indeed go straight through
 * Hobbsee hands soren a capsicum too, thne :)
<cjwatson> \sh: it means that archive.ubuntu.com is in the middle of rsyncing from leningradskaya
<cjwatson> it's a bug if that results in bad signatures, although there are known (supposedly short) races in the process
<\sh> cjwatson, and on the other server ip it's lithium...but the timestamp on both files are different...leningrad is from 07:xx this morning and lithium is from 11:11
<cjwatson> the fact that Release and Release.gpg are separate files means that races are unavoidable right now
<cjwatson> \sh: #canonical-sysadmin if you think there's a real sync problem
<cjwatson> soren: perl synced
<\sh> cjwatson, kk
<cjwatson> soren: I don't see libxml-parser-perl in incoming or in the sync queue; maybe it was in the pile I did this morning?
<cjwatson> apparently not, 2.36-1.1 was synced on 3 May
<cjwatson> which is also the newest recorded by packages.qa.debian.org
<soren> cjwatson: Hm.. Ok. My intrepid chroot (which ought to be up-to-date) complained about it.
<soren> cjwatson: I'll look into it.
 * Twigathy waves to channel
<Twigathy> Myself, and a couple of others, are having weird problems with mdadm and sata_sii controllers, see: https://bugs.launchpad.net/ubuntu/+bug/208551
<ubottu> Launchpad bug 208551 in ubuntu "mdadm, Raid5 and XFS stuck in uninterruptable sleep" [Undecided,New]
<Twigathy> Is there anything I can do to help track down the bug? :x
<\sh> Twigathy, hmm? I'm having a areca sata raid controller running, 4x raid5 volumes,  one as system, 3 inside a software raid0 array via mdadm...everything is formatted with xfs...no problems here.
<Twigathy> \sh: yeah, my problem isn't with xfs it's with sata_sii
<Twigathy> or sata_sil....whatever it's called :)
<\sh> Twigathy, yes...see it now
<cjwatson> Keybuk: merges.ubuntu.com doesn't seem to be updating (I uploaded lowmem yesterday evening, and it's still on the list). Is something wrong with it?
<Keybuk> it didn't update yesterday due to a 404
<Keybuk> still is 404ing
<Keybuk> DEBUG:root:Downloading http://archive.ubuntu.com/ubuntu/pool/universe/a/aterm/aterm_1.0.1-4.dsc
<Keybuk> elmo: ^ missing from the archive
<Hobbsee> oh dear.  so i really did break MoM
<Hobbsee> wait, no i didn't - that wasn't my requsted sync.
<Hobbsee> morning Spads
<Spads> howdy
<pitti> cjwatson| soren: perl synced
<pitti> cjwatson: ^ apparently not?
<cjwatson> is too, I saw it building
<pitti> ah, now; I wonder why I didn't see it on -changes
<cjwatson> Keybuk: (synced at 8:05 this morning)
<pitti> cjwatson: ok, thanks
<cjwatson> pitti: I use NOMAILS=-M flush-syncs for autosyncs to avoid spamming the list
<cjwatson> the others you saw were from new packages, which I think historically have been announced
<pitti> ah, right
<pitti> cjwatson: I think we weren't very consistent for new packages from Debian
<cjwatson> agreed
 * soren would still rather get mails about everything
<Keybuk> wing-commander scott% wget http://archive.ubuntu.com/ubuntu/pool/universe/a/aterm/aterm_1.0.1-4.dsc
<Keybuk> --12:12:48--  http://archive.ubuntu.com/ubuntu/pool/universe/a/aterm/aterm_1.0.1-4.dsc
<Keybuk>            => `aterm_1.0.1-4.dsc'
<Keybuk> Resolving archive.ubuntu.com... 91.189.88.31, 91.189.88.45, 91.189.88.46
<Keybuk> Connecting to archive.ubuntu.com|91.189.88.31|:80... connected.
<Keybuk> HTTP request sent, awaiting response... 404 Not Found
<Keybuk> 12:12:48 ERROR 404: Not Found.
<Keybuk> cjwatson: lies
<\sh> Keybuk, use the .45 directly ;)
<cjwatson> Keybuk: synced as in synced from Debian to drescher
<jscinoz> So i hear the auto-syncer is being screwy with packages New to debian?
<cjwatson> jscinoz: uh, no?
<Keybuk> cjwatson: so is something wrong with drescher->soyuz?
<cjwatson> Keybuk: drescher *is* soyuz, but perhaps the mirroring process out to archive.ubuntu.com is having trouble
<Keybuk> that's what I mean
<jscinoz> cjwatson... oh i must have misinterpreted what was said above about inconsistency with new packages.
<Keybuk> dists clearly has it, but it's not in the pool
<elmo> archive.ubuntu.com is struggling atm; we've thrown some extra resources at it, but it'll take a while to take effect
<cjwatson> jscinoz: I don't think I said anything about inconsistency, even; which bit did you misunderstand?
<jscinoz> you didn't say it, pitti did "<pitti> cjwatson: I think we weren't very consistent for new packages from Debian"
<cjwatson> jscinoz: oh, that was a comment on consistency of whether we send mails to the -changes list for such packages or not
<cjwatson> there's no operational problem with the autosyncer itself that I'm aware of
<jscinoz> interesting...
<jscinoz> A package of mine has been available in unstable for a few weeks now, but hasn't turned up on the NEW queue yet
<cjwatson> jscinoz: which package?
<cjwatson> jscinoz: I only started dealing with packages new in Debian today
<cjwatson> (the autosyncer is not quite as auto as the name implies)
<jscinoz> cjwatson, teeworlds and two new libs (build-deps of teeworlds) libpnglite and libglfw
<jscinoz> "not quite as auto" what does it automate if people are still required to manually deal with packages?
<cjwatson> it's a script that needs to be run occasionally
<cjwatson> new packages need some level of manual checking
<cjwatson> but it automates the whole fetch, tweak, and upload process, and the normal daily routine is just a couple of commands
<jscinoz> Oh i see
<cjwatson> trust me, it's a lot more auto than it could be :)
<jscinoz> heh
<cjwatson> one of the reasons for manual checks is that sometimes things show up as "new in Debian" whereas in fact they were intentionally removed from Ubuntu and somebody forgot to blacklist them
<cjwatson> so I have to cross-check against that
<jscinoz> Is any further action required by me to ensure my packages are synced? Should i file a syncrequest or will it be looked over by you or someone else eventually
<cjwatson> teeworlds is currently showing up in that list, probably because it was also in a PPA (this is a flaw in my process)
<cjwatson> I'm not seeing either libpnglite or libglfw in Debian
<jscinoz> hmm
<jscinoz> one moment
<cjwatson> jscinoz: please do not file sync requests
<cjwatson> oh, pnglite and glfw are the source package names
<jscinoz> yes
<jscinoz> if thats nonstandard, blame debian-games-team :P
<cjwatson> no, it's fine
<jscinoz> Alright, thanks for the help :)
<Keybuk> elmo: ok, thanks
<Keybuk> cjwatson: so MoM will update whenever the archive reaches consistency
<cjwatson> jscinoz: glfw and pnglite are in the set of packages I just punted through the NEW queue, and should hit the archive in a bit (bear in mind that I just threw 500+ packages at the queue and the binaries will need to be NEW-processed at the other end so it may take a while)
<cjwatson> jscinoz: in general, there is no need to file sync requests for any changes in Debian before our Debian import freeze (see the release schedule) unless the package is already in Ubuntu and has been modified there
<jscinoz> Alright, thank you :)
<jscinoz> Hopefully i can get my UrbanTerror package in before the freeze finally got all the licensing issues resolved
<cjwatson> I'm going to let the archive settle for a bit before doing any more new-source processing, though
<cjwatson> so teeworlds will have to wait until after that, I think
<elmo> ok, leningradskaya's up-to-date and back in rotation
<pitti> \away -all
<pitti> sorry
<Hobbsee> pitti: fail.
 * Hobbsee hands pitti a gummy bear
<pitti> yummy!
 * Hobbsee throws soren a few jelly beans, and a gummy bear - dessert!
<cjwatson> Keybuk: oh, could you stick an Archive Open marker on the merges graph? IRC logs say that happened on 2008-05-01 at 22:10
<cjwatson> (er, BST, if you really care)
<doko> hmm, syncing perl packages before perl was built on all archs was a mistake ...
 * soren drools uncontrollably
<doko> these packages still get the perl5.8-api dependency
<cjwatson> they get to be rebuilt if necessary, I suppose; I didn't worry about it because perl packages are being uploaded quite frequently at the moment
<cjwatson> and it's only extensions
<doko> I identified these as currently not installable in a buildd chroot: libft-perl libterm-readkey-perl libhtml-parser-perl liblocale-gettext-perl libtext-iconv-perl libtext-charwidth-perl
<cjwatson> liblocale-gettext-perl was just synced again today
<doko> rescored perl on the buildds, won't help until it's built on all archs
<ogra> glfw ? a 3D iptables frontend ? :)
<cjwatson> oh yeah, we could do with britney output for intrepid, couldn't we
<cjwatson> ok, britney output should get generated shortly
<pitti> Keybuk: http://lists.freedesktop.org/archives/hal/2008-May/011560.html is an interesting read
<soren> Debian doesn't have ssp enabled in gcc by default, right?
<doko> soren: yes
<doko> lamont: perl ftbfs on hppa
<soren> "Yes, that's correct" or "yes, they have ssp enabled"?
<soren> Please don't answer "yes" again.
<soren> :)
<doko> no
<doko> ;)
<soren> *headdesk*
<soren> :)
<lamont> doko: \o/
<doko> soren: yes, you're right
<soren> Ok.
<soren> So if I pass -fno-stack-protector to it, it just ignores it?
<doko> yes
<gnomefreak> incase noone is running intrepid GUI libxfont1 version 1:1.3.2-1 makes X not load after restart
<emgent> heya
<soren> doko: Cool. Thanks.
<doko> lamont: disable the testsuite, on thread test does fail
<lamont> hooray for NPTL
 * gnomefreak was gonna wait until after toolchain was done to report this as bug
<cjwatson> soren: English is inadequate in this regard - we need yes / no / contradictory yes, like French and German have
 * soren takes a break
<jdong> gnomefreak: That bug should be known.. talked to at least 3 people experiencing it yesterday :)
<gnomefreak> jdong: ah ok cool
<jdong> I just like to say y'all intrepid daredevils are crazy ;-)
<gnomefreak> :)
<gnomefreak> this is an extra box so if it gets messed up i have 3 other backups i can use
<awalton__> jdong, ibex helped find a gcc bug through nautilus ;)
<awalton__> wouldn't have seen it if it weren't for the new toolchain.
<gnomefreak> you mean the gcc-4.2 that removes most of the system?
<gnomefreak> only found with dist-upgrade afair
<awalton__> no no, a real gcc bug, 4.3
<jdong> awalton__: well I'm *sure* I missed out on a lot of fun then ;-)
<awalton__> of course ;).
<gnomefreak> we found a cvs bug as well but it is expected
<awalton__> gnomefreak, -Wno-strict-aliasing was broken in gcc-4.3
<gnomefreak> jdong: see all the fun your missing :)
 * gnomefreak is waiting a bit longer before building for intrepid due to a few issues but i find it fun to run early dev cycle 
 * jdong thinks it's fun too, but lacks the time and a dedicated victim computer to keep up
<awalton__> dedicated computers, pfft. real men run ibex on their daily machines!
<jdong> awalton__: unfortunately real men at MIT cannot afford even minutes or an hour of computer downtime during the 2nd half of the week ;-)
<awalton__> true enough, but I'm not sure if we can classify men at MIT "men", they're some kind of more advanced life form..
<jdong> awalton__: nah they just get less sleep and hence appear less sane than others
<sladen> hmmm, somebody didn't reapply the middle-click disable in ubufox
<joaopinto> could someone check http://www.ubuntuguide.org/ with ff3 ? (NOTE: It is crashing X on me)
<sladen> joaopinto: works for me.  except the usual FF3 hangs every 90seconds
<joaopinto> I see it reported yesterday, the person was using an nvidia just like me, I just want to be sure it's related to the nvidia driver to file the bug
<joaopinto> sladen, which graphical card  are you using ?
<Ng> works for me on i965
<wgrant> WFM on an i915
<sladen> joaopinto: intel.
<jdong> sladen: have you pulled the update from hardy-proposed?
<jdong> that bug is supposedly fixed
<cjwatson> WFM (i965, hardy-proposed)
<Hobbsee> wfm, i945
<sladen> jdong: the FF3 sqlite update?
<joaopinto> hum, it could be bug 212648
<ubottu> Launchpad bug 212648 in linux-restricted-modules-2.6.24 "[nvidia-new, hardy] certain websites in firefox causes X restart due to lack of wfb symlink" [Critical,Fix committed] https://launchpad.net/bugs/212648
<jdong> sladen: yeah
<tjaalton> joaopinto: which nvidia card?
<joaopinto> VGA compatible controller: nVidia Corporation GeForce 8400 GS (rev a1)
<tjaalton> joaopinto: that page works here, 7950GT2
<tjaalton> I'll test on 8600GT
<tjaalton> although it's running the fixed version
<joaopinto> according to the lXorg og, it's really the driver, nvidia_drv.so
<tjaalton> works on 8600GT
<tjaalton> I'll downgrade the package
<joaopinto> there is someone else on the bug reporting it on a 8600 GT, maybe it's 64 bits specific
<joaopinto> anyway, it's already reported, I will just follow-up the bug :)
<tjaalton> the fix is on it's way
<tjaalton> already uploaded
<gnomefreak> tjaalton: is that the bug i think it is?
<tjaalton> gnomefreak: you've got mail :)
<gnomefreak> nope but same as other bug about nvidia >8xxx
<gnomefreak> tjaalton: checking :)
<gnomefreak> tjaalton: i dont have it :( ill check gmail maybe it got caught up somewhere
<tjaalton> joaopinto: confirmed that it crashes with the old package, and not with the new one
<joaopinto> where is the new package available ?
<tjaalton> not built yet
<tjaalton> uploaded to hardy-proposed
<tjaalton> waiting for ACK
<tjaalton> gnomefreak: hmm, you don't seem to be subscribed to that bug
<gnomefreak> what bug number?
<joaopinto> hum, I didn't got any default commented lines for -proposed
<tjaalton> bug 212648
<ubottu> Launchpad bug 212648 in linux-restricted-modules-2.6.24 "[nvidia-new, hardy] certain websites in firefox causes X restart due to lack of wfb symlink" [Critical,Fix committed] https://launchpad.net/bugs/212648
<gnomefreak> tjaalton: thanks i thought i still was
<sladen> jdong: that -proposed update of FF3 moves the desktop file from  firefox-3.0.desktop to  firefox.desktop  which breaks panel icons on Kubuntu
<sladen> (or anywhere that the user already has a shortcut to that .desktop file
<sladen> asac: ^^
<gnomefreak> tjaalton: thanks  for looking into that
<gnomefreak> and fixing it
<tjaalton> gnomefreak: well, that bug has haunted me for some time now
<tjaalton> apparently it was also in gutsy
<tjaalton> who knows how many crashers it fixes..
<tjaalton> or other problems
<gnomefreak> it should fix a bunch since the bug has been around a while atleast i remember 6xxx havign this issue when we first introduced -glx-new
<asac> sladen: err, firefox 3 -proposed update? ... i uploaded xulrunner-1.9, but no firefox
<tjaalton> gnomefreak: could be
<gnomefreak> once the fix is release i will update bugs that could have been the same issue to see if it fixed it for them
<gnomefreak> cause im sure firefox still has bugs like that somewhere in LP
<pitti> 618B/s - I've seen faster mirrors; /me sighs at de.archive.u.c.
<ion_> We should switch to Van Jacobson's new Internet. :-) Mirrors would become extinct, or rather, everything would become a mirror.
<norsetto> anyone has any idea why perl 5.10.0-9.1 still doesn't show in a.u.c.?
<ogra> pitti, well, a.u.c seems gone (for me at least) might be related
<pitti> yeah, everything is horribly slow today
<stgraber> lithium gives me ~150kB/s (instead of 1.8MB/s)
<ogra> elmo, ? aware ? ^^^
<stgraber> local mirror is two days behind
<maswan> pitti: we're still fast!
<pitti> OO.o's revenge
<ogra> oh, now it answers
<ogra> elmo, nm
<maswan> pitti: Fetched 70.9MB in 1min4s (1106kB/s)
<maswan> (and that's limited by the wlan here at cern)
<pitti> lucky you :)
<pochu> why don't developers have access to syncing packages from Debian, since they can 'workaround' that by signing and uploading the package? Is that a policy decission or a Launchpad shortcoming?
<Hobbsee> pochu: because it requires access to a whole bunch of the internal queue stuff, which isn't accesable to non-canonical employees.
<pitti> pochu: it's pretty much lack of LP feature
<Hobbsee> pochu: that being siad, there is a sync-source.py script, and launchpad is supposed to grow the feature at some point
<maswan> pitti: by a simple change to your sources, you too could get fast updates. Act now, and save an additional 100kB/s! Our httpds are standing by.
<pitti> maswan: I'd rather buy local, sir
<joaopinto> erm, I need a mirror which is able to update as for today :P
<pochu> pitti, Hobbsee: thanks. I was looking at soyuz bugs but couldn't find it... I guess I looked at the wrong place and it's this blueprint :) https://blueprints.edge.launchpad.net/soyuz/+spec/sync-workflows
<Hobbsee> pochu: probably.  i try not to follow the blueprints page, as most of it is non-visible.
<pochu> cprov: ^ you are the assignee of that and it's targeted for 1.2.5... do you know whether that will make the release, or whether that will be available anytime soon?
<cprov> pochu: considering the current amount of job we have to do in 1.2.5 and the issues we are having with copy-UI it will probably slip to 1.2.6, so now less than 1 month and half.
<Hobbsee> cprov: did the stuff planned for 1.2.4 get done, re archive admin stuff?
<cprov> Hobbsee: some, the new queue UI was part of it.
 * Hobbsee nods
 * Hobbsee wonders hwo to sort by what has a blueprint
<Hobbsee> oh, hmm, scrolling works
<pochu> cprov: that's fine, thank you
<ogra> geez, no cdbs on the intrepid buildds available ....
 * ogra looks for packages that dont use cdbs for merging ....
<pitti> ogra: it's still the same perl wreckage, breaking intltool, breaking cdbs, breaking the world
<ogra> yeah
<ogra> my first three merges were debhelper only so i didnt notice until now
<Keybuk> wait until you get your first debhelper 2000 crack
<pitti> /usr/bin/dh ?
<pitti> I dislike the (too short) name, but the idea is quite nice
<Keybuk> I don't see how it's better than cdbs
<Keybuk> if anything, it's a little less flexible
<chmj> hi pitti
<chmj> hey Keybuk
<chmj> ltns
<pitti> hi chmj
<pitti> tjaalton: rejecting audacious from hardy-proposed; http://launchpadlibrarian.net/14326332/audacious_1.5.0-2ubuntu2~hardy1_source.changes is not an acceptable changelog
<tjaalton> pitti: right, not really a "detailed and user-readable changelog" :)
<pitti> tjaalton: it also needs sru bug #
<pitti> tjaalton: using -v to include previous changelogs is acceptable, though
<pitti> but just merging the previous PPA changelogs (or whereever they came from) is less confusing
<tjaalton> it's from intrepid
<ogra> HUM !
<soren> pitti: Could you reject kvm-68+dfsg-0ubuntu1, please? It adds a new kvm-data package, so it should be sitting in binary new.
<ogra> why do i have a package that build-deps on libpng3-dev in sid ?
<zul> pitti: #219528 I should be able to upload that one shouldnt I?
<ogra> we have libpng12-dev, how can they have 3
<soren> pitti: I've joined the debian kvm team, and we just decided to drop it, so there's no point in getting it added and then have to remove it again tomorrow :)
 * ogra scratches head
<pitti> tjaalton: for bug 212648 and the other related two (l-r-m), please prepare them to be correct for SRU next time (hardy/intrepid tasks, subscribe ubuntu-sru, etc.)
<Mithrandir> > apt-cache show libpng3 | tail -n 7  |head -n 2 This package is superseded by libpng12-0, and is provided only for transitional purposes.
<ubottu> Launchpad bug 212648 in linux-restricted-modules-envy-2.6.24 "[nvidia-new, hardy] certain websites in firefox causes X restart due to lack of wfb symlink" [Undecided,In progress] https://launchpad.net/bugs/212648
<Mithrandir> ogra: ^
<ogra> Mithrandir, aha, thanks that looked weird
<pitti> soren: sure
<soren> pitti: ta
<tjaalton> pitti: ok, I thought I did that
<pitti> soren: hm, it's not in NEW
<pitti> soren: it's in DONE
<pitti> i. e. built and published
<zul> pitti: meh...ignore me :)
<soren> pitti: I didn't see it on packages.ubuntu.com
<pitti> soren: https://edge.launchpad.net/ubuntu/+source/kvm/1:68+dfsg-0ubuntu1
<pitti> zul: ?
<pitti> zul: ah, just saw my recent comment? :)
<zul> pitti: nm I need more coffee
<soren> pitti: rmadison doesn't know about it either.
<pitti> soren: rmadison is always about 6 hours behind archive.u.c.
<pitti> (the delay of the mirror on rookery)
<pitti> soren: and nowadays, archive.u.c. seems to be much behind drescher
<soren> pitti: Wow, I thought rmadison would be ahead.
<soren> pitti: Oh, ok.
<pitti> eeeverything feels like tar today :/
<pitti>       kvm | 1:68+dfsg-0ubuntu1 |      intrepid | source, amd64, i386
<pitti> ^ drescher
<soren> pitti: Well, expect it to show up in NBS quite soon :)
<pitti> soren: heh, NP :)
<pitti> . o O { reminds me of P=NP; if it's "problem == no problem", it must clearly be false }
<Hobbsee> or a heisenproblem.
<tjaalton> pitti: can I upload using the same version (audacious)?
<calc> anyone know what location to put scripts to execute on resume with 8.04? aiui it changed from 7.10
<calc> it used to work under /etc/acpi/resume.d but i hear that doesn't work any longer?
<ogra> calc, look in /etc/pm
<calc> hmm all those dirs are empty
<ogra> calc, there is a system equivalent as well, but i forgot the path
<calc> is there a doc somewhere explaining the format of what to put in there?
<ogra> /etc/pm is for local admins
<calc> ah ok
<ogra> i think the docs of pm-utils have something
<calc> looks like system location is under /usr/lib/pm-utils/
<calc> although that sounds like a fhs violation, heh
<calc> i guess it is architecture specific so is better than /usr/share
<pitti> tjaalton: please do
<tjaalton> pitti: uploaded
<LaserJock> pitti: have you been checking to make sure uploads to -proposed have been ack'd by a SRU team?
<pitti> LaserJock: oh, did something slip through? I usually check, but there were so many that I might have forgotten
<tjaalton> pitti: the wikipage is a bit unclear about this, so I've uploaded directly :/
<tjaalton> but will wait for an ack the next time
<pitti> tjaalton: you don't need to for main/universe
<pitti> tjaalton: erm, sorry
<pitti> tjaalton: for main/restricted
<tjaalton> ah, ok
<pitti> tjaalton: in fact, for main/restricted I prefer people to upload directly
<pitti> faster to check debdiffs, etc.
<tjaalton> gotcha
<LaserJock> pitti: ummm, why is an ack from Ubuntu SRU not needed for Main?
<pitti> LaserJock: it is, but not prior to uploading
<LaserJock> Main and Universe share the same policy
<LaserJock> I'm surprised that we have such a stark difference
<pitti> LaserJock: getting an ack before upload would just introduce two more iterations between ~ubuntu-sru and the uploader
<cjwatson> the policy used to be (IMO) unclear and subject to multiple readings
<pitti> so right now, an ack means that ~ubuntu-sru processes the upload and the bug
<pitti> and a nack is to reject the upload from the queue and comment on the but
<cjwatson> but it seems quite clear from the current policy document that an ack before upload is not required
<pitti> s/t$/g/
<pitti> this shortens the process without actually changing the meaning
<LaserJock> MOTU SRU does the ack before upload
<hwilde> do you guys have an irc plugin that actually executes /s/t$/g/   and replaces it in the previous statement ?
<pitti> hwilde: hah, nice idea ;)
<pitti> hwilde: entirely wetware processed ATM, though
<pitti> LaserJock: right, and that makes sense, IMHO
<pitti> LaserJock: that shortcut works for main/restricted, because ~ubuntu-sru happens to be a subset of ~ubuntu-archive
<pitti> LaserJock: whereas when we process universe SRUs, it's helpful to look into the bug and search for a approval
<LaserJock> ok
<LaserJock> well, I'll add that to my list of things that need to get fixed
<pitti> LaserJock: what do you want to change?
<pochu> LaserJock, pitti: that may be fixed with https://blueprints.edge.launchpad.net/soyuz/+spec/soyuz-community-admin, IIUC
<xivulon> seb128: ping
<pochu> hmm, not really...
<xivulon> seb128: I am looking for a way to show a wubi /host dir onto the Desktop (since many users seem to be confused)
<pochu> bug 207680 would be the good one, supposing 'access' means rw and not ro :)
<ubottu> Launchpad bug 207680 in soyuz "Community Admin: Require MOTU queue access for universe/multiverse" [High,In progress] https://launchpad.net/bugs/207680
<xivulon> seb128: bug #225593
<ubottu> Launchpad bug 225593 in wubi "/host does not appear as an icon on the desktop" [Low,Confirmed] https://launchpad.net/bugs/225593
<xivulon> mtab_file_changed
<ogra> mumble mumble ... tuxpaint merge mumble ... grrr
<xivulon> I am not too familiar with gnome code, on quick skim it looks like that depends on mtab_file_changed
<xivulon> but /host will only be visible in /proc/mounts
<LaserJock> pitti: I'm working on clarifying the SRU policy
<pitti> LaserJock: ah, ok
<LaserJock> pitti: obviously people are unsure of when to expect/wait for an ACK
<LaserJock> as the SRU page actually never says
<jdong> LaserJock: I propose Launchpad to support a blame-ball!
<LaserJock> I've had I think at least 3 Universe SRUs go through without and ack
<xivulon> pitti are you familiar with ^ too?
<LaserJock> in all cases people said "oh, I didn't see that on the SRU wiki page" which is quite understandable
<seb128> xivulon: not sure to understand the question, if you want a mount to be listed in GNOME mount it under media or the user directory
<cjwatson> seb128: /host is very tricky to move I'm afraid. Is it possible to add a further exception?
<cjwatson> seb128: it's a move-mount of the Windows filesystem with the Ubuntu root loop-mounted inside it, and a number of bits of code rely on its current location
<cjwatson> it was the best we could do
<seb128> cjwatson: that require some easy glib2.0 source changes but yes
<cjwatson> I don't think /media is appropriate - /media suggests to me that you might be able to unmount it - and the user's home directory would definitely be wrong
<cjwatson> it's really more an integral part of the system
<xivulon> seb128 do mount binds trigger that too? I think I tried that with little success
<seb128> xivulon: I didn't play with that
<xivulon> well I think if we can also monitor /host it would be better
<seb128> glib gio/gunixmounts.c g_unix_mount_guess_should_display() is what you want to change
<calc>  /host is the mountpoint for the wubi root?
<xivulon> seb128 isn't that fed from mtab?
<calc> ah yea i see in scrollback :)
<seb128> xivulon: yes, it is, why?
<xivulon> calc /host hosts the root loopfile
<xivulon> seb128 because /host is not going to be in mtab :)
<seb128> why not?
<seb128> I start thinking you should add /host to .gtk-bookmarks ;-)
<ogra> you can do a *very ugly* (!) workaround and add a fake entry for it to fstab ... then gvfs ignores it
<ogra> ah, .gtk-bookmarks sounds slightly saner :)
<calc> xivulon: ok
<xivulon> seb128 it is mounted very early on in the game
<xivulon> a symlink ~/Host -> /host was in fact my first bet
<xivulon> it is only visible in /proc/mounts
<xivulon> on the plus side it is not something that requires "monitoring", has to be done only once per session
<seb128> well, do you really want this one being listed as a mount?
<xivulon> if it cannot be unmounted easily, sure
<seb128> well, why do you need a mount if that should not be considered as a mount?
<seb128> wouldn't a bookmark be better?
<seb128> like the video, music, etc ones
<xivulon> I think that will do. Is that preferrable over a symlink? Particularly considering that we might need to replicate on other distros
<xivulon> or maybe both, Desktop/Host (or WinDir) symlink plus bookmark
<xivulon> cjwatson, is symlink and/or bookmark ok?
<seb128> xivulon: well, symlinks will be listed only where you make it where the bookmark will be listed in the places menu, nautilus and fileselector sidebars, etc
<cjwatson> I continue not to like sticking it in ~
<cjwatson> bookmark would be OK
<xivulon> was about to ask that
<cjwatson> just lose the symlink
<xivulon> np
<xivulon> will have to setup bookmarks for kubuntu/xubuntu too though
<pitti> xivulon: familiar with what?
<xivulon> nope
<pitti> xivulon: if it's wubi, then 'no'
<xivulon> pitti no problem, seb128 already answered
<xivulon> Will .gtk-boomkarks also work on Xubuntu? does anybody know the kde equivalent?
<xivulon> Is that initially generated from some common "skeleton"?
<seb128> xivulon: no idea, no idea, no
<_MMA_> xivulon: cody-somerville might be able to answer re: Xubuntu.
<ion_> IIRC .gtk-bookmarks is supported by the Xfce file manager, and of course by the Gtk file dialog.
 * cody-somerville nods.
<xivulon> cool, so we only have kubuntu left
<ion_> There should be a fd.o spec for the bookmarks as well.
<xivulon> thx ion_
<kestaz> does vim compiled with vim-shell extension ?
<Caesar> So here's a fun weird race-condition
<Caesar> We ocassionally see xserver-org's preinst fail because /etc/X11 doesn't exist when at line 990 it goes to touch /etc/X11/xorg.org
<Caesar> Yet xserver-xorg pre-depends on x11-common, which ships /etc/X11
<Caesar> I'm told we saw it with Gutsy as well
<Caesar> Is that an APT bug?
<Caesar> Is this APT splitting the dpkg command-line in a bad place?
<gladk> hi all!
<gladk> may I ask here a question about Launchpad using?
<Pici> gladk: you may have better luck asking in #launchpad
<gladk> Pici: thank you
<e-gandalf> asac: ping
<asac> e-gandalf: go ahead
<e-gandalf> asac: I was pinging you on the Prague schedule
<e-gandalf> to book my tickets
<e-gandalf> I'm the mozilla guy
<asac> e-gandalf: ah right. go for the first three days
<mathiaz> slangasek: does mount.cifs support spnego ?
<slangasek> mathiaz: yes
<slangasek> though I'm not sure if that's really the question you meant to ask :)
<mathiaz> slangasek: well - I've got a report that cifs in hardy doesn't support kerberos
<mathiaz> slangasek: so they have to keep smbfs around
<slangasek> I haven't tested this directly, but it's documented to support kerberos and there's an option to explicitly request that it use kerberos auth
<mathiaz> slangasek: documented -> README.Debian ?
<slangasek> mathiaz: documented in the mount.cifs manpage
<mathiaz> slangasek: ok - thanks.
<mi> i have problem with QT 4.4 after upgrade  i can't compile KDE 4.1
<slangasek> mathiaz: was the user using 'sec=krb5' and it failed?
<mathiaz> slangasek: I don't know - I'll ask.
<slangasek> mathiaz: is there a channel I should join to discuss this directly?
<compbrain> Anyone running or know of a wanna-build run build-cluster that has docs to share?
<proq> what is a wanna-build?
<geser> proq: afaik Debian's database with packages which needs building, it gives out the builds to the build daemons
<compbrain> Yep
<Caesar> pitti: any chance #214770 can get fixed in Hardy?
<loffe> Hi all, I can't install libqt4-opengl-dev. There seems to be a conflict. I get this error message: trying to overwrite `/usr/lib/pkgconfig/QtOpenGL.pc', which is also in package libqt4-dev
<Caesar> Bug!
<ScottK> loffe: I think there's an open bug on that.  Let me look.
<loffe> Is there a workaround?
<ScottK> I think it says in the bug.  I'll point you at it if I find it.
<mi> huh what a mess with qt4.4
<ScottK> loffe: I was thinking of a different package (python=qt4, sorry).
<ScottK> loffe: #kubuntu-devel is generally a better place for qt4 discussions.
<loffe> ok, thanks anyway
<mi> loffe, u need libqt4-opengl-dev for KDE 4.1
<wasabi> Oh. Heh. Nice.
<wasabi> Warning: Removing group `nogroup', since no other user is part of it.
<foka> Just wondering: Is it known bug that when running virtual machines with virtualbox, often the keyboard gets stuck?
<foka> In Ubuntu Hardy, I mean.
<jwendell> seb128, around?
<seb128> jwendell: yes
<jwendell> seb128, where does gnome-session read the autostart files from?
<jwendell> seb128, besides /etc/xdg/autostart
<seb128> jwendell: /etc/xdg/autostart /usr/share/autostart
<seb128> then the XDG_DATA_DIR, user dir, etc
<jwendell> seb128, I mean, where is gnome-panel and nautilus ?
<jwendell> there's no /usr/share/autostart...
<seb128> those are not autostarted
<jwendell> no?
<seb128> they are in the gnome-session default session
<seb128> they don't use autostart
<jwendell> seb128, where is it?
<jwendell> default session?
<seb128> jwendell: /usr/share/gnome/default.session
<jwendell> seb128, thanks
<seb128> you are welcome
<mario_limonciell> kees, ping
<kees> mario_limonciell: hola
<mario_limonciell> hi kees
<kees> hiya mario_limonciell, how goes it?
<mario_limonciell> i was investigating bug 218955 as it was looking like a bug in dkms
<ubottu> Launchpad bug 218955 in lirc "upgrade to hardy breaks lirc 0.8.3pre1 kernel modules" [Undecided,In progress] https://launchpad.net/bugs/218955
<mario_limonciell> but it turns out it's a bug in the way dkms is used for lirc.
<mario_limonciell> it will unfortunately break on every ABI rev of the kernel
<mario_limonciell> so i was going to put together an SRU at the same time to fix that
<mario_limonciell> and then also do a new lirc package for intrepid with the final 0.8.3 release
<mario_limonciell> sound like a good plan?
<cjwatson> wasabi: what emitted that message? that's a serious bug - nogroup is a global static user
<cjwatson> er, group
<wasabi> cjwatson: deluser did
<ion_> You were deleting the user nobody?
<ion_> I don't think there should be a special case to avoid the automatic deletion the group ânogroupâ if the user really wants to delete the user ânobodyâ.
<wasabi> No. I added a user, then deleted it.
<wasabi> By default it added it to nogroup.
<wasabi> Then deleting it removed nogroup.
<ion_> Interesting. Does the user ânobodyâ still exist?
<wasabi> Yes.
<wasabi> In fact. The nogroup group stil; exists. :0
<wasabi> It just printed the warning message
<tjaalton> can new packages be added after release via backports or updates?
<ScottK> tjaalton: It'd take a really odd problem to get a new pacakge into an SRU for updates.  Generally backports.
<tjaalton> ScottK: ok, backports would do
<tjaalton> ScottK: actually, would a broken dependancy (missing package..) warrant an SRU?-)
<ScottK> So it's uninstallable now?
<tjaalton> <sigh> yes
<ScottK> Is this Universe or Main?
<tjaalton> universe
<ScottK> I'd guess it might.  I'd ask on #ubuntu-motu for someone from motu-sru to give you an opinion.
<tjaalton> yeah, thanks
<cjwatson> wasabi: I guess if it still exists that's not so bad, but er ...
<LaserJock> tjaalton: did you get somebody on your SRU question?
<tjaalton> LaserJock: not yet
<LaserJock> tjaalton: what package/bug is it?
<tjaalton> LaserJock: vdr-plugin-burn...
<tjaalton> not that popular, but still a blatant oversight on my part
<tjaalton> it installed fine on my box, which happened to have local packages installed <sigh>
<LaserJock> tjaalton: so this is bug #226072 ?
<ubottu> Launchpad bug 226072 in vdr-plugin-burn "vdr-plugin-burn depends on non-existent packages" [Medium,Confirmed] https://launchpad.net/bugs/226072
<tjaalton> yes
<tjaalton> mkisofs -> genisoimage, projectx -> project-x, and add vdr-genindex. that should do
<LaserJock> is genisoimage in Multiverse?
<tjaalton> no
<tjaalton> mkisofs is
<tjaalton> genisoimage is in main
<LaserJock> so vdr-plugin-burn is ok in Universe?
<tjaalton> yes
<LaserJock> that's what I thought, just wanted to confrim
<LaserJock> *confirm
<tjaalton> yeah I didn't realize that mkisofs dep could be changed
<LaserJock> tjaalton: how big of a deal is this vdr-genindex package going to be?
<tjaalton> LaserJock: installed size 64kb, one binary
<LaserJock> tjaalton: well, I think it's worth going for an SRU
<tjaalton> LaserJock: ok thanks, I'll test it properly this time and see how it goes
<LaserJock> tjaalton: I can't say 100% I'd approve it until I've seen all the workup, but it seems like a worthwhile thing to do
<tjaalton> of course
<LaserJock> cool, sounds like a plan
<paran> anybody here that manages the http://ddebs.ubuntu.com/ archive?
<LaserJock> tjaalton: I just sub'd motu-sru so I can keep track of it
<tjaalton> LaserJock: cool
<cjwatson> paran: pitti
<cjwatson> paran: unlikely to be around at this time
<paran> cjwatson, pitti: ok. the problem is that many packages in hardy-updates seems to be available as deb-files in the pool-dirs but missing from Packages.gz
<LaserJock> tjaalton: btw, is vdr-genindex in Intrepid?
<tjaalton> LaserJock: not yet
<tjaalton> since I noticed this mess this evening :)
<LaserJock> heh
<LaserJock> tjaalton: we'd want to have it go through NEW in Intrepid first
<LaserJock> so that's probably a good place to start
<tjaalton> LaserJock: yep, sure thing
#ubuntu-devel 2008-05-08
<blueyed> Can somebody please clear vbox-ose-modules from NEW/hardy-proposed?
<LaserJock> can anybody think of a reason why a package would just disappear from Hardy?
<jdong> LaserJock: usually that involves sabdflatory processes ;-)
<jdong> or launchpad magic.
<LaserJock> I think perhaps something went boom
<LaserJock> I don't see a removal bug
<LaserJock> but a decently important science app is just gone
<LaserJock> looking at the publishing history all the Hardy uploads are "superseded" and none are "published"
<blueyed> btw: "hardy-proposed" is missing from http://ddebs.ubuntu.com/dists/
<TheMuso> LaserJock: Has it been removed from Debian.
<LaserJock> TheMuso: I seriously doubt it, let me check
<LaserJock> oh, actually it appears it has!
<bd_> heh, why was it removed?
<LaserJock> RoQA; (very) RC-buggy
<LaserJock> well that's kinda crappy
<LaserJock> somebody was clearly trying to fix it up and they go and remove it
<LaserJock> I don't suppose there's a way for us to get it back?
<cjwatson> LaserJock: err, it could come back in intrepid, maaaaaaaaybe in hardy-proposed given an SRU
<cjwatson> BTW the RoQA stuff typically only happens after the maintainer has been delinquent for some time, and is a reaction to many previous occurrences when people promised to fix things up and then forgot
<LaserJock> I guess
<cjwatson> for some reason, removing things seems to kick people into action ...
<LaserJock> but why not orphan it for a while first
<LaserJock> I can see removing it from testing
<LaserJock> as it had problems with gcc 4.3
<LaserJock> so instead I have users wondering where their app is
<LaserJock> and turning to PPAs
<LaserJock> which I guess is alright
<LaserJock> but perhaps we should just get the PPA packages into Ubuntu and let Debian do whatever they're gonna do
<LaserJock> cjwatson: would you just blacklist a package like that from syncing?
<LaserJock> I guess there wouldn't be anything to sync anymore
 * LaserJock shuts up for the moment :-)
<cjwatson> LaserJock: usually we don't blacklist packages that have been removed from Debian, on the basis that if they get put back into Debian then we probably want to follow suit
<cjwatson> the blacklist is for packages that have been removed from Debian but not for Ubuntu
<LaserJock> yeah, makes sense
<LaserJock> I'm sure we'll bring them back for Intrepid
<LaserJock> I don't feel like trying an SRU for Hardy, especially when there are PPAs available for it now
<cjwatson> LaserJock: what's the package name?
<LaserJock> qgis
<LaserJock> it's a very common/popular GIS gui
<LaserJock> I've seen people who use Ubuntu soley for it
<LaserJock> I was just reading a forum thread about people wondering where it went, that's how I found out
<cjwatson> well, it'll come back if it gets accepted back into Debian before import freeze
<cjwatson> or if somebody reuploads it manually to Ubuntu
<LaserJock> I'll have to talk to the people who are running the PPA, I think they are upstream developers
<LaserJock> maybe I can convince them to maintain it in Debian and/or Ubuntu
<ScottK> LaserJock: If it gets into Intrepid, it can be backported to Hardy.
<LaserJock> ScottK: good point
<TheMuso> StevenK: Any objections to me doing your libsdl1.2 merge? I'm preparing an SRU for it for hardy, and need to get the same fix into intrepid, so I may as well merge while I'm at it.
<StevenK> TheMuso: None.
<TheMuso> StevenK: Thanks.
<WhiteNoise> if anyone is good with cryptsetup and initramfs, please check out this confirmed bug exposed when upgrading to Hardy and the new kernel:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213279
<ubottu> Launchpad bug 213279 in linux "cryptsetup: source device not found during boot" [Undecided,Confirmed]
<doctormo> Hey is anyone here involved in the Remote-Support thread on the mailing list?
<ScottK> I haven't noticed that any of the people significantly involved in it are regulars here (I commented once or twice).
<doctormo> ScottK: Ah, i got this stomach turning dread when i noticed the thread; "Ah damn they're reinventing our project"
<ajmitch> which project is that?
<doctormo> https://launchpad.net/locoremotesupport/
 * Hobbsee tends to get people who give her an ssh login, and hand over root access, and say "fix it"
<fabbione> morning guys
<Hobbsee> morning fabbione
<ion_> "ciao a tutti".upcase.l337ize.mirc_colorize
 * StevenK slaps ion_ with a large trout.
<StevenK> If I can remember mIRC's default ...
<ion_> :-)
 * ScottK pan fries the trout in butter and has a late night snack.
<ajmitch> late?
<ion_> Yeah
<doctormo> ScottK: I was curious as to what you would make of our project, you seemed interested
<ScottK> doctormo: I'm mostly interested in we don't compromise security in order to 'help'.
<doctormo> ScottK: yea, something that has brought about grave discussion in our irc channel. One of the reasons we decided to make it elective
<Hobbsee> ScottK: oh, but why don't we give ppa access, and so put the correct versions of everything in there, and do an upgrade of critical packages, jus tto fix things?
<Hobbsee> blah.  my brain's not doing thoughts in a coherant order, today
<LaserJock> nifty idea
<LaserJock> "download this package and it will fix everything up for you .. ;-)"
<Hobbsee> LaserJock: it's called automatix3, and won't let you turn on your computer again.
<ScottK> "download this package and you'll never need to worry about your data again."
<StevenK> It melts the machine down and encases it in rapid-set concrete?
<doctormo> StevenK: and drops it in a 27 foot hole and covers it with rocks and bolders?/
<StevenK> doctormo: Not enough.
<doctormo> StevenK: It was a weird-al quote from his "Virus alert" song
<StevenK> Haha
<doctormo> "Then burn any of the clothes you wore when you were online"
<doctormo> hehe
<ion_> Sorry if i'm being ignorant (i didn't read the mailing list thread or study the locoremotesupport project), but i'd just like to point out that it would be nice if there were an easy way for a helpee to *connect to me* so that i'd gain access to her system for a single session. She wouldn't need to have something listening to a port, and i would be the one to set up an open port etc.
<LaserJock> ion_: that does seem more sane
<doctormo> ion_: yes, that is what we're working on, elective ssh support
<doctormo> it uses reverse ssh tunnels
<ion_> Nice
<RAOF> Heh.  That was my one contribution to the thread :)
<doctormo> The idea is that it would work even if your on a weird PPoE or a McDonnelds Wifi, although weather you'd want to...
<doctormo> RAOF: really? heh, you should have been in #ubuntu-us-ma about 2 months ago when we were talking about it
<RAOF> Reverse ssh seems eminently sensible.
<doctormo> RAOF: so far we have `ssh -o "StrictHostKeyChecking yes" -nNT -R %s:%s:%s %s@%s`
<dholbach> good morning
<Hobbsee> morning dholbach
<dholbach> hiya Hobbsee
<norsetto> heya dholbach
<dholbach> heya norsetto
<LaserJock> guten morgen dholbach
<dholbach> heya LaserJock
<nixternal> w00t, 1 more week of classes baby!
<nixternal> now I just need to find a job and I will be good to go
 * dholbach hugs nixternal
<LaserJock> nixternal: job? what's that?
<doctormo> programming?
<nixternal> I have no clue...only job I have held the last 3 years is right here with all of you :)
<nixternal> though I have taken the slacker route obviously
<nixternal> I quit Microsoft to work with you LaserJock!
<LaserJock> haha
<nixternal> for real!
<nixternal> people think I quit to go back to school...in all honestly it was you!
<LaserJock> yes, my magnetic charisma stole you away from Ballmer ;-)
<nixternal> that and he didn't pay worth a crap
<nixternal> they hated us so much they gave us crappy office space and all...wouldn't even let us come near redmond
<ajmitch> free copies of vista weren't enough for you?
<nixternal> oh, you test ms products and linux.....no redmond for you!
<ion_> And free chairs
<nixternal> ajmitch: you still using that free copy aren't you :p
<LaserJock> I've been to the Redmond campus, it's very beautiful
<ajmitch> of course
<nixternal> LaserJock: I have seen the redmond campus
<nixternal> in 2 presentations and on google maps
<ion_> laserjock: Any chairs flying around?
<LaserJock> ion_: I was just outside waking through, never dared go inside the buildings
<nixternal> they would have killed you..they have people dressed up like the imperial forces just waiting to get rid of your hippy ways
<LaserJock> I was afraid they'd catch me and make me one of their code monkeys
<LaserJock> I didn't have the lasers I have now for just such an occasion ;-)
<nixternal> haha
<nixternal> my 2 current job offers would require me to leave the community behind...and I can't deal with that honestly...I am to addicted
<nixternal> plus mario lemonsquare owes me a drink
<ajmitch> require?
<nixternal> ya, as in I wouldn't be allowed to work on Ubuntu
<superm1> lemonsquare?
<ajmitch> harsh
<nixternal> ya you superm1 :p
<superm1> was that explicitly told to you?
<superm1> that you'd have to leave them behind?
<Yasumoto> nixternal: that's brutal.. :(
<nixternal> superm1: ya
<superm1> nixternal, yuck.  w/ what groups/companies are these offers?
<nixternal> and the one, was the Red Hat job down there by you
<nixternal> but that was business services type stuff...marketing..they would only allow me to use what I was to support/market/manage/whatever
<nixternal> the other is my old MS job :p
<Hobbsee> !visternal
<ubottu> Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!
<Hobbsee> evil man.
<nixternal> hehe
<nixternal> only in your eyes!
<nixternal> well, maybe a few others as well
<superm1> nixternal, can they really dictate what you do on free time?
<lucent> my evil sense is tingling
<nixternal> I am hoping on a job opening with a local free software company that won't hamper anything but time
<nixternal> superm1: not really, but it is easy for them to use it against you when you are sucking
<Hobbsee> nixternal: then surely the solution is not to suck?
<nixternal> most definitely, but everyone hits those times when they aren't 100%
<nixternal> especially in business management
<nixternal> I so wish I would just go ahead and complete my damn CS stuff and forget this business crap
 * Hobbsee thought there was more to the range, rather than just '100%' or 'sucky'
<nixternal> anything less than 90% is sucky in my books :)
<nixternal> unless of course you are talking about the humidity in Chicago, then anything above 60% is sucky
<pitti> Good morning
<Hobbsee> right.
<Hobbsee> morning pitti!
 * Hobbsee hugs pitti
<nixternal> mornin' pitti
 * pitti hugs Hobbsee and nixternal
<superm1> nixternal, yeah well down here if you are talking about any part of the year between the end of may and end of august, it's always sucky
<Hobbsee> :)
<superm1> temperature wise at least
<jsgotangco> evil nixternal making this channel noisy again!
<nixternal> oh no!
 * jsgotangco goes back to work
<superm1> haha
<\sh> nixternal, you need a new job? overseas? come to germany ;)
<ajmitch> hi pitti
<nixternal> whatever jerome! you know you want to come back to Chicago
<\sh> nixternal, you can work on ubuntu full time ;)
<nixternal> \sh: I am on my way!
<nixternal> I will FedEx myself in the morning
<jsgotangco> nope i am getting an island soon :)
<\sh> nixternal, hehe...
<nixternal> Blue Island?
<nixternal> Stoney Island?
<jsgotangco> i was supposed to be in ubuntu live but i have a sched that week elsewhere sunddenly came out i had to decline the slot
<\sh> nixternal, na really, I need an add here for the sysadmin stuff, deploying ubuntu on servers, fixing packages, pushing new crack in
<StevenK> \sh: Your servers run Automatix?
<lucent> jsgotangco: a goose island?
<nixternal> \sh: Hobbsee will attest...I am the best crack pusher this community has ever witnessed!
 * Hobbsee beats StevenK
<\sh> nixternal, you are allowed to even fix flash ,)
<Hobbsee> nixternal: no, jdong is.
<nixternal> ooh, good one lucent, I forgot about the all important Goose Island
<\sh> StevenK, what is automatix?
<nixternal> damn, I need to start producing more crack then
<StevenK> \sh: Something you should continue to ignore.
<nixternal> which they are closing at the end of the year except for their one cruddy spot near wrigleyville
<lucent> nixternal: I was going to say "312" but it doesn't make itself immediately obvious to outsiders
<\sh> StevenK, i thought the dev of autocracknix told the world that automatix died
<nixternal> lucent: where the heck are you at?
<nixternal> the name definitely rings a bell living right down the street from lucent
<nixternal> hehe
<lucent> I'm Eric Shattow
<nixternal> have we met?
<hunger> So what is the recommended upgrade path hardy/intrepid? Should I just remove the gcc-4.2 stuff? What about perl?
<lucent> I live north of Chicago, IL
<lucent> I don't know
<nixternal> groovy...I am out by Schaumburg
<\sh> hunger, there is no upgrade path...there is only pain...real pain...it will hurt...yay...pain is good ,->
<RAOF> hunger: The currently recommended upgrade path is "don't".
<nixternal> Schaumburg, a nice German town with more Greek restaraunts than you could shake a stick at
<Yasumoto> \sh: haha. so reassuring.. :P
<RAOF> Incidentally, it's also the currently recommended debootstrap path :(
 * \sh doesn't even no Schaumburg...and the story about more greek restaurants...
<hunger> \sh, RAOF: I know unstable ubuntu distris. Have been using them since before breezy:-)
<Hobbsee> nixternal: do my assignment for me, kthxbye.
<Hobbsee> this thing looks woefully stupid.
<nixternal> haha, Hobbsee I spent all day doing a bogus Business Needs Analysis
<\sh> hunger, it's too early to upgrade...believe us
<Hobbsee> nixternal: this assignment refers to the internet consistently as the "InterNet"
<nixternal> I faked an interview from about 3 of you in this channel actually :p
<Yasumoto> hunger: it's still too early to upgrade yet though. the toolchain isn't even up yet (right?)
<\sh> hunger, just try latest debootsrtap from intrepid and try to create a chroot...
<hunger> Yasumoto: gcc 4.3 is uploaded and a lot of packages are already build.
<RAOF> Yasumoto: The toolchain is, and stuff's building.  The autosync hasn't finished yet IIRC, and it's not debootstrappable at the moment.
<lucent> nixternal: I'm unemployed at the moment, work would be interesting
<nixternal> hehe, you and I both :)
<hunger> Yasumoto: gcc-4.3 transition does not seem done yet and perl is updated but not the perl addon libs.
<lucent> I was doing some work as an installer for Allen Visual Systems in Buffalo Grove, IL
<RAOF> Hobbsee: I suggest in your response you consistently capItalise rAndom chAracters.
<\sh> yay..another re-installation of hardy in only 3 mins...ubuntu-minimal rocks
<RAOF> hunger: If you know this, why are you asking how to upgrade?  Either it works or it doesn't, and if it doesn't we don't much care yet :)
<lucent> \sh: are we talking about a "netinst" version of Hardy?
<hunger> RAOF: I have just checked what aptitude would do. And was wondering whether there are workarounds for these problems.
<lucent> my friend asked me today if there exists a netinst version of Ubuntu Server, I told him "no" thinking that there was none
<Yasumoto> hunger & RAOFL: gotcha, thanks
<\sh> lucent, nope..I'm taking about a nice tool of this Hetzner company...they have actually a nice little util named installimage...and it takes finally 5 mins to install ubuntu...including changing the installation template
<Hobbsee> RAOF: heh
<\sh> lucent, for simple installations over network you can use the netboot image...
<\sh> lucent, for real life mass deployment I advise looking at FAI
<lucent> good info, thank you
<pitti> yay, intrepid is sane again, perl works
<RAOF> hunger: I'm not sure if anyone in here has actually upgraded anything but a build-chroot to Intrepid yet.
<\sh> that reminds me, my new two servers arrived...2x DL365, 16GB+16GB, 2x Quad Core Opterons...yay
<hunger> pitti: It is? Aptitude still wants to keep back perl since all the libs are not upgradeable at this time.
<\sh> 8 Cores for ESX...I'm a lucky guy
<lucent> har... I saw a blog entry about "Completely Fucking Slow" (CFS) scheduler
<hunger> RAOF: Where is the fun in waiting till everything works?
<RAOF> pitti: Oh, does that make it debootstrappable?
<pitti> hunger: hm, WFM now, I could dist-upgrade, and now build-essential (which includes perl) installed
<\sh> pitti, you are my jesus with this message ;)
<pitti> RAOF: should
<RAOF> Yay!
<pitti> intltool still seems to be broken, though
<pitti> libxml-parser-perl
<hunger> pitti: Well, I have a somewhat non-standard system, so maybe it is just additional stuff.
<RAOF> hunger: Yeah, but where's the fun in installing before _anything_ works?
<\sh> if only our a.u.c. servers were letting me sync intrepid..
<hunger> pitti: Well, still 33 perl packages waiting to get build... lets see how things are once they are there.
<lucent> intrepid?  what's so hot about that
<RAOF> lucent: Goats are hot.
<lucent> I've run debian unstable before, mostly because it was more or less stable
<RAOF> The internet knows that!
<pitti> hunger: ah
<lucent> compared to say, any other OS I've used for the desktop
<pitti> hunger: libxml-parser-perl is current, though
<pitti> ah, it was built against the old perl
 * pitti does another rebuild
<stgraber> morning
<\sh> waaaaaa
<\sh> passwd -l root
<\sh> apt-get install mysql-server
<\sh> failed
<\sh> Unpacking mysql-server-5.0 (from .../mysql-server-5.0_5.0.51a-3ubuntu5_amd64.deb) ...
<\sh> Your account has expired; please contact your system administrator
<\sh> chfn: PAM authentication failed
<\sh> wth?
<\sh> well, sudo su - <-- tells me the same, sudo -i doesn't
<ion_> sh: Well, please contact your system administrator. ;-)
<\sh> ion_, hehe
<\sh> we do agree here, this shouldn't happen
 * \sh looks at mysql this evening...
<ion_> Do the passwd/shadow lines for root look ok?
<\sh> ion_, root is enabled during installation from the rootserver provider...
<\sh> ion_, passwd -l root locks root account and make it unusable...it should be the same as the default non-root install now
<\sh> i am logged in via useraccount , sudo -i to become root, and install the package...
<\sh> mysql-server does something during postinst..and runs into a pitfall, because passwd -l root is not the same as telling the passwd package somehow to not enable root
<ion_> Yeah, i'd assume that, but have you actually looked at passwd/shadow? I mean, is passwd/shadow broken by passwd -l root or is e.g. PAM broken?
<\sh> ion_, na passwd/shadow are looking sane
<\sh> ion_, and no...pam is not broken ;) because in the end everything works.
<pitti> yay, with that libxml-parser-perl upload, intltool becomes installable
<pitti> and cdbs
<TheMuso> The joys of the first weeks of a new release cycle.
<pitti> so everyone who would like to see their intrepid upload build, please compile a list of source packages (NO commas in between) and toss it to me, I can give them back
<pitti> (their uploads which FTBFSes because of intltool, that is)
<Hobbsee> pitti: can't you just get someone to do a mass giveback for anything that didn't build in intrepid?
 * \sh checks this afternoon after rollout of companies new product release
<TheMuso> pitti: jack-audio-connection-kit
<pitti> Hobbsee: yes, infinity can
<pitti> (and will)
<Hobbsee> pitti: right
<pitti> TheMuso: noted, will do
<TheMuso> pitti: oh and at-spi
<TheMuso> pitti: Thanks.
<norsetto> pitti: re. the intltool ftbfs, I only have gnome-radio to be given back
<pitti> norsetto: noted down, will do
<norsetto> pitti: danke
<pochu> pitti: could you also put gstreamer0.10 and libbeagle on that list to give back? re: intltool uninstallable
<pitti> pochu: done
<pitti> I'm still waiting for the new libxml-parser-perl to become really published
<pochu> sure, no hurry. thank you
<Ng> pitti: is apport supposed to get disabled at release? or am I on crack? ;)
<pitti> Ng: it is supposed to, and it's actually disabled for SIGSEGV-like crashes
<pitti> Ng: it's not yet for Python crashes, that's bug 222260
<ubottu> Launchpad bug 222260 in apport "apport_python_hook.py doesn't check to see if apport is enabled" [Medium,In progress] https://launchpad.net/bugs/222260
<Ng> pitti: ahh, that would explain why we're seeing python crash reports here, thanks :)
<cylex> hello.. I am wondering if anyone's home
<emgent> morning
<cylex> I had a question... if I want to develop something for Xwindows.. like a small app
<cylex> morning emgent
<cylex> What language do I use?
<cylex> C ok?
<cylex> or better question.. what languages most packages are written in.. for Xwindows?
<pitti> cylex: depends on which language you know and prefer; personally I find Python and pygtk rocking, and it's so easy and fast to develop small GUI apps
<pitti> cylex: C works fine, of course
<pitti> cylex: BTW, this is off topic here (not related to Ubuntu development, not even to Ubuntu in particular)
<cylex> Are there mailing lists or any development places I can go for help
<cylex> with this stuff
<pitti> cylex: maybe try http://library.gnome.org/devel/gtk-tutorial/stable/ if you want GTK?
<cylex> and is it difficult to code with C for GUI?
<tseliot> cylex: try asking in the "Programming Talk" section of ubuntuforums:
<tseliot> http://ubuntuforums.org/forumdisplay.php?f=39
<pitti> cylex: in C it is not more difficult, but much less comfortable than in scripting languages like Python or Perl
<lucent> cylex: Gnome lovers will strike me, but the Qt toolkit provides a solid multi-platform base of code in C++ language to work with for professional application development
<pitti> cylex: (you need much more code, since C is a low-level language)
<lucent> cylex: the other popular choice is Python language with Gtk+ bindings
<cylex> ok thanks, you guys been great help :)
<cylex> Is there chan on this network for programming talk?
<Le-Chuck_ITA> Hi there, I would like to prepare a patch to dexconf, but I don't understand: in /etc/X11/xorg.conf it says that the file is regenerated whenever xorg is upgraded
<Le-Chuck_ITA> on my system this does not happen even though I reconfigured X manually to get back the original file without my modifications
<pochu> cylex: generally or for a specific language?
<chmj> :'(
<cylex> pochu: C/gtk for ubuntu
<cylex> pochu: language specific
<lucent> what the heck is ctrl+Y in irssi hmm
<cylex> I think I got it.. I'll just join #c
<broonie> Has the process for doing SRUs for main changed in the past 6 months or so?
<pochu> cylex: and #gtk+
<Le-Chuck_ITA> nobody can tell me how to force xorg.conf to be updated in a patched package for xorg or x11-common?
<pitti> broonie: the procedure became a bit more streamlined, and we added a few acceptable cases
<pitti> Le-Chuck_ITA: no, because packages must not touch xorg.conf
<broonie> Hrm, right. Might be worth trying then.
<broonie> Thanks.
<pitti> broonie: see the current policy document
<pitti> it has been rearranged quite a bit for readability
<broonie> The last policy didn't look too bad either...
<broonie> But yes, I'll have a look.
<Le-Chuck_IT1> pitti: sorry for disappearing so suddenly, my laptop is breaking and sometimes it dies
<Le-Chuck_IT1> You said packages shouldn't touch xorg.conf but when is dexconf triggered? Never?
<pitti> Le-Chuck_IT1: oh, I just read your previous lines, when I replied I just saw the last one
<xivulon> seb128, had a quick look at changing the bookmarks yesterday night
<pitti> Le-Chuck_IT1: no, dexconf does not change xorg.conf automatically either
<xivulon> but it seems that the default bookmarks are hardcoded :(
<pitti> Le-Chuck_IT1: just if you manually do dpkg-reconfigure xserver-xorg
<Le-Chuck_IT1> pitti so why in xorg.conf it says that the file is not regenerated when manually modified? Is it just an old comment and should be removed?
<xivulon> seb128 would it be possible to change xdg-user-dirs-gtk so that it sources the default bookmarks from a config file?
<xivulon> unless you have a better idea on how to do this, that is
<pitti> Le-Chuck_ITA: ah, I think it might still be true
<seb128> xivulon: I guess everything is possible, it just require somebody doing the changes
<Le-Chuck_IT1> er... pitti: now it was pidgin that died
<pitti> Le-Chuck_IT1: bryce and tjaalton would know better
<xivulon> seb128 I guess by "possible" in this case I mean "appropriate for point release" :)
<Le-Chuck_IT1> thank you pitti
<pitti> Le-Chuck_IT1: ugh, what's wrong on your machine, that everythign crashes? bad rAM?
<seb128> xivulon: well, depends what you suggest to do
<Le-Chuck_IT1> pitti: this is a different laptop than the other one really :) This time I think it was a crash in pidgin since I pressed ctrl+w to close a tab
<xivulon> seb128, as you know, I would need to change the default bookmarks generated on first login
<Le-Chuck_IT1> pitti: the other laptop is dying for something related to temperature
<xivulon> I guess my idea would be to have some file in /etc/xdg or such that contains a list of default boomkark types
<seb128> xivulon: /etc/xdg/user-dirs.defaults for example?
<xivulon> yep, that contains the dirtype <-> dir
<xivulon> we need another similar file to give me a list of default dirtypes
<\sh> pitti, we need something to ensure, that if some build-deps are name-changing all packages source-build-depending on them are recompiled automatically
<xivulon> such as "VIDEOS PICTURES MUSIC... HOST"
<pitti> \sh: how do you want to do that? you need actual uploads for that
<seb128> xivulon: ok, so you suggest changing the way it's working
<xivulon> yep update.c
<pitti> \sh: and if the build deps actually change names, you need to modify the source
<seb128> xivulon: I'm too busy to look at doing that but if you come with a reasonable patch why not
<\sh> pitti: e.g. php5 -> php5-imagick , needs libWand.so.9 now (in hardy) but we have libmagick10 in our archives, and libmagick9-dev still available...
<xivulon> seb128: I am not on my machine now (and not too familiar with gnome code) but I will think of something
<\sh> pitti, php5 compiled against the old version, so the imagick extension does not work and failes to load
<seb128> xivulon: ok, cool
<xivulon> seb128 is there any xdg standard for bookmarks?
<\sh> pitti, looks like that libmagick9-dev still available, but there is no libmagick10-dev ... I wonder what happend actually
 * xivulon reading http://www.freedesktop.org/wiki/Specifications/desktop-bookmark-spec 
<pitti> \sh: yeah, that's very inconsistent and a broken name
<\sh> s/php5/php-magick/ ;)
<seb128> xivulon: not that I know about
<\sh> pitti, src imagemagick still builds libmagick9-dev ... but somehow we really need to ensure a rebuild of all rdependant packages after such an upload...
<xivulon> seb128: I suggest /etc/xdg/user-boomarks as a flat list of  dirtypes
<xivulon> seb128: I /etc/xdg/user-boomarks.defaults
<\sh> pitti, and kick the maintainer if imagemagick to not take care in the first place ;)
<\sh> s/if/of/
<\sh> now for an SRU for php-magick, to be just an rebuild ;)
<Le-Chuck_ITA> Is there a channel for talking about xorg bugs in ubuntu?
<dholbach> Le-Chuck_ITA: try #ubuntu-x or #ubuntu-bugs
<Le-Chuck_ITA> thanks dholbach
<\sh> hooray...I can create intrepid chroots ;) thx
<\sh> pitti, can you give-back ddccontrol? (libxml-parser-perl ftbfs)
<emgent> W: Failure trying to run: chroot /home/emgent/.chroots/intrepid dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10ubuntu3_i386.deb
<emgent> argh..
<emgent> italian mirror dont work fine
<\sh> emgent, it's not updated...
<\sh> emgent, this problem is resolved since yesterday/today
<emgent> i will try to use international mirror :)
<\sh> emgent, be careful of leningradskaya ;)
<emgent> :)
<calc> cjwatson: bug 186049 appears to be it was mentioned in the arstechnica review
<ubottu> Launchpad bug 186049 in galago-sharp "System.DllNotFoundException: libgalago" [Undecided,Confirmed] https://launchpad.net/bugs/186049
<cjwatson> calc: yeah, that was why I stuck an 8.04.1 milestone on it
<cjwatson> I got to it from arstechnica
<calc> ah ok
<cjwatson> looks easy to fix and worth fixing
<\sh> grmpf...a lot of stuff ftbfs because of this intltool/perl problem earlier on...more difficult that it hit on most of  auto-synced packages
<cjwatson> that's what mass give-backs are for ...
<\sh> cjwatson, for sure...but it's hard to tell now, if packages are already NEWed + building or NEWed + FTBFS ... the webfrontend is not as nice as it could be ;)
<cjwatson> that much is pretty clear from the builds page for the relevant package version
<asac> siretart: wpasupplicant 0.6.x - is it safe to just use the debian version or are there any changes you would like to add/keep?
<\sh> cjwatson, yes..when you click on the version in <release> first...clicking through the buildlogs to find out why etc...quite long ways for a simple info ;) anyways..
<siretart> asac: I was about to ask you, no, AFAIK we can and should just sync the debian package
<siretart> asac: if you need to do some changes to the package, let's please do them to the debian package directly, okay?
<cody-somerville> Is the UDS "business" or can I say I'm a "tourist"?
<asac> siretart: sure. if i add you to ~network-manager team would you upload updates there for the next few weeks (until i have sorted some grave issues for NM 0.7)
<asac> to PPA i mean
<asac> siretart: i have a question though. how is wpasupplicant started? for me it first didn't start, but then (i don't remember exactly what i fixed) it started automagically
<siretart> asac: it depends. from the wpasupplicant maintainers POV, the recommended way is via ifupdown
<siretart> see /usr/share/doc/wpasupplicant/README.modes for details
<siretart> NM however is starting it on its own behalf
<siretart> and AFAIUI, NM 0.7 is supposed to use this dbus activation service thingy, which I haven't seen in action yet
<siretart> does this answer your question?
<asac> yes its dbus
<asac> no, but i'll look closer and ask later i guess ;)
<siretart> may I ask why you suggest uploading to the ~network-manager PPA first instead of directly into intrepid?
<siretart> or do you want to develop in hardy first?
<siretart> asac: if you want we can also phone about that
<asac> i am on hardy still yes.
<siretart> same here
<siretart> I have uploaded a wpasupplicant package in my personal PPA. you should be able to just copy it from there
<asac> siretart: cool, would you be available tomorrow? i still need to actually know for sure what i am talking about :)
<asac> (phone call)
<siretart> I should be. ping me on irc first to be sure
<asac> awesome
<pitti> \sh: noted; let's see whether it finally got published
<pitti> \sh: ah, seems to
<\sh> pitti, thx...
<\sh> is zope3 working now with py2.5 or is it still only usable with 2.4?
<pitti> \sh: I gave back one arch:all test package for now, building now; cross your fingers!
<\sh> pitti, I'll pray to the mighty sbuild ... somehow right now everything is blocking my merges/syncs mostly because of missing new package releases ... and in the meantime fighting with stupid commercial software a la adobe flash media server is not even better
<pitti> Status:   Successfully built
 * pitti does the intrepid dance
 * pitti flushes his give-back list
<TheMuso> pitti: I've just discovered that ardour, a package that got autosynced, was hit by the libxmlparser-perl issue discussed earlier. That can be given back too while you're at it.
<seb128> is launchpad down?
<elmo> seb128: works for me?
 * ogra points pitti to dia and italc while he is at it
<TheMuso> seb128: No problem here.
<seb128> elmo, TheMuso: thanks, looks like an url copy error, works now
<pitti> TheMuso, ogra: done
<ogra> gracias :)
 * ogra wnders if we could/should drop hwdb-client from the archive in intrepid ... there are still bugs rolling in for it
<TheMuso> pitti: thanks.
 * ion_ hopes X in intrepid will gain input hotplug and MPX. Iâm going to buy a remote mouse-keyboard combination for sofa usage and keep the current keyboard and mouse on the desk.
<ogra> ion_, works for me since gutsy with a wirelesss usb media keyboard
<ogra> and didnt break in hardy
<ion_> ogra: I mean, iâd really love to have separate focus for both keyboard/mice pairs.
<ogra> ah
<jcwinnie> Hardy Heron is a marvelous OS and aptly named because it can stand there and do nothing for evah!
 * cody-somerville blinks.
<siretart> hm. since the upgrade to intrepid, my laptop heats up way more. did anyone notice that as well on his laptop?
<ion_> This insight was provided by: having accidentally dropped the baby ten years ago.
<cjwatson> ion_: I think that's needlessly harsh
<ion_> cjwatson: Sorry, didnât mean to be malicious.
<pitti> seb128: btw, intltool buildd issue in intrepid is solved, happy uploading
<Hobbsee> \o/
<pitti> infinity: I think now is a good time for a mass-give back in main
<infinity> pitti: Kay.  Doing so.
<pitti> infinity: cheers
<infinity> pitti: When you say "solved", you mean "completely published on drescher", right?
<pitti> infinity: yes, I just gave-back some of the failed packages, and they worked
<pitti> infinity: well, the Perl issue anyway
<infinity> pitti: Alright.  The queues on /+builds just got a lot longer again.
<pitti> :)
<ogra> sigh
 * ogra watches dia explode again on other missing packages now
<ogra> i guess i'll wait a week asking for the next give back
 * ogra sighs about tuxtype merge ....
<Hobbsee> what about it?
<ogra>   * use dh_desktop to add maintainer script fragments to call
<ogra>     update-desktop-database
<ogra> from the latest debian changelog
<ogra> but there is no .desktop file in the whole package
<ogra> (it never had one)
<ogra> i'D love to drop our patch tat creates one if i knew debian added on
<ogra> e
<Hobbsee> interesting.
<ogra> oh, debian uses ours in the same place
<ogra> thats why it didnt show up in the patch
<Riddell> "W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/intrepid/universe/binary-i386/Packages.bz2  Hash Sum mismatch" humph
<cjwatson> testing germinate-update-metapackage changes is no fun with a loaded archive.u.c
 * ogra wonders when mom runs again, all stuff i uploaded yesterday still shows up
<andrew___> Hi, I'm Andrew Sayers.  Martin Owens wanted to talk to me - are any of you him?
<cjwatson> andrew___: doctormo
<cjwatson> ogra: stuck on archive.ubuntu.com coming up to date, which is having serious load trouble
<ogra> ah, still ?
<cjwatson> IS are aware, but we have those pesky users
<ogra> i thought that was solved
<andrew___> cjwatson, thanks.  I'll nudge him.
<ogra> well, i using a localhos apt-proxy here in pbuilder and for the chroots so i dont really notice slowness anymore
<ogra> s/i/i started/
<doctormo> hey andrew___
<doctormo> andrew___: thanks for popping by, email can be fustrating at times.
<doctormo> So our plan is to have vnc-x11 running over the reverse ssh tunnel. my guess is that this is a similar plan as yours
<doctormo> the ssh part is set up by creating a support user, creating a random password (putting it in .bashrc as an echo) using the helpers public ssh keys to get access over the tunnel. keys are transmitted over jabber (ssl)
<andrew___> Yeah, our plans have gone a little further since then :)
<andrew___> I've not really talked to Justin about this, but I'm personally most interested in the case of nearly-broken systems.
<doctormo> As you may have noticed, I've been working on the support tool side of things.
<andrew___> Busted video card, dist-upgrade cancelled halfway, etc.
<andrew___> Where you really can't make many assumptions at all about the system.
<andrew___> (e.g. Python working)
<doctormo> andrew___: broken video card means a trip to the nearest techy, not a support call
<andrew___> Yeah, once you've confirmed that's what it is.
<doctormo> Anything that would undermine the system, we would ask users to load a live cd
<andrew___> That's another thing - we're looking at the "technical friend" case...
<doctormo> andrew___: meet leftyfb, a technical friend who is my case.
<andrew___> As in, you get a phone call from a friend of yours saying "hey, you know something about Linux, right?  Well, my computer doesn't work.  Please fix it"
<andrew___> Hey leftyfb.
<leftyfb> hi
<leftyfb> i've already done all this a few times using scripts ... works well
<doctormo> andrew___: I'm sure we're all used to taking those calls, but leftyfb has a whole load of people doing that to him.
<andrew___> leftyfb, are they available online somewhere?
<leftyfb> nope, i write them up as needed .... all it does is ssh back to me and create a reverse tunnel
<andrew___> Ah right.
<doctormo> So, we were talking about the very broken case leftyfb, where the computer has a hardware fault or isn't software sane.
<leftyfb> doctormo's project will simplify this with a nice gui, but also provide the ability to troubleshoot some things without needing full ssh access. It also audits the whole process with a ticketing system
<leftyfb> oh
<leftyfb> uh
<leftyfb> nothing you can do there
<andrew___> My original impetus for this was a friend that had a power cut (or similar) halfway through an upgrade to 8.04.
 * Hobbsee wonders what happens if ssh is dead.
<leftyfb> unless the tool is included on the live cd
<leftyfb> or we put one out
<doctormo> Hobbsee: we can still help via chat
<Hobbsee> doctormo: i guess you can't do anything if nm decides to fall over.
<andrew___> Hobbsee, use socat, or cryptcat, or netcat, or try to resurrect ssh with custom config files...
<doctormo> Hobbsee: yep
<leftyfb> Hobbsee: I think we talked about that ... doing some basic testing of an inet connection and either fixing it if it's absent or forcing one for the session
<andrew___> The actual code we're looking to write is looking like it'll be a general mechanism for creating a session on one computer, accessible from another, using whatever tools are available/working.
<leftyfb> what about adding in your own ssh daemon and making x11vnc a dependency of the tool?
<andrew___> Again I haven't talked to Justin about this, but I'd like to have a tool with no explicit dependencies, then metapackages called something like technical-friend/nontechnical-friend that depend on a useful collection of tools.
<doctormo> andrew___: I didn't want to get too far into the broken use cases, there is only so much you can mitigate before you end up http://xkcd.com/416/
<andrew___> True.  I'm not planning to go nuts about that sort of thing until there's some evidence for what actual problems people have in real life.
<doctormo> andrew___: there is no reason why a cli version of our support tool couldn't be made. your scripts could download deps if broken.
<doctormo> but I'd want to mop up these things after the first release
<andrew___> True, although it's overkill for a friend that you're already talking to on the phone.
<andrew___> Would you agree with this general assessment:
<andrew___> You want to create a Jabber-based support tool that makes it easy for a sitting group of experts to debug the computer of someone they don't know, and in order to do that, you need a tool to start SSH or VNC sessions, although that's not really where your technical interest lies.
<doctormo> andrew___: not quite, leftyfb knows all the people he helps but would still use this tool
<leftyfb> this tool is for people I already know, at home, who need help from me and need to give me access to logs/etc or full ssh/vnc access to help troubleshoot their problem. You don't create scripts for helping people over the phone.
<doctormo> andrew___: and, past tense. Have created a jabber-based...
 * Robot101 would like to point out that Telepathy and Empathy provide excellent infrastructure for such a tool...
<leftyfb> jabber is more established
<doctormo> leftyfb: er, they're just a set of gtk widgets and libs for chat
<Robot101> yes, telepathy uses it, amongst other protocols
<doctormo> leftyfb: imagen libpurple but for gnome ;-)
<Robot101> we've actually got branches to Empathy which let you click a buddy and share your desktop with him
<Robot101> telepathy deals with nat traversal etc for you, you just ask it for a "stream tube"
<leftyfb> so this would be instead of using python to create the client which doctormo has already done?
 * ogra just read steam tube above :)
<Robot101> mm, well there are benefits to integrating with an existing mechanism of communicating with people
<leftyfb> i'll let doctormo handle that part of it :)
 * Robot101 thinks this is very much a use case we'd be interested in addressing
<leftyfb> my only concern is the security and functionality of the tool, now how it's made :)
<cody-somerville> crap
<doctormo> Robot101: It's an interesting idea, I'd need convincing since I've spent time getting pyxmpp working with all the business logic we have.
<Robot101> so you can be IM or VOIP chatting with someone and then they can say, oh yeah this pops ups, what do I do
<Hobbsee> ogra: you can have steam if you want.
<Hobbsee> ogra: but it's probably not useful.
<Robot101> then you can just click share desktop, and the other guy gets a libnotify, clicks OK, and is then in the VNC viewer...
<ogra> Hobbsee, telepathic steam :)
<cody-somerville> If I cancel a dput upload in progress, what are the implications?
<doctormo> ogra: sounds like a doctor who
<ogra> haha
<Robot101> also it works over link-local contacts using the bonjour backend
<Robot101> that being somewhat the purpose of the abstraction :)
<doctormo> Robot101: We're doing fancy stuff with ticket handeling, auditing and various other things. Useful for one to one help, though community help use case is not there.
<Mithrandir> cody-somerville: it gets thrown away.
<cody-somerville> Mithrandir, \o/ cheers.
<doctormo> But it sounds interesting, maybe future versions could use it, though I'd not want to risk changing direction now that we're so close to finishing the first version
<Robot101> doctormo: reading scrollback a bit, it sounds like you're solving a slightly different set of problems
<leftyfb> remote support that's easy for the user to install and use to give us access to help them
<Robot101> doctormo: but I just thought I should let you know there are some options for the p2p/interactive support case where you're already using IM/VOIP to talk to someone
<Robot101> seems to me like adding new users to the system and requiring sshd to be installed is kinda overengineering isn't it?
<leftyfb> nope
<leftyfb> ssh = ability to fix anything
<hunger> Robot101: Incoming connections are blocked in most home setups.
<leftyfb> lots of other programs add users/groups ....   vmware for one
<Robot101> hunger: exactly why you should leave this to the NAT traversal experts :D
<leftyfb> hunger: this works off reverse ssh connections
<leftyfb> no inbound ports needed
<hunger> leftyfb: Oh, great:-) Then why do you need a sshd?
<leftyfb> uh
<Robot101> oh, maybe I misunderstood
<doctormo> hunger: how would it do it otherwise?
<leftyfb> you want me to answer that?
<leftyfb> :)
<Robot101> does the user's system need sshd installed?
<leftyfb> yes
<leftyfb> how else are you going to connect to them?
<Robot101> so the helper ssh's to the user's system?
<andrew___> leftyfb, ssh client != ssh daemon
<hunger> Does the outgoing SSH do port forwarding so that somebody can via that?
 * leftyfb sigh
<Robot101> or the user ssh's somewhere, with a port forward, so the helper can ssh back?
<doctormo> andrew___: can you create a reverse tunnel without sshd?
<andrew___> What are you referring to as a "reverse tunnel" here?
<Robot101> doctormo: (yes, use a stream tube from telepathy :D)
<doctormo> hunger: no port forwarding
<doctormo> Robot101: no steam tubes ;-)
<Robot101> can you explain in terms of a sequence of connections (who connects to who) how it'd work?
<leftyfb> customer ssh's to our remote/secure server using generated ssh keys using an account that doesn't have shell access. This creates a reverse tunnel back to their local sshd service. We, as support, login to the server and ssh to the localhost port created by the reverse ssh tunnel giving us access to the customers account. All automated. Customer see's a pretty chat windows with a "remote access button". We click connect and up comes gnome
<leftyfb> -terminal with the connection open.
<doctormo> Robot101: user -> server, helper -> server -> user
<Robot101> this seems alarmingly overengineered. cool. :)
<leftyfb> overly secure is the word you are looking for
<Robot101> encrypting things more times isn't more secure, and nor is granting remote shell access to people without being able to supervise (or even understand) what it is they're doing
<doctormo> Robot101: I'm larry wall lazy
<andrew___> If you're assuming the user has a GUI fired up, why not use VNC?
<Robot101> andrew___++
<doctormo> I'll let leftyfb handle these questions
<leftyfb> I use this method all the time just fine
<leftyfb> we don't always need VNC access
<leftyfb> in fact, VNC is just going to slow most troubleshooting down
<leftyfb> most things can be fixed via ssh
<Robot101> VNC has the benefit that the user can /see/ what the helper is doing
<doctormo> We want to use vnc access to show the user how to do things, not to do things ourselves
<leftyfb> if the user request that, then that's what we use
<andrew___> Also, they can type in their passwords without telling you them.
<leftyfb> but it's not the default method of troubleshooting
<leftyfb> a lot of users don't care
<leftyfb> we will have a local account with sudo access
<leftyfb> we don't need their passwords
<leftyfb> again, this isn't the first program to create local accounts/groups to get things done
<andrew___> That's fair enough for people that know you, but training users to hand out root access to people online they've never met seems like a bad plan.
<doctormo> Robot101: We use auditing, although users don't generally mistrust their geeky friends
<Robot101> it's the first program I've heard of which automatically grants local root access to 3rd parties :P
<Robot101> and also installing a sshd service behind the user's back, unless you bind it localhost only or something, seems extremely undesirable
<doctormo> Robot101: who said anything about automatically?
<Mithrandir> uh, is this a package which is going to go into the normal repositories?
<leftyfb> andrew___: people give M$ compete access to their computer when doing remote support. This support tool is meant to be used by groups/companies providing support to a large customer base
<Hobbsee> Mithrandir: supposedly.
<leftyfb> it will be bound to localhost
<Hobbsee> Mithrandir: i'm sure it will show up as forums crack for a while
<leftyfb> the sshd
<Robot101> doctormo: automatically as in "Do you want foo to fix your system? [ Yes ]" is sufficiently automatic
<Hobbsee> fix == sudo rm -rf /
<leftyfb> it'll be a custom sshd access only accessible via pregenerated keys and via localhost only
<Robot101> oh well. I prefer the idea that you can hook these things into a conversation with someone, and not let them do things you can't see.
 * Hobbsee grins maliciously
<Robot101> which could be sharing a pty and exporting it over a socket, or VNC
<doctormo> Robot101: that's because you know what your doing
<Hobbsee> "i'm a core dev, of course i'll fix your getdeb'enated or automatixenated machine!"
<Robot101> doctormo: yes, not letting 3rd parties cheese around with my system :P
<andrew___> Robot101, speaking of PTYs, can Telepathy do that on its own?
<doctormo> Robot101: Some people don't mind
 * Mithrandir makes a mental note to get that package blacklisted from all his hosts.  Seriously, shipping a package that includes a) pregenerated ssh keys and b) new user with full sudo access?  Are you guys completely out of your mind?  What happens when you lose the private SSH key to a disgruntled employee or a cracker?
<leftyfb> ssh access is preferable and MUCH quicker for someone that just wants to finish their report and doesn't care how the person is fixing their computer
<Robot101> Mithrandir: yeah seriously
<doctormo> Mithrandir: thanks for joinging the discussion constructivly
<Robot101> andrew___: no, it'd be something the "support app" would hook up and provide to telepathy
<Hobbsee> doctormo: the guy is an archive admin, FYI.  and also a core dev.
<Mithrandir> to quote somebody much smarter than me, the interesting bit about security system is not how they work, it's how they fail.
<Hobbsee> doctormo: you may not want to blow him off like that.  he might end up reviewing your package, fi it goes into ubuntu.
<Hobbsee> it's called karma.
<Robot101> andrew___: telepathy itself is plumbing, it abstracts different protocols and types of communication. one of them is "tubes" for plugging arbitrary apps together.
<doctormo> Hobbsee: I'm not partial to being treated baddly even by karma gods
<andrew___> Robot101, Yeah, I'm starting to understand.  You can rip on my idea later ;)
<Hobbsee> Mithrandir: i'm assuming they generate the ssh keys on the fly, though.
<Hobbsee> Mithrandir: they'd have to...
 * cody-somerville is scarred to ask what is being discussed.
<Hobbsee> cody-somerville: see ubuntu-devel-discuss ML
<Robot101> cody-somerville: remote support tools
<Mithrandir> Hobbsee: oh, how would you do that?  You'd need to do secure key exchange somehow, then.
<Hobbsee> cody-somerville: system recovery by ssh, basically, for non-secure users.
<Robot101> andrew___: in this case, telepathy would use XMPP to say you'd started a local VNC/whatever service (which could be "Share my desktop" or "Share a terminal" or such)
<Hobbsee> Mithrandir: dunno - send by email / other IM is all i'm really coming up with.  But that's still better than pregenerated.
<doctormo> Hobbsee: not seeing what you guys are talking about, maybe not required?
<Mithrandir> Hobbsee: yes, it's better than pregenerated, but it didn't sound like what leftyfb/doctormo was talking about.
<cody-somerville> I've never found it very difficult to tell someone how to install openssh-server and how to add a new account for me.
<cjwatson> doctormo: if you guys are trying to solve the key exchange problem, I suggest reading the several decades' worth of cryptographic literature on the subject ... it's not a trivial problem
<cody-somerville> Or how to get them to enable the remote desktop
<doctormo> cjwatson: nope
<Mithrandir> doctormo: prove me wrong by showing me a page with a thorough design and analysis of the security architecture, then.
<Robot101> andrew___: and then when the remote user accepts, it'll signal over XMPP and do some negotiation (TCP, NAT traversal, tunnel via the server) to open the connection
<doctormo> not trying to solve that
<cjwatson> doctormo: it sounds like a necessary element
<hunger> KDE has a system where a user generates invitations (valid for 60min) that can get submitted to "support guys" via mail or whatnot.
<cjwatson> doctormo: if you aren't trying to solve it, the system seems fatally flawed ...
<Mithrandir> cjwatson: either that or ship pregenerated keys with all the fun that entails.
<Hobbsee> Mithrandir: true
<hunger> Whoever has that invitation can get a VNC session.
<Hobbsee> doctormo: you have to have some way of generating the key, and getting it to the clued user.
<doctormo> Mithrandir: remind me what the keys are for again?
<Hobbsee> doctormo: root access on the system.
<ogra> doctormo, safety :)
<Mithrandir> doctormo: you need to log into the localhost-only ssh?
<Mithrandir> doctormo: technically, you could use a preset password, but that would be even worse.
<doctormo> public key of the helper copied over to client on elective basis? must be missing something since you guys seem very concerned
<ogra> well, without that you can as well use telnetd
<Hobbsee> doctormo: because listing the private key in a publically available source is akin to suicide.
<Hobbsee> doctormo: which appears to be what you're thinking about doing.
<doctormo> Hobbsee: I didn't mention private key
<Hobbsee> doctormo: so, how does the private, and public key, get generated?
<doctormo> Hobbsee: what public private key?
<cjwatson> doctormo: I think what we're missing is how the server gains access to the user's machine
<Hobbsee> 2 keys.
<Mithrandir> doctormo: yes, the public key.  How do you get it onto the system and copied into this brokensystem:~helper/.ssh/authorized_keys?
<Mithrandir> s/this/the/
<doctormo> Mithrandir: xmpp
<Mithrandir> doctormo: so you're vulnerable to mitm attacks then.
<doctormo> Mithrandir: jabber using ssl? odd
<Mithrandir> to a host where you ship the ca certs used for the host in the package itself and do proper certificate validation, then?  In that case, who are running the CA?
<leftyfb> the jabber connection is SSL and the ssh is encrypted. What mitm?
<Mithrandir> SSL isn't magic powder you can sprinkle on a TCP connection to make it secure, it takes a little bit more than that.
<hunger> Mithrandir: The community of course;-)
<Mithrandir> but I have to go now.  Drop me a link to a design document about this and I might go poke at it and see if I can find weak spots.
<doctormo> Mithrandir: your skill may be required
<cjwatson> the CA here is a great big target for compromise
<hunger> Who will do the support by the way?
<Hobbsee> require all you like.
<Hobbsee> hunger: them, methinks.
<cjwatson> Hobbsee: easy ...
<Mithrandir> (tfheen@ubuntu.com or just highlight me here.)
<hunger> Hobbsee: Them, who?
<Hobbsee> hunger: it's not an #ubuntu issue unless it gets in the archive, afaik.
<leftyfb> the client generates their own private keys on installation, then sends the public key via xmpp to the server via our "bot" which places it in the proper ~/.ssh/authorized_keys for the session and removes it when the session is over
<Hobbsee> hunger: those who are writing the system
<Hobbsee> leftyfb: bot?
<leftyfb> jabber client
<doctormo> Now that we've struck fear into the hearts of ubuntu developers.
<Hobbsee> leftyfb: how does that scale?
<leftyfb> scale?
<leftyfb> speak english please
<hunger> doctormo: Assuming that the system is safe: Who will do the support?
<cjwatson> leftyfb: "scale" is perfectly normal English in system design
<Hobbsee> leftyfb: as in, how will it work with 1000000000 users, for eg?
<doctormo> hunger: business is the main candidate
<hunger> doctormo: Which business? Is there a company doing the support?
<doctormo> hunger: That is probably the problem right there.
<hunger> doctormo: Are you developing this for a company?
<leftyfb> Hobbsee: what would the difference be with supporting 10 users as opposed to 1000? If it gets beyond 1000, of course you need to think about multiple servers and load balancing
<cjwatson> doctormo: is the server capable of sending essentially arbitrary commands to the client (upon request by the helper)?
<doctormo> hunger: no
<doctormo> cjwatson: no
<Hobbsee> leftyfb: right, so this would be a service you were charging to your users, running on your HW, i take it.
<cjwatson> doctormo: is it capable of sending any commands to the client?
<doctormo> cjwatson: no
<hunger> How do you select the helpers if this is a community effort?
<leftyfb> Hobbsee: for right now, i'll be using this to support my own customers who I do consulting for. We as a LoCo team will also use it as a group to support people we come in contact with.
<leftyfb> hunger: carefully
<cjwatson> doctormo: I think I'm missing how it's useful, then; I thought the point of this was to be able to remotely extract information from the client system
<Hobbsee> cjwatson: it's to remotely fix it - adn to set up an ssh tunnel so they can.
<leftyfb> signed pgp keys and CoC signing is required
<doctormo> cjwatson: It's able to send information upon request, the supporter tool is able to send requests for information and requests for access.
<cjwatson> doctormo: so it must be capable of sending some kind of command to the client, then? (Note I don't necessarily mean shell command here.)
<doctormo> cjwatson: there is a difference between the server and the supporter client.
<doctormo> which do you mean
<cjwatson> err, I don't know your precise terminology. I mean the client as in the end user's system (as a whole) and the server as in the thing that both the client and the helper connect to.
<doctormo> cjwatson: ok, the server is not able to send commands, it can send information to both the supporter (helper) and the suportee (client) upon request
<doctormo> It's actually a bot program
 * Hobbsee is greatful that e l m o has not been highlighted about this.
<cjwatson> I'm not bothered about the implementation; I want a data and command flow diagram really
<cjwatson> doctormo: how is information extracted from the client system?
<doctormo> cjwatson: I see, supporter tool sends request to client tool, client tool asks user if it's ok. information is sent back.
<cjwatson> what format do the requests take? They must have to be pretty general
<doctormo> cjwatson: not that general, for instance to request logs: "@request logs xorg" would ask for xorg logs (various) which are pre-defined.
 * Hobbsee assumes that's after the authentication.
<cjwatson> I think what is confusing us is that you and leftyfb seem to be talking about radically different things
<cjwatson> leftyfb is saying things like:
<cjwatson> 16:23 <leftyfb> we will have a local account with sudo access
<cjwatson> 16:23 <leftyfb> we don't need their passwords
<cjwatson> 16:25 <leftyfb> andrew___: people give M$ compete access to their computer when doing remote support. This support tool is meant to be used by groups/companies providing support to a large customer base
<cjwatson> 16:25 <leftyfb> it will be bound to localhost
<cjwatson> 16:25 <leftyfb> the sshd
<cjwatson> 16:25 <leftyfb> it'll be a custom sshd access only accessible via pregenerated keys and via localhost only
<doctormo> cjwatson: I'm a programmer, leftyfb is a sysadmin we talk on different levels.
<andrew___> doctormo, what does "@request logs ../../etc/shadow" do?
<cjwatson> that isn't "different levels", that's a completely and utterly different designm
<doctormo> andrew___: sends an error
<leftyfb> i'm talking about ssh access
<andrew___> doctormo, Good :)
<cjwatson> leftyfb: so I think we should be interrogating you about your plans, rather than doctormo about his :-)
<leftyfb> doctormo: is talking about the programs ability to send logs/etc to the helper without giving ssh access
<cody-somerville> leftyfb, If you want ssh access to someones computer, get them to install the openssh server and create you an account. It is very very easy already. What use case are you trying to fullfill here?
<cjwatson> leftyfb: how do you plan to arrange for safe authentication?
<Hobbsee> cody-somerville: the 'user is clueless, can't do that'
<leftyfb> I don't have much part in the design/implementation of the requesting logs part, only the giving ssh access part
<Hobbsee> cody-somerville: the idea of one-click-authentication, etc.
<Hobbsee> (i assume)
<cody-somerville> Hobbsee, No matter how clueless the user is, they can type in what you tell them to pretty easily.
<Hobbsee> s/authentication/implementation/
<cjwatson> I'm much happier with what doctormo outlined above than anything that involves "type in what you tell them"
<leftyfb> cody-somerville: my grandmother doesn't want to install ssh, generate keys, set it up for localhost access only, and ssh to me, creating a reverse ssh tunnel
<doctormo> cody-somerville: I've done remote support a lot, it's not that easy behind a router.
<Hobbsee> cody-somerville: actually, they can't.  i've seen all sorts of users doing strange things, when you tell them to type in some commands.
<andrew___> cody-somerville, it's not so much a matter of clueless, as good at describing things.
 * _MMA_ hates the idea that"ï»¿users are clueless" and the dumbing-down that goes on because of it. But that's a topic for a different time.
<Hobbsee> leftyfb: how does the localhost access only?
<Hobbsee> er, stuff work?
<cjwatson> type in what you tell them might involve "sudo apt-get install symlinks; sudo symlinks -d /" for example, which looks just as innocuous as many other commands one might request that a user issue, but will subtly screw up the user's system
<Hobbsee> by definition, isn't the idea that it's remote, ssh'ing in?
<cody-somerville> leftyfb, and all of that is required why
<cody-somerville> ?
<leftyfb> Hobbsee: you can configure sshd to only listen on localhost
<cody-somerville> doctormo, true.
<Hobbsee> leftyfb: yes, i know, but then, if you can't physically get to the box, you can do nothing.
<andrew___> cody-somerville, For example, I was helping out a fairly technical friend lately, and we went round in circles for about 15 minutes because he hadn't understood that lines beginning with a '#' are comments
<leftyfb> cody-somerville: security, simplicity as far as the user is concerned ... no firewalls to mess with
<cjwatson> security is not achieved simply by adding ssh to the equation
<Hobbsee> leftyfb: if you're going to do that, then why not just get the user to login, sudo -s, put in their password, then tell them to go make coffee for a while?
<andrew___> (Or indeed that '#' is a character that needs spelling out)
<cjwatson> which is why I asked the question above "how do you plan to arrange for safe authentication?"
<leftyfb> cjwatson: security is achieved by ONLY allowing ssh to the customers machine via keys and a reverse ssh tunnel
<cjwatson> leftyfb: how are those keys distributed?
<doctormo> cjwatson: I'll get you a diagram, I think I have one
<hunger> leftyfb: Where do the keys come from?
<cjwatson> leftyfb: I'm interested in cases where there is no customer<->consultant relationship as well
<Hobbsee> cjwatson: by the xmpp, which is vulnerable to mitm attacks, as Mithrandir said.
<Hobbsee> hunger: presumably they get generated on first launch.
<cjwatson> Hobbsee: please let them answer the questions I've posed, rather than answering for them
<leftyfb> I already said that ... the ssh keys are generated at install time .. the public key is then sent via XMPP to the server where the "bot" on the server puts the keys into the proper place for the session and removes the keys after the session is closed
<hunger> Hobbsee: Can't work... the consultant will need to have the private key so that he can authenticate.
<Hobbsee> cjwatson: apologies, i was effectively regiving answers discussed above.
<leftyfb> Hobbsee: the public key is sent to the server, not the private key
<Hobbsee> leftyfb: i think that was directed at hunger
<hunger> leftyfb: How does that allow the consultant to gain ssh access to the requestors computer?
<doctormo> There are two instances were public keys are transmitted
<cjwatson> leftyfb: the supporter needs to have a private key that grants authentication to the client system. How does the server ensure that the public key matches a trusted user?
<cjwatson> s/user/supporter/
<leftyfb> our public keys are either prepackaged or uploaded to the client at install and/or via xmpp for the session ... same drill
<doctormo> leftyfb: not quite
<leftyfb> sorry, not at install
<cjwatson> leftyfb: what happens the first time the server is compromised and starts allowing evil public keys?
<leftyfb> during the session
<Hobbsee> hunger: er, the consultant generates the keypair, then sends it to the broken system, not the other way around.
<doctormo> cjwatson: the public key for the supporter is transmitted over xmpp to the client.
<hunger> Hobbsee: Yeap. But I do not get how it gets there.
<Hobbsee> hunger: that's the discussion now
<cjwatson> doctormo: that simply pushes the authentication problem one step back
<doctormo> cjwatson: probably
<hunger> Hobbsee: Yeap... that was what I was trying to ask, too:-)
<cjwatson> you still have to trust that the supporter is Alice Aidgiver, not Evil Eye
<cjwatson> s/Eye/Eve/
<leftyfb> cjwatson: what happens when the support/client/server/canonical is compromised?  We work on not letting that happen.
<cjwatson> so you have to authenticate that somehow
<cjwatson> leftyfb: Canonical has a key rollover procedure for compromise of the central archive key
<doctormo> cjwatson: The supporter doesn't send the public key, the server does. the server has a list of good guys
<cjwatson> leftyfb: I expect the same of any similarly-critical system
<cjwatson> doctormo: how is that list maintained?
<Hobbsee> cjwatson: out of curiosity, is that documented publically anywhere?  i'd be interested in seeing what that is.
<doctormo> cjwatson: at the moment, by hand
<cjwatson> Hobbsee: no, though it probably should be (with the list of people you need to mug excised)
<Hobbsee> cjwatson: heh, yes.
<cjwatson> so I think this probably can be made secure, but it does need a competent security review, and for its proponents to be willing to make changes as a result of that review as necessary
<doctormo> cjwatson: I agree
<Hobbsee> oh, ffs.
<doctormo> I'm not a security expert and I would a fool to sugest otherwise.
 * Hobbsee goes off to rant elsewhere.
<cjwatson> and you *will* encounter problems. At some point you have to assume that a supporter will go bad.
<leftyfb> cjwatson: public keys will be flushed from the customer's system and the server each time a session is created and repopulated with the public key from the supporter uploaded via xmpp on the fly (yes doctormo ,this is new but doable)
<doctormo> cjwatson: yes, I've thought about that.
<doctormo> not enough to solve it though
<leftyfb> that sound better?
<cjwatson> leftyfb: the key rollover problem I refer to is that, when the server is compromised, you need to have a trusted way to re-secure all clients
<cjwatson> because you will have to regenerate the keys used to authenticate the server to the client
<leftyfb> if the server is compromised, they get nothing. No ssh private or public keys, no access to ssh to anywhere using passwords
<cjwatson> err
<doctormo> leftyfb: no, your suggestion won't work
<leftyfb> ?
<cjwatson> that can't be true, given what you've said
<cjwatson> the client is given supporter keys by the server
<cjwatson> ergo, the server has a means to authenticate its identity to the client
<cjwatson> this further implies that a compromised server can feed evil supporter keys to the client
<cjwatson> (only once a client connects of course, but that's just a matter of time0
<cjwatson> )
<doctormo> cjwatson: those keys are use once, if the server is recovered the effects are null
<cjwatson> doctormo: we're talking about different keys
<doctormo> I think so
<cjwatson> I don't mean the session keys for an individual client<->supporter session
<cjwatson> I mean the keys that protect the exchange that delivers new session keys
<cjwatson> there must be such keys
<doctormo> Over ssh or xmpp? just to be sure I understand
<cjwatson> transport is unimportant
<cjwatson> at the level of protocol design, details of transport are a distraction and best ignored
<doctormo> cjwatson: no I mean not in tech terms. in our context where we are using ssh or where we are using xmpp.
<cjwatson> I honestly haven't followed in enough detail to know and it doesn't matter to my question
<xivulon> out of curiosity, is this a different problem from a (trusted) repo providing packages as opposed to keys?
<cjwatson> xivulon: it's related
<doctormo> cjwatson: true, it just matters for my understanding
<xivulon> then couldn't similar techniques be applied in both cases?
<cjwatson> xivulon: that's part of where I'm headed
<cjwatson> but it's dangerous to make too many assumptions up front ...
<doctormo> OK (this is implimetation detail), the client does have the configration for the server in a nice xml file, it has the servers public key which is used to confirm that the server is who it says it is.
<doctormo> This I think is what you mean
<cjwatson> doctormo: from what I recall I *think* you described this as being by xmpp but I am honestly not sure
 * ogra finds the words "nice" and "xml file" in one sentence disputable :)
 * cjwatson waves the "distraction" flag again
<doctormo> cjwatson: So if the server becomes evil, the public key in the config is invalid and potentially evil?
<cjwatson> doctormo: correct
<doctormo> right
<doctormo> So far we're only using that key for the ssh connection, we're not using it for xmpp which just connects using dns only. not very secure as it doesn't certify the server (afaik)
<cjwatson> yes, that's horrible
<cjwatson> no secure protocol may rely only on DNS
<doctormo> As for public key updating... I'll have to think about the problem
<doctormo> colin if you know of an existing solution, do tell
<cjwatson> my suggestion would be that the server public key should reside in a package and only ever be updated out of band (i.e. by package updates, thus transferring the problem to that of archive signatures); furthermore, in order to ensure that clients are updated as quickly as possible after a compromise, there should be a way for the client to check whether newer versions of itself are available with newer keys, and refuse to run i
<cjwatson> or something along those lines
<cjwatson> if xmpp relies on DNS for authentication of remote identity, I think you should rethink your use of that problem
<leftyfb> compromised server + customers broken package management = no support tool
<cjwatson> err ... of that protocol
<cjwatson> leftyfb: yes
<leftyfb> and if this were to get into the main repositories, updating keys would be dependent on how quick canonical is with pushing the updates
<cjwatson> yes
<cjwatson> though not just Canonical
<doctormo> cjwatson: I agree with your idea, I believe xmpp can be made to check validity of the server more rigerously
<hunger> leftyfb: You do not want to have your own package repos for this? Is everybody supposed to get the same config (== end up on the same server)?
<doctormo> hunger: indeed, very good question +1
<hunger> Or will you modify the config for the users your company wants to support?
<cjwatson> I think it is probably a good idea for commercial support offerings to run a separate server, or deliver separate configuration in some other way
<doctormo> There is the possibility of having a number of servers available, both LoCo, canonical offical support maybe even system76 available from ubuntu repos and the tool could let the user decide
<hunger> I really do not see the need for such a package in a distribution... Maybe in some enterprisy thingy with support contracts, etc.
<hunger> "Community support" with access to the system in question does smell too much like inviting random idiots from the net to break install troyans to me.
<hunger> Maybe that is just me... but I doubt it.
<leftyfb> what about having a list of of server to join for remote support. The servers would be the different LoCo's willing to provide support, possibly Canonical, system76, Dell, etc
<doctormo> hunger: that is a concern i have, I imagen the good name of a LoCo being the basis for community support. Those who lead such groups would have to be trusted to only allow trusted people in, as above PGP signed keys and CoC would be a good start
<hunger> doctormo: LoCo? CoC? Sorry, my english sucks:-(
<ogra> hunger, local communities
<ogra> hunger, coc = code of conduct ... dude you hang around in this channel since how many years ?
<leftyfb> LoCo - Local Community    CoC = Code of Conduct which all official ubuntu members need to agree to and sign
<hunger> Well, in a support forum you can not post responses that will do bad-stuff since everybody can see it and will tell you.
<hunger> With some single guy messing with your system via SSH: Who is ever to know?
<doctormo> hunger: yes, there is an audit, but ultimatly root access is root access. If someone intentionally or mistakenly hurts a machine then it's the group that must make amends.
<hunger> doctormo: Audit?
<doctormo> hunger: nothing fancy, the ~/bash_history is sent to the server after disconnect. it could be removed if someone was malicious though.
<leftyfb> again, who's to say a Microsoft support employee isn't going wipe your "My Documents" folder when he's doing remote support?
<leftyfb> This is the nature of remote support
<leftyfb> you assume the helper is to be trusted
<leftyfb> there's no way to ensure it
<doctormo> hunger: the only real barriers we can put in place are organisational, not technical
<cjwatson> with a Microsoft support employee, you have a contractual relationship and can at the very least prove which legal entity was responsible for the breach
<hunger> leftyfb: Sure, but with a MS support guy there is a company that gives its (good?) name and says "that guy will not mess up your system". And you can sue them if they misbehave;-)
<cjwatson> this environment is different because it's quite possible you won't even know whom to prosecute under the Computer Misuse Act
<cjwatson> which lays the server operator open to subpoenas for logs, etc.
<doctormo> cjwatson: not a problem, subpoenas aren't always a bad thing
<cjwatson> right, but I think it's important to bear in mind that "make amends" may be a little more than "we're sorry, we won't do it again"
<cjwatson> the system has to be designed up-front to avoid problems
<doctormo> cjwatson: i agree, it may be "get sued into bancrupsey"
<hunger> doctormo: They do cause work that somebody has to do:-)
<cjwatson> I liked the sound of a system that could only offer certain predefined classes of information on request
<cjwatson> that's a lot better than "some guy gets a root shell by ssh"
<hunger> doctormo: And that work will end up on the server admin's desk...
<cjwatson> ~/.bash_history> unset HISTFILE; do malicious things
<doctormo> cjwatson: It isn't some guy though, it's a person the server knows, who has a signed PGP key and who the server operators personally know.
<cjwatson> I'd suggest keeping a connection trace instead
<doctormo> cjwatson: I never found out how to do that, that was my first thought
<cjwatson> personally know> that wasn't clear to me from the above. You mean somebody whom the server operators have met?
<doctormo> cjwatson: yes
<doctormo> But again, that is organisational
<cjwatson> that doesn't sound like it will scale as people want
<cjwatson> which means there'll be pressure to breach that
<hunger> cjwatson: That is not a good idea either! Think what kind of info might end up in such a trace. Having that stored on the server does not sound too good an idea.
<doctormo> cjwatson: I know, but it's important to organise the organisational scalling too
<hunger> cjwatson: Plus the SSH connection is encrypted and not visible to the server anyway.
<doctormo> hunger: the ssh is a double hop through the server
<doctormo> couldn't the server trace from there?
<hunger> doctormo: So I can put arbitrary info into any currently running ssh session streams if I gain access to the server?
<cjwatson> hunger: logging just the supporter->client side of the exchange (and not client->supporter) wouldn't reveal anything private
<cjwatson> or at least is unlikely to
<doctormo> hunger: not sure, maybe
<hunger> doctormo: No, from what I understand the supporter logs directly into SSH on the users box (going through port forwarded to the server).
<cjwatson> hunger: port-forwarding on the server => server can snoop
<cjwatson> actually, no, I suppose that isn't true
<hunger> cjwatson: It can snoop an SSH stream...
<cjwatson> yeah, end-to-end encrypted
<hunger> cjwatson: Not very informative;-)
<cjwatson> hunger: however, the client software could report a trace of what the supporter asked it to do
<cjwatson> (obviously you can't trust a malicious supporter to do so)
<hunger> So logging needs to be done either by the supporters system or by the users system. Both are under the control of the supporter...
<cjwatson> that could still be nobbled by the supporter, but it would raise the bar, particularly if it were done immediately rather than at the end of the session
<doctormo> hunger: at the moment it's set up so the supporter logs onto the server, then logs into a localhost port to log into the tunnel to the client
<cjwatson> if it were done immediately, then the last thing in the trace would be <supporter nobbles reporting software> which would be a big alarm bell in itself
<cjwatson> provided that you report all commands before execution
 * ogra wonders if the landscape team couldnt give some hints on secure connecting remotely
<hunger> cjwatson: SSH can force commands to execute... you could have that forward the commands back to the server before handing it to a shell.
<hunger> s/SSH/sshd/
<cjwatson> hunger: there's no obvious reason to do this by ssh alone. It should be something richer on the client side that can receive a command format, report them, and execute them as appropriate.
<cjwatson> hunger: (p.s. I maintain our openssh packages)
<doctormo> cjwatson: that would be interesting
<hunger> cjwatson: Something we have not considered is that the supporter could set up SSH tunnels, bypassing your firewall configuration.
<cjwatson> hunger: which is yet another reason allowing the supporter to execute arbitrary commands is an unwise design
<cjwatson> DDTT
<doctormo> cjwatson: although more alarm bells
<hunger> So he can even attack the system or others...
<Hobbsee> cjwatson: DDTT?
<cjwatson> don't do that, then
<leftyfb> If we aren't trusting the supporter, then this tool is useless
<cjwatson> leftyfb: that's not true at all
<doctormo> leftyfb: you just have to be able to catch supporters that go bad, auditing is good for that.
<cjwatson> the supporter can be given the ability to ask for certain information and get it automatically, and then recommend certain courses of action under the control of the user
<cjwatson> it's not an all-or-nothing thing, and presenting it as such is harmful
<leftyfb> I need this tool for root ssh access to my customer box's when they have problems. Without this, I won't be using this tool. Simple as that.
<cjwatson> leftyfb: so make the tool flexible enough that it can offer that to *you* where you have a contractual relationship with the customer, but don't turn that on for general user support over the Internet
<doctormo> leftyfb: no reason it can't do both, if the server doesn't have ssh support, the client won't allow ssh
<cjwatson> leftyfb: you don't have to make your requirements mandatory in the tool as a whole
<hunger> leftyfb: I think it is a great tool for a company/customer relationship. I just do not think community support with root access is a good idea.
<andrew___> It sounds like you guys are coming at this problem from different directions.   doctormo and leftyfb are starting with tech support for friends and scaling up, cjwatson is looking at a way of automating/real-timing some of the work of the Ubuntu forums.
<doctormo> andrew___: both doable using the existing tool
<leftyfb> we need to start small to support customers we have now
<doctormo> cjwatson: I've organised the support tool so that commands can be added on quite easily.
<cjwatson> andrew___: that's not an accurate representation of my position, FWIW
<andrew___> cjwatson, what would be more accurate?
<hunger> andrew___: I don't need such a tool to support friends and get supported by them. krfb is great for that:-)
<cjwatson> andrew___: I have nothing to do with the forums; my interest is in ensuring a secure design for any software that is offered to users of Ubuntu
<andrew___> cjwatson: Fair enough.
<cjwatson> (and, FWIW, I would rather have no software than insecure software in this case; although I accept that it is a significant requirement and I suspect it can be made acceptably secure with some effort)
<doctormo> cjwatson: and I thank you for your help.
<leftyfb> hunger: the biggest advantage of this tool I see is not needing to open up ports on their firewall/router
<leftyfb> cjwatson: i'm of the opposite opinion
<cjwatson> leftyfb: that's fair enough, but part of my job is ensuring high standards of software in Ubuntu
<hunger> leftyfb: Sure. But I can do that when I set up a system:-)
<cjwatson> leftyfb: you are (obviously) entitled to do whatever you like within your customer relationships
<leftyfb> hunger: i prefer not to poke holes in the customers network
<hunger> leftyfb: In a commercial setting you will have a hard time to sell a firewall-bypass-tool.
<cjwatson> leftyfb: but, when it gets offered to all Ubuntu users, it comes within my purview
<cjwatson> (among others)
<leftyfb> hunger: gotomypc, logmein, teamviewer
<hunger> leftyfb: I found it much easier to ask them to open a port which is then documented in their security documentation than to "sneak in" some piece of software.
<doctormo> leftyfb: there is no reason why we can't have the more advanced features enabled by us personally or by some simple option. Normal internet wide servers wouldn't do ssh but our own would.
<hunger> leftyfb: Maybe we are talking about different kinds of customers here:-)
<doctormo> hunger: It's not sneaking in,
<ogra> there are many corporate environments where you cant get more than http and mail protocols through the firewall by policy and getting another port open can take you months to get approval fro from all parties involved
<hunger> doctormo: If it is not approved by the IT department and documented in the security guidelines, then it is sneaking in.
<hunger> ogra: Sure. But it can get you kicked out of the company if you get caught going round the firewall, too.
<ogra> judging from myself, thats actually the majority of companies i have worked for doing it in such a way
<hunger> doctormo: Well, that tool is probably not targeted at companies with a IT department anyway.
 * hunger has to run.
<ogra> run hunger run
<ogra> :)
<doctormo> ogra: remind me, were you at UDS "Boston"?
<ogra> doctormo, yep., i think we met outside several times
<doctormo> I think so too
<ogra> you're the one from the local loco, right ?
 * ogra refines to typo the name of the state he cant pronounce either :)
<doctormo> Yes, Ubuntu-US-MA this might explain the development
<ogra> ah, right there is an abbreviation i forgot :)
<Amaranth> Massachusetts
<ogra> Amaranth, :P
 * Amaranth used spell check
<ogra> i still cant pronounce it without getting knots in my tongue :)
<LaserJock> hah
<LaserJock> ogra: I feel the same about many German city names ;-)
<doctormo> You get used to the spelling after a while
<ogra> Amaranth, oh, while you are here, i put willow on the uds agenda :)
 * Amaranth runs
<doctormo> ogra: we were talking at uds about dohickey and hardware tools
<ogra> LaserJock, yeah, understandable ... my hometown is easy though
<ogra> doctormo, ah, yeah, cr3 is doing all that now
<andrew___> Since there's a lull in the other debate, cjwatson: how come sshd allows password authentication by default?
<andrew___> (I asked this in launchpad, but since you're here...)
<doctormo> ogra: I thought canonical had dropped hardware information projects? I assume this because I heard nothing from anyone.
<ogra> doctormo, we have a new tool that hooks in with LP now
<ogra> hwtest-gtk
<ogra> (had to look that up)
<sladen> it died because nobody would share the data from the project
<ogra> sladen, its still ongoing
<ogra> just not 100% finished afaik
<sladen> s/died/has not achieved its full potential/
<doctormo> ogra: forgive me if i'm not hurt by being left out.
<cjwatson> andrew___: well, it's the upstream default as well. I tend to think that it's sufficiently useful in many environments to be left on by default, though I'm not surprised by people turning it off
<andrew___> Isn't it a serious security issue though?  It's alright for upstream, because OBSD users can be trusted not to use abc123 as a password ;)
<cr3> doctormo: hiya, how's it been since last uds?
<cr3> ogra: thanks for pimping my wares :)
<ogra> :)
<Hobbsee> andrew___: if they're that stupid and install an ssh server with such a p/w, don't they *deserve* to be rooted?
<doctormo> cr3: Busy, very busy.
<andrew___> Hobbsee: not if Ubuntu is supposed to be Linux for human beings, no.
<cjwatson> andrew___: well, considering that we don't install an SSH server by default, it hasn't particularly worried me
<mjg59> andrew___: There's no default username, and there's no default password
<Hobbsee> andrew___: then remove all their input devices.
<cjwatson> it was perhaps more of an issue when we did
<doctormo> cr3: I was just talking to ogra about how I've not had any emails from you guys about hardware information and detection.
<cjwatson> anyway, got to go ...
<andrew___> Bye - thanks.
<cr3> doctormo: the limiting factor here is mostly on the launchpad side where additional hardware detection would not supported by the relaxng schema.
<cr3> doctormo: I would like to see the schema eventually evolve to support more clever hardware detection such as done by dohickey, but Launchpad should first provide an interface for the existing schema before evolving it.
<doctormo> cr3: launchpad may be the wrong place to create a schema, although I'm sure you'd disagree at this point. it's too late.
<doctormo> when I get back to dohickey, I'll come calling and see what you've learned that I could aply
<cr3> doctormo: it is necessary for the schema to be defined server side in order to provide a form of validation before storing the information in a database
<cr3> doctormo: consider any rpc system for example, it is the server which enforces somekind of api in the form of a schema, dtd, idl, etc.
<pitti> seb128: hah! I now got one common fakechroot error case fixated in a test case, and I can perfectly reproduce it on my desktop, without mixing different chroots, etc.
<pitti> seb128: I was afraid that the combination of dapper system + gutsy chroot + hardy fakechroot mixed shlibs in a way to break this
<cr3> doctormo: I don't quite see how this could be debated so, perhaps I misunderstand what you mean by: launchpad may be the wrong place to create a schema
<cr3> doctormo: did you mean another server should be used for displaying hardware results to the community such as the dohickey server or the smolt server even?
<andrew___> doctormo: About LoCoRemote, it's worth having a poke about at http://popcon.ubuntu.com/ to see what package people tend to have on their systems.  For example, it looks like only about 20% of people have an SSH server already installed.
<pitti> seb128: ah, and the test still succeeds in feisty and gutsy; that explains the regression in hardy; apparently hardy's rm uses a new stat()-like call which isn't recognized by hardy's fakechroot
<andrew___> Speaking of popcon, does anyone know how there can be 541,530 submissions to popcon, only 540,735 of which had popularity-contest installed?
<pitti> andrew___: apparently you can submit your system data several times?
<ogra> it is an optional thing
<ogra> so not really something to base actual statistics on
<andrew___> Sure, but how do you submit data if you don't have the program to submit it?
<pitti> andrew___: I mean, those wo do have it installed might have submitted more than once
<andrew___> Yeah, but then popularity-contest would show up more than once.
<andrew___> Maybe the other handful were installing popularity-contest from source or something.
 * ogra tries to imagine a hand with 800 fingers
<ogra> :)
<andrew___> If two parties share a secret of, say, 10 or 20 characters, is there a security algorithm that could give you reasonable security for a few kilobytes of text, implementable in sed (or Perl with no modules)?
<doctormo> cr3: What I meant was that the schema for hw information is not static, launchpad doesn't ahve the tools to deal with dynamic hardware schemas yet.
<doctormo> andrew___: I wonder if it's worth having a seperate ssh package which is pre-configured for localhost, unsure of the solution with regards to sshd
<andrew___> I'm not sure I follow - what would that involve?
<awalton__> andrew___, depends on your definition of "reasonable."
<andrew___> awalton__: unlikely to be cracked within 20 minutes?  At a guess.
<awalton__> but then again, perl is turing complete, even without its modules, so I guess the answer is "yes"
<andrew___> True.  Do you have any particular pointers for where I might look?
<awalton__> google, wikipedia are often where I start.
<ogra> andrew___, if you use ssh, then you surely have ssh-keygen installed?
<awalton__> you could probably do a small blowfish implementaiton...
<andrew___> ogra: if I've got SSH, I don't need to worry about such hacks :)
 * andrew___ makes note to look for Blowfish implementations in Perl
<andrew___> Basically, I'm browsing popcon and thinking that sed, perl and netcat are amazingly popular and can probably be convinced to work with just a binary...
<awalton__> or if you want a really, really small implementation, something like xtea or RC4, but they're both substantially weaker :-/
<andrew___> sed and netcat are even in /bin, so get around problems with /usr failing to mount.
<andrew___> Not so much small as possible for me to verify (and write if absolutely necessary), given my lack of security training.
<awalton__> is it even worth it though? does it matter?
<andrew___> Depends how hard it is.
<seb128> pitti: ah ok
<pitti> seb128: currently digging in the fakechroot code to add an implementation for the missing newfstatat()
 * seb128 hugs pitti, good work
<andrew___> If I can put something together in an afternoon that's a guaranteed "download this and follow the instructions" solution for anything from a 90's NetBSD to a modern Leapord, I'd say yes :)
<pitti> none of the new *at() functions are implemented :/ (http://lwn.net/Articles/164887/)
<Riddell> doko: any idea what causes an error like this? http://paste.ubuntu.com/10990/
<Riddell> doko: seems I have to add -ldl for some reason
<lamont> mvo: is your util-linux change for #157763 something that should go in long-term upstream?
<lamont> meh.  no mvo
<pitti> seb128: BANZAI!
<jdong> is archive.u.c under stress? it's responding very slowly to me
<pitti> yes, it is
<pitti> both mirroring drescher (master archive) and downloading from it take ages
<jdong> oh
<cr3> doctormo: perhaps a schema allowing for dynamic data could be proposed for launchpad. any suggestions?
<LaserJock> geeze, 2 times in 2 days I find a package I'm interested has been removed from Hardy :(
<bimberi> hi LaserJock, which one? iirc qgis was the other.
<Mithrandir> andrew___: look at http://www.cypherspace.org/adam/rsa/perl-dh.html to get a key exchange going, then you have a session key and can use that with regular crypto.  I'd probably just use "openssl bf" or similar, though.
<LaserJock> bimberi: ksynaptics
<LaserJock> my touchpad has too many "features" on it that are very annoying so I was hoping to turn them off
<LaserJock> I think I'll just do it in xorg.conf and see how that goes
 * pitti uploads another fakechroot which now finally works again for hardy
<pitti> \o/
<pitti> bdmurray: ^ FYI, that means I can reactivate the retracers (will do tomorrow, too late now)
<bdmurray> pitti: sweet!
<Caesar> pitti: so I've got various small bugfixes I'd like to get into hardy-proposed
<Caesar> I presume I can't upload there because my key's not in the keyring, so I'll need sponsorship?
<jdong> Caesar: main or universe? (make sure it meets SRU policy and follows the SRU process)
<geser> Caesar: yes, you'll need sponsorship. Have you already an ACK from the (correct) SRU team?
<jdong> even developers must get approval from the appropriate SRU approval team to ACK the request before uploading
<doctormo> cr3: I thought you'd seen dohickey, next UDS in mountin view I'll have to show you how it works
<Caesar> jdong, geser, where/how do I get SRU team blessing?
<Caesar> Point me at docs, I'll go read
<geser> Caesar: https://wiki.ubuntu.com/StableReleaseUpdates
<Caesar> thnx
<cr3> doctormo: you showed me dohickey in person and I took the time to look at the code on the client side. I have to admit I didn't look at the server side but, apparently, I'm missing out :) thanks for pointing this out
<doctormo> cr3: It has a schema for dynamic data using data pathing
<cjwatson> andrew___: I'd second Mithrandir's recommendation of something pre-cooked. Designing your own cryptosystem without security training is a really bad idea, and 20 characters => 160 bits => probably worthless for security purposes
<andrew___> Yeah, that link is a good idea (thanks Mithrandir).  Actually, I'm starting to think that it's better to use small, simple tools to make the whole "recovery from a nearly-broken system" idea redundant.
<andrew___> Hence posting to ubuntu-devel-discuss about dealing with failed mounts.
 * davidm is away: I'm busy
<cjwatson> andrew___: to back up my "160-bit keys are worthless for security purposes" statement: I just tested msieve (http://www.boo.net/~jasonp/qs.html) on my laptop with a series of 160-bit numbers that were products of two random 80-bit primes. The mean time taken to factorise each was .67 seconds.
<andrew___> Bearing in mind my lack of security training, does that mean that any amount of information that could usefully be transferred over the phone is only useful in the context of something like a password in an SSH session?
<andrew___> (Where by "usefully transferred over the phone", I mean "dictated phonetically at one character per second for less than 30 seconds")
<Mithrandir> andrew___: tbh, I'd recommend using SMS-es or a similar out-of-band medium for transferring a passkey, preferably with a very short time span (5 minutes)
<Mithrandir> so you'd get an sms with "the server should tell you abcd1234 and you should tell it gargleblaster"
<andrew___> That's still only 160 characters max. though?
<Mithrandir> it's not foolproof, but it's probably one of the better key exchanges you can come up with today.  It has a cost associated, but if you're in a business relationship, that should't be a problem.
<Mithrandir> that doesn't really matter so much, since you'd need to make it short-lived and lock the password on three wrong tries
<Mithrandir> of course, an attacker can continually request new passwords, but you might notice that your phone keeps getting new passcodes and then react on that.
<Mithrandir> but then, I think this is a good idea, so find somebody smarter than me to poke holes in it and tell you on what points I'm wrong.
<andrew___> Yeah, part of the reason I prefer an actual phone call is because you can at least verify that they sound like the right person.
<Mithrandir> social engineering is typically quite easy, especially in a business situation.
<andrew___> My personal interest is in tech support for friends.  If I was looking at a business thing, the first thing I'd do would be to get them to pay for me to physically go there and set up a reasonably secure login.
<Mithrandir> between friends, social engineering is harder, agreed.
<Mithrandir> and between friends, well, I wouldn't want a bot to message me, since that probably meant the login was actually going through a third party I had no reason to trust.
<Mithrandir> trust is bloody hard to manage and is not transitive, which makes this a problem.
<andrew___> You're thinking of doctormo and leftyb, I'm looking at a completely different thing :)
<Amaranth> hrm, i thought the bug squad had access to all ubuntu bugs
<Mithrandir> Amaranth: not security ones, I'd have thunk.
<Amaranth> security doesn't mean private though, apparently
<Amaranth> although i guess if you set it private and security it might lock the bug squad out
<Mithrandir> andrew___: true, but if you're serious about having some decent security in your system, sit down and make a design document explaining what and how and let people poke holes in it.
<Mithrandir> after a few iterations, we might have something that none of us are clever enough to break, at least.
<Mithrandir> and it's not the crypto that's going to be the hard part.  It's the procedures, the social engineering and how your components fit together and managing trust between them.
<andrew___> Sure - as soon as I can get to the end of a sentence without falling through eight of those holes.
<mneptok> Amaranth: you won;t have access to private bugs of paid Canonical customers.
<Mithrandir> mneptok!
<mneptok> Mithrandir!
<Mithrandir> mneptok: crazy man, how are things?
 * mneptok spews ponmies and glitter
<mneptok> *ponies
<Amaranth> some guy is complaining about aptoncd but his bug report is private
<mneptok> not too bad. the jbailey replacement has finally arrived. that's quite nice.
<mneptok> Amaranth: bug#?
<Amaranth> bug 221839
<Mithrandir> mneptok: ah, sounds good, and about time
<ubottu> Amaranth: Bug 221839 on http://launchpad.net/bugs/221839 is private
<wgrant> Amaranth: Security issues are private by default.
<mneptok> Amaranth: no access here, either. not private because of a paid relationship.
<mneptok> Mithrandir: no kidding. it's been too long.
<doctormo> andrew___: some completly different remote support tool using reverse ssh tunnels then
<mneptok> Mithrandir: keeping busy? reporting to your parole officer as expected?
<Mithrandir> mneptok: keeping busy, yes, lots of fun and learning, which is good.
<Mithrandir> mneptok: billing customers is kinda weird, though. :-P  Given that I didn't work in such a position at C
<andrew___> doctormo: probably.  as of right now, I'm still trying to work out what the actual missing pieces are in the puzzle.
<Mithrandir> andrew___: do you have a document explaining what the problem you are trying to solve is?
<doctormo> andrew___: the main parts? well I see people as a missing part, people that can be trusted. but this may not be the same as your problem.
<Mithrandir> and some rough sketches of your approach to solving it?
<Amaranth> wgrant: Yeah but some guy set a compiz bug as a security issue just because he wanted someone to look at it
<Amaranth> That's when I noticed security didn't automatically mean private
<andrew___> Mithrandir: short answer - nothing worth reading yet.  As I say, I'm still getting my head around things.
<Mithrandir> andrew___: ahkay.  Once you have that, tell me and I'll be happy to see what holes I can poke in your solution. ;-)
<andrew___> Thanks :)
<andrew___> I suppose the basic problem I'm looking at is: someone you know has a system that doesn't work, and your phone number exists somewhere in the list of things ways they know how to fix computer problems.  How do you get said friend's computer working?
<Mithrandir> I would probably pull out my bike and bike over or ask them to bring the laptop to my place.
<andrew___> Most of the people I know are not within biking distance :s
<Mithrandir> hehe
<andrew___> Plus, it's always been my opinion that Linux adoption is constrained mainly by the number of people in generation N that can be supported by the community from generations <N.
<Mithrandir> conceivably, yes.
<andrew___> Therefore, two key ways to increase the pace of Linux adoption are to reduce the support burden and increase the number of people that older generations can support.
<lifeless> Mithrandir: in the deep of winter ? :)
<Mithrandir> I think a solution using the telepathy framework and such might work well, but I'd start by having a good description of the problem and the requirements.
<Mithrandir> lifeless: I live in Oslo, we don't get real winters any more. :-(
<Mithrandir> lifeless: (yes, I bike the whole winter)
<andrew___> I live in Britain.  We don't get real winters, but we're starting to get real summers :s
<lifeless> Mithrandir: I knew where you lived :), I didn't know the climate had changed so noticably for you.
<Mithrandir> lifeless: well, it's more about being downtown, I think.  I live basically at sea level about 1km from the ocean, so it doesn't get very cold for very long.
<andrew___> What I'm thinking now is: there's lots that can be done with bullet-proofing the "mostly-broken" case.  I've mentioned two of what I think are the biggest issues on the ML: half-installed packages and FSs that won't mount...
<andrew___> There's plenty of work already done in the "mostly working" case, and I'm starting to think that we need existing solutions to be promoted, rather than the likes of me adding another voice to the cacophony.
<andrew___> But what about the intermediate case?  How common is it that someone will boot to a system that's not functional enough for Telepathy and friends, but too functional for automated special-case solutions?
<Mithrandir> that's called "live CD", isn't it?
<Mithrandir> and then have the support tools available from there and the "help from a friend" functionality available there
<andrew___> Generally speaking, people with enough foresight to have a live CD lying about generally don't need my help :)
<andrew___> Hmm.
<andrew___> Should there be a recovery option to download and burn a live CD?
<andrew___> From GRUB or similar?
<Mithrandir> grub2 can give you netboot, and well, tftp can be routed, so theoretically you could boot over the internet
<Mithrandir> it wouldn't be fast, though
<Mithrandir> and would absolutely not be secure
<andrew___> Yeah, and security becomes an issue again.
<Nafallo> Mithrandir: wouldn't that depend on the speed of the connection? :-)
<Mithrandir> Nafallo: no, it would probably more depend on the latency of the connection.
<Nafallo> Mithrandir: point-to-point 10GbE wave? :-)
<Mithrandir> Nafallo: most people don't have that at home though
<Nafallo> Mithrandir: ...yet :-)
<monic> can anyone tell me what is the graphics library people use for Ubuntu now; i gather it won't be SVGAlib
#ubuntu-devel 2008-05-09
<mathiaz> kees: while trying to merge ipsec-tools I got this error - cc1: warnings being treated as errors
<mathiaz> policy_token.c: In function '__libipseclex':
<mathiaz> kees: http://paste.ubuntu.com/11039/
<mathiaz> kees: is this related to the new hardening flags ?
<james_w> mathiaz: https://wiki.ubuntu.com/CompilerFlags <- -D_FORTIFY_SOURCE=2 seems to be relevant here.
<mathiaz> james_w: thanks :)
<andrew___> Who is it that actually decides what goes onto the Ubuntu CD, and how do us mortals go about understanding (and potentially altering) their reasoning processes?
<andrew___> As opposed to universe etc.
<_MMA_> The Tech Board and or Desktop team I believe.
<_MMA_> And nothing from Universe goes on to the disks.
<Amaranth> not true
<mathiaz> _MMA_: well - it depends which iso you're refering to
<Amaranth> xubuntu is in universe
<_MMA_> Oh jesus. Nit-pick. He said Ubuntu. ;)
<Amaranth> hehe
<_MMA_> So :P
 * Amaranth pokes _MMA_
<mathiaz> _MMA_: it was true that nothing from universe could be on the cd. But this has been changed during the last release cycle so that xubuntu, ubuntustudio and other derivatives can be built
<Amaranth> ubuntustudio is in main, no?
<TheMuso> No.
<TheMuso> Its the primary reason that universe packages can be on disks.
<Amaranth> most of it is :P
<_MMA_> mathiaz: I'm sorry. You obviously don't know who you're talking to.
<andrew___> The reason I'm asking is that to some extent the remote recovery issue is about defaults and policies rather than optional components, and I'd like to understand a little about that side of the process.
<_MMA_> andrew___: I think people like Colin are the best resource for that.
<_MMA_> A post to ubuntu-devel-discuss might be in order.
<andrew___> There've been a few on the issue already :)
<Amaranth> what, specifically, do you want changed?
<andrew___> Well, I'm still going through the understanding stage...
<andrew___> I've been bugging anyone that will listen for the past few days about ways to do better tech support for friends.
<mathiaz> andrew___: technically, a ubuntu-core-dev has to make a change to the seeds - so you'd have to convince a core-dev to make that change.
<Amaranth> core-dev has access to the seeds?
<andrew___> How do they tend to feel about new packages getting accepted into main?
<_MMA_> No. It's not that simple. It is a team decision.
<mathiaz> Amaranth: yes
<Amaranth> andrew___: To get a package into main you have to file a main inclusion report
<andrew___> Do they prefer packages that are small, or well established, or well-maintained...?
<Amaranth> andrew___: then you need to talk to the relevant team
<Amaranth> if it's in main it should be well maintained and have no crazy security issues
<mathiaz> andrew___: https://wiki.ubuntu.com/MainInclusionProcess
<andrew___> Thanks - I think that's what I needed to know.
<Amaranth> that page is no longer valid
<andrew___> Or at least, it'll shut me up for another few hours :)
<Amaranth> not everything in main is supported by canonical
<mathiaz> Amaranth: huh - that page is still valid IIRC
<Amaranth> the steps are right, the reasons are not
<mathiaz> Amaranth: what do you refer to by 'supported by canonical' ?
<stdin> commercially supported by commercial support people, commercially :)
<_MMA_> mathiaz: ie: There are things in Main you can't get paid support from Canonical on.
<pwnguin> _MMA_: im sure if you name the right price you can?
<jdong> hmm, compiz runs a LOT slower with DDR-533 unmatched sticks of RAM
<jdong> on the GMA950.
<jdong> time to revert this setup
<pwnguin> gma950 uses RAM?
<jdong> pwnguin: GMA950 uses only RAM
<jdong> pwnguin: it has no dedicated graphics RAM
<_MMA_> pwnguin: Who knows. I haven't talked to the support guys enough to know.
<pwnguin> im sure handing off hard stuff to the CPU doesn't help
<jdong> pwnguin: so I guess having dual-channel interleaved RAM is important
<pwnguin> double throughput is important -- 3d stuff is very bad at caching
<jdong> oddly seems like Firefox is the only major offender
<jdong> hmm
 * TheMuso has never liked shared RAM.
<pwnguin> lots of pixmaps in ff
<vlowther> ï»¿anyone here willing to help me debug a kernel-related suspend/resume problem on 2.6.24-17 on Hardy?  It appears to be scheduler-related, but debugging it beyond what I can see in the log is a bit tricky.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/212660 has details -- the short version is that suspend/resume last worked properly on 2.6.24-12 for me.
<ubottu> Launchpad bug 212660 in linux "kernel 2.6.24-16 fails suspending" [Undecided,Confirmed]
<TheMuso> vlowther: You may get more help in #ubuntu-kernel.
<vlowther> heh, did not know that channel existed.
<vlowther> I will ask there.
<pwnguin> TheMuso: that assertion is tenous at best
<pwnguin> vlowther: you may get better help in the ubuntu-kernel mailing list.
<vlowther> pwnguin: indeed.
<pwnguin> as far as i can tell, the ubuntu kernel team uses IRC to communicate with other ubuntu kernel team members, and anyone else's best hope is getting ogarasawa's attention =(
<TheMuso> pwnguin: ?
<pwnguin> TheMuso: i'm just suggesting that i see unanswered calls for attention plenty in that channel.
<vlowther> wn that case, why bother with a public channel at all?
<TheMuso> pwnguin: Right.
<Amaranth> well, this channel is the same way, really
<pwnguin> except nobody says "go to ubuntu-devel for bug help", that I know of
<vlowther> well, I come here because people only want to look at easy things on #ubuntu
<mathiaz> _MMA_: do you have example of such packages ?
<mneptok> _MMA_: got an example?
<mneptok> hahahahahahahaha!
 * mneptok bops mathiaz on the nose
<Amaranth> I did before hardy
<Amaranth> maybe that's changed now, i dunno
<mneptok> Amaranth: examples of unsupported packages in Main?
<Amaranth> yeah, xubuntu stuff :P
<mneptok> uh ..
<mneptok> fark you, too. ;)
<mneptok> *smewch*
 * mneptok beams brightly at Amaranth 
 * Amaranth gets confused
<pwnguin> do i have someone on ignore? cuz this isnt making sense =/
<mneptok> Amaranth: you had me wracking my brain for Main packages i didn;t think of.
<mneptok> and then ... "Xubuntu."
<LaserJock> pwnguin: same here ;-)
<mneptok> there is no support for Xubuntu.
<mneptok> any pacakges. at any time.
<mneptok> so the slap was for making me start to actually think ;)
<LaserJock> I believe there are other packages in Main Canonical doesn't support
<LaserJock> and Xubuntu is in Universe now right?
<mneptok> LaserJock: do you have an example?
<mneptok> LaserJock: 'cos i don't
<LaserJock> well
<mneptok> i'm not saying i couldn;t have overlooked something.
<LaserJock> do you have a list of things Canonical *does* support? :-)
<mneptok> packages in Main.
<mneptok> a short list of vital Universe stuff.
<mneptok> that's it.
<mneptok> (slmodemdaemon, when that was in universe)
<LaserJock> Main/Universe is not how Canonical support is defined
<mneptok> it is here.
<LaserJock> how interesting
<LaserJock> mdz said it wasn't
<LaserJock> and I would think he'd know
<mneptok> LaserJock: like i said, it doesn;t break out exactly along repo lines
<LaserJock> sure
<mneptok> LaserJock: but we still use repo names to define things
<mneptok> like "a few critical packages from Universe"
<LaserJock> mneptok: and some Main packages that aren't supported ;-)
<mneptok> i know of none
<mneptok> i await an example.
<mneptok> (not to make that sound like a stupid challenge)
<crimsun> (I presume a support contract w/ Canonical overrides component lines anyhow.)
<LaserJock> well, is abiword and gnumeric supported?
<mneptok> yes.
<LaserJock> you sure?
<mneptok> *blink*
<LaserJock> well, stupid question
<LaserJock> but I wasn't aware that it was
<mneptok> all fourteen users of both apps are entitled to support.
 * mneptok runs
<LaserJock> overall I'm not sure that Canonical knows what's supporte
<LaserJock> +d
<mneptok> we do not fully support anything with a non-Free license
<mneptok> as we cannot guarantee resolution
<LaserJock> sure
<mneptok> *with* a free license, it basically breaks out along repo lines, but with some exceptions. hence mdz's comment.
<mneptok> personally, i'd like to stop supporting GUI environments and server daemons. when i mentioned it, sabdfl asked me to wait in the lobby for the adults to finish their conversation.
<andrew___> If I allow untrusted users SSH access to an account on my computer, where the account is in a chroot jail, they can only run a specific command I specify (not a shell), and remote and X11 forwarding are disabled (but local forwarding is enabled), have I compromised the security of my computer in any way?
<LaserJock> mneptok: well, there have historically been examples like Xubuntu
<mneptok> Xubuntu != Ubuntu
<LaserJock> so?
<mneptok> Canonical Support offers commercial support for Ubuntu, Kubuntu, and Edubuntu
<hi5> For bandwith challanged users, it'd make sense to just download the compressed differences between an old package in the apt cache and a new version of a package. Could an rsync method driver to apt be a solution, for instance?
<_MMA_> mneptok: re: "Example packages" when Xubuntu went to Universe there was a big chat in here and people like Matt Z. Colin and Scott R. mentioned a good few I believe. Besides the previously mentioned Xubuntu packages. Making a list of unsupported packages was mentioned but I don't know if anything came of it.
<LaserJock> right, but Xubuntu was in main and dragged in quite a bit
<mneptok> _MMA_: Xubuntu is not supported. therefore, its packages, regardless of repos, are not supported.
<LaserJock> right
<mneptok> _MMA_: it's not that "stuff in Main is not supported." it's that "Canonical only supports certain variants"
<_MMA_> Sure. But that was under contention at the time.
<LaserJock> but you asked for packages in Main that aren't supported by Canonical
<_MMA_> No. I don't think it's that cut and dry either.
<LaserJock> or did I get the question wrong?
<mneptok> LaserJock: Main/Xubuntu is not the same as Main/Ubuntu
<_MMA_>  As I said others had examples.
<LaserJock> mneptok: so?
<mneptok> so, when you say "Canonical supported stuff in Main" it assumes a variant that actually has support.
<_MMA_> ï»¿I want to get jackd back into Main to be able to build PulseAudio packages that can work with JACK. I doubt that will get support from Canonical.
<LaserJock> mneptok: when people say "Canonical provides support for Main" it implies that *all* of Main is supported, right?
<andrew___> hi5: Isn't that what jigdo does?
<hi5> andrew__: I don't think so, but i might be wrong
<mneptok> LaserJock: Canonical provides support Main packages on supported platforms.
<mneptok> LaserJock: therefore, if you install a Main package on Sid, no dice.
<hi5> that's more for dividing iso files into .debs and recompiling afaik
<LaserJock> mneptok: Canonical provides support for most of Main on supported platforms
<hi5> it doesn't provide 32/64K diff from one .deb to another
<hi5> and it's not for apt
<LaserJock> however, I again don't know that it matters much
<_MMA_> ï»¿LaserJock: At one point I thought on ubuntu.com it wasn't as clear as that. Hence all the confusion about Xubuntu.
<_MMA_> I think a bug was even filed.
<LaserJock> _MMA_: the website says "The main distribution component contains applications that are free software, can freely be redistributed and are fully supported by the Ubuntu team"
<_MMA_> ï»¿bug 172672
<ubottu> Launchpad bug 172672 in canonical-website "http://www.canonical.com/projects claims that Xubuntu is supported by Canonical" [Undecided,New] https://launchpad.net/bugs/172672
<_MMA_> Looks like it's been fixed. SHould close the bug.
<pwnguin> one should note that the Ubuntu team and canonical are not identical sets
<hi5> Re:rysnc method driver for apt. The context of this can be anything from people over sat connections, 3rd world countries (like iraq where there is no fiber, or copper backbones/lines since the ground is so hard it's almost impossible to run it so everything is expensive sat. based), or saving bandwidth / speeding up updates 1000x for all users / saving money to run repos. Are there no thoughts?
<LaserJock> pwnguin: exactly
<LaserJock> what goes in main is independent of Canonical
<andrew___> hi5: Depends how much work you're planning to put in.
<LaserJock> though it certainly works well for Canonical to use Main to define support
<hi5> andrew__: Well, I've spent days getting enough info to formulate that question properly.
<andrew___> hi5: Yeah, I know that feeling :)
<pwnguin> hi5: so this means you're doing investing time, or does it mean you're in it for the long haul?
<hi5> Annoyingly, people's response of "bandwidth is cheap" is highly beside the point, and innacurate for most of the non-western world.
<andrew___> hi5: What's the average size of the binary diff between two versions of the same package?  How does it differ between packages?  How does that compare to the diff between source packages (a la Gentoo)?
<pwnguin> if you're merely looking for counterpoints, CPU time isn't cheap either.
<pwnguin> andrew might have a point -- .debs are compressed and may not make good rdiff candidates
<hi5> So I'm pretty invested in this. I should note that I've receive many responses to contact the various devel lists however I'm not a developer. Hence my apprehention about contacting a dev list which a.) may not care b.) would be annoyed I'm just a (l)user
<hi5> However, after much research it appears no such solution exists... which is very surprising to me considering how obvious this seems
<hi5> (even to a new user)
<awalton__> it may seem obvious, but the solution is definitely non-trivial to implement.
<andrew___> As to (b), I'm not much more than a (l)user myself.  If they start picking on us, we should unionise ;)
<hi5> awaiton: Why? nobody has been able to tell me why?
<pwnguin> im not familiar with how rdiff works, but it may require a non trivial amount of disk space
<awalton__> hi5, better idea: try it. realize just how hard it really is.
<LaserJock> doesn't it take quite a bit of CPU on the server as well?
<andrew___> hi5: I'm not sure of the technology details, but here's a thought experiment based on how I would expect it to work:
<pwnguin> LaserJock: indeed
<pwnguin> oh dear
<andrew___> Imagine a 10MB binary split into 1024 10KB chunks...
<hi5> Well, real-time decompression of binaries on the server end, and similar on the client end mean you dont't need 20x the server space i'd think
<hi5> but that was a theoretical concern i also had
<hi5> though, hdd space is still cheaper than bw for a repo's purpose
<LaserJock> I'm fairly sure the current servers basically out of space
<pwnguin> if there's fifty versions you might upgrade from
<andrew___> Version n+1 of the file inserts a single byte at the front of the first chunk....
<andrew___> this causes every single chunk to appear different, and need to be re-downloaded.
<awalton__> ideally, packages would be distributed over something like bittorrent, where you don't care so much about compression and on-disk space, but focus on the perfect reproduction of the file and various locations of retrieval. at least, IMO.
<LaserJock> if you imagine having to house diffs for all packages for all versions it can be pretty significant
<pwnguin> LaserJock: wikipedia is enlightening
<hi5> awaiton__:no offense, did you even read my post?
<pwnguin> basically, it's compute intensive because it network computes the diff
<hi5> Seriously, empathise with someone outside of your country for a moment.. bit torrent doesn't solve a bandwidth issue for a single node. It merely distributes it among many similarly bandwidth endowed nodes
<pwnguin> hi5: wouldn't a CD be just as / more effective?
<hi5> pwnguin: yes, i can see that being a minimal issue
<pwnguin> "minimal"
<hi5> pwnguin: a cd would not be effective
<awalton__> hi5, the best way I can sympathize with you is to say, I don't want you wasting any bandwidth on bad downloads
<hi5> a cd as a compromise would be a tad bizarre to me in fact
<pwnguin> that "minimal" issue of CPU use very well may kill servers on upgrade day
<pwnguin> take one server and add a couple hundred / thousand users and bam, instant problem
<LaserJock> pwnguin: almost for sure
<awalton__> bittorrent is designed so files don't 'fail' during download. time sensitivity can come from using the absolute best compression available (something like lzma), but using something like binary diffs is almost never a good idea due to just how tricky they are to get to work...
<hi5> so, this avoids the topic at hand doesn't it?
<hi5> I think those are administrative issues, and ones that aren't impossible to deal with
<pwnguin> what?
<hi5> cpu load vs bw load
<pwnguin> CPU is an administrative problem?
<hi5> etc
<LaserJock> hi5: but you wondered why it hadn't been implemented
<LaserJock> that's one very good reason
<hi5> First, less defensively folks, is there consensus that this isn't implemented somewhere?
<awalton__> that's for you to answer. but I doubt it.
<hi5> It seems many people say "use jigo" or "debian already does that" and such
<andrew___> I'm not aware of anything like that for binaries.
<pwnguin> ive seen about a billion attepts at alternative apt transports
<pwnguin> i think i saw an apt-rdiff
<hi5> http://www.tjansen.de/debiff/ comes to mind
<andrew___> Source downloads are a different matter, because that's a much easier problem to solve.
<pwnguin> i know ive seen an apt torrent
<hi5> pwnguin: same
<awalton__> someone tried apt over bittorrent before, but it was pretty poor :/
<hi5> awaiton__: there's better alternatives to that too. it works fine for me ;)
<awalton__> the idea wasn't bad though, it's just hard to make work.
<hi5> agreed
<awalton__> binary diffs on the other hand, are almost impossibly hard to make work on a widescale.
<pwnguin> the BT problem is one of availability -- you need to be able to trade chunks across packages
<andrew___> hi5: If you don't mind trading a lot of CPU for less bandwidth, how do you feel about downloading source and compiling it?
<awalton__> pwnguin, that's not such a hard problem once you realize you have a captive set of mirror servers across the globe to act as seeds...
<hi5> ah, a good point about client end cpu
<hi5> seems then patching would be possible via using deb-src?
<hi5> I still think it's not apple-apples though. Compiling an OS, vs cpu use for making diffs of binaries is not comparable
<pwnguin> hi5: thats not at all the point though. the point is you're asking ubuntu and mirrors to spend massive CPU on behalf of users, and he countered with a scenario where the user spends instead ;)
<hi5> well, bandwidth bills are already an issue
<pwnguin> kinda
<pwnguin> a lot of university institutions donate to the cause ;)
<hi5> so, i don't see why a bandwidth -> cpu tradeoff would be so unheard of
<awalton__> you might be better off with the postal system if bandwidth is that big of a problem...
<pwnguin> hi5: more fundamentally, I'm not sold on rdiff substantially improving the bandwidth problem
<StevenK> hi5: Usually since it's CPU hit on both ends of the pipe.
<hi5> right, but donate != free
<hi5> it's still costly
<hi5> just not costly to someone on a wester DSL line
<hi5> (again, a tradeoff does exist)
<pwnguin> there is no free lunch
<StevenK> hi5: And server administrators tend to not like process that constantly chew CPU.
<pwnguin> canonical offers something close with the CDs though ;)
<andrew___> The claim being made is that binary diffs are a hard problem.  You can accept that, or explain what you're not understanding about the problem, or go and prove everyone wrong, but (without wanting to be rude), just dismissing the claim doesn't work.
<mrec> hi, anyone here who knows about that broken ubuntu alsa configuration?
<hi5> andrew__: the claim being made is unsubstantiated
<pwnguin> andrew___: i think that IF you managed to undo the ar compression on packages, you'd probably see some great gains in bandwidth
<awalton__> hi5, google it. do some research into the issue.
<hi5> so without being rude (which you are) it's not helping me. besides, this isn't my personal pet peeve. i'm trying to help
<hi5> i don't think many ppl understand this
<pwnguin> hi5: as a challenger to the status quo, and a champion of the under championed, you'd be well off to substantiate the opposite
<hi5> i've seen this topic brought up many times before, and it's odd how there's a peculiarly hostile reaction to it. sorry for being new, i just don't understand why this issue sticks out like a sore thumb
<LaserJock> hi5: I believe the Canonical sysadmins have said that it'd probably be too CPU intensive with what we have now
<pwnguin> if all rdiff/rsync does is transfer modified blocks, compression is likely to nuke that idea in hurry
<hi5> laserjock: I appreciate the response, and I've been trying to figure out if that's the case
<LaserJock> hi5: people *have* looked into this issue and it's not that we're saying "it can't be done" but just that "it's probably not feasible at this time"
<mrec> does anyone know if the alsa drivers got recompiled for ubuntu hardy or are they just taken from debian?
<LaserJock> although there are significant other concerns about some techniques
<pwnguin> mrec: whats the version of alsa?
<andrew___> hi5: In fairness to you, there is an issue that this doesn't scratch the itch of many developers, because they tend to be behind fat pipes (or they wouldn't have been able to learn enough to become developers).
<hi5> laserjock: interesting
<LaserJock> andrew___: I honestly don't know that that's totally true
<hi5> andrew___: yes, this is part of my aggravation. if i had dev skills, i'd work on this. I'm actually reading "Computer Programming for Dummies" right now sadly
<LaserJock> I know of devs on dialup
<hi5> if i get the skills, i'll work on this
<mrec> pwnguin: that's a good question...
<StevenK> LaserJock: I'm in Australia, which is worse.
<awalton__> hi5, that's probably why you don't appreciate just how difficult it is, no offense.
<pwnguin> hehhaha
<hi5> it annoys me how selfish and unempathetic ppl can be (no offense to anyone here, it's a general sentiment i get though sometimes)
<mrec> I cannot compile external modules against the ubuntu hardy kernel because the alsa headers seem to be out of sync with the binary files
<hi5> awaiton__: well, i don't know if you appreciate how easy it can be
<LaserJock> hi5: on the other hand, you'd be surprised I think at how unselfish and empathetic people can be
<awalton__> hi5, I've done binary patching before, I can tell you just how hard it is.
<mrec> whoever build that kernel didn't know what he did
<pwnguin> calling people selfish and unempathetic strikes me as arrogant, on the other hand ;)
<awalton__> hi5, it's especially not trivial when you realize just how many users there are, how many different versions are in the field, and how hard quilting binary diffs is..
<mrec> built*
<awalton__> hi5, if it were trivial, it would have been done years ago, and thusly not an issue.
<andrew___> hi5: I think you need to be reading a book on statistics rather than programming, actually.  If you can show that debiff will reduce bandwidth by X% and increase CPU usage by Y%, we can have a proper debate about whether it's worth it.  Until then, we're all just hand-waving.
<awalton__> *not be
<hi5> awaiton__: andrew__: well, i can appreciate the science and bit swapping of binary comparisons a lot
<pwnguin> hi5: andrew is right. if you can demonstrate that rdiff is a win or at least a substantial tradeoff, you'd have far fewer opponents. and possibly a few volunteers
<hi5> however, tools for doing this already exist it seems
<hi5> so it's not like the wheel needs to be reinvented. so i consider some of those points red herrings
<hi5> well, without implementation, statistical theory is pulling numbers out of my arse
<hi5> i need a test bed
<hi5> and i'm trying to build one!
<awalton__> hi5, just because a peg exists, doesn't mean that it necessarily fits the whole...
<awalton__> *hole
<hi5> right, that's a platitude
<hi5> not a response to the problem at hand
<awalton__> think about it this way: ever had to downgrade a package?
<hi5> lol
<hi5> yes
<hi5> it's a PITA
<jdong> pwnguin: just confirmed, switching from 1x2GiB + 1x1GB @533MHzz --> 2x1GB @667MHz made a HUGE difference in GUI performance
<awalton__> hi5, think about doing a reverse binary patch.
<hi5> :)
<pwnguin> jdong: is anyone surprised? ;)
<jdong> pwnguin: I sure am
<jdong> pwnguin: I didn't expect noninterleaving RAM to have such a big performance impact as to make compiz UNUSABLE
<RAOF> jdong, pwnguin: As am I.
<jdong> I mean, it scrolled at 3 lines a sec in Firefox
<pwnguin> you upped the MHz, and dual channeled it
<andrew___> hi5: this is a very rough methodology, but try this: check the version history for all the packages in Ubuntu, and see how often they're updated...
<jdong> pwnguin: it was dual channeled
<jdong> pwnguin: just not interleaved (striped)
<pwnguin> what?
<hi5> andrew__: i'm listening
<jdong> pwnguin: popular benchmarks "cited" a 5% difference in performance
<jdong> pwnguin: what I saw was more like a 75% difference
<pwnguin> jdong: popular benchmarks use gma950 now?
<andrew___> Then download the current and last-but-one version, compute the diff, and divide by the number of days between updates...
<jdong> pwnguin: popular benchmarks OF the GMA950
<ajmitch> jdong: that sounds seriously broken
<jdong> ajmitch: idn if it's an EXA bug or what
<andrew___> That should put you on the road to a very rough number for bandwidth saved/day.
<jdong> ajmitch: OS X felt the same speed
<jdong> just Ubuntu crumbled without matched RAM
<andrew___> Then you publish that, it gets ripped to shreds for being unscientific, you come up with a better methodology, and after half a dozen iterations, people start agreeing with you.
<awalton__> then calculate the average frustrated user who got smited by a bad binary patch vs. the average user's anger of having to wait a few extra minutes for a package...
<andrew___> awalton__: wait for the numbers.  The conclusion might be something that nobody expects.  Like, 90% of bandwidth goes on OpenOffice, and splitting that into yet more packages would cut bandwidth in half.
<awalton__> (keeping in mind, of course, that the user who got bitten by a bad binary patch now has to download the whole package over again, or hope their file system does automatic revisioning.. or hope for a miracle of some other kind)
<pwnguin> jdong: how do you dual channel sticks of differing size?
<jdong> pwnguin: the access to RAM is distributed across to both channels independently, but they are not interleaved (i.e. striped)
<jdong> pwnguin: from what I understand on Intel dual channel and interleaving are not the same
<pwnguin> hmm
<pwnguin> ive only got AMD, this may explain things
<jdong> pwnguin: the AMD K8 memory controller might treat the situation much differently
<pwnguin> heh, in my experience, i cant boot incompatible ram
<pwnguin> if they wont interleave, it wont boot =/
<awalton__> the hidden horrors of on-core memory controllers -_-
<andrew___> hi5: I already have that methodology licked: it doesn't account for the popularity of each package.  Multiplying by the results from popularity-contest will give you a (decidedly biased) way to deal with that.
<pwnguin> awalton__: its' a fairly good win too in a lot of cases
<hi5> hmm
<awalton__> pwnguin, oh of course.
<awalton__> pwnguin, just not the panacea that everyone makes it out to be...
<pwnguin> as far as compiz performance difference goes, can more than one process render at once?
<pwnguin> if not, then the idea that dual channel non interleaved should be fast might block right there =|
<jdong> pwnguin: I'm not sure. It could also be Compiz or EXA doing something underneath that is bandwidth intensive on RAM
<jdong> pwnguin: because clearly OS X coped with it fine, just Ubuntu whenever Firefox is visible slows down to like 15fps
<pwnguin> you mean like rendering to a texture and then rendering again?
<jdong> pwnguin: I'm not sure, I don't nearly understand enouhg about the backend to make that judgement
<jdong> pwnguin: but at any rate, my 3GiB setup finds happy home in a mobility radeon x1400 system :)
<jdong> pwnguin: at the same time I had both systems open, I also transplanted an ipw3945ABG into the macbook
<jdong> which shall be interesting :D
<pwnguin> how do you transplant a wifi chip?
<jdong> pwnguin: both are mini-PCIe
<jdong> pwnguin: it was a straightforward swap minus fidgeting with antenna connectors
<pwnguin> wait, do any macbooks ever come with ipw?
<jdong>  pwnguin nope.
<pwnguin> heh
<jdong> pwnguin: so I've created a transvestite mac. I think.
<pwnguin> "osx sucks, my wireless card works fine in linux!!"
<pwnguin> jdong: a frankentosh
<jdong> pwnguin: lol currently, wifi support in OS X is a TODO
<jdong> (wow, how many times do you get to say *THAT*?)
<pwnguin> I had a friend who build a mac from refurb parts
<awalton__> sit in the osx86 rooms, you'll see it a lot.. ;)
<jdong> awalton__: true
<pwnguin> he mentioned that "it mounted into an ATX case just fine after drilling a few holes in the mobo"
<TheMuso> pwnguin: Surely other changes would have had to be amde to the back of the case for connectors etc?
<pwnguin> i have no idea, i didnt question him too hard after that
<TheMuso> heh right.
<pwnguin> even though it was on the floor and apart, i had seen it working previously
<pwnguin> we built and debugged nachOS on it
<awalton__> heh, surprisingly Macs have been pretty standard PCs for years.
<awalton__> the newer ones are even close to ATX inside..
<TheMuso> awalton__: The mac pros? I woulln't think they were.
<TheMuso> wouldn't.
<jdong> TheMuso: they are pretty similar to server xeons
<sladen> "pretty standard" would not be the phrase that would come to mind
<jdong> TheMuso: at least the one that I peeked inside
<awalton__> they're close.. the mountings are a bit off, but I managed to put a normal PC board in mine
<jdong> I had to put it back together when IS&T gave me a stare for disassembling a public terminal
<sladen> they have an x86 chip in them, yes.  But so does your washing machine and the space-shuttle booster rockets
<jdong> sheesh!
<pwnguin> i recently saw a similar minded, though less capable, person who had affixed an apple logo sticker to an acer laptop
<pwnguin> people
<awalton__> then again I love apple's hardware, so I probably stick out...
<awalton__> I'd use them exclusively if I weren't kentucky poor...
<pwnguin> you know, ive had to help look after some macs at a community college, and they don't hold up well
<pwnguin> but perhaps im comparing university lab use to my own standards
<awalton__> mine have.. well, with the exception of the stupid frat kid who thought it would be a good idea to shatter my iBook's LCD...
<awalton__> the powerbook I had before it held up to some pretty severe torture though
<jdong> pwnguin: we have a lab that's all kerberized Macs and they hold up very well from both a software and hardware point of view
<jdong> it's okay
<jdong> it's decent hardware, not the best, not the only decent ones
 * jdong has a 1 year old macbook that's holding very well to constant abuse
<pwnguin> well outside the halls of MIT we have to deal with the evils of preferred vendors
<awalton__> my condolences.
<jdong> pwnguin: lol we to. 50% HP 40% Dell 10% mac
<pwnguin> ever heard of atipa?
<jdong> gesundheit?
<pwnguin> exactly
<jdong> :)
<andrew___> hi5: I don't suppose you could have a community of people that lack bandwidth who collectively keep a memory stick current?
<pwnguin> i dont think its coincindence that atipa spelled backwards is "a pita"
<RAOF> So, I've just helped someone unbreak their 3d in #ubuntu-bugs because they installed the fglrx-control package, thinking that it would be awesome.
<hi5> andrew__: sorry, i've been reading stuff to implement the idea i think is more rational
<RAOF> What it *actually* did was install xorg-driver-fglrx, not set it up, and break their 3d.
<hi5> if this topic is still being discussed, i'll need to read back in a few to see if any useful ideas have emerged
<andrew___> hi5: As in, Alice has the stick Mondays, Wednesdays and Fridays, Bob has it Tuesdays, Thursdays and Saturdays; when Alice has the stick, she keeps [A-M]* current.
<hi5> else, it appears i'm still on my own so
<hi5> right, i understand andrew__
<hi5> that's insane
<andrew___> Not discussed, just me :)
<andrew___> How so?
<hi5> *oops, well.. no offense, that's insane
<pwnguin> so is downloading a gigabyte of updates over dialup :P
<hi5> large scale... 100,000 people in iraq won't do that
<pwnguin> i have a question
<pwnguin> how do you know that?
<hi5> thanks for the idea, i just don't think you understand the scale
<RAOF> It would be nice to be able to not break people's systems, or at least flag some sort of warning.
<andrew___> Yeah, you'd have to do it on the LUG level or something.
<hi5> sorry if that sounded a tad asscorbic
<pwnguin> your dns says minnesota
<hi5> yeah, well or setup a local server for repos
<hi5> a fork of current debian / ubuntu etc used locally
<pwnguin> hi5: have you actually consulted with the people you're presumablly attempting to help?
<hi5> that's still what i'm after
<hi5> for fuck's sake, screw it
<hi5> get beyond the idea of help small group of ppl in africa, *i'm* someone that would be helped by this
<hi5> so are MANY other's i've consulted in places like iraq
<hi5> this is the solution they want
<hi5> i'm sorry nobody in this chat can see why
<pwnguin> i can see why
<LaserJock> hi5: I think we all understand the problem
<awalton__> sure we can see why. it's the how we take issue with.
<awalton__> saying "this would be cool" is awesome. doing that cool thing is often a lot harder.
<hi5> well, no.. andrew said passing around a memory stick would be a solution. with all due respect, that's represents an extremely misunderstood notion of the problem
<LaserJock> hi5: it's not that bad of an idea though
<pwnguin> so is the problem rural minnesota or highly populated but underserved baghdad?
<LaserJock> I know a lot of people do similar things in Latin America
<pwnguin> ive read the USB stick story on planet somewhere
<LaserJock> somebody sends a CD then it travels from town to town
<hi5> physical media being passed around? i disagree.. there's invisible costs that are very high to that method
<hi5> i'll admit it seems only advanced users in these circumstances understands the need
<andrew___> I am assuming is that there are several people in a similar situation within walking distance of each other, but if that assumption holds, making it easy to use isn't a particularly hard problem.
<hi5> which might mean that advanced programmer types see why this is a dumb idea (which is fine if it really is)
<awalton__> it's not that it's dumb. it's just difficult.
<awalton__> weighing the ideas, cost/benefit, it doesn't seem to work out to me. feel free to disagree and prove me wrong though.
<pwnguin> oh i remember now. it was a story about distributing information in cuba by USB stick
<pwnguin> guerllia sneakernet ;)
<andrew___> pwnguin: guerilla is right - you're basically talking about a cell structure.  The IRA proved how well that scaled :s
<pwnguin> so did al queda?
<pwnguin> (and my dorm wing...)
<hi5> awaiton__: appreciate the response, as I'm sure you hope I (or someone else) will also, I'll try and prove you wrong about that for the betterment and greater dispersion of gnu/linux.
<hi5> hopefully it is as scalable as it still seems :)
<andrew___> pwnguin: let's not get into an argument about whose terrorists are better ;)
<pwnguin> i wasnt sure if you were making a postive or negative claim there
<andrew___> Who, me?
<pwnguin> i mean, the IRA claimed to give up / stop / disband / whatever
<pwnguin> so anyways as an ignorant american i have no idea how well that scales
<andrew___> Yeah, I'm just pointing out that cell structures are scalable.  The fact that the experts also tend to be bad guys isn't really relevant.
<hi5> i just think the latency sucks
<hi5> ;)
<pwnguin> well thats a tradeoff ;)
<andrew___> pwnguin: For the record, you're right.  The IRA stopped a while back, and so far as I'm aware, the place has been much better lately.
<hi5> pwnguin: "so is the problem rural minnesota or highly populated but underserved baghdad?" just saw that. minnesota... you saw my IP? idk why I'm bouncing off a mn server atm, never have before. short answer: shouldn't matter.
<pwnguin> well they're two different problems
<pwnguin> and yes, irc broadcasts dns unless you request a cloak
<hi5> well, my pt is they shouldn't be held to two different standards. and i've never been to mn, just using the dns for various reasons
<hi5> but it's water under the bridge unless you're driven by this issue as much as i am. otherwise, i've only got a few ppl interested so far i'm talking with and that's fine
<pwnguin> why not? a dense and close knit community might accept different solutions than people living in rural MN or rural KS
<pwnguin> recall the seattle wifi project
<andrew___> hi5: would it be fair to say that you've settled on keeping the current infrastructure but reducing the bandwidth?
<andrew___> As opposed to weird-and-wonderful, highly location-specific solutions.
<hi5> you mean as opposed to swapping flash drives to millions on sat. connections? yeah...
<andrew___> Well that wasn't what I was proposing, but fair enough.
<pwnguin> why is the target millions?
<hi5> anyway, i fear the conversation here isn't constructive any longer except with those that have PMd me so if you really don't care about the issue, feel free to ignore what I've asked earlier and thanks for the info.
<pwnguin> i just wonder why this particular rdiff solution is important to the classes you presented.
<andrew___> Yeah, I've said my piece w.r.t. reducing bandwidth.  I do wish you good luck, though.
<pwnguin> either way, I'd love to read some concrete results
<pitti> Good morning
<LaserJock> morning pitti
<ajmitch> hello pitti
<cartman|office> hi
<geser> Guten Morgen pitti
<pwnguin> so i found a hilarious lecture about rsync
<RAOF> Orly?
<pwnguin> by the author
<pwnguin> http://ftp.gnumonks.org/pub/congress-talks/ols2000/high/cd2/2000-07-21_15-02-49_C_64.mp3
<pwnguin> http://olstrans.sourceforge.net/release/OLS2000-rsync/OLS2000-rsync.html <-- transcription
<arekm> on ubuntu ftp there is a patch fixing somethings in 2.6.22 kernel - linux-source-2.6.22_2.6.22-14.52.diff.gz. I'm trying to find out where this patch is developed? Some repository I assume (where it's splitted into smaller logical chunks). Does anyone know where such repository can be?
<RAOF> arekm: That'd be in the Ubuntu kernel git repository.  I'll dig up a link for you.
<RAOF> arekm: https://wiki.ubuntu.com/KernelGitGuide?highlight=%28kernel%29
<arekm> thanks!
<siretart> morning folks!
<dholbach> good morning
<pitti> thekorn: argh, seems that p-lp-bugs fails all over the place :/
<pitti> hi dholbach
<dholbach> hiya pitti
<mvo> hey dholbach
<dholbach> hey mvo
<thekorn> good morning, pitti and dholbach
<pitti> hey thekorn
<thekorn> pitti, do you have any hint on how to reproduce it?
<dholbach> heya thekorn
<pitti> thekorn: I filed bug 228565 with an analysis and a patch
<ubottu> Launchpad bug 228565 in python-launchpad-bugs "AssertionError: Wrong XPath-Expr in Secrecy.parse() '__xml'" [Undecided,New] https://launchpad.net/bugs/228565
<pitti> thekorn: (and a reproducer)
<pitti> thekorn: ever-changing LP *sigh*
<pitti> thekorn: I have more problems, but one after the other
<thekorn> pitti, this is already fixed in the .main branch by kees and bdmurray
<pitti> ah, great
<thekorn> and I think it was already uploaded to hardy, but I'm not sure
<pitti> maybe only intrepid
<thekorn> yes
<pitti> gosh, the duplicate check pool is huge
<pitti> the retracers will have a fun time with catching up :)
<pitti> thekorn: hm, maybe I should stop using the hardy packages and just keep a checkout of main in the retracers
<pitti> thekorn: is there anything in the ubuntu branches except the packaging?
<pitti> (I don't use the packaging anyway, I just copy the module directory
<StevenK> Grm. And the PPA buildds are langpack'd again.
<thekorn> pitti, using the .main branch is a good decision
<pitti> thekorn: that will work for the 'outside' retracer, but of course not for the ones in the chroots
<thekorn> pitti, maybe we should think about an always up-to-date PPA
<pitti> thekorn: if we can (reasonably) count on API backwards compatibility, I could also do some dirty tricks as symlinking the outside branch checkout to the retracer chroots
<thekorn> pitti, I do not plan the change the API in the intrepid cycle
<pitti> thekorn: I might try that then
<pitti> thekorn: hm, attachment parsing is broken in hardy final as well
<pitti> $ python -c 'import launchpadbugs.connector as Connector; cb = Connector.ConnectBug(); cb.authentication=".lpcookie"; b=cb(218113); print b.attachments'
<pitti> []
<pitti> thekorn: is that also fixed in .main?
<thekorn> pitti, tworks in .main
<thekorn> the reason for this was yet another string change in launchpad
<pitti> gah
<pitti> thekorn: hah, that 'symlink to p-lp-bugs checkout outside of the fakechroot' seems to work
<pitti> thekorn: do you already have a test script which exercises the usual stuff?
<pitti> thekorn: which we could run after a new lp release (also of edge)?
<Keybuk> mvo: my System Monitor window is being shy
<Keybuk> for no readily apparent reason, it's transparent
<wgrant> p-lp-bugs should be a lot nicer in a couple of months, particularly with the lack of breakage from changes.
<pitti> wgrant: do you know something about a stable XML-RPC LP interface? :-)
<wgrant> pitti: With Python library included.
<gnomefreak> Keybuk: i saw same thing in blam i upgraded to a PPA package of xulrunner-1.9 nad it fixed it
<gnomefreak> but mozilla should be relasing RC1 in next few days/week
<wgrant> System Monitor != XUL
<gnomefreak> wgrant: blam isnt xul either
<gnomefreak> least i dont think it is
<wgrant> william@irranat:~/Development/ivle/trunk$ apt-cache show blam | grep gecko > /dev/null && echo "Isn't it?"
<wgrant> Isn't it?
<thekorn> pitti, I started some test here: https://code.edge.launchpad.net/~bughelper-dev/python-launchpad-bugs/better.testing.errors
<gnomefreak> nope its not from what show says
<StevenK> wgrant: grep -q
<wgrant> StevenK: That works too.
<pitti> thekorn: ah, cool
<wgrant> gnomefreak: gecko!
<thekorn> pitti, I plan to add this in the intrepid cycle
<gnomefreak> wgrant: http://gnomefreak.pastebin.ca/1012531
<thekorn> pitti, sorry I'm of for a weekend at the nordsee now, but I think it should be not hard to understand how this works, it's basically python testing/run_tests --all
<gnomefreak> it looks mono to me
<wgrant> I smell a libgecko2.0-cil.
<gnomefreak> wgrant: ok i missed that
<wgrant> grep doesn't lie.
<pitti> thekorn: right; thanks a lot, and enjoy the Nordsee!
<pitti> thekorn: with that much sun it should be fun
<thekorn> yes, of course
<pwnguin> hmm
<pwnguin> preliminary testing suggests apt-rsync cannot work
<pwnguin> at least, not without huge effort somewhere
<pwnguin> http://jldugger.livejournal.com/6115.html for anyone interested in hi5's rsync stuff from earlier.
<lucent> I haven't been following apt-rsync
 * lucent reads
<lucent> pwnguin: oh geeze, they're talking about rdiff on compressed data?
<pwnguin> to be fair, all you have to do is patch gzip to make it reset every so often
<pwnguin> i ran across a project to try that, with suggested losses of 3 percent compression
<pwnguin> or you could decompress the whole mirror ;)
<pwnguin> (and .debs I guess)
<lucent> that sounded silly when I thought to suggest it
<lucent> but yeah
<lucent> forget Deb package system for a moment, and let's take Gentoo system of source code downloads as an example
<pwnguin> someone already suggested that
<lucent> it's still mind-boggingly difficult to track diffs between source versions
<pwnguin> uuh?
<lucent> say you have a source-based dist
<lucent> foo user wants an efficient and minimal update to the data they already have
<lucent> how do you make a package management system which only grabs the diffs between one version of code and the next?
<lucent> it's okay for one or two packages, but the storage and management of so many packages, it is a lot of CPU overhead
<pwnguin> lets ask linus torvalds
<pwnguin> i hear git does this
<lucent> heh
<lucent> yes scm systems are brought in
<lucent> have you heard about making apt torrent'able?
<lucent> like p2p style
<lucent> in your journal entry, I read that the problem is about bandwidth being expensive, so I'm going on a tangent here
<pwnguin> this was also brought in
<lucent> when Ubuntu makes a release, I saw an unnacceptable slowdown in the mirror system to fetch updates
<pwnguin> i think the guy who suggested it was called selfish and unempathetic ;
<pwnguin> ;)
<lucent> :(
<pwnguin> like i said, too much investment in the solution instead of the problem
<\sh> who deals with NEWing before the weekend? :)
<pitti> \sh: my archive day today
<pitti> \sh: I just finished kicking fakechroot and the retracers, I'll start dealing with archive stuff now
<mvo> Keybuk: your system monitor window is transparent? out of the blue? you opened it and it was transparent?
<Keybuk> mvo: yeah
<pitti> argh, len(NEW) == 584
<Keybuk> some kind of weird interaction with murrine
<Keybuk> I guess that the system monitor app is rgba-aware
<Keybuk> but dunno why it ended up semi-transparent
<mvo> Keybuk: I switched to human-murrine to test it - is that sufficient?
<Keybuk> probably, yeah
<pitti> doko: can we remove gcc-4.0 from intrepid? it was removed in Debian long ago
<doko> "long ago" = this year, but yes, we can do that now
<pitti> doko: I meant 'not just last week' or so
<Keybuk> mvo: does for me, yes
<pitti> doko: ok, thanks
 * mvo tries it on a intel system
<mvo> Keybuk: it seems to be ok on a nvidia
<wgrant> It's fine on hardy/i915.
<seb128> pitti: when are the next language packs update planned? I think spanish users really would appreciate, we keep receiving bugs about nautilus crashing or displaying weird strings
<pitti> seb128: can they test the PPA ones? I was told to hold off until LP translations fixes a serious bug with teh Firefox translatiosn
<seb128> pitti: well, the strings have been fixing in rosetta sor ppa should be correct
<seb128> s/fixing/fixed
<pitti> right; as I said, I'm waiting for asac/jtv to give me thumbs up
<seb128> ok
<seb128> what is the ppa line to add again? I should not it
<seb128> s/not/note
<seb128> can't type today ;-)
<pitti> deb http://ppa.launchpad.net/ubuntu-langpack/ hardy main
<seb128> danke
<pitti> de rien
<ogra> argh
<ogra> mvo, why did u-m's icon change to such a scary thing ?
<ogra> (i had the nice star/sun a second ago, now there is a huge red arrow)
<james_w> isn't that for security updates?
<ogra> oh, we have different icons for different purposes now ?
<pitti> ah, I just wondered about the same
<ogra> james_w, right, thanks for the hint, installing only the security updates changes the icon back
<james_w> no problem
<asac> pitti: seb128: current state, waiting on decision from kiko for the cherry-pick
<hunger> Why are there so many pending builds for fakechroot in the intrepid build queue?
<ogra> because pitti plays around :)
<Riddell> pitti: please give back strigi/0.5.9-1
<pitti> hunger: many as in 3 (ok), or many as in 1000 (bug)
<pitti> ?
<pitti> hunger: yes, took me three uploads to get it really right, sorry
<hunger> pitti: 3 in the top 4 pending requests.
<pitti> hm, it shouldn't build the old versions...
<pitti> Riddell: done
<Riddell> thanks
<hunger> pitti: Oh, sorry. I missed the diff in the last digit of the version:-)
 * ogra wonders why he still didnt get the new vbox modules yet
<ogra> they were uploaded days ago
<xivulon_> ogra, you were working with loopfiles some time ago', correct?
<xivulon_> do you have any link to your project?
<ogra> xivulon_, yes and i resorted to use vfat and syslinux to not waste more time on weird grub hacks
<xivulon_> what was your project about, if I may ask?
<ogra> xivulon_, i didnt push the code up anywhere yet, its a specially custom image for the Classmate PC
<ogra> but its very dedicated to the HW in its design
<xivulon_> ogra, ok, was looking into bootable usb key/hd devices, and was wondering if there was any overlap
<ogra> http://people.ubuntu.com/~ogra/classmate/images/hardy/
<ogra> xivulon_, there wil be overlap for sure if we go towards intrepid
<ogra> i want to look into an easy USB image builder for this release we all can use
<mvo> ogra: yes, what james_w said
<xivulon_> i was looking for grub4dos + liveCDiso + overlaid file via uninonfs to make a bootable r/w liveCD like environ
<ogra> its a general topic on the platform team spec list :)
<xivulon_> ogra if I am around when that is discussed at next uds I will certainly attend
<xivulon_> only there last 2 days :(
<xivulon_> ogra I would think though that grub4dos should also work well for you
<xivulon_> and possibly even grub2
<ogra> xivulon_, you mean you will be in prague for the last two days ?
<ogra> grub2 would be the way to go imho, but its not clear that will be ready in time for intrepid yet i think
<xivulon_> ogra yes
<ogra> well, lets see that we get the schedule adapted for this :) and at least have a session about it in the last two days then :)
<xivulon_> that would be nice, thanks
<ogra> since we'll run into probs with archive size by adding a full usb image my idea was to have a script on the liveCD that builds you one so you can easily generate a liveimage with ubiqiity on the fly fom the iso
<ogra> d-i already supports USB keys with some easy fiddling that just needs some improvement
<xivulon_> ogra, in early wubi days, I had this approach of using a LiveCD as is (squashfs) but replacing some files therein at runtime
<xivulon_> the hooks are still there and it is well possible to do so
<ogra> well, if you have unionfs on top, there is no prob to use three directories ;)
<xivulon_> yes, I was using unionfs, to override default files, this is how I added loopfile support to the installer in 7.04
<ogra> what i do for the installer is simply using the squashfs as is in any case, have an ext3.img where i do my installer script specific adjustments and then in the end have both of these redonly merged with a tmpfs
<xivulon_> I did something similar squashfs (ro) + tmpfs (rw) merged via unionfs, and then copying over the files from a folder (this spares me the trouble of having to create an ext3.img).
<ogra> the installer dumps the squashfs in place and makes adjustments with mounted /cow in the target (the classmate keeps the readonly image, something you likely dont want for normal installs)
<xivulon_> I think eee has a similar approach internally, ro fs + rw fs via unionfs
<ogra> likely
<ogra> even the eee has 4G
<ogra> that would fit a scaled down normal install
<ogra> (classmate has 2G in the smallest setup)
<ogra> (and i have to squeeze 3G in there :) )
<xivulon_> heh
<xivulon_> well in fact I have to rectify my previous statements, in 7.04 even if support for livecd/squashfs + unionfs was in the code, I ended up using the alternate ISO for the actual installation
<emgent> pitti: thanks for you work :)
<pitti> emgent: you're welcome :)
<ogra> oh, fun, now i get why i dont have gotten any update to the vbox modules, apprently the last kernel update even removed the ones for -16  ... weird
<pitti> seb128, mvo: which was the good one? ccsm or compizconfig-settings-manager? the former is still in Debian
<seb128> pitti: ccsm
<seb128> pitti: and simple-ccsm
<pitti> hm, so shall I remove
<pitti> compizconfig-settings-manager | 0.7.4-0ubuntu2 | intrepid/universe | source, all
<pitti> and sync ccsm?
<seb128> that's a question for mvo I guess
<seb128> ccsm has no ubuntu change?
<seb128> they are not the same thing, they are different software
<pitti> ccsm isn't in Ubuntu
<mvo> pitti: please don't yet - debian seems to have choosen a different name for the same thing
<pitti> E: ccsm is trying to override compizconfig-settings-manager_0.7.4-0ubuntu2 without -f/--force.
<mvo> (oh well)
<mvo> pitti: what version does debian have?
<pitti> http://packages.qa.debian.org/c/ccsm.html
<pitti> 0.6.1~gitsomething
<mvo> pitti: please blacklist it for now, that is a ancient version
<ogra> (given that both broke my setup i'D vote to remove them all :P )
<pitti> mvo: ok
<mvo> there is a effort in debian with compiz, but they decided to go a different route, e.g. not use cdbs
 * pitti spots bzr-dbus from syncing
<pitti> WTH? :-)
<james_w> works nicely with bzr-avahi
<pitti> . o O { libtheschwartz-perl ??? }
<pitti> people don't stop inventing crazy names
<thom> heh
<thom> that's a good one. thank the livejournal people
<ogra> pitti, did the glib fix for not showing inaccessible mounts work for you in your ltsp tests ? even though i got confirmation from users i still see the issue in virtualbox
<pitti> ogra: yes, it worked for me (didn't I write so in the bug?)
<ogra> pitti, yes, you did
<ogra> i wonder why it doesnt work for me :(
<pitti> ogra: hm, I remember testing the one with the unmount menu
<ogra> ah
<pitti> ogra: I don't actually remember testing the 'hide inaccessible' one
<pitti> what's the bug#?
<ogra> 210379
<ogra> bug 210379
<ubottu> Launchpad bug 210379 in glib2.0 "should not list mounts that the user doesn't have permission to use" [Low,Fix committed] https://launchpad.net/bugs/210379
<ogra> you said you can verify
<pitti> ogra: right, I didn't test that yet
 * pitti does now
<ogra> but not that you did
<ogra> bu i know at least two users from #ltsp for which it fixed the issue
<pitti> that's actually easy, login as a second user, plugin an USB drive, it shouldn't appear for the first user
<ogra> one commented
<ogra> right
<pitti> I do know that this was the case before, and you got a nautilus window and an error
<ogra> well, in vobox i have a floppy icon on the desktop for every user and mounting an iso as CD shows up for everyone as well
<pitti> erk
<pitti> I did that, and now my primary user has a completely white window here
<pitti> (nautilus)
<ogra> sounds not right
<pitti> and another completely white dialog box
<ogra> what about desktop icons ?
<pitti> got it as well
<ogra> :(
<ogra> i wonder why the two guys saw it fixed then
<ogra> i guess we need to look into that agin
<ogra> *again
<ogra> thanks for testing
 * ogra gets glib and takes a look at the patch
<pitti> ogra: well, CDs might be a different case -- are they really mounted as 700?
<ogra> yes
<pitti> but probably not if you have it in fstab
<pitti> ?
<ogra> and all in subdirs owned by the user in /media
<ogra> fstab is different
<ogra> i have /media/ogar/cdrom and /media/test/cdrom
<ogra> *ogra
<ogra> and i have a hardy cdrom mounted on the server which is actually supposed to show on all desktops
<mrec> is there anyone here who knows about the latest kernel in hardy and how alsa is wired with it?
<mrec> I'm getting a general protection fault when trying to load a module built against the sources of the latest kernel
<mrec> so I'm actually just looking for sources which are in sync with the running kernel which comes with ubuntu hardy
<mrec> I've got quite alot bugrequests because of that
<mrec> the solution for me would be to wipe out that kernel and set up my own one but I'd like to avoid that if possible
<pitti> mrec: apt-get source linux linux-ubuntu-modules-2.6.24 should give you the two relevant source packages
<pitti> mrec: linux is more or less teh upstream kernel, and l-u-m are third-party, and backported modules
<pitti> mrec: I believe that l-u-m has newer ALSA drivers
<mrec> pitti: alsa is the problem yes
<mrec> it's not in sync with the kernel sources which modules are normally built against
<pitti> dpkg -L linux-ubuntu-modules-2.6.24-17-generic
<pitti> mrec: ^ check this output whether the affected module/driver is in l-u-m or the kernel
<pitti> mrec: (that's the kernel from -proposed, BTW; you might have -16, which is hardy final)
<mrec> yes I have 16
<pitti> mrec: btw, if you don't use hardy-proposed, it might be worth a try; -17 has several fixes which might also solve your problem
<mrec> it's about empiatech hybrid analog / digital TV drivers
<mrec> is there a chance to get them included even in final now?
<ogra> pitti, oh, its 755, my bad
<ogra> wtf
<pitti> mrec: see https://launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24, the second-latest changelog
<ogra> who changed that? grmbl
<pitti> mrec: that pretty much sounds like your problem
<pitti> ogra: 'changed'?
<ogra> pitti, it was 700
<ogra> checking upstream bzr
<mrec> pitti: ya I read through that one already, do you know when this will be in upstream?
<mrec> urgency should be high actually
<pitti> mvo: it's not an upstream problem, it was an Ubuntu packaging bug
<mrec> I could immediatelly add around 60 devices to ubuntu if this would work
<pitti> mrec: if you mean '-updates', not 'upstream', a week or two
<ogra> pitti, do i need a separate SRU for that one digit change in ltspfs or can that just go under coverage of the existing bug (i.e. can i just upload a fixed package to proposed or do i need extra paperwork ?)
<mrec> pitti: ah well it doesn't seem to matter it's just a source change no binary one.
<mrec> So I guess to fix my problem I just need those sources
<ogra> pitti, http://paste.ubuntu.com/11110/
<ogra> pitti, confirmed, that fixes it
<jeromeg> does anyone know the name of the application which is launched in gnome when pressing ALT + F2 ?
<andrew___> You mean the "run application" dialogue?
<jeromeg> andrew___: yep
<andrew___> After a quick play with `ps`, I don't think it's an application at all.
<jeromeg> andrew___: i would like to find the sources of this dialog
<jeromeg> andrew___: yeah, it must depend on the panel or something like that
<andrew___> Makes sense.
<pitti> ogra: it should become a separate task; anyway, I just added a comment; this is all very confusing
<pitti> andrew___: I think it's produced by the gnome panel
<ogra> pitti, the ltspfs fix is mentioned in the gnome bug
<jeromeg> andrew___: just checked, it's indeed included in the gnome panel code
<ogra> pitti, /media/$USER isnt a mointpoint ;)
<pitti> ogra: oh?
<ogra>  /media/$USER/$client_device
<ogra> thats the actual mountpoint
<pitti> ogra: ah, I see
<pitti> but shouldn't $client_device itself be 700?
<ogra> so so get indeed E_ACCESS :)
<pitti> (by virtue of mounting with umask=700)
<ogra> hmm
<pitti> ogra: either way, I wonder why this change works for you, but not here
<ogra> did you patch lbmount ?
<ogra> sbalneav, !
<sbalneav> Morning!
<ogra> youre alive :)
<sbalneav> :)
<pitti> hey sbalneav
<sbalneav> Hey pitti
<ogra> pitti, lbmount creates the /media/$UID dir (if nonexeisting) on plug and removes it (if empty), i doubt just changing permissions will be a proper way of reproducing
<ogra> the devices are all mounted 755
<ogra> with user=$USER
<pitti> ogra: ok, if you actually *want* the devices to be umask=022, then I see why you need to chmod 700 the parent dir
<pitti> ogra: (in Ubuntu proper we mount devices with umask 077 by default)
<pitti> ogra: I am just saying that currently nautilus still tries to open a window for inaccessible devices for me
<ogra> pitti, i wonder why they appear as 022 :/
<ogra> it will only not open them if they are in a subdir
<ogra> davidz refused to do it for all devices
<pitti> ogra: you mean it only checks /media/foo/bar, not /media/bar?
<pitti> why on earth??
<ogra> right
<ogra> read the upstream bug
<ogra> its silly but no way to fix it if its true
 * pitti sends a rant to the upstream bug
<ogra> seems gnome-vfs was to hacked up to fail on hanging mounts gvfs is shiny and beautiful and the glossy shoeshine but will hang on E_ACCESS on stale nfsmount
<ogra> thats what the current tenor is apparently
<pitti> ogra: replied upstream and in the ubuntu bug
<ogra> pitti, http://bazaar.launchpad.net/~ltsp-upstream/ltspfs/ltspfs-trunk/revision?start_revid=wtogami%40redhat.com-20080428222323-en6gyfai5fzwdz8k&filter_file_id=lbmount.c-20060916234153-8xltobgv2a2xtqy1-3
<ogra> pitti, explanation about the choice of 750
<ogra> even though they didnt seem to take 0700 into account at all
<pitti> ogra: what's the group of those directories?
<ogra> lets see
<ogra> ah, thanks for asking ... that was the missing bit, the dirs are root.$USER and 750
<pitti> ogra: weird
<pitti> well, if they are managed by a root process, it's ok
<ogra> no, bmount is suid root, remeber
<ogra> all fine that way
<ogra> *lbmount
<pitti> yeah, I said 'weird', not 'wrong' :)
 * pitti hugs ogra
<ogra> :)
<pitti> ogra: so, I don't mind that ltspfs change, but I'd still like to see gvfs be fixed properly
<pitti> the current behaviour sucks for multiple users
<ogra> pitti, your suggestion on the bug wont help ltspfs
<ogra> they are no local devices
<pitti> ogra: right
<ogra> so that still needs special casing
<pitti> ogra: if you want the devices to be umask=022, it won't help either
<pitti> ogra: right, I agree
<hwilde> anybody know why the story of why xmms was dropped ?
<pitti> hwilde: it's dead
<ion_> And it was starting to stink.
<pitti> and it had long-standing security issues nobody cared about
<ogra> imho gio should have a comparison list for filesystems and their capabilities anyway though
<ogra> and act accordingly
<hwilde> so is there a lightweight way to play shoutcast streams (without totem and the visualization) ?
 * cody-somerville wonders why synergyc performs so horribly in Hardy but not Gutsy. :/
 * ion_ typically uses mplayer-nogui, assuming shoutcast streams are just streaming MP3s.
<hwilde> ion_,  it's a url stream playlist   http://www.shoutcast.com/sbin/shoutcast-playlist.pls?rn=2916&file=filename.pls
<hwilde> I just like the winamp look and feel of xmms :/
<pitti> ogra: processed (please upload to intrepid, too)
<ogra> pitti, debians ltspfs will have the fixes
<ogra> i'm starting t switch to syncs with the ltsp stuff where possible
<ogra> i just havent decided on ldm yet, thats ahy ltspfs still sits on mom
<ogra> *why
 * davidm is back (gone 17:37:19)
<ion_> davidm: Thanks for the info!
<jdavies> !away > davidm
<hwilde> Keybuk, iftab replaced by udev now?? :/
<Keybuk> hwilde: no
<Keybuk> iftab replaced by udev A LONG TIME AGO ;-)
<hwilde> heh
<ion_> :-)
<hwilde> are there a set of tools I could be using to make an image that can be ported to multiple machines?
<ion_> !away > ion_
<hwilde> now I have to change UUIDs for the harddrives and MAC addresses in udev
<hwilde> how do oem people build images to clone?
<andrew___> hwilde: Have you tried asking in #ubuntu?
<andrew___> My understanding is that they're better with support type stuff.
<dholbach> hwilde: maybe http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/ helps
<hwilde> #ubuntu is just a bunch of noobs asking each other noobish questions... I don't even get responses there
<andrew___> Fair enough, shows what I know :)
<hwilde> hehe
<hwilde> I was not so much asking for support, but more asking how I might develop an image that could be cloned to multiple machines... so I thought maybe devel could help :)
<Ng> isn't the correct way not to use images, but to use pre-seed installs, so that information is generated correctly?
 * hwilde writes down new vocabulary word   "pre-seed installs" 
<hwilde> Ng, any link or resource about this?
<Keybuk> dholbach: typical jdub sillyness
<hwilde> Keybuk, can't I just delete that file and trigger whatever builds that during the initial install and have it generate with the correct mac ?
<Keybuk> yes
<hwilde> can you replace "whaver" in that sentence with what I should be looking for :)
<hunger> Is it save to remove the gcc4.2 stuff when upgrading from hardy to intrepid?
<hunger> What about the perl-holdback? I guess I need to wait for all the perl stuff in the build queue to get done?
<hwilde> Keybuk, udevinfo -a -n eth0    doesn't work... how do I get it
<Keybuk> interfaces don't have devices
<Keybuk> udevinfo -a -p /class/net/eth0
<cjwatson> hunger: if you aren't able to work out the answers to those questions, please don't run intrepid yet
<hwilde> Keybuk,  do you think its safe to take out the MACs and use DRIVERS=="e100" for eth0 and DRIVERS=="ath_pci" for ath0   http://pastebin.com/m770185db
<hunger> cjwatson: Add updates to hardy then so that I don't need to suffer from my package addiction ;-)
<Amaranth> !amaranth
<ubottu> Stabbity stab
<hunger> cjwatson: Withdrawal sympthoms have set in;-)
<cjwatson> hunger: I'm sorry, but this is still not the place to ask basic questions about how to deal with routine package upgrades in a development release, even if you think our update standards are wrong.
<cjwatson> hunger: if you upgrade through intrepid and don't have the ability to deal with this sort of thing, then your system is almost guaranteed to break beyond your ability to fix it
<hunger> cjwatson: I'll manage, no worries:-)
<hunger> cjwatson: I've been doing this since before breezy. I just don't know whether gcc 4.2 or 4.3 is the default nowadays.
<Keybuk> hwilde: I would just delete the file and let it be generated automatically
<Keybuk> there's zero point writing that by hand
<hwilde> Keybuk, I don't know how to do that
<hwilde> Keybuk, I image the disks using ghost
<hunger> cjwatson: So far I have not seen that documented... but that probably is my own problem since I hate to use LP:-)
<Keybuk> hwilde: you don't know how to delete files?
<hwilde> Keybuk, funny... after I delete it, what would regenerate it with the correct macs ?
<Keybuk> automatic stuff
<hwilde> !find gcc intrepid | hunger
<ubottu> hunger: Found: gcc, gcc-4.1, gcc-4.1-base, gcc-4.1-doc, gcc-4.1-multilib (and 35 others)
<cjwatson> hwilde: so, do you think that was helpful ...?
<hwilde> maybe if it displayed the other 35
<hunger> hwilde: Thanks, but I do have the package list.
<cjwatson> hunger: consider for example 'apt-cache show gcc'
<hwilde> Keybuk, seriously?  the udev rules will just rebuild themselves on the next reboot ?
<Keybuk> yes
<hwilde> wow
<hunger> cjwatson: Thanks. So not having cpp-4.2 deinstalled is a oversight and will be fixed at some point.
<cjwatson> hunger: why would we require the old compiler to be deinstalled?
<cjwatson> that would be inconvenient for many people
<cjwatson> the different compiler versions don't conflict
<hwilde> that statement would be funny out of context
<cjwatson> if you've been doing this since breezy, you'll have seen this before
<hunger> cjwatson: I know. But in this system cpp is dragged in as a dependency, so it should get deinstalled.
<hunger> cjwatson: Ah, found it. libqt4-dev still depends on it indirectly:-) So I can indeed remove it. Thanks.
<hwilde> Keybuk, can that rebuild be triggered without a reboot ?
<hunger> hwilde: Remove the card or its driver.
<Keybuk> hwilde: yes, but if you don't know how, you don't want to do it
<hwilde> Keybuk, heh thats what i thought
<hwilde> very cool tho
<Keybuk> it'll generate it exactly the same as the one you just deleted, after all
<hwilde> now if grub can just do the same I can delete the menu.lst :)
<hwilde> Keybuk, no I can delete /etc/udev/rules.d/70-persistent-net.rules from the image, and first reboot on the clone'd machine it will regenerate with the correct macs
<Keybuk> right
<hwilde> that is freaking awesome
<hwilde> only thing left is the UUIDs in fstab and grub.   am I losing anything by replacing the UUID with generic /dev/sda1 so it can be cloned to another machine?
<cjwatson> /dev/sda1 isn't generic
<cjwatson> there are still systems on which it will be /dev/hda1
<cjwatson> if you don't care about that, then you aren't losing anything
<hwilde> not on mine, they're all the same
<hwilde> the older one is hda1 tho you're right
<hwilde> if there's no benefit then why complicate things with UUIDs ?
<cjwatson> there is a benefit
<cjwatson> 17:24 <cjwatson> there are still systems on which it will be /dev/hda1
<cjwatson> I didn't mean purely older systems
<cjwatson> and also it made the transition vaguely sane
<hwilde> ahh I see
<Amaranth> at install we can see that hda1 is / and hda6 is /home but if at upgrade time those change to sda1 and sda6 we have no way of knowing
<hwilde> yeah
<Amaranth> they might have changed to sdb because maybe you already had an sda, etc
<hwilde> that makes sense
<hwilde> but I can't clone UUIDs between systems, and /dev/sda1 works fine, so i'll just go with that
<Amaranth> sure, in your case you know what your hardware is and can take such shortcuts
<jdong> hwilde: I think the UU part of UUID makes that a bad idea.
<jdong> :D
<cjwatson> we know UUIDs are a bit unwieldy, but unfortunately they remain (AFAIK) the best solution to the problem at hand
<jdong> oh nvm
<jdong> misread your sentence
<hwilde> sweeheh
<jdong> thought you said you were going to clone the UUID from another system
<hwilde> I wish
<Keybuk> if you insert a second drive, it may become sda1
<Keybuk> with your original sda1 now sdb1
<Keybuk> and *boom* she vill not boot
<hwilde> seriously?
<Keybuk> seriously
<hwilde> why wouldn't the new one have the new name
<Keybuk> better question
<Keybuk> why _would_ it?
<jdong> hwilde: because there's no guaranteed order of initialization
<jdong> hwilde: even on the same system drives could come up in somewhat nondeterministic order
<jdong> I had one system with 5 drives where 2 of them would consistently swap block device names every boot
<hwilde> so how does Dell do it?  They type in the unique UUID on every system??
<Keybuk> I would imagine that every Dell computer has the same root filesystem UUID
<Keybuk> since it's a cloned image
<Keybuk> (but maybe not, since that would lead to other problems)
<jdong> Keybuk: I'd expect them to have a smarter way of generating them?
<jdong> (I hope)
<Keybuk> indeed
<hwilde> there must be oem tools to handle this...  I want them
<Keybuk> hwilde: oem-config
<Keybuk> the installer has its own oem mode
<jdong> it's not hard to programmatically get the UUID of a disk and replace placeholders in fstab/menu.lst with it
<cjwatson> oem-config doesn't handle UUIDs, though it does have hooks into which you can drop your own scripts to do that kind of thing
<hwilde> jdong, it is if the system won't boot.
<Keybuk> why wouldn't it boot?
<jdong> hwilde: presumably it's done by the installer
<jdong> as the last step of installation
<cjwatson> jdong: he's ghosting an image
<jdong> cjwatson: ah.
<Keybuk> ghosting an image copies the filesystem exactly, right?
<hwilde> yeah if I was going to go through the installer everytime this wouldn't be an issue
<hwilde> yes it copies bit by bit the entire flashcard
<cjwatson> file-by-file, or at the filesystem level?
<jdong> I'm guessing binary?
<jdong> (at the file system level)
<Keybuk> hwilde: so what's the problem with UUIDs?
<cjwatson> hwilde: you may be missing the information that UUIDs are associated with a filesystem, not with the hardware
<hwilde> they are not unique ?
<jdong> hwilde: not if you clone them
<cjwatson> they are unique to the filesystem
<Keybuk> hwilde: if you've bit-by-bit duplicated the filesystem
<jdong> hwilde: the UUId is a field in the superblock
<Keybuk> you would have duplicated the UUID too
<jdong> hwilde: if you do a binary copy it duplicates the UUID
<mjg59> hwilde: Didn't we have this conversation last week?
<hwilde> I am struggling to remember said conversation, or the reason why UUIDs allegedly did not work...  i'll give it a shot
<Keybuk> are you sure you'll be able to support the systems you're cloning?
<hwilde> nah we have a support department for that
<hwilde> :)
<jdong> ...
<andrew___> I'm way out of my depth here, but is this something that LVM could help with?
<jdong> I don't think LVMs are any easier to boot ;-)
<Keybuk> andrew___: same problem
<andrew___> If UUIDs on normal drives are somehow hardware-specific, LVM UUIDs can't be.
<Keybuk> the filesystem in the LVM has a UUID
<Keybuk> the LVM PV has a UUID
<hwilde> it sounds like everyone says to just use the UUIDs, and I can't remember why we aren't, so i'll try it
<Keybuk> and the drive the PV is on would still change names
<hwilde> where they never unique ?
<hwilde> like back in 6.06 ?
<Keybuk> hwilde: *wah*wah*scary*UUID*
<Keybuk> hwilde: they are unique for each invocation of mkfs
<Keybuk> if you copy the filesystem image you make, the UUID is also copied
<Keybuk> the UUID of every Ubuntu Live CD is identical, since we don't mkfs on each boot ;)
<hwilde> great then I can just clone them
<hwilde> but... how do I find the UUID now to restore fstab and grub :)
<ion_> UUIDFSVOUU
<Keybuk> hwilde: vol_id
<andrew___> cjwatson: mind if I pick your brains a bit again?
<hwilde> Keybuk, what kind of device path is it expecting?  it doesn't like sda /dev/sda sda1 /dev/sda1
<hwilde> Keybuk, nvrmind
<cjwatson> andrew___: now is probably not the best time, I'm afraid
<djwon1> kirkland: i hear you're trying to get a hold of me?
<kirkland> djwon1: hey there, i just msg'd djwong
<kirkland> djwon1: yeah, deneen pointed me to you about a power management driver you're working on....
<djwon1> which one?
<djwon1> there's two kernel drivers so far
<kirkland> djwon1: :-)  you tell me....
<djwon1> ibmpex = old power meter hardware interface driver
<djwon1> ibmaem = new (2006 onward) power meter interface driver
<kirkland> djwon1: ibmaem is targeted for 2.6.26?
<djwon1> maybe.  it's in akpm's tree right now; don't know if he'll push to linus before .26
<djwon1> alternately the hwmon maintainer might come back to life and push it to linus late in the rc cycle (he did for adt7473 in 2.6.25-rc2)
<kirkland> djwon1: gotcha
<kirkland> djwon1: is there some documentation overview you can point me to for ibmaem ?
<Amaranth> the 2.6.26 merge window is over
<djwon1> Amaranth: yes it is, but linus took new drivers after the 2.6.25 merge window closed, on the grounds that there weren't any regression possibilities
<vbabiy-laptop> Hey guys is there a way to manage policy kit for more then one computer remotely
<djwon1> kirkland: yes there is, but the doc file fell off the patch :(
<kirkland> djwon1: ;-)  could you send something or a url my way?  kirkland@canonical.com
<djwon1> sure
<kirkland> djwon1: deneen also mentioned a userspace component, written in python?
<kirkland> djwon1: still undergoing OSSC?
<djwon1> who knows
<djwon1> still wrangling with "IP concerns" or some nonsense like that
<kirkland> djwon1: fun, fun
<djwon1> a year of meetings for 5 months of coding work
<kirkland> djwon1: is the userspace stuff necessary for the driver to do any good?
<djwon1> tis not required
<kirkland> djwon1: can you tell me briefly what ibmaem does by itself then?
<djwon1> reads air temperature/energy use registers from the BMC
<kirkland> djwon1: and logs them /proc or /sys?
<djwon1> no logic involved, just simple ipmi commands
<djwon1> and exports them via sysfs
<kirkland> djwon1: and the userspace code does something smart with cpu freq scaling based on that data in sysfs?
<djwon1> the userspace program figures out correlations between cpufreq steps and power consumption so that you can set a power budget and constrain the system
<djwon1> if you only care about _energy_ then it's usually best to run the system at full speed and then fall asleep, of course :)
<kirkland> djwon1: okay, cool.  well let me know when it makes it into Linus' kernel, and when the userspace stuff comes available.  i can help with the packaging, and getting the module build flag turned on.
<djwon1> ok
<bigon> infinity: hi are you around?
<djwon1> kirkland: the "old" ibmpex module seems to be turned on already in hardy
<kirkland> djwon1: yeah, I saw that
<djwon1> old is a bit of a misnomer since we only stopped shipping systems with that interface a month or two ago
<kirkland> djwon1: when i saw that, i figured Deneen must have been talking about something newer
<kirkland> djwon1: is there a user space app necessary to make that information useful?
<kirkland> djwon1: or is that said code in the OSSC black hole?
<djwon1> ibmpex is monitor-only, so lm-sensors 3.0 can pretty-print the readings
<djwon1> er.. 3.0.2
<kirkland> djwon1: gotcha.  i'm familiar with lm-sensors
<kirkland> djwon1: will lm-sensors be able to read ibmaem data, or will it need to be enhanced to do so?
<djwon1> no enhancements to lm-sensors needed
<djwon1> except for the parts that make it read power/energy sensors, which is part of the 3.0.2 release
<djwon1> (if they've even released that yet)
<kirkland> djwon1: gotcha.  hardy ships lm-sensors-3.0.0-4ubuntu1
<kirkland> djwon1: your new userspace code, are you seeking to contribute it to lm-sensors, or somewhere else?
<djwon1> wishing i'd just contributed it to lm-sensors
<kirkland> djwon1: always easier to push to an existing project :-P
<djwon1> someone got wind of it and said "This would be great to release on IBM's web site"
<djwon1> *bam* legal approval hell
<kirkland> djwon1: my experience was a) write whitepapers and put those on ibm's website (developerWorks), b) write code and put it were it belongs, in properly managed/packaged open source projects ;-)
<djwon1> hmm
<djwon1> i might have an old tarball on kernel.org still
<djwon1> nope, gone.
<djwon1> sadly, the blueprint route is the fastest approach to getting it out
<djwon1> though allegedly it's shipping in the idataplex
 * ogra giggles 
 * ogra giggles even loder 
<ogra> *louder
<Amaranth> Ok, ogra finally had a mental breakdown.
<ogra> opensuse uses my configure-X.sh script from ltsp as default way to configure X on their liveCD
<Amaranth> hrm
<ogra> (configure-x.sh is a very hackish sed script that just replaces vlues in the dump of X --configure output, nothing i'D use outside of ltsp)
<Amaranth> yeah
<Amaranth> that's....wow
<ogra> yeah
<ogra> " it just seems faster than our sax2 tool, so for trial Beta3 live CDs are now using it"
<compbrain> Anyone know the magic incantation in debian/control for a package to depend on libc6 used to build it?
<cjwatson> compbrain: ${shlibs:Depends}
<cjwatson> unless you actually *mean* the version of libc6 used to build it, rather than the usual answer of the version of libc6 that will satisfy its symbol requirements
<compbrain> cjwatson: That was the one, thanks!
<james_w> I can't find a policykit mailing list, do they just use the hal one?
<james_w> alternatively, anyone here know how to debug why policykit isn't allowing an action? It's telling the app to acquire an authorisation to do it, when I already have said authorisation granted.
<Amaranth> how does the brainstorm site decide who is a developer?
<stgraber> funny, you are the second one to ask that today :)
<LaserJock> :-)
<stgraber> so, basically we (someone from the QA team) set you as Developer
<Amaranth> Who is the QA team? :)
<Amaranth> You, I guess
<stgraber> Canonical's QA Team + nand + me
<Amaranth> alright then, can you set me as a developer?
<Amaranth> do you need my #?
<stgraber> done
<Amaranth> Oh, thanks
<stgraber> np
#ubuntu-devel 2008-05-10
<rio> where can i find the maintainer of libgphoto2?
<rio> i fixed a problem with certain canon cameras
<LaserJock> rio: probably the best is to file/find a bug and attach a patch
<LaserJock> rio: we don't have specific maintainers
<mathrick> hi, sorry for dropping in out of the blue, however, upgrading to Hardy exposed me to the atrocity of freesans again... so is anyone familiar with fonts / fonts.conf situation enough to tell why exactly Free{Sans,Mono,Serif} aren't listed as absolutely last in the list, emergency fallback fonts if there's really nothing else?
<rio> LaserJock: i already did that
<LaserJock> rio: great, thanks for that
<mathrick> and where/whose buttons do I press to see them banished in Hardy+1?
<rio> LaserJock: https://bugs.launchpad.net/ubuntu/+source/libgphoto2/+bug/228154 :)
<ubottu> Launchpad bug 228154 in libgphoto2 "Canon Digital IXUS 30 doesn't show up as PTP" [Undecided,Incomplete]
<LaserJock> rio: cool
<rio> LaserJock: which status should i set?
<LaserJock> rio: hmm, I guess back to New
<LaserJock> as I don't see anybody confirming it
<rio> okay
<ted2> So, where do I find "merge-genchanges"?
<LaserJock> ted2: it's created by grab-merge.sh
<LaserJock> and it's wherever you ran grab-merge.sh from
<ted2> LaserJock: Cool, thanks.  I found it now :)
<Auzy> hey.. I assume its known that brainstorm has run out of space again?
<Riddell> pitti, doko, Mithrandir: could you give back strigi/0.5.9-1
<Xtreme_Great> I wanted some help regarding kernel module programming
<Xtreme_Great> The compiler can't find module.h
<Xtreme_Great> can anyone help?
<Xtreme_Great> I wanted some help regarding kernel module programming
<Xtreme_Great> anyone?
<Hobbsee> ...
<Hobbsee> fail.  on multiple criteria.
<Xtreme_Great> Is there anyone who can help me out with the module.h not found problem?
<Xtreme_Great> I can't understand where to get that
<Xtreme_Great> anyone of all 231
<Hobbsee> Xtreme_Great: please read the /topic
<Hobbsee> !weekend
<ubottu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Hobbsee> Xtreme_Great: dpkg -S module.h will give your answer.
<Hobbsee> Xtreme_Great: also, packages.ubuntu.com would have told you.
<mok0> Xtreme_Great: there are 166 packages containing module.h
<mok0> :(
 * Hobbsee suggests picking the most sane one.
 * mok0 concurs
<LucidFox> What's the point of having both cairo and libcairo?
<LucidFox> they provide the same binary packages, only cairo is newer
<geser> LucidFox: check if it was renamed in Debian and we simply forgot to remove the old source package
<LucidFox> it was indeed renamed in Debian, and then in Ubuntu
<geser> file a remove request for the old source package then
<LucidFox> maybe there was some reason?
<LucidFox> I imagine if libcairo  was simply forgotten, it would stay in main - instead it was demoted to universe
<geser> LucidFox: there should be no reason to have two source packages building the same binary debs
<geser> as you can only have one version of the binary debs in the archive (the newer ones)
<Hobbsee> LucidFox: if nothing depends on it, it would get marked on teh 'drop' list
<geser> Hobbsee: libcairo is the old source package name of cairo (both produce the same binaries)
<Hobbsee> right
<Hobbsee> then file a bug, get it removed
<Hobbsee> as you said :
<Hobbsee> * :)
<cjwatson> LucidFox: demotion to universe is the sort of thing that might well happen semi-automatically
<cjwatson> without somebody thinking too much about it
<cjwatson> removals tend to require actual thought
<LucidFox> can it be removed from hardy now, or only from intrepid?
<cjwatson> can't remove packages from hardy now
<cjwatson> or "won't" if you prefer, but the result is the same :)
<emgent> heya thesaltydog
<thesaltydog> mom
<emgent> dad?
<emgent> :)
<Lightkey> oO
<Lightkey> I know a salty-horse, are you two related?
<emgent> Lightkey: i think now :)
<emgent> s/now/no/
<thesaltydog> eccomi, ma vado di corsa!
<emgent> thesaltydog: this is an english room, anyway no problem :P
<Lightkey> no, the other was from israel..
<thesaltydog> oh, sorry. I have 5 tabs opened!
<Lightkey> that is not much
<thesaltydog> Hi oliver ogra!
<thesaltydog> Lightkey, for me is over my limit..:-(
<stgraber> I have something like 21 chans opened, not that hard to manage
<helowo> 8->7 here ;)
<Lightkey> no chance, I have the longest
<Chipzz> what's with this? http://bobthegnome.blogspot.com/2008/05/apportbug-buddy-disabled-in-ubuntu-804.html
<Chipzz> what is the intended behaviour for that?
<ssam> Chipzz, https://launchpad.net/ubuntu/+source/apport/ the change log for 0.108 say "Disable Apport for the final Hardy release"
<cjwatson> Chipzz: yeah, it's intentional
<cjwatson> bug-buddy should maybe have the same done to it
<cjwatson> (maaaaybe)
<Chipzz> cjwatson: but the post mentions bug-buddy not being enabled either - is that a bug or intended behaviour?
<cjwatson> Chipzz: the subject line says that, but the post itself doesn't back it up; a comment indicates that bug-buddy probably is enabled
<cjwatson> though that comment is also odd because Ubuntu 8.04 does have bug-buddy 2.22 and there's no obvious reason why it shouldn't have been upgraded along with everything else; also it is still installed by default
<cjwatson> so it's unclear to me exactly what's going on there
<andrew___> Can a package in main suggest or recommend a package outside of main?
<sistpoty> andrew___: suggest: definitely... it used to be that it can recommend a package outside main as well... not sure if this is still true though
<andrew___> Okay, good.
 * andrew___ continues pondering
<pochu> would an archive admin approve a package which just has 'BSD' in LICENSE?
<geser> pochu: just the word "BSD" or the complete BSD licence text?
<pochu> just the word
<andrew___> Surely that's ambiguous?
<andrew___> (How many clauses of BSD license do you mean)
<pochu> I see
<andrew___> Why not include the whole thing?
<pochu> ask upstream :)
<andrew___> Ah :)
<andrew___> How about you started maintaining a very close fork?
<pochu> andrew___: I guess I can't fork it since I don't know what BSD license it has ;-)
<pochu> andrew___: anyway I'm reviewing it, not packaging it :)
<pochu> I'll ask the packager to ask upstream to fix this
<andrew___> Good catch-22.
<pochu> also there's no single 'copyright' word in all the upstream code
<andrew___> Yeah, I'm no lawyer, but it doesn't sound legally very useful.
<pochu> right
<andrew___> Especially if there's no hint who it's attributed to or how you'd contact them.
<pochu> well, there's the AUTHORS file with their names and emails, but my problem is that the packager put 'Copyright 2008 ...' but I wonder if that's true, as I can't find that in the upstream code :)
<pochu> btw, how many BSD licenses there are?
<andrew___> Wikipedia would know.
<andrew___> (I'm upgrading to Hardy at last, so my browsers don't work :s)
<andrew___> You can get templates for them all, just get them to change $NAME etc. to whoever owns the files.
<andrew___> Anyway, speaking of upgrading, I have to reboot now - brb.
<Xtreme_Great> I needed some help regarding building my ubuntu kernel's restricted drivers
<Xtreme_Great> can anyone help?
<Xtreme_Great> anyone???
<Xtreme_Great> hello?
<Xtreme_Great> anyone home?'
 * jdavies sighs
<jdong> jdavies: reading the topic is a lost art, isn't it.
<jdavies> jdong: that's the third time I've seen him do that in seperate channels
<ion_> Iâm still in favor of making ChanServ tell people joining to read the topic.
<jdong> ion_: still wouldn't work, based on experience.
<jdong> ion_: when Backports still took requests from the forums, I had a 1/2 page bold forum header describing the proper post format. Nobody listened.
<jdong> ion_: at one point I got pissed off and made it <font size="72">
<jdong> still got people who, after scrolling down 5 pages to the New Post button, forgot the proper posting format. again.
<geser> jdong: it didn't help either, did it?
<jdong> :)
<jdong> I don't know what it would've taken. A strobing flash applet with sound?
 * jdavies still follows: http://paste.ubuntu.com/11280/
<ion_> A magic word within the message one needs to type next to the submit button? :-)
<geser> a big captcha with the post format description?
<jdong> geser: ROFL
<jdong> "Type the following paragraph EXACTLY as you see it..."
<tseliot> ï»¿jdong: would death threats help? :-P
<nxvl> is there something like an upload count?
<andrew___> For uploading what?
<nxvl> packages into ubuntu
<laga> pitti: thanks for fixing apport
<andrew___> The short answer is that I don't know, but I'd assume you could piece it together from new versions of packages.
<geser> nxvl: you mean how many uploads a person did?
<nxvl> geser: yup
<geser> nxvl: http://ubuntu.joejaxx.org/ but it gets updated irregularly
<nxvl> geser: thnx
<Amaranth> Riddell does more uploads than seb128? I find that hard to believe :P
<geser> Amaranth: kde language packs :)
<joejaxx> i need to change that for ibex
<Amaranth> hehe
<Amaranth> And I guess seb128 has a team of people doing GNOME updates now
<nxvl> Amaranth: kde4 comes in the middle of the development cicle
<nxvl> Amaranth: also there is kde3.5 and kde4, against only one version of gnome
<nxvl> it's understudable
<emgent> heya dendrobates :)
<sistpoty> hi, what's the lp name for x developers?
<sistpoty> tjaalton: or should I subscribe you to bug 229079 instead?
<ubottu> Launchpad bug 229079 in libxfont "[intrepid]: broken" [High,Confirmed] https://launchpad.net/bugs/229079
<sistpoty> tjaalton: (just saw, you're not away... not that I want to blame anyone here *g*)
<sistpoty> oh, just saw that ubuntu-x is already subscribed, so nevermind :)
 * norsetto wonders who fujitsu is ...
<sistpoty> heh, my brain still hasn't realized the fujitus -> wgrant change :)
<sistpoty> fujitsu even
<emgent> true :p
<emgent> hi norsetto
<norsetto> emgent: ./
<sistpoty> tkamppeter: just saw your comment to bug #229016, thanks! however I guess you'll also want to conflict on system-config-printer-kde (at least versioned, for the versions shipping smburi.py)
<ubottu> Launchpad bug 229016 in system-config-printer-kde "missing conflicts" [High,New] https://launchpad.net/bugs/229016
<sistpoty> (otherwise the upgrade path might be broken)
<elmo> as a reminder: Launchpad will be offline from maintenance in 45 minutes time, for 2 hours (i.e. 21:00-23:00 UTC)
<sistpoty> anyone, who'd like to sponsor debdiff 1 from bug #229016 (http://launchpadlibrarian.net/14432575/scpkde.debdiff)?
<ubottu> Launchpad bug 229016 in system-config-printer-kde "missing conflicts" [High,New] https://launchpad.net/bugs/229016
<sistpoty> (Riddell... ? as it will still need to get updated in bzr)?
* elmo changed the topic of #ubuntu-devel to: Launchpad will be down from 21:00 UTC to 23:00 UTC to upgrade the DB server || Archive: Intrepid open, go wild! | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wi
<pwnguin> topic too long ;)
<jdavies> pwnguin: that happens ;-)
* elmo changed the topic of #ubuntu-devel to: Archive: Intrepid open, go wild! | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tmmoyer> if I apply a patch and rebuild a package to use on local machines, should I use dch -n to increment the version number and will that be seen as a version number greater than the unpatched version?
<sistpoty> tmmoyer: afaik, yes. the next ubuntu version would usually be taken from dch -i so I assume it's true
<tmmoyer> okay.  also is there a way to force apt-get -d to only download the specified packages and not any unsatisfied dependencies?
<sistpoty> tmmoyer: no idea actually... maybe be both pinning packages and specifing what you want to upgrade?
<sistpoty> (or just pinning?)
<tmmoyer> so what I need to do is get some packages to put on the install CD (for customizing purposes) and I only need to get packages I specify
<tmmoyer> basically I have a list of all packages that I need on the CD, and I have removed any packages that are already on the CD leaving me a list of packages that I need to put on the CD.  I would like to find a way to download only those packages I need not all of the depends as well
<sistpoty> tmmoyer: as in list of packages with dependencies or w.o.?
<tmmoyer> yes.  I used the program germinate to generate a list of all packages needed, then removed any packages for which I already have the deb files
<andrew___> Could you wget them with a shell script?
<andrew___> for f in $(<package_list) ; do wget http://myarchive/dists/hardy/blah/blah/$f ; done
<tmmoyer> so right now the package list is something I could pass to apt-get directly (package names only) what would be the easiest way to convert these to full paths that I can pass to wget
<sistpoty> tmmoyer: should be easy then... iirc packages.gz contains a relative link to all (binary) packages locations (w.o. the name, you'd need to get this from version + package name in packgages.gz) to download
<sistpoty> tmmoyer: however I'm not entirely sure about this... and iirc there might be s.th. out there which does that for you
<sistpoty> tmmoyer: (maybe casper, but I guess you'll want to look at debimg as well)
<tmmoyer> I may just deal with the dependencies, since in my cases right now, it is only 3 files.  I may just install the dependencies and then run the download
<sistpoty> tmmoyer: whatever you think fits best your need ;)
<andrew___> I hope I'm not being rude, but did you guys hear my suggestion before?
<sistpoty> andrew___: I did at least. but I'm not the one with that endavour ;)
<tmmoyer> andrew___: yes I did, the only problem is that I need a way to convert the package list to a series of urls to pass to wget,
<andrew___> If it's just three, you could do it manually.
<tmmoyer> the only way I know how to do that right now is through apt-get which resolves dependecies
<tmmoyer> yeah my end goal though is complete automation of the process
<tmmoyer> meaning I would like to find automatic methods of doing these things
<andrew___> Ah, fair enough.
<andrew___> I agree with sistpoty about checking the packages list then.
<tmmoyer> yeah may not be a bad idea
<sistpoty> (imho actually there should be some apt thingy to use for this... I'm not sure, but I guess there are python-bindings for apt, which could help you further)
<tmmoyer> other than the customization page on the wiki is there any place where alternate CD creation is documented from beginning to end?
<tmmoyer> yeah
<tmmoyer> thanks
<tmmoyer> hopefully things work out
<andrew___> FIW, `grep "Package: $package" /var/lib/apt/lists/* -A15 -h | grep ^Filename:` gets you most of the way there.
<andrew___> *FWIW
<ion_> andrew: grep-dctrl(1)
<andrew___> That's better :)
#ubuntu-devel 2008-05-11
<ScottK2> Is somebody coordinating the libffi4 -> libffi5 transition?
<tmmoyer> has anyone worked with germinate and could tell me why when I list a metapackage as a seed it doesn't say I need the metapackage?
<tmmoyer> does anyone know of an easy way to take a list of packages, and ensure that all dependecies are satisfied by some archive, specifically the archive that is present on the install CD.  what I am trying to do is starting from the server install cd for hardy, add a bunch of custom build packages to the cd, and ensure that I can install the system (including any packages on the CD) without a network connection
<pwnguin> i have an idea
<pwnguin> piuparts
<pwnguin> just make sure the piuparts chroot has identical packages to the server cd
<tmmoyer> that looks interesting, not sure it is exactly what I am looking for though.
<tmmoyer> i think from looking around, I may have to come up with my own script to verify this, which while not hard is just time consuming to get correct.  I think I should be able to utilize things like apt-rdepends and such to retrieve all dependencies and also dpkg --info
<mgolisch> heya ppl
<DrivenMad> Has anyone installed linux on a E-Vectra system( terminal box) ?? I keep getting blank screens
<DrivenMad> I am trying to get ANY linux distro to run on these boxes to build a public wifi network :)
<DrivenMad> not yet .. :) I am About to though :)
<dmb> is it me, or is http://packages.ubuntu.com not working very well right now?
<LaserJock> dmb: perhaps not. The guy that runs it is looking for a new place to host it
<LaserJock> perhaps his server went down for a bit
 * jdong reads arnieboy's comments about mjg59 a few times... sure that he is misreading it repeatedly.
<pwnguin> jdong: link?
<jdong> http://www.getautomatix.com/forum/index.php?showtopic=2424&view=findpost&p=6331
<jdong> pwnguin: a bit disturbing.\
<pwnguin> but par for course
<Amaranth> heh
<Amaranth> I just read that
 * pwnguin suggests that mvo offer the next "design review" ;)
<pwnguin> kinda reminds me of that guy who came in a few days ago accusing apt-rsync detractors as unforward thinking, selfish and unempathetic
<Hobbsee> jdong: sounds like good crack!
<Hobbsee> jdavies: right, so he still didn't learn :(
<Hobbsee> jdong: then again, do you really expect any better from a 'kill -9 dpkg'er?
<Auzy> hey
<Hobbsee> hi
<Auzy> quiet day?
<Hobbsee> it's a sunday, so yes
<Hobbsee> and launchpad had been down
<Auzy> ah
<wgrant> jdong: ... wow.
<matty3269> Hi all
<matty3269> Please could somebody help me, I am looking for a system call or an API that I can use to get the model name of all the network cards inside a ubuntu box, does anybody know how i could do this?
<pwnguin> lspci?
<pwnguin> or perhaps lshw
<matty3269> yeah I was thinking that. Although i would like to resolve it to an interface name so  I could get the IP address etc for it.
<pwnguin> ifconfig
<matty3269> yeah but that doesnt give the manufacturer and model does it?
<pwnguin> so glue them together
<pwnguin> or perhaps lshal
<matty3269> Yeah i looked at hal and was looking at the API for it, looked rather complicated, so I may just use a g_spawn_command_line_sync instead
<matty3269> does anybody know how i can get started on developing applications for ubuntu?
<TheInfinity> matty3269: like every other development for linux
<bimberi> !develop | matty3269
<ubottu> matty3269: Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<matty3269> bimberi, thanks
<bimberi> matty3269: yw
<mathrick> hi, it seems that packages.ubuntu.com is down
<bimberi> mathrick: #canonical-sysadmin might be a good place to report that
<mathrick> ok
<bimberi> mathrick: feel free to point at me if that's wrong :)
<mathrick> ok :)
<mathrick> also, what on earth happened to hal-device-manager in hardy?
<mathrick> it disappeared completely, not even the package is there
<cody-somerville> Germinate is still writing to germinate-output/$DISTRO.hardy
<Keybuk> mathrick: it's called gnome-device-manager now
<mjg59> Anyone around with a laptop with a geforce 8000 or greater? (Not a Dell or Thinkpad)
<mathrick> Keybuk: oh'
<jerry> hi, everyone! where could I get my first task ?
<cjwatson> cody-somerville: thanks, I'll fix that
<cody-somerville> :)
<cjwatson> cody-somerville: just hadn't changed it since the archive wasn't in place yet when I was last poking at that stuff
 * cody-somerville nods.
<cjwatson> will be fixed next crontab run
<cjwatson> 2 */4 * * *             update-germinate
<ryanakca> doko: ping, mind if I attempt to merge john ?
<xhaker> mjg59: got a nvidia 8600 here.
<mjg59> xhaker: What machine?
<andrew___> Does anyone have any ideas how I could track down the cause of a weird issue with keyboard preferences being ignored?
<xhaker> mjg59: LG r500
<xhaker> mjg59: sorry for the delay, want me to try something? having problems?
<mjg59> xhaker: Can you do acpidump and stick the output somewhere?
<pochu> why isn't MoM being updated?
<LaserJock> maybe it got stuck
<juliux> hi doko
 * xhaker really needs to get notifications for irssi
<t4g> xhaker: http://pthree.org/2007/03/21/irssi-gui-notify/
<xhaker> mjg59: http://pastebin.ubuntu.com/11465/
<xhaker> t4g: thanks for the link. I might try to setup that.
<mjg59> xhaker: Ok, thanks for that
<t4g> xhaker: np
<emgent> heya people
<Keybuk> pochu: it's not MoM, it's the actual Ubuntu archive
<pochu> Keybuk: I guess Colin or somebody is aware of it? :)
<pochu> Keybuk: btw do you know when MoM will have comments support? It's being done, right?
<LaserJock> pochu: I was told it just needed to get merged in
<Keybuk> pochu: elmo is aware of it
<Keybuk> LaserJock: it also needs a bunch of support on the machine like mod_python
<Keybuk> and a security audit since it's running from the DC
<Keybuk> I've been monumentally busy, so haven't had a chance yet
<Keybuk> it's on my things to do during relaxed hours at UDS
<LaserJock> Keybuk: ah, makes sense
<Skiessi> why libsamplerate hasn't been updated?
<Skiessi> I mean I think it should
<norsetto> Skiessi: its a merge
<slangasek> ok, so what's changed in g-p-m/hal in hardy-proposed, that my laptop now suspends to ram when idle only when the lid is /open/?
<Nafallo> ehrm...
<pwnguin> heh
<ScottK> slangasek: Nothing AFAICT (No gpm package and HAL seems unrelated).  It's seemed to me that suspend has gotten more problematic since release, but I'm not sure where to point.
<pwnguin> ScottK: i had a guy in #ubuntu-kernel git-bisect and he came up with a watchdog timer commit
<ScottK> pwnguin: You mean for hal?
<pwnguin> no =/
<ScottK> OK.  'cause the hal change is a timer change.
<pwnguin> interesting
<ScottK> But it's a change for CD ROM detection.  I can't see how that would affect suspend
<pwnguin> unfortunately, I lent out my laptop, and it suffered from a suspend bug
<pwnguin> for ages. ive never been able to suspend it
#ubuntu-devel 2009-05-04
<LordMetroid> Is Canonical doing most of the dev work themselves?
<calc> LordMetroid: dev work for what?
<LordMetroid> Assembling the distribution...
<calc> LordMetroid: some is done by canonical and some by community
<calc> LordMetroid: there are many more community people than canonical people though
<calc> LordMetroid: canonical people have the benefit of being able to work on it full time though
<LordMetroid> Yes, but I can't seem to figure out where the main work is being done
<pwnguin> its a little tough to tell; im given to understand canonical occasionaly contracts community members to do some work
<directhex> depending on which news sources you believe, i'm apparently an evil microsoft plant
<calc> and yes directhex is an evil Novell-Microsoftie ;-)
<directhex> oh yeah, i love me some microsofts
<calc> my OOo build worked, yipee
<directhex> is it called OOOo yet?
<pwnguin> LordMetroid: in one sense, the vast majority of Ubuntu is written by non-ubuntu people be it canonical or otherwise
<calc> now to forward port all my OOo 3.0 patches to 3.1
<directhex> pwnguin, debian!
<Amaranth> directhex: throw some of that microsoft cash my way :)
<pwnguin> directhex: and the people who write the programs debian packages
<LordMetroid> So I've tried to figure out where the decisions are being made now for a good 4 month but I can't seem to grasp it
<directhex> ah, your question is a governance question
<LordMetroid> yes, I think so
<calc> maybe he means UDS decisions?
<pwnguin> ubuntu is divided into "members" "developers" and "core developers"
<directhex> and "annoying hanger-ons"
<pwnguin> theoretically there isn't supposed to be a hierarchy like this
<LordMetroid> UDS's where the decision are being made?
<LordMetroid> I was thinking of going down to UDS in Barcelona
<Amaranth> LordMetroid: UDS is where things are planned
<pwnguin> UDS is one place where decisions are made
<calc> most of them happen at UDS
<Amaranth> LordMetroid: but the people doing the work make the decisions, basically
 * directhex remembers to pack his ice beam & missiles
<LordMetroid> lol
<pwnguin> LordMetroid: basically, anyone in core developers can upload to main/restricted
<Amaranth> LordMetroid: So just because some people at UDS decide we're going to rewrite nautilus in scheme doesn't mean it'll get done
<directhex> Amaranth, thank $EXPLETIVE
<calc> directhex: instead you are going to rewrite it in mono, eh? ;-)
<directhex> calc, damn straight!
<LordMetroid> *facepalm*
<ajmitch> calc: he's probably going to unveil that at UDS
<directhex> calc, with winforms!
 * Amaranth remembers when we almost decided to use xgl for FUSA
<pwnguin> LordMetroid: the CoC directs people to be collaborative, so they shouldnt really be abusing the powers to override any consensus
<directhex> unless they're sabdfl
<LordMetroid> CoC?
<ajmitch> calc: don't forget, directhex's a fan of VB.NET as well :)
<Amaranth> one Xserver with multiple xgl servers under it for each user and OpenGL effects for user switching
<directhex> ajmitch, "fan of"? never written a line of it matey!
<ajmitch> directhex: you try & hide it now...
<Amaranth> then everyone would get compiz and we could do awesome transitions for user switching, logging out, etc
<directhex> ajmitch, which sorta breaks the first rule of packaging... :/
<pwnguin> LordMetroid: in the event that no obvious consensus can be found, the technical board exists to handle things
<LordMetroid> ok
<Amaranth> I had that one specced and most people either saying it was a good idea or they weren't sure
<pwnguin> !coc
<ubottu> The Ubuntu Code of Conduct to which we ask all Ubuntu users to adhere can be found at http://www.ubuntu.com/community/conduct/
<Amaranth> thank goodness that didn't happen :P
<RAOF> Amaranth: That would've been *awesome*.  Apart from the death of upstream, of course.
<Amaranth> RAOF: yeah, that was before upstream completely died
<Amaranth> RAOF: we were going to get input redirection too!
<directhex> know what i want?
<ajmitch> a pony?
<directhex> i want mouse sensitivity settings that can cope with mice >1000dpi
<pwnguin> a gnome-panel that does intelligent layout?
<directhex> and a pony
<Amaranth> I want sharks with fricken laser beans
<pwnguin> directhex: wacom has some ridiculusly high input resolution
<Amaranth> err, beams
<directhex> but i'm both allergic to horse hair and french, so if i could have that with chips...
<LordMetroid> Death of Upstream, that seems really horrible!
<Amaranth> who put those two keys so close together?
<RAOF> Mmmm... laser beans.
<ajmitch> pwnguin: I won't mention my hassles with gnome-panel & multiple displays then, I may break the CoC :)
<directhex> pwnguin, the highest resolution consumer-grade mouse on the market is 5600dpi
<LordMetroid> 5600dpi is nothing, I can move way less distance than that!
<directhex> pwnguin, my mouse does 4000, and i need to lower it to 1500 for it to be remotely usable on ubuntu
<LordMetroid> I move one pixel at a time!
 * Amaranth spends $10 on a mouse
<Amaranth> so I doubt it does that :P
<pwnguin> directhex: maybe its time to gift some x developers with high resolution mice ;)
<directhex> Amaranth, the 5600dpi mouse is $130
<directhex> so... no
<directhex> pwnguin, if i knew which specific person would guaranteed produce results, then i'd donate a reasonable high-dpi mouse
<pwnguin> LordMetroid: wacom input resolution is like 20000x20000
<directhex> pwnguin, tablets != mice though
<pwnguin> indeed
<LordMetroid> I have a wacom from the 90s
<pwnguin> anyways, i hope you have a better understanding of how decisions are made
<pwnguin> locally, with the backing of consensus and oversight of community and technical boards
<LordMetroid> Hmm, maybe one should find a place to stay in Barcelona before it is too late
<LordMetroid> Yes, I have thank you very much pwnguin
<directhex> i really don't remember where i put my euros
<LordMetroid> euros chemrous, just use the plastic
<directhex> aha, here on my desk
<LordMetroid> Remember, do not drink the tap water, it does not contain your bacteria culture and from my experience of Spain, it is highly chlorated as well so you will become quite quizzy
<directhex> i never drink the tap water when abroad. who knows what those funny foreigners have done to it
<james_w> luckily the beer is fine
<LordMetroid> All these people attending the UDS, they are like diehardcore distro developers?
<directhex> and/or microsoft plants
<LordMetroid> >_>
<directhex> james_w, what's drinkable beerwise though? i'm used to nice local ale!
<james_w> we'll be short on ale unfortunately
<directhex> well, never mind. i hopefully have enough euros that i won't taste it by the end
<james_w> there's plenty of good lager and wine though
<Amaranth> directhex: Do a couple shots first, you won't taste any of it :)
<directhex> hm, i wonder if anyplace sells my favourite rum. i'm almost out!
<directhex> is james_w going?
<james_w> directhex: where?
<directhex> james_w, uds!
<james_w> of course!
<james_w> UDS in Barcelona? I wouldn't miss that
<LordMetroid> You think a general user of Ubuntu which merely is reporting bugs when he sees them has anything to contribute at the UDS?
<LaserJock> I'd think it'd at least be nice to have some non-developer feedback for some things
<Amaranth> LordMetroid: You may have some ideas or input that is useful
<LordMetroid> I develop my own software projects. Mainly concerned about usability...
<LaserJock> usability is always a hot topic
<pace_t_zulu> anyone here familiar with building Chromium on Ubuntu?
<dtchen> pace_t_zulu: fta does; he maintains the ppa.
<pace_t_zulu> dtchen: i don't see fta in here
<directhex> #ubuntu-mozillateam
<dtchen> pace_t_zulu: https://launchpad.net/~chromium-daily/+archive/ppa
<pace_t_zulu> dtchen: i am trying to figure out why my builds fail on stock Ubuntu systems
<pace_t_zulu> dtchen: if there are any steps particular to Ubuntu that are necessary
<dtchen> contrast w/ his generated source packages.
<calc> is there a way to view a diff of a git commit without having to give the commit name of the previous commit?
<james_w> git show
<james_w> or "git diff name^..name"
<LaserJock> james_w: btw, do you know if people have been testing the bzr git plugin on the gnome repos?
<james_w> yes, they have
<LaserJock> james_w: and it's been working pretty good?
<james_w> I've no idea
<LaserJock> pretty much every upstream and Debian project I've worked with has gone git now
<james_w> 100% success record for the feedback I've heard
<LaserJock> awesome
<LaserJock> do you imagine it might be LP ready pretty soon?
<james_w> you didn't ask what the sample size was though ;-)
<LaserJock> heh
<james_w> I don't know when LP will be ready, you're better off asking them
<pace_t_zulu> asac: are you around?
<RAOF> LaserJock: I've been playing with Banshee, and the initial branch works just fine (now that it no longer consumes multiple GB of memory), but subsequent pulls seem to die, but only in the particular repository I have.  I'm trying to track it down to something easily reproducible before filing a bug.
<Ademan> this is somewhat offtopic I suppose, but it relates to a jaunty package (ushare)
<Ademan> does anyone know why the pid stored in a pid file would consistently be two less than the actual pid of the daemon?  (the daemon is being started by start-stop-daemon)  If I had to guess I'd say the pid is from the bash instance that starts start-stop-daemon, rather than the instance of the daemon itself.  Can anyone confirm this?
<Ademan> WAIT, duh, the process is daemonizing itself by forking twice...
<Ademan> and that was my own addition/mistake
<Ademan> please disregard anything i've said :-p
<billisnice> my intel and 9.04 is slow
<wgrant> billisnice: You might want to read the release notes.
<LaserJock> luckily all my intel problems have been fixed in -proposed
 * wgrant is using the x-updates PPA plus bits of Karmic.
<wgrant> KMS is nice.
<billisnice> does 9.04 update to x-updates PPA auto when you update?
<maco> huh, hey guys, there's no jaunty directory under http://cdimage.ubuntu.com/ ...who should be told about that?
<ajmitch> maco: there is one under /releases/
<maco> and http://cdimage.ubuntu.com/releases/jaunty/release/ only has DVDs
<ajmitch> as far as I know, releasse.ubuntu.com is the main site
<calc> maco: cd's are available at http://releases.ubuntu.com/9.04/
<wgrant> Right, most images will be on releases.ubuntu.com or ports.ubuntu.com
 * ajmitch cannot spell either :)
<maco> ah, so then what's cdimage?
<directhex> unofficial portrs
<directhex> e.g. ps3 port
<directhex> plus other general non-standard cruft
<wgrant> And the pre-release images.
<wgrant> Only RC and final are ever on releases.u.c, IIRC.
<maco> i give up on quassel for tonight
<pace_t_zulu> is there a python-tlslite package available in the repos? i can't seem to find one
<pitti> Good morning
<StevenK> Morning pitti
<pitti> directhex: dh_clistrip> URL?
<pitti> calc: hi
<pitti> apw: no, the default "lp:apport" is trunk, which isn't wrong
<pitti> Riddell: will look ASAP
<pitti> doko: tsconf> is there a MIR bug?
<pitti> hey StevenK, how are you?
<StevenK> pitti: Great, you? :-)
<NCommander> morning pitti and StevenK
<StevenK> And that's an early morning
<TheMuso> Morning pitti
<pitti> hey TheMuso
<TheMuso> Yay, chroot problem. :)
<pitti> Riddell: oh, I take it this was invalidly closed as "fix released" then?
 * pitti boggles
<pitti> "You are not the bug assignee nor the maintainer of xmlrpc-c (Ubuntu), and therefore cannot edit this bug's status. "
<pitti> WTH?
<pitti> it's an Ubuntu bug
<NCommander> pitti, which bug?
<dholbach> good morning
<pitti> NCommander: sorted out already, I wasn't logged in
<pitti> NCommander: filed as bug 371517
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/371517/+text)
<NCommander> Launchpad being buggy
<stooj> Hi folks
<dholbach> pitti: do you know what the deal with libpango/libthai is atm?
<dholbach> (karmic amd64)
<pitti> dholbach: might be what doko meant with tsconf promotion
<dholbach> pitti: hm, not sure I get it - in any case it makes pbuildering / sponsoring anything to do with pango a bit tough :-)
<pitti> right, it's uninstallable right now
<pitti> doko: hm, tsconf is in main; what did you mean?
<pitti> dholbach: what is the error?
<persia> dholbach, If you're on amd64, you ought to be able to construct an i386 or lpia pbuilder environment, which might get around some of that class of issue (assuming it's arch-specific).
<dholbach> persia: I dunno
<dholbach> pitti: it tries to deinstall everything to do with pango :)
<dholbach> ah
<dholbach> it seems to need a newer libdatrie0
<dholbach> libdatrie0 0.1.3-2 is in the archive right now, libthai0 conflicts with libdatrie << 0.1.4
<dholbach> ah, maybe pango needs a rebuild against libdatrie
 * dholbach will try that
<pitti> hm, this morning's dist-upgrade killed f-spot
<pitti> ah, seems to be some mono transition
 * pitti eyes directhex
<StevenK> dholbach: 0.1.3-2 is the latest in Debian, too
<dholbach> StevenK: libdatrie0 -> libdatrie1 - I'm just trying a quick pango rebuild
<StevenK> Ah!
 * StevenK checks other rdepends
<StevenK> Right, m17n-lib and libthai need a rebuild too
<StevenK> dholbach: &
<StevenK> s/&/^/
<dholbach> StevenK: will you take care of them or shall I do it?
<StevenK> dholbach: I'll look at them when my machine finishes it's current build run
<dholbach> StevenK: gracias
<StevenK> pitti: Oh, is the NBS checker pointing at karmic yet?
<pitti> StevenK: yes
<StevenK> \o/
<dholbach> StevenK: I'm just taking care of m17n-lib and libthai - don't worry
<dholbach> libthai does not seem to need the rebuild anyway
<doko> pitti: james_w did promote it yesterday
<pitti> ah, ok
<pitti> StevenK, kirkland, jdstrand, james_w: warning, I just ran new-binary-debian-universe, and the output has some bogus (packages which are and should be in main)
<pitti> so please don't use that right now
<pitti> ah, ignore me, it's just harmless noise
<olmari> cjwatson_: in case you bear any interest on the issue, I coudn't repeat the dreaded apt "racing condition" bug anymore...
<olmari> cjwatson_: as suggested on the bugreport, would there be any way to get some ubuntu "installation server" to be available basically with mirror of 23th of april, as with that day this bug happened every time no matter which other way I tried to install ubuntu-desktop with mini-installer :)
<Omahn> Is it normal for the build servers to have over 5000 packages queue or is it just the recent opening of Karmic that's had such an affect?
<maxb> Omahn: The buildds are still churning through the initial surge of autosynced packages that happens when the archive opens again after a release
<Omahn> maxb: I'm guessing it normally settles after a week or so then?
<maxb> lpia's already settled. At the current rate of progress amd64 and i386 should have caught up in another day or so
<maxb> The other architectures are, I presume, building on slower hardware.
<Omahn> I'm guessing all the build servers are internal to Canonical?
<maxb> yes
<Omahn> Seems sensible. Shame though, we have some fairly beefy boxes sitting at our place that could certainly help.
<ebroder> Anybody backporters around willing to sign off on bug #216761?
<ubottu> Launchpad bug 216761 in xen-3.3 "[hardy-backports] errors in xendomains init script" [Undecided,Fix released] https://launchpad.net/bugs/216761
<scapor> Could someone tell me where the data in the user's home of a persistent live usb (created with usb-creator) is stored? there's no other partition created, no /home on the usb stick's one partition
<scapor> and an empty /home in the sqaushfs
<soren> scapor: There's a file on the usb stick that holds the filesystem overlay.
<soren> I forget what it's called. casper-rw, perhaps.
<tdmackey> yeah, casper-rw
<tdmackey> in the root directory
<scapor> I see. And that's sqaushfs too, then ? :)
<tdmackey> tells how much reserved space there is for persitent storage
<scapor> oh it's a ext3 partition I see
<scapor> tdmackey: soren: thank's very much :)
<tkamppeter> pitti, can you pass through the SRU package of bug 365329? Thanks.
<ubottu> Launchpad bug 365329 in system-config-printer "HP LaserJet P1005 (using hplip) fails to print in 8.04 and 9.04" [Medium,Fix released] https://launchpad.net/bugs/365329
<soren> scapor: Sure.
<pitti> tkamppeter: please reupload with correctly wrapped changelog (too long line)
<maxb> What is the official line length, ooi? /me can't find an exact statement in debian-policy
<pitti> lintian uses 79 or so
<soren> I tend to wrap at 72. It be pleasin' to me eyes.
 * soren doesn't know why he got all piratey all of a sudden
<slangasek> a vitamin C deficiency?
<dholbach> must be scurvy :)
<bigon> is the procedure to request package remove written somewhere?
<slangasek> create a bug on the package, give a reason, subscribe ubuntu-archive
<slangasek> bigon: ^^ written there ;)
<bigon> :)
<dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages
 * dholbach makes sure it's linked from https://wiki.ubuntu.com/UbuntuDevelopment/KnowledgeBase
<kumarabhi> hey people
<kumarabhi> is there any bounty programme from ubuntu for  studen developers
<kumarabhi> student developers
<tkamppeter> pitti, can I use the same version number or do I have to bump it?
<pitti> tkamppeter: same number is fine
<slangasek> StevenK: you haven't killed hildon-fm-l10n yet... :)
<StevenK> Hm. I'll do that now.
<tkamppeter> pitti, s-c-p reuploaded.
* nhandler changed the topic of #ubuntu-devel to: Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dpm> hi pitti, I've got a question on langpacks when you've got a minute
<dpm> I'm trying to find out the status of a translation not from Rosetta but from the langpack sources.
<pitti> dpm: hi! just ask
<dpm> I have tried to find the language-pack-gnome-mk-base from here -> https://edge.launchpad.net/~ubuntu-langpack/+archive/ppa?field.name_filter=mk&field.status_filter=published&field.series_filter=hardy , but they don't seem to be there. Is there a location where I can find those -base packages?
<pitti> dpm: what do you mean by "find the packages"?
<pitti> apt-get source?
<pitti> dpm: what are you trying to do?
<dpm> pitti: I'm trying to find out the status of a given translation for Hardy in a more or less accurate way. Therefore, I'm not looking at the Rosetta stats, but at the data from the last released langpacks. I've first gone the apt-get source way, but I noticed that depending on the language, a given translation had less strings than others, and in any case they seemed to differ from the Rosetta template. Then danilo told me that there is some
<dpm>  post-processing going on after the PO files are extracted from Rosetta (such as removal of duplicate strings) ...
<pitti> dpm: apt-get source will give you the exact data that is shipped in a release
<pitti> dpm: we don't do any post-processing _in_ the source packages' build process
<pitti> just some to create these source packages
 * pitti -> lunch, bbl
<dpm> pitti: ok, I'll ask you some more later, enjoy your meal!
<slangasek> dpm: if you need answers sooner, there may be others in the channel who can help answer
<slangasek> (I know a bit about langpacks, though I'm not an expert)
<ogra> god, when did the ArchiveAdministration wikipage grow so much
<dpm> slangasek: thanks, I can wait. I think in the case of langpacks pitti and ArneGoetje are the experts, though
<slangasek> they are
<slangasek> but you needn't treat them as a bottleneck for everything :)
<ogra> slangasek, so its your day today, could you take care for bug 369159 ? seems that slipped through the recent syncs
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/369159/+text)
<ogra> pfft
<slangasek> ogra: it did not...
<ogra> hmm, why dont i see it on any ML
<slangasek> at a guess, because StevenK accidentally included in a NOMAIL flush-syncs batch
<ogra> ah
<ogra> we have that ?
<ogra> ok
<slangasek> yes, it's what's supposed to be used for all autosyncs
 * ogra wonders how he missed the bugmail ... at least i have that
<ogra> why are you up already btw ? :)
<slangasek> so that I can get my archive day done before Europe has a chance to fill the queue with even more stuff. >:)
<ogra> heh
<mdke> pitti: re your last comment on bug 366098, do you mean "jaunty" instead of "karmic"?
<ubottu> Launchpad bug 366098 in ubuntu-docs "ubuntu-serverguide has a "DRAFT" watermark" [Low,Fix released] https://launchpad.net/bugs/366098
<slangasek> no, he means karmic
<slangasek> of questionable import in the case of ubuntu-docs, but it was copied nonetheless :)
<mdke> slangasek: karmic already has a package with a higher version number, though
<calc> hi
<mdke> slangasek: does that not matter?
<slangasek> mdke: in that case, the copy presumably failed ;)
<mdke> slangasek: I don't know how it works. The bug isn't fixed in the karmic package with the higher version number, because it's not a bug in karmic
<slangasek> correct
<mdke> as long as it hasn't superceded the existing karmic package, I'm happy
 * calc hugs slangasek for syncing all his packages :)
<slangasek> it hasn't; I guess pitti overlooked the error message (as well as overlooking that it wasn't a karmic bug, of course)
<mdke> ok, no worries then
<mdke> thanks slangasek
<slangasek> calc: get _rene_ to upload those to unstable, please, so we don't have to do that manually again :)
<calc> slangasek: ok... he is going to once he decides to actually upload OOo 3.1.0 to unstable :\
 * slangasek nods
<TheMuso> Are any build admins able to kick the amd64 build of alsa-lib back into gear? Its a chroot problem, but appears to be due to locking issues which don't seem to be a problem for other builds now.
<mdz> pitti: I'm trying to work up a patch for bug 316215.  can you point me to some information about access_control.* and how it works?
<ubottu> Launchpad bug 316215 in hal-info "rule to enable use of android's adb" [Wishlist,Triaged] https://launchpad.net/bugs/316215
<mdz> what I want is to make the path in linux.device_file read/writable by the user
<mterry> slangasek: Thanks for the pm-utils patch fixups!
<slangasek> mterry: sure thing :)
<pitti> dpm: re
<pitti> mdke: I copied it from jaunty-proposed to jaunty-updates and karmic
<pitti> mdke: ah, I remember (sorry, too much SRU stuff this morning); this should be reopened, of course
<slangasek> pitti: no, it shouldn't, it wasn't a bug in karmic at all
<slangasek> the bug was "document includes an 'unreleased' watermark", and karmic isn't released... :)
<pitti> slangasek: right, but it should be kept as a RC bug as a reminder to do it *before* karmic's release this time
<dpm> pitti: thanks. Going back to the question: I'm trying to compare the status of the translation of e.g. gnome-terminal in two different languages. I see that in Rosetta the template has got 483 strings, and both translations are 100% complete. However, when I apt-get source the langpack for each language, one PO file has got 472 strings and the other 467. In any case, none of them has got the 483 strings from the original template.
<dpm> pitti: 1) Why do the 100% translated PO files have a different number of strings and also differ in number from the Rosetta template? (I know that this does not pose any kind of problem, I'm just trying to understand why)
<slangasek> pitti: I don't think a bug is the right way to track things that are supposed to be part of the release process
<pitti> slangasek: if we move it there, that works for me as well
<pitti> aside from the fact that I question the entire idea of this watermarking in the first place
<pitti> after all, everything in karmic is a "draft" until we release
<slangasek> I was rather surprised that this wasn't in the process checklists already
<pitti> dpm: are you getting the ones from hardy-proposed, hardy-updates, or hardy final?
<dpm> pitti: hardy-updates
<pitti> mdz: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#access-control is the initial documentation
<geser> doko: do you know why python-distutils.mk from cdbs (karmic) renames dist-packages to site-packages?
<pitti> mdz: there is an existing patch which adds ACLs for smartcard readers: http://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/annotate/head%3A/debian/patches/02_smart_card_readers_acl.patch
<doko> geser: what is python-distutils.mk?
<geser> doko: /usr/share/cdbs/1/class/python-distutils.mk
<doko> geser: see above, answered to pitti as well. packaging *.install files expect these in site-packages
<mdz> pitti: thanks
<mdz> pitti: what defines the meaning of access_control.type=smart-card-reader?
<pitti> mdz: it's just a human readable identifier which binds together the policy (who has access) in the .policy file with the subject (device file, in the fdi)
<geser> doko: do we still need to modify packages for the python2.6 transition with all this automatic renaming done by the different packaging helpers?
<mdz> pitti: ah, and "active" and "inactive" in the .policy refer to active user and inactive user?
<pitti> mdz: console session, but that by and large maps to user, yes
<mdz> pitti: so access_control.type=foo maps to org.freedesktop.hal.device-access.foo ?
<pitti> mdz: right
<mdz> pitti: can you give me a hint as to whether I should create a new type or if an existing one is appropriate?
<pitti> mdz: looking at /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
<DnaX> please fix bug #340718! I've post a patch before final release.
<doko> geser: if a package ftbfs, yes
<ubottu> Launchpad bug 340718 in irda-utils "[jaunty] irda-utils won't install (depends on /dev/MAKEDEV symlink in postinst)" [Undecided,Confirmed] https://launchpad.net/bugs/340718
<pitti> mdz: well, portable_audio_player wouldn't be entirely wrong
<pitti> or camera
<pitti> mdz: ah, hang on, there's "PDA"
<DnaX> this package fail to install and irda do not work automatically
<mdz> pitti: that reminds me of another bug which i haven't looked for / filed yet...when I plug in the G1, I get multiple popups (music player, camera).  technically correct, but not very helpful
<mdz> pitti: PDA seems to imply a palm-like sync interface though
<pitti> mdz: I noticed that, too; I just didn't see an obvious way to fix it
<mdz> this stuff is closest:
<mdz>     <!-- support for Linux USB stack where linux.device_file is set (e.g. device node is on the main usb device) -->
<pitti> mdz: not necessarily, that's just there for the Pam/pocketpc ones
<pitti> mdz: in that block, portable_audio_player is closest then
<mdke> pitti: we use the watermark for the doc.ubuntu.com website too. But I agree with slangasek that a bug is not the right way to remember this, since it will happen in releases after karmic too. I think the best way is to include it on a -doc specific release process list
<mdz> pitti: the text in org.freedesktop.hal.device-access.policy wouldn't really be accurate though.  I don't know how big a problem that is
<DnaX> pitti: have you see irda-utils bug?
<mdz> "System policy prevents access to audio players"
<pitti> mdke: works for me
<DnaX> pitti: can you triage it?
<mdke> pitti: ok, I'll do that then
<pitti> mdz: that string is displayed if the admin sets the PK policy to "auth_admin"
<pitti> mdke: it's not shown for "yes" or "no"
<pitti> erm, mdz: ^
<pitti> DnaX: I don't have any IR devices, and I'm quite busy ATM, sorry
<mdz> pitti: then why are there so many entries with the same defaults (yes and no)
<pitti> mdz: it's the upstream default, and we never cleaned it up
<DnaX> pitti: I have it... and i've post a working patch for it!
<pitti> mdz: basically, that allows an admin to say "my users can access a music player, but not an USB stick"
<mdz> pitti: ok, just tell me what you recommend and I will submit a patch
<pitti> DnaX: please subscribe ubuntu-main-sponsors then
<DnaX> done
<pitti> mdz: string-wise, PDA still sounds closest to me
<pitti> DnaX: thanks
 * zhxk wants know if there are any ready made pakages in depo to ubuntu
 * zhxk wants know if there are any ready made pakages in depo to ubuntu about arm cross-build-chains
<ikonia> zhxk: you'll have to build your own tool chain to cros-compile
<zhxk> ikonia:well, i encontered a problem to it  http://pastebin.ca/1412096
<zhxk> its logs to (export,config,make)
<zhxk> to e2fsprogs
<ikonia> zhxk: that's nothing to do with ubuntu development
<zhxk> ikonia:which channel should i ask?
<ikonia> zhxk: no idea, but it's nothing to do with ubuntu
<pitti> dpm: the hardy-updates are from January, perhaps the mk translations weren't that complete at that time?
<zhxk> ikonia:thanks all the same
<ikonia> no problem
<persia> zhxk, You may want to ask in #ubuntu-arm, while we don't do cross-compilation, someone there may have more useful information.
<zhxk> persia:thanks a lot
<dpm> pitti: If I understand it correctly, the mk translation was complete at the time, the only thing I cannot understand is the difference in the number of actual strings (msgid) in the template (Rosetta) and in the PO file (langpack source package). The PO file in the langpack tarballs seem to have the same number of strings as the Rosetta templat, though. In any case, I think I'll try to follow this up in an e-mail and I'll provide the links
<dpm> to the exact files I'm looking at, which will be easier
<tkamppeter> pitti, did you see my s-c-p re-upload?
<pitti> tkamppeter: yes, I did
<pitti> dpm: okay
<kirkland> pitti: okay, thanks for the headsup
<directhex> it's an ikonia!
<dholbach> al-maisan_: congratulations to your upload to Ubuntu :)
<al-maisan_> dholbach: thanks :) it's a pleasure to contribute :)
<dholbach> :-)
<ogra> slangasek, when do you plan the first dailies again ?
<slangasek> ogra: tomorrow
<slangasek> (but they'll probably fail to build, the installer's not merged up yet)
<ogra> good (i just got the responsibility for alpha1 mobile images assigned)
<ogra> yeah, i wouldnt expect them to build yet
<ogra> mako, you dont happen to be around, do you ?
<dholbach> tjaalton, bryce: anything Andreas can do to make bug 352708 more useful?
<ubottu> Launchpad bug 352708 in xserver-xorg-video-intel "[i915] external screen stays dark after suspend/resume via lid" [Medium,Confirmed] https://launchpad.net/bugs/352708
<kirkland> cjwatson_: hey, one more ssh auth question ... i assume that the message the client signs to verify its identity is some randomly generated different signature every time, right?  (else replays would be possible)
<soren> kirkland: It's a blob of data consisting of the session id and some other tidbits, yes.
<dholbach> can somebody please shove ibus through binary new? :)
<james_w> dholbach: it's not built has it?
<dholbach> ah, so it's through new, but not built yet, ok :)
<dholbach> thanks james
<kirkland> pitti: hey
<james_w> dholbach: binary NEW after building I think
<kirkland> pitti: am i correct in remembering you being the person who is anti-/etc/groups ?  :-)
<kirkland> pitti: i was thinking about for Karmic making /sbin/mount.ecryptfs_private perm'd 4750, and adding an ecryptfs group
<pitti> kirkland: I am, yes :)
<kirkland> pitti: currently, any user can created an encrypted-private dir
<kirkland> pitti: which means that users could, say, "hide" data from the sysadmin, perhaps
<dholbach> james_w: ok, I'll shut up and wait then :)
<pitti> kirkland: I thought that was the point? :-)
<kirkland> pitti: fedora is shipping ecryptfs with a patchset that restricts this to users the admin puts in the ecryptfs group
<kirkland> pitti: yeah, well, RHEL got some customer complaints, evidently!
<kirkland> pitti: users in the ecryptfs group can continue to "hide" data from root, but not everyone, necessarily
<kirkland> pitti: i guess my question to you is, how would i solve this without a group?
<kirkland> pitti: is this something that PolicyKit is cut out to do?
<pitti> kirkland: you can add a PK check to ecryptfs.mount if you wanted to
<kirkland> pitti: what does that look like?
<pitti> kirkland: my main crusade was to stop people from using groups for device access
<kirkland> pitti: ah!
<pitti> kirkland: for your use case, a group is less evil
<kirkland> pitti: so a group might actually be "okay" for this?
<pitti> kirkland: but I don't think you'd want to deny it by default, do you?
<kirkland> pitti: less evil, heh :-)
<pitti> kirkland: well, adding a group is still an excuse for us to push work to an admin
<kirkland> pitti: right, this is going to be a really tough one, particularly for upgrades
<pitti> kirkland: upgrades> don't even think about it
<pitti> kirkland: you can't add users to groups on upgrades
<kirkland> pitti: ideally, there would be an existing group that we already use, that I could piggy back onto
<kirkland> pitti: i think 'admin' is not the right one, though
<kirkland> pitti: i think i might make it a really, really low priority debconf question
<kirkland> pitti: "Do you want to restrict eCryptfs use to members of 'ecryptfs' only?"
<kirkland> pitti: default in Ubuntu is "no"
<pitti> kirkland: that wouldn't help us, though
<kirkland> pitti: but fascist sysadmins can preseed that "yes", or change it later
<pitti> kirkland: since you can't have a group "no-ecryptfs"
<kirkland> pitti: well, i worded that question poorly
<pitti> kirkland: seriously, a fascist sysadmin could just dpkg-statoverride mount.ecryptfs
<kirkland> pitti: really, it's just about the setuid binary
<kirkland> pitti: which is mount.ecryptfs_private
<pitti> kirkland: no, but you want users who currently run ecryptsfs to continue to do so after an upgrade
<kirkland> pitti: not the generic mount.ecryptfs
<kirkland> pitti: right, which is why the question would be low priority, and the default value would be our current policy
<kirkland> pitti: which would keep that setuid binary 4755
<kirkland> pitti: the fascists can make it 4750
 * kirkland decides that 'fascist' isn't particularly accurate, when describing this class of sysadmin
<pitti> kirkland: ah, I see
<pitti> kirkland: but those kind of sysadmin can probably also use statoverride themselves
<kirkland> pitti: it's really just about the encrypted-private, encrypted-home
<pitti> kirkland: but well, your call
<pitti> kirkland: as long as it doesn't involve putting users into that group _by default_, it's okay with me
<kirkland> pitti: well, i didn't know that -stateoverride existed, or what it did, until i just manpaged it
<kirkland> pitti: yeah, i don't think we add any users in that group by default
<kirkland> pitti: if the admin chooses to go with mount.ecryptfs_private at 4750, then it's up to them to add users to that group
 * slangasek envisions a nanog logo involving a fasces
<kirkland> ||)
<kirkland> ||*
<kirkland> slangasek: i like the asterisk one better ;-)
<slangasek> heh
<kirkland> pitti: cool, thanks for your ideas
<kirkland> pitti: i think i know how we're going with this
<pitti> kirkland: great, thanks for the discussion
<kirkland> cjwatson_: i'm curious what you think about https://bugs.launchpad.net/bugs/371719, if this might be acceptable for Karmic
<ubottu> Launchpad bug 371719 in ecryptfs-utils "establish ro,bind mount of /home for backup purposes" [Wishlist,Triaged]
<savvas> pitti: here? do you think I should file a bug at debian about libmtp package still using a link? and for the proper prefix?
<pitti> savvas: Debian is moving towards udev rules in /lib/ as well, so they should just do that
<savvas> pitti: sorry I'm confused :) you mean I shouldn't and just keep the patch as it is in ubuntu, right?
<pitti> savvas: oh, Debian should by all means fix their package as well
<pitti> savvas: but we shuold keep the ubuntu one as it is for now, yes
<pitti> savvas: basically, debian could take our patch (and update the version numbers in the comparison adequately)
<savvas> ok trying right now then, I'll let you know if a few minutes
<pitti> savvas: no hurry; I need to leave in 30 mins, I won't get to sponsoring it today anyway
<savvas> ok then :)
<savvas> those preinst / postinst are really twisted scripts, but gooooood :) I got the hang of it, no changes required, conf files and packages will be properly upgraded
<savvas> (I mean no changes required on my behalf)
<pitti> savvas: no; the main point of the merge is to send the patch to Debian, so that eventually we can sync again
<pitti> savvas: also, would you have time to integrate the other patch I mentioned?
<pitti> good night everyone, see you all tomorrow
<savvas> pitti: I'll check that out as well, I'll let you know through the bug report
<rtg> kees: I've updated the kernel flavours blueprint https://wiki.ubuntu.com/KernelTeam/Specs/KarmicKernelFlavours and referenced one that you wrote a year ago.
<kees> rtg: ah-ha, cool.
<kees> rtg: instead of the current one?
<rtg> kees: I'm not sure what you mean.
<kees> https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-pae-desktop instead of the other one since the other was already scheduled for the last UDS
<geser> doko: any idea how to resolve the FTBFS of cerealizer in karmic? the problem is that cdbs renames the dist-packages back to site-packages, but the testscript adds get_python_lib() prefixed with debian/cerealizer to find the modules which fails as the files are at this point in site-packages and not dist-packages
<geser> doko: http://launchpadlibrarian.net/26117036/buildlog_ubuntu-karmic-i386.cerealizer_0.7-3_FAILEDTOBUILD.txt.gz
<rtg> kees: I just referenced yours since it was apropo wrt PAE, but my spec also covers other topics.
<kees> rtg: also, why do lpia and armel get -$arch instead of -generic
<kees> rtg: okay, but I'd like to make sure that the cs-limit nx-emulation stuff gets in too.
<rtg> actually, they $flavour
<rtg> they get $flavour
<kees> rtg: and why "generic-pae" instead of just "pae"
<rtg> kees: the names are open for discussion. perhaps 3gb is more appropriate.
 * kees nods
<kees> "-allyourRAMisbelongtous"
<elmo> I thought the cutoff for non-PAE was 2Gb? :-P
<rtg> kees: my goal is to have the minimum difference between -generic and -generic-pae
<kees> rtg: I don't know what the conventions are for UDS scheduling, but you might want to check if using +spec/use-pae-when-possible is correct (since it was last UDS)
<elmo> umm, 4, rather
<rtg> elmo: 1GB is reserved for mem mapped I/O stuff
<kees> elmo: iiuc, it's only 3 because of how the kernel maps virtual memory.
<maswan> elmo: minus whatever pci etc wants, and then kernel/userland split
<maswan> elmo: We got 3.5GB on our machines, back in the days before real pointers
<kees> rtg: -generic vs -generic-pae> yeah, I'm all for it being just a single CONFIG difference.  :)
<maswan> but anyway, 32-bit stuff has been obsolete for close to 5 years now anyway. ;)
<elmo> maswan: haha
<kees> rtg: and what're your current thoughts on cs-limit?
<rtg> kees: um, ambivalent. Its an ugly patch but I'm probably gonna add it. I _would_ like to see some evidence that it might have prevented past abuses.
<kees> rtg: I can certainly go find some example exploits that don't work as a result of cs-limit nx-emulation.
<rtg> kees: that would certainly help bolster credibility for the patch
<kareem> hello
<kees> rtg: if it helps, nearly all security vulnerability research starts with "and if we turn off NX, [example]".
<kees> rtg: all the stuff about how to avoid ASLR, stack canaries, etc, all depend on NX being non-functional.
<kareem> Would this qualify as a Q for here?  I'm trying to make an Ubuntu package for FreeSWITCH, and when I test it, I keep getting: "E: Internal Error, Could not perform immediate configuration (2) on g++-4.2"  No one in any other Ubuntu channels I've been in can figure it out.
<kees> rtg: shall I send it to the kernel-team thread?
<rtg> kees: I've got no problem with NX, its just that the cs-limit emulation is a bit of a hack (but understandable given HW limits)
<rtg> kees: yes- the k-t list is appropriate
<kees> rtg: well, cs-limit == NX for people lacking NX hardware, so basically, all exploits that work when NX is missing are protected by cs-limit nx-emu
<rtg> kees: true, it is page granular.
<kees> rtg: do you still want examples?  it's an entire class of vulnerabilities, so I thought it'd be an obvious protection.
<ogra_> heh ... that abbreviation is used way to often /me just thought of nx-server/client
<rtg> kees: it may be obvious to you, but a list of examples wouldn't hurt.
<kees> rtg: okay
<cody-somerville> My ssh-agent seems to have been replaced with one that has an icon of a weird looking fish
<cody-somerville> I thought I remember reading about this in a changelog
<cody-somerville> Can anyone jot my memory?
<Pici> cody-somerville: seahorse?
<cody-somerville> I'd like to use seahorse
 * zhxk runs away
<LaserJock> is there an easy way to determine what the default python version is for a given release?
<geofft> packages.ubuntu.com/python
<LaserJock> geofft: thanks, that was easy :-)
<geser> LaserJock: you can also run "python --version" (assuming a supported setup)
<LaserJock> yeah, I just didn't have chroots available for the releases I wanted
<LordMetroid> Does the launchpad automatically forward bug reports upstream?
<geser> LordMetroid: no
<LordMetroid> Damn, why not? It ought to, it is so convenient to report bugs for anything in one place
<geser> one reason is that the bug might be due to Ubuntu changes, another reason that not every bug is really a bug but an user-error and upstream won't be happy if we auto-forward those bugs too
<geser> I guess there are more reasons against it
<LordMetroid> So what do I do with this:  https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/371819 ?
<ubottu> Launchpad bug 371819 in gimp "Gimp doesn't rerender canvas on canvas size change undo" [Undecided,New]
<LaserJock> upstreams not wanting automatic bugs from LP comes to mind
<geser> LordMetroid: forward the bug to the gimp bugtracker yourself and add a bugwatch to the bug in LP
<LordMetroid> ok... I'll try to do that
<geser> I guess some upstream prefer to have a human contact to a bug instead of some script (another reason against automatic bug-forwarding)
<LordMetroid> Bugwatching is more intersting then birdwatching...
<mrooney> Would anyone be kind enough to whitelist me on the ubuntu-devel list?
<cody-somerville> mrooney, Are you a Ubuntu developer?
<mrooney> cody-somerville: I am not familiar with the official definition of that :)
<cody-somerville> mrooney, Are you a member of the ubuntu-dev or ubuntu-core-dev teams on launchpad?
<mrooney> As I understand it anyone can be whitelisted if they have a history of reasonable posts
<mrooney> cody-somerville: nope
<cody-somerville> mrooney, You might try e-mailing an administrator of the list
<cody-somerville> mrooney, Or try your luck and see if the right people see your message above
<mrooney> cody-somerville: yeah I have seen someone successfully ask here so I thought I'd try as well :)
<kirkland> jcastro: yo
<kirkland> jcastro: got your email about ec2+screen
<kirkland> jcastro: try the new screenbin
<kirkland> jcastro: i put everything you need in there
<jcastro> ok
<kirkland> jcastro: you'll need to install Karmic's deb on your Jaunty system
<kirkland> jcastro: give that a try, and let me know how it works for you
<jcastro> likely tomorrow before I prep for a talk on s-p
<kirkland> jcastro: neat
<kirkland> jcastro: who are you talking to?
<kirkland> jcastro: btw ... kees patched screen itself to fix one annoyance, where someone trying to type in their read-only session will cause a 'bell' or ding-message to all other users
<kirkland> jcastro: i built that in the screen-profiles ppa for hardy/intrepid/karmic
<kirkland> jcastro: you'd probably want that package on your host :-)
<thebloggu> my network manager applet is taking too long (like 2-3 min) to recognize my wireless card (not even connect to network, just recognize the card only) on boot. it is possible it is a bug or maybe i am missing something. using openbox if it is relevant
<pace_t_zulu> can someone help me will pbuilder?
<pace_t_zulu> i have a problem with unmet dependencies on a build
<pace_t_zulu> i have read https://wiki.ubuntu.com/PbuilderHowto
<pace_t_zulu> but i can't find a way to resolve the issue
<pace_t_zulu> can someone help me figure out how to fix unresolved dependencies in debuild and/or pdebuild?
<pwnguin> pace_t_zulu: unresolved dependencies?
<pwnguin> as in, the build deps aren't installable?
<pace_t_zulu> pwnguin: yeah i figured pbuilder would handle it better
<pace_t_zulu> pwnguin: no, the build can't happen
<pace_t_zulu> pwnguin: i think it is specific to this package
<pace_t_zulu> pwnguin: i am trying to put together a patch
<pwnguin> if you have an error log, that might help to pastebin. but right now i have to run the vacuum =(
<maco> thebloggu: see if it's showing up in hal during that 2-3 minute wait
<thebloggu> maco, how can i do that ?
<maco> lshal...
<pace_t_zulu> pwnguin: http://pastebin.ubuntu.com/164447/
<maco> (by the way, #ubuntu-bugs might be a good place for debugging...or #nm for that matter)
<thebloggu> maco, wow enourmous :P it will be difficult to test it because it is on boot
<thebloggu> right after start
<maco> thebloggu: log in, run "lshal >> lshal.out" and then read through at your leisure to see if your wirless card is listed
<maco> (it'll put the output in a file called lshal.out)
<thebloggu> maco, ok, i'll test it and i'll bring the results here
<maco> #nm would be better
<maco> since they know how this stuff all works and all i know "it gets info from hal" ;)
<pace_t_zulu> pwnguin: did you get that pastebin?
<pwnguin> yea
<pwnguin> pace_t_zulu: so it's complaining that ipython isn't installable
<pwnguin> pace_t_zulu: by chance, is this a patch for a package in universe?
<pace_t_zulu> pwnguin: let me check
<pace_t_zulu> pwnguin: indeed it is
<pwnguin> then #ubunt-devel isn't the right place to chat about the patch :)
<pwnguin> #ubuntu-motu handles universe packages
<pwnguin> lets move the conversation to there, and stop bothering core developers :)
<pace_t_zulu> pwnguin: you here?
<tkamppeter> pitti, hi
#ubuntu-devel 2009-05-05
<maxb> Looks like zirconium has wedged on sysvbanner translation stripping just like molybdenum did for the previous upload
<billisnice> i have chatzilla and can not connect to ubuntu. I get another window#ubuntu-read-topic
<maxb> billisnice: Well, perhaps you should, uh, read the topic?
<billisnice> i do not understand how to set another port with chatzilla
<mnemo> billisnice: google for it or ask in #ubuntu
<mnemo> billisnice: I think its "/server irc.example.org 6667"
<billisnice> i can get to ubuntu to ask
<mnemo> billisnice: just type "/join #ubuntu"
<billisnice> when i type that i get ===	#ubuntu #ubuntu-read-topic Forwarding to another channel
<billisnice> i am not very computer literate for sure
<billisnice> lol
<mnemo> billisnice: ok sry you have some weird router problem.. im not sure why its not letting you join..
<mnemo> billisnice: the topic in that channel says:
<mnemo> Your router is buggy 1) Please follow these instructions: https://help.ubuntu.com/community/FixDCCExploit to FIX it (yes, it can be fixed) 2) after carrying out those instructions please type Â« test me Â» and wait few minutes | if this fails, type Â« /join #ubuntu-ops Â» to be tested manually
<billisnice> i was in for yrs until a few days ago
<mnemo> billisnice: maybe they added a check for this recently or something.. not sure
<mnemo> billisnice: anyway, what you need to do is to start connecting to freenode using port 8001 instead of 6667
<mnemo> billisnice: the command to do that is: "/server irc.ubuntu.com 8001"
<billisnice> let me try
<billisnice> this is what i get NickServ *	This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>. 	" =-=	User mode for Administrator_ is now +i
<mnemo> billisnice: just choose another nickname, type: "/nick billisnice2" or whatever
<mnemo> billisnice: anyway, you should probably talk to the folks in the #ubuntu-ops channel, they seem to have added this router check thingie
<billisnice> it says =-=	YOU are now known as billisnice2   but there is no one in the room buy me  lol
<ianm_> anyone know why wacoms create so many XInput devices?
<ianm_> in jaunty
<calc> wow the buildds are way behind
<pwnguin> ianm_: how many?
<ianm_> pwnguin: I think 4 per physical device
<pwnguin> sounds about right
<pwnguin> stylus, cursor, erasor and?
<ianm_> pwnguin: and one without any suffix
<ianm_> I don't get it, they all claim to have the same axes and buttons
<ianm_> it's "Wacom Bamboo", "Wacom Bamboo eraser", "Wacom Bamboo cursor", and "Wacom Bamboo pad"
<pwnguin> ah
<pwnguin> the pads sometimes have buttons on themp
<pwnguin> them
<ianm_> but why don't those just show up in "Wacom Bamboo" ?
<pwnguin> probably the better question is what "Wacom Bamboo" is about
<ianm_> ?
<ianm_> Wacom Bamboo = a pad and a pen, and both have buttons on them
<pwnguin> whats the pen have on it? just an erasor and right click button?
<ianm_> the pen has two side buttons
<ianm_> plus cursor tip + eraser tip
<pwnguin> i only have 1 wacom device, so the other stuff is foriegn to me
<ianm_> pwnguin: in Jaunty?
<pwnguin> i mean
<pwnguin> physical device
<pwnguin> one laptop
<persia> Right, so wacoms are special.
<pwnguin> ?
<persia> Different ways of using them are supposed to have different results.
<persia> A common case is that where someone has multiple pens, say a pen, a pencil, and an airbrush.
<persia> So, to support using lots of different devices with a wacom, the input layer has to be able to differentiate different pens.
<persia> (it doesn't really matter what comes in the box with a given set: the facilities are in the hardware, and expansion is supported).
<pwnguin> so i can buy a super duper pen?
<persia> Right.
<pwnguin> or steal one from the graphic design program
<persia> And you can have the different pens serve different purposes, or act differently.
<ianm_> persia: ok. do you know if this current model (4 XInput devices) is going to change soon?  (the way wacoms work seem to be changing a lot)
<persia> Of course, this requires application support, and will be able to support even cooler effects with full MPX.
<ianm_> of course it's going to change?
<persia> ianm_, Well, there's actually that many devices.  You have a pen that contains both a nib and eraser, and a pad that also has buttons.
<persia> If you add another pad, and no more pens, you'd get six.  If you added an airbrush, you'd get seven.
<pwnguin> thats only three
<pwnguin> nib, eraser and pad is three by my count
<ianm_> persia: so why 4? I mean why both "Wacom Bamboo" and "Wacom Bamboo cursor" ?
<persia> Erm, I'd have to look at the events generated by them to answer that.  Send me one?
<pwnguin> heh
<persia> (or fiddle with input-utils yourself to achieve faster results)
<pwnguin> i think the bamboo's are ~100 dollars
<ianm_> persia: a wacom?  but I only have 5 :(
<ianm_> shows nothing:  xinput test "Wacom Bamboo cursor"
<persia> ianm_, I'm mostly joking.  Inspect the input-events streams from each device.
<ianm_> how?
<ianm_> maybe cursor is for the mouse that some come with?
<pwnguin> cursor is for the nib
<ianm_> nib?  the normal tip?
<pwnguin> yes
<ianm_> hm? but it has no input events
<ianm_> ==> shows nothing:  xinput test "Wacom Bamboo cursor"
<persia> and you shouldn't get a device showing for a physical device you don't own.
<hile> you mean, if I steal a usb stick it should not show up :)
<hile> ianm, my question would be was there any difference with previous versions when you are specific about jaunty?
<hile> it's not clear from this discussion if you ask 'should this really have 4 input devices?' or 'it used to have only n now it has 4, what changed?'
<ianm_> my #1 question is, is this right/normal and likely to remain this way in the next ubuntu version
<hile> I guess this is not a decision for ubuntu devels, it comes from the kernel drivers
<ianm_> hm OK
<persia> ianm_, It's at least explicable, and not entirely unexpected from discussions on tablet support during the jaunty cycle.  I would expect future solutions to also identify individual devices (although perhaps not with that level of specificity: I would only have expected 2 guessing entirely based on the packing description for the device)
<hile> of course I don't know anything about wacoms, but it might simply show in hardware level as four devices in same usb cable to system
<persia> hile, No, that's not the issue.  wacoms are special.
<hile> ah, ok
<hile> ianm, my guess is based on this discussion (remember, not really familiar with these devices) the driver shows all things which this tablet might support, if you had them, and maybe should be hiding things which are not connected
<hile> I guess it really _is_ good idea to have multiple devices for different parts, of course it's not fun if the names and IDs change between releases though
<persia> No.  It *doesn't* show the set of possible devices.  It shows the set of devices required to process the set of input events the hardware generates.
<hile> I was just wondering about the 'extra' device myself here, but maybe I'll shut up if I don't know tablets anyway :)
<pwnguin> persia: when did this happen?
<pwnguin> last i knew the HAL detection gave you one device and you just got to deal
<wgrant> pwnguin: HAL was fixed fairly late in Jaunty to provide lots of devices.
<pwnguin> this is what i get for not paying attention
<pwnguin> and for working around the whole autodetection with xorg.conf
<ianm_> persia: do you know if the device IDs show up in the same order for all wacoms?  "Wacom Bamboo eraser", "Wacom Bamboo cursor", "Wacom Bamboo pad", "Wacom Bamboo" as 9,10,11,12 respectively in this case (NOT asking if they'll be the same numbers, of course)
<persia> ianm_, I don't,.
<pwnguin> presumably, you could write a script to resolve the deviceID from the string
<ianm_> pwnguin: yes, but I use multiple wacoms at once :D
<ianm_> pwnguin: so several have the name "Wacom Bamboo"
<pwnguin> heh
<pwnguin> i would imagine usb connected pads are not detected deterministically
<wgrant> ianm_: I'm fairly sure that's not guaranteed.
<persia> I'm certain it's guaranteed *not* to be deterministic.
<ianm_> so how do I (as programmer) know which eraser goes with which cursor and which pad?
<wgrant> The X server could quite reasonably one day start to randomly assign numbers.
<wgrant> ianm_: You check the properties on the input device, which probably don't exist yet.
<persia> ianm_, It doesn't work that way: you can use any eraser on any pad.
<wgrant> Ideally something like the device's serial number would be exposed in the device.
<pwnguin> every time i think wacom is nearly solved
<persia> And beause of the identity of the eraser, it will be the same device.
<wgrant> Device *properties*, that is.
<pwnguin> someone comes up with a crazier "but, but.." scheme
<wgrant> persia: Oh, it works like that, does it?
<persia> wgrant, That's actually sensible.
<persia> wgrant, That's my understanding, to support different (physically identical) devices.
<pwnguin> ianm_: what exactly is the purpose of having multiple pads?
<persia> But including the serial numbers, or some other UUID would be a way to resolve it.
<wgrant> persia: I was under the impression that the tablet just thought "ooh look, an eraser! I'm going to report events to my eraser device now"
<pwnguin> competitive crayon physics?
<ianm_> pwnguin: to have multiple people drawing
<wgrant> ianm_: You could check the HAL device name, although that might not be visible to normal apps.
<ianm_> pwnguin: or just two super high res x/y/pressure inputs.  I'm a VJ
<persia> wgrant, From a which search, I believe that it's not per-class, but per-device.
<persia> s/which/quick/
<pwnguin> a VJ?
<pwnguin> do you do parties?
<wgrant> persia: That doesn't seem likely, as that would mean it would have to grow a new XI device when it saw a new pen. That's doable, but doesn't seem likely.
<ianm_> yeah
<ianm_> so in an app that just knows the id of a wacom device (the one called "Wacom Bamboo") which reports the pen tip x/y/pressure and the pen buttons, how do I connect to the eraser?
<pwnguin> i thought video jockies were an MTV invention
<ianm_> pwnguin: don't get caught up on the name, it's fun interactive light shows
<persia> wgrant, Hrm.  I don't know how else to do the "automatic per-pen profile selection" I see in the data sheets, and without the ability to grow new devices, how does one support an airbrush, mouse, etc.
<wgrant> persia: It sounds like you might be right, then, although it seems a little strange.
<persia> But I suspect I should stop participating in this conversation before I end up adding a collection of wacom stuff to my shopping list (when I don't really have a use case for owning them beyond comprehension)
<wgrant> Heh.
<persia> wgrant, Right.  wacoms are special. (which is where I came in)
<ianm_> persia: do you have a projector?
<persia> ianm_, No.
<wgrant> persia: I knew they had lots of heads, but I didn't know they grew new ones at will.
<persia> wgrant, At least the shops sell a variety of heads for use.  I'm not sure about the *any pen* bit: there seem to be several different color-coded options for pens.
<persia> So, rather than pen+UUUD it might just be pen+color
<persia> (limiting one to 5-6 devices per-pad)
<wgrant> How confusing.
<persia> Indeed.  It's a really cool solution for the intended purpose, but not a close fit to our model of handling input events.
<ianm_> hm
<ianm_> maybe I should remodel this
<persia> More complication: according to wacom(4), wacom protocol IV doesn't support the pen-profile bit, and wacom protocol V does, and both are used in currently-shipping hardware.
<pwnguin> http://www.penny-arcade.com/comic/2009/1/9/
<persia> (and also according to that it is based on serial number, so exposing that as a UUID to HAL would make sense)
<ianm_> wgrant: so are you saying there's no way to determine which eraser is on which pen?
<persia> ianm_, If you set your X debug level to 6, the driver will show the serial number, but it's apparently not used by HAL.
<persia> For your use case, I would have recommended a couple of USB synaptics touchpads.
<wgrant> HAL doesn't really need to know about it - the driver or evdev needs to expose it as an XI property.
<ianm_> persia: touchpads are pretty awkward for drawing though (I also have a driver for touchpads as X/Y pads)
<persia> wgrant, So, it's just a driver issue?
<persia> ianm_, Hrm.  That's certainly true.
<wgrant> persia: If the driver is able to spew it into the log, it is also able to put it into a property.
<wgrant> persia: So it looks like it's just down to the driver now, yes.
<persia> Right.  So that's the bug.  Someone with a wacom should track that down and fix it.
<ianm_> persia: http://photos-d.ak.fbcdn.net/hphotos-ak-snc1/hs004.snc1/4155_72565298156_531288156_1844763_3590172_n.jpg
<persia> And then we have eraser-7a8d8c9e9f9b9a
<persia> Which can then be used sensibly in userspace.  For extra points, the UUID should probably also encode which pad is being used, as well as which device.
<pwnguin> for the highest difficulty, convince Ping to do this before the heat death of the universe
<wgrant> persia: You could either put it in the device name, or hide it away in a property so users don't see the ugliness.
<persia> wgrant, hiding it in a property is better.  I just don't know how to express that as a noun effectively.
<persia> Actually two properties: one for the pointer device UUID and one for the tablet UUID.
<ianm_> wgrant: so currently there's no way to know which eraser goes with which pen?  that's rough... :)
<persia> ianm_, As an accident of device enumeration, it's likely that adjacent devices belong to the same physical device.
<ianm_> persia: yes that does seem to be the case, that's why I asked if that's consistent
<wgrant> ianm_: It's a lot less rough than having only one device show up, like Intrepid and earlier.
<persia> It's not guaranteed.
<ianm_> wgrant: yeah!  and I would imagine no one uses more wacoms simultaneously than me, so I appreciate that ;)
<pwnguin> so what magic am i missing
<pwnguin> that my tabletPC only has one apparent device
<wgrant> ianm_: No, no, previously only one of the heads of each device would show up.
<wgrant> pwnguin: Do you have wacom-tools?
<pwnguin> i do
<ianm_> wgrant: you mean multiple wacoms worked before, even though you had to set it up manually in xorg.conf?
<pwnguin> ive also moved xorg.conf out of the way to see this in action
<wgrant> ianm_: I'm not sure.
<ianm_> if so, I did a lot of upgrading, including running into new intel graphics bugs, for nothing, but oh well :D
<pwnguin> actually, it seems to be finding my cursor and erasor
<pwnguin> but i have no right click
<ianm_> so maybe I'll hardcode it to use ID-1, ID-2, and ID-3, and see how far that gets me
<pwnguin> i guess its time to go read those bugs ive been ignoring about wacom
<persia> wgrant, I can't seem to find the bit that sets the properties.  Do you have any suggestions for function names I should be seeking?
<ianm_> hm the buttons on the Wacom Bamboo pad don't seem to show up anywhere
<pwnguin> ianm_: i have a similar problem with my right click
<persia> I'm now very confused.  There's a changelog entry in xf86Wacom "2005-11-17 47-pc0.7.1-1 - Report tool serial number and ID to Xinput".
<persia> pwnguin, Can you double check the xinput properties for your device?  There should be useful information available.
<pwnguin> persia: any tips on what commands do that?
<ianm_> persia: http://pastebin.com/d6cf59844 ?
<persia> pwnguin, xinput list?
<persia> ianm_, Thanks.
<persia> ianm_, Could I have list-props for the other three as well?
<ianm_> persia: all identical
<pwnguin> http://pastebin.com/f72f6d546
 * persia is all sorts of confused.
<pwnguin> probably
<pwnguin> i grepped too much out
<persia> You guys have xserver-xorg-input-wacom loaded?
<pwnguin> http://pastebin.com/m4016b702
<pwnguin> there's the full entry
<ianm_> persia: installed yes
<persia> Does Xorg.log report it being used?
<pwnguin> (II) Loading /usr/lib/xorg/modules/input//wacom_drv.so
<persia> I'd expect list-props to provide a serial number or something.  There's a bug in here.
<ianm_> mmhmm
<ianm_> (II) LoadModule: "wacom"
<ianm_> (II) Loading /usr/lib/xorg/modules/input//wacom_drv.so
<calc> anyone know why openjdk-6-jre is not installable on hardy?
<calc>   openjdk-6-jdk: Depends: openjdk-6-jre (= 6b09-0ubuntu2) but it is not going to be installed
<cody-somerville> calc, what happens when you try to install openjdk-6-jre?
<calc> hmm i think the problem may be with my chroot not havint the security/updates uncommented
<calc> hmm actually they are
<calc>   openjdk-6-jre: Depends: openjdk-6-jre-headless (= 6b09-0ubuntu2) but it is not going to be installed
<calc>   openjdk-6-jre-headless: Depends: tzdata-java but it is not going to be installed
<calc>   tzdata-java: Depends: tzdata (= 2008b-1ubuntu1) but 2009f-0ubuntu0.8.04 is to be installed
<persia> pwnguin, ianm_ My apologies, but I think I've gotten as far as I can without a device, and want to delay getting one by at least a few more months.  I'd recommend looking at the VCS for the driver, specifically xf86Wacom.c, and review the changes made to "add hotplug support".  I believe the passing of the tool and pad serial numbers to Xinput was dropped at that point.
<pwnguin> persia: well, im not interested so much in crazy multi pen / pad maddness
<calc> i'm confused these versions seem to be old versions even though i have security/updates available
<ianm_> 4 pads is the minimum for any reasonable person
<calc> doh
<calc> cody-somerville: nm i figured out what i did wrong
<ajmitch> calc: no universe -updates?
<calc> cody-somerville: i forgot to add universe to those
<pwnguin> ianm_: thats far too many to carry around
<calc> ajmitch: yea, doh ;-(
 * cody-somerville goes to watch the newest episode of house! :)
<persia> pwnguin, re: multiple pads, I agree.  re: multiple tools, I think it's a nice use case to be able to physcially switch between pen and airbrush without worrying about fiddling with software.
<wgrant> persia: Input properties only appeared in 2008; that 2005 thing must be talkin about some other interface.
<persia> Aha!
<ianm_> persia: multiple pads sure is useful when you have multiple humans :)
<persia> ianm_, So are multiple computers :)  But yes.
<ianm_> persia: it's quite fun to draw on the same canvas!
<pwnguin> how does that even work without MPX?
<persia> pwnguin, rapid switching on absoute coordinates.
<ianm_> pwnguin: was that Q for me?
<ianm_> if so, it works by reading from the xinput devices directly
<ianm_> not using them as mice
<dholbach> good morning
<pitti> Good morning
<pitti> tkamppeter__: hi
<tkamppeter> pitti, hi
<pitti> tkamppeter: good morning
<tkamppeter> pitti, I have re-uploaded s-c-p yesterday night, with the missing bits in the debian/changelog missing.
<tkamppeter> pitti, now I see you have passed it through. Thanks.
<pitti> tkamppeter: no problem, sorry for the hassle
<maxb> pitti: There's a sysvbanner build stuck in dbgsym processing on i386 and lpia again
<directhex> wasn't me, i didn't break it
<pitti> maxb: weird
<pitti> maxb: I'll try to reproduce it locally
<NCommander> pitti, in the mood to sponsor an upload? (I'm just finishing off an FTBFS fix for apr)
<pitti> NCommander: sure
<NCommander> Let me just finish the bug.
<NCommander> Oops, hold on, forgot to fill out the dpatch header
<NCommander> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/apr/+bug/372068
<ubottu> Launchpad bug 372068 in apr "FTBFS fix for APR" [Undecided,New]
<cjwatson> kirkland: section 7 of RFC 4252 describes the messages used in SSH publickey auth
<pitti> NCommander: please send this to Debian as well, it should hit them as well?
<NCommander> pitti, I'll test to see if APR if it still breaks
<pitti> NCommander: if it breaks for us, why doesn't it break for Debian?
<NCommander> pitti, I stopped trying to make sense of libtool breakage along time ago
 * NCommander is just waiting for his sid chroot to update
<pitti> it built just fine in Debian
<pitti> NCommander: anyway, upload prepared, tell me when to fire
<NCommander> pitti, fire when ready
<pitti> NCommander: *boom*
 * NCommander watches karmic die
 * NCommander is somewhat amazed at the level of breakage this cycle
<pitti> NCommander: really? except for the new intel driver, karmic didn't break at all yet
<NCommander> pitti, are we looking at the same FTBFS counts :-)
<pitti> oh, those
<pitti> NCommander: just talking about stuff that actually reaches my machine
<NCommander> pitti, you already upgraded to karmic?
<pitti> sure
<pitti> and speaking about autof*** breakage, /me goes back to that gthumb merge
<NCommander> pitti, which merge?
<pitti> (didn't I just say? gthumb)
<NCommander> pitti, er, I mean whats broken about the merge :-P
<seb128> pitti: we still have some changes ubuntu specific in this one? ideally it should go to universe and be a direct sync
<pitti> seb128: yes, lpi and a gvfs fix to unmount when using libgphoto
<seb128> ah ok
<pitti> the lpi one is sticky
<seb128> I guess lpi could be dropped
<seb128> but if we have diff anyway we can as well keep it
<pitti> I sent the gvfs one upstream months ago, it wasn't applied yet :(
<NCommander> pitti, Debian already has a fix pending (slightly different from the one they used), and its fixed upstream
<NCommander> so once Debian has an upload its just a sync <g>
<pitti> NCommander: in apr? nice
<bigon> is it now some magic for packages with python modules to compile nicely with python2.6 without modification?
<NCommander> pitti, yeah, someone backported the SVN fix for APR
<pitti> seb128: if we drop it to universe, we could drop two changes (libopenrawgnome-dev build dep and POT building)
<pitti> but it's one of the packages which call autoconf at runtime, and it just falls apart
 * pitti renews his deep hate towards autotools
<seb128> bigon: if you have the site-packages directory coded in rules on install I don't think so
<seb128> on -> or
<seb128> pitti: so basically once the gvfs fix is upstream or in debian we could move to universe and sync
<pitti> yes
<pitti> if we don't care about lpi any more
 * NCommander takes out a machine gun and shoots gstreamer0.10
<bigon> seb128: http://pastebin.com/d1b39b68 << because I get that and the module is correctly installed
<seb128> NCommander: what is the issue?
<NCommander> seb128, libtool breakage
<seb128> NCommander: you don't try to fix the karmic build do you?
<NCommander> seb128, huh?
<NCommander> pitti, do I need to files bugs to get NBS packages with no rdepends removed? (file size 0)
<seb128> NCommander: no
<seb128> those are autocleaned when somebody have a go at this list
<NCommander> seb128, which list? (I'm trying to fix outstanding FTBFSes in main and universe)
<seb128> NBS
<NCommander> oh
<seb128> NCommander: and gstreamer0.10 is already fix commited
<NCommander> Oh
<NCommander> Handy :_)
<seb128> it's early to fight karmic ftbfs issues
<pitti> NCommander: http://paste.ubuntu.com/164757/
<pitti> I have NFC what libtool wants to tell me
<NCommander> Oh that fun.
<NCommander> yeah, I had that issue
<NCommander> Looks like the package is setup in a way that there are multiple libtool instances
 * NCommander grabs the source
<seb128> pitti: run autoreconf
<NCommander> pitti, autoreconf -if
<seb128> pitti: you are using different versions than the one used for the tarball and don't run all the auto* or not in the right order
<seb128> pitti: running "autoreconf" should fix it
<Keybuk> pitti: that's a mismatched ltmain.sh/aclocal.m4
<pitti> in fact, the Makefiles themselves run autoconf
<pitti> so apparently they don't run libtool (neither the external nor the internal copy)
<NCommander> seb128, if its too early to start fighting FTBFS, when do you recommend doing so? Alpha 1 is in a week and a half :-/
<seb128> NCommander: no need to clean universe for alpha1
<NCommander> seb128, I'm just focusing on main ATM
<pitti> (apr is in main)
<seb128> NCommander: most of those issues will be fixed along the way with autosyncs, etc
<NCommander> seb128, there is enough breakage in main to be afraid :-P
<seb128> "<NCommander> seb128, which list? (I'm trying to fix outstanding FTBFSes in main and universe)"
<seb128> you listed universe
<NCommander> pitti, I'll do universe ones when I run out of main :-P
<NCommander> er
<NCommander> seb128,
<seb128> I've nothing against you spending your time on that
<seb128> but that's often a waste of time
 * NCommander usually goes right down the list 
<seb128> don't create extra diff for things which are on sync and that debian will fix though
<Keybuk> NCommander: the archive doesn't need to be buildable for alpha1, just installable
<Keybuk> they're quite different things
<seb128> ie gstreamer ;-)
<Keybuk> and it's probable that most FTBFS can be fixed by doing an outstanding merge
 * pitti flushes an autosync run
<pitti> seb128, Keybuk: thanks, that helped; I'll add it to debian/rules
<pitti> it now FTBFSes in a different way at least
<NCommander> Keybuk, then what do you recommend I do?
<Keybuk> NCommander: http://merges.ubuntu.com/main.html#]
<pitti> intltool-update looking at .pc/04-fix-gvfs-umount.patch/data/gthumb-import.desktop.in
<Keybuk> NCommander: 293 to do there
<seb128> pitti: can't you just comment the autotools call there? ;-)
<seb128> urg
<pitti> seb128: no, the upstream makefiles themselves are set up to call autoconf etc.
<pitti> apparently in an insufficient way
<Keybuk> pitti: sounds like something ran aclocal or similar by accident?
<Keybuk> ordinary automake makefiles won't do that
<pitti> debian/rules doesn't call any auto* so far; I added an autoreconf -fvi now
<pitti> we have it in bzr-buildpackage, so screw an unclean diff.gz after binary build
<pitti> Keybuk: we do patch some Makefile.am, so in principle it is right in automake'ing
<Keybuk> pitti: right, but calling automake itself should be harmless
<Keybuk> likewise autoconf
<Keybuk> that won't cause the error you saw
<Keybuk> calling aclocal is what tends to cause that brekage
<Keybuk> probably just need "libtoolize" ran
<pitti> directhex: here?
<pitti> directhex: ah, nevermind; unping
<zhxk`> hello, how to let sshd start before desktop? i can't login to ubuntu by ssh at gdm time
<pitti> zhxk`: by default that should work; ssh is started at S16, gdm at S30
<zhxk`> how to troubleshoot? sshd stops as soon as out to gdm from gnome
<ogra> (on a sidenote that belongs to #ubuntu)
 * directhex smells n-m
<directhex> pitti, you can still ping me if you like
<dholbach> seb128: why are you "rebasing" the gnome packages?
<seb128> dholbach: you probably call that merging, why not?
<seb128> dholbach: to lower delta, send changes back to debian, etc?
<seb128> dholbach: why do we do it for all the non GNOME packages?
<dholbach> merging and sending stuff upstream is definitely fine - you're dropping history
<seb128> we do that since warty
<dholbach> I was a bit confused by the wiki page and the stuff in the sponsoring queue
<seb128> if you are speaking about changelog entries
<dholbach> yeah
<seb128> we do that for ages
<dholbach> a lot of packages have history since warty
<seb128> no point to have hundred of NEWS summaries
<NCommander> pitti, when you get a free moment, can you please sync https://bugs.edge.launchpad.net/ubuntu/+source/libxfcegui4/+bug/372098 for me? (I have a bunch of outstanding merges that are dep-wait until that goes through :-))
<seb128> and I don't see the point, it's extra work
<ubottu> Launchpad bug 372098 in libxfcegui4 "Sync libxfcegui4 4.6.1-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed]
<seb128> NCommander: you know there is a process to request syncs and several archive admins
<dholbach> seb128: OK, I was confused - if we do it we should make sure though that we still have pointers to all the bugs that were fixed by patches that we ship
<seb128> NCommander: karmic is not such an hurry now that you need to ping people on IRC
<NCommander> seb128, we're uploading to karmic so we can do a SRU of 4.6.1
<NCommander> seb128, (of Xfce)
<NCommander> which has quite a few bug fixes
<seb128> dholbach: we summarize changes in the current changelog entry and try to tag patches
<dholbach> seb128: that's good - just wanted to make sure I knew what you guys were doing
<seb128> NCommander: that doesn't seem urgent enough to IRC ping to speed up things, syncs are processed daily
<dholbach> (when doing sponsoring)
<seb128> dholbach: ok thanks
 * seb128 hugs dholbach
<seb128> dholbach: I don't think that changed since you were in the desktop team but thanks for checking ;-)
 * dholbach hugs seb128 back
<pitti> NCommander: was going to do it, but my LP cookie is broken again on cocoplum; I'll just defer it to today's archive admin
<NCommander> pitti, ah well
<pitti> yay, there goes my last merge
<seb128> pitti: lucky you ;-)
<pitti> seb128: I only had about 15 or 20, most of my stuff finally got accepted in Debian
<seb128> that's where sending back to debian pays ;-)
<seb128> and not having lpi used in his packages too :-p
 * pitti hugs seb128
 * seb128 hugs pitti
<highvoltage> ok you guys can let go now
<bigon> infinity: are you around? long time ago we discuss about the openhackware package that need to be built on ppc, it whould really great if you could build it and put it in the archive
<NCommander> bigon, its a non-trivial problem (I've been looking at it myself)
<bigon> NCommander: yeah I know but IIRC infinity told me that he whould build the package himself and use some backdoor to but it in the archive
<bigon> as the package doesn't change so often
<NCommander> bigon, he said the opposite in the bug report :-/
<NCommander> bigon, I was looking at the possibility of building the necessary cross-toolchains
<bigon> k
<directhex> oh, i see. how to make it arch:all but build on ppc
<directhex> i can think of a couple of hacks which probably wouldn't work because the archive doesn't work the way i think it does
<NCommander> directhex, I can get it to build, but it will not upload due to some hardcoded bleck in the generated changes file
 * NCommander spent quite a bit of time on this
<directhex> NCommander, how are you doing it?
<NCommander> directhex, deep magic
<NCommander> directhex, http://launchpadlibrarian.net/26054517/upload_962116_log.txt - here's the failure to upload log
<directhex> hm, i see
<directhex> what would happen if the package generated both the arch:all openhackware package, and a dummy arch:powerpc package, in the binary-arch rule? leave binary-indep empty?
<davmor2> Quick question why does kvm and libvirt etc recommend samba?
<NCommander> directhex, its a problem with how sbuild calls dpkg-buldpackage
<NCommander> directhex, we can't control the call to dpkg-genchanges
<directhex> bloody sbuild
<directhex> someone remind me why sbuild is the favoured buildd
<NCommander> directhex, well, it calls dpkg-buildpackage with -B
<NCommander> :-P
<NCommander> which makes the changes called with dpkg-genchanges -B
<pitti> Keybuk: how do you update the udev-extras package from upstream?
<pitti> Keybuk: I'd like to play with udev-acl, and check whether it can sufficiently replace our hal auto-ACL magic
<Keybuk> pitti: git fast export | bzr fast import, etc.
<Keybuk> I can update it if you like
<pitti> ah, so there's no magic debian/rules incantation or so
<Keybuk> no
<pitti> Keybuk: if you could pull and push to bzr, that'd be great
<pitti> saves me from figuring out where and how to pull and import
<Keybuk> even if you did it, you'd end up with something incompatible with my branch :-(
<Keybuk> sadly git fast-export | bzr fast-import doesn't generate predictable revision ids
<Keybuk> so if you do it, you'll get an entirely different branch
<pitti>  bzr fast-import --help
<pitti> bzr: ERROR: unknown command "fast-import"
<pitti> (and that, too)
<pitti> ah, bzr-fastimport package
 * Keybuk wishes bzr-git just worked
<pitti> Keybuk: http://lists.freedesktop.org/archives/devkit-devel/2009-April/000140.html was quite interesting
<james_w> Keybuk: it's improving quickly
<Keybuk> james_w: it didn't even install correctly when I tried at the release sprint
<james_w> from the package?
<pitti> Keybuk: the source package doesn't even build for me; debian/rules provides no rule for generating "configure" by calling autoreconf for ./autogen.sh; how is that supposed to work?
<Keybuk> pitti: why should the rules do that?
<pitti> Keybuk: oh, nevermind me; I didn't get/unpack the tar.gz before
<Keybuk> udev-extras_0~20090414+1-git4817acf-1_source.changes uploaded
<pitti> Keybuk: sweet, thank you!
<Keybuk> I think we're still missing the hal-info -> ? conversion
<pitti> wow, that changed quite a bit
<pitti> Keybuk: I also didn't see any new world counterpart to the setkeycodes bit in hal and the keymaps in hal-info
<Keybuk> no, probably doesn't exist
<pitti> I got the hang of it, and I'm quite interested in that one
<pitti> Keybuk: I'll mail the devkit list about it
<Keybuk> cool
<Keybuk> the last I heard, the temptation was to just have X do this stuff directly
<Keybuk> rather than have a DeviceKit-input
<pitti> I wouldn't like to have a full-blown devkit-* stuff for that
<pitti> it's something you do once at boot, and never again
<Keybuk> yeah
<pitti> well, "never" -> if you hotplug a new keyboard, it needs to be run again, I figure
<Keybuk> right
<Keybuk> worth chatting on #udev about, probably
<pitti> Keybuk: could htat become an udev rule which fires a setkeycodes script whenever you add an input device?
<Keybuk> pitti: possibly, yes
 * pitti will discuss on the list
 * Keybuk gets confused by soyuz
<Keybuk> "Version older than that in the archive"
<cjwatson> $ dpkg --compare-versions 0~-2~gite5fb9bd-1 lt 0~20090414+1-git4817acf-1 && echo yes
<cjwatson> $
<cjwatson> can't help feeling that putting git sha-1s in things that are meant to be versionwise comparable is a recipe for confusion anyway, not that that's the problem here ...
 * cjwatson gets a migraine from the console-setup merge
<Keybuk> yeah, it's a pretty insane version string ;)
<directhex> can't help feeling that putting git sha-1s in things that are meant to be versionwise comparable is a recipe for disaster
<ion_> In git, you can refer to commit as <previous-tagname>-<commit-number-since-the-tag>.
<pitti> Keybuk: how efficient is the udev rules parser? I. e. if there was a rules file with a thousand laptop model key's worth of keymap data, would that take a significant time? or does it use some clever internal tree structure?
<Keybuk> very efficient
<cjwatson> james_w: I've been finding it very hard to keep dulwich, bzr-git, and bzr in sync for testing :-(
<Keybuk> it does process each in order
<Keybuk> but the time to do that is pretty low
<pitti> Keybuk: so it could actually be done that way, instead of providing an udev callout with its own pattern matching processor?
<Keybuk> done what way?
<pitti> Keybuk: have the long list of vendor/product -> keymap encoded in udev rules
<cjwatson>             echo unsupported_layout=$unsupported_layout >>/tmp/cslog # asdf
<cjwatson> lovely
<pitti> Keybuk: also, is there a standard way for an udev rule to refer to DMI data, such as hw vendor/product name?
<pitti> Keybuk: (of the system, not the added device)
<Keybuk> pitti: the long list should be ideal
<Keybuk> obviously we'd want to guard it with SUBSYSTEM!="...", GOTO="end" simply to speed up other processing
<Keybuk> but udev should rattle down it quickly
<pitti> Keybuk: right, and another shortcut for not adding an input device
<Keybuk> pitti: dmi data such as loading a module based off it?
<pitti> Keybuk: I just wondered whether we could do the system vendor/product matching in the udev rules, too, or whether we need a special callout in the beginning to detect that and export it into env vars
<LordMetroid> jseval [foo: "bar"];
<LordMetroid> sorry
<pitti> Keybuk: not a module, to do the matching; e. g. on "LENOVO"/"ThinkPad X6", keycode 0061 is "next song"
<Keybuk> pitti: SUBSYSTEM=="dmi", ATTR{chassis_vendor}=="LENOVO", ATTR{product_name}=="Th
<Keybuk> inkpad X6", ...
<Keybuk> ?
<pitti> Keybuk: right, but that woudl match on "adding" (well, coldplugging) the DMI stuff, not a new input device, woudln't it?
<Keybuk> right
<Keybuk> annoyingly the chassis dmi information isn't a "parent" of anything
<Keybuk> it'd be worth an upstream discussion how to do that kind of thing
<pitti> so I would need an ACTION="add|change", SUBSYSTEM=="input", ENV{SYSTEM_VENDOR}=="Lenovo", [run callout with keymap data]
<pitti> or, if that isn't possible, just always run the callout on addition of an input device and have the callout do the vendor/product matching
<pitti> less elegant, though, since we couldn't re-use the udev rules parser
<Keybuk> I think it'd be better to fix udev so we could just directly use it
<pitti> yeah, that would be great
<pitti> I wouldn't like to add an IMPORT{program}="dmidecode" something to each rule
<pitti> Keybuk: I guess variables are only valid within a rule, i. e. you can't have one callout at the beginning of your .rules which sets SYSTEM_{VENDOR,PRODUCT} and use those vars in the following rules?
<Keybuk> no, sadly not
<Keybuk> can you think of any other cases, apart from dmi, where you'd want to refer to another device?
<james_w> cjwatson: yeah, it's a pain unfortunately. It's one of my targets for this cycle to make sure they are up to date in karmic and there are snapshots available
<pitti> Keybuk: I saw a lot of rules which refer to a device's parent, or grandparent, but not an arbitrary one
<pitti> (other than the equivalent of /org/freedesktop/Hal/devices/computer, which is special)
<Keybuk> right, we obviously can do any ancestor in udev, that's quite easy
<pitti> Keybuk: maybe it would make sense to special case system vendor/product/version, since referring to them will become very common once we migrate hal-info
<Keybuk> right, I'm wondering whether we should special-case dmi data
<pitti> or introduce the concept of global variables
<Keybuk> sadly the kernel doesn't have the concept of a top-level device
<pitti> so that you can have one callout at the beginning of your .rules which exports these vars and you can use them
<Keybuk> which is what they should really be set on
<Keybuk> pitti: obviously the main concern will be making sure that we process the DMI information first
<Keybuk> otherwise you might end up finding the keyboard before the kernel announces the DMI info
 * ogra points out that there are enough broken BIOSes out there that we might introduce issues with using DMI data as reliable source
<pitti> Keybuk: the global variables approach seems more generic, and more robust against such races
<pitti> Keybuk: but then again, with that we'd probably end up with doing the same DMI decode stuff in 5 different places
<pitti> ogra: we have used it for ages
<ogra> oh, ok
<pitti> ogra: hal reads /org/freedesktop/Hal/devices/computer from DMI, and hal-info relies on it
<cjwatson> the kernel has had DMI-based quirks since shortly after the beginning of time
<Keybuk> you're misunderstanding me
<pitti> ogra: so while there are certainly lots of broken BIOSes around, I think we can rely pretty well on the vendor/product data
<Keybuk> right now the kernel puts DMI information in its own kobject under /devices
<Keybuk> so there's inherently a race unless we deliberately process that first
<pitti> ogra: no-name products will just have empty or bogus string, then they just don't match anything
<Keybuk> where deliberately process would have to include "spin until the kernel announces it"
<ogra> pitti, right, of these i have seen a few
<pitti> Keybuk: ah, you are saying that even with the global var/initial callout appraoch, calling dmidecode would fail in that case, since it's not been discovered yet?
<Keybuk> we don't want to call dmidecode
<pitti> (if we can avoid it, so much the better)
<Keybuk> we want to import the information from /sys/devices/virtual/dmi/id
<Keybuk> such that it is available to all other objects
<lifeless> TheMuso: up?
<pitti> Keybuk: shall I open a bug about that, or a ML post?
<Keybuk> pitti: I'll chat to kay first and see if there's something obvious ;)
<pitti> Keybuk: okay, many thanks
<cjwatson> hmm, I should probably convert d-i over to using /sys/devices/virtual/dmi/id/sys_vendor rather than using dmidecode or stripped-down versions of it
<pitti> if that's a reliable path, it does seem very elegant
<cjwatson> it wasn't around when I added DMI handling to d-i originally (for Macs)
<pitti> Keybuk: does the SYSFS{} function take a full path? i. e. in theory, if it weren't for the race, rules could refer to that?
<Keybuk> if I were being paranoid, I'd genericise it as /sys/devices/virtual/dmi/*/sys_vendor ;)
<cjwatson> the 2.6.22 kernel, at least, doesn't have it
<Keybuk> but I don't think that's warranted, it should always be "id"
<Keybuk> pitti: no, precisely because otherwise there'd be a race <g>
<pitti> Keybuk: heh, robustness by design; I like that
<lifeless> TheMuso: if you are around, I'm hacking on dmraid, and you seem to be active there...
<TheMuso> lifeless: What can I do for you?
<Keybuk> pitti: turns out it's easy
<Keybuk> SUBSYSTEM=="input", ...some keyboard matching..., ATTR{[dmi/id]product_name}=="Thinkpad X60", ...
<Keybuk> pitti: join #udev ;)
<lifeless> TheMuso: bug 372170
<ubottu> Launchpad bug 372170 in dmraid "intel isw raid metadata at odd offset" [Undecided,New] https://launchpad.net/bugs/372170
<TheMuso> lifeless: looking
<TheMuso> lifeless: do you have a reason to use dmraid over generic linux software raid?
<lifeless> dual boot with windows
<lifeless> I may not do that but I need the option
<lifeless> I'm aware that dmraid is the devil's spawn and a half arsed compromise from folk that make IDE controllers and should know better.
<TheMuso> lifeless: Right good enough reason
<TheMuso> lifeless: afaik offset locations can be specified in the isw header, but I am not 100% sure, since I've not had to look in that file for a while.
<TheMuso> lifeless: have you tried the latest debian/karmic package?
<lifeless> no, haven't got an installed system yet ;P
<TheMuso> right
<lifeless> isw probes only one spot
<lifeless> that was part of my change
<TheMuso> right
<lifeless> random question, how big does the installer make swap?
<lifeless> I want to keep disk space aside for windows, so doing manual partition
 * TheMuso can't remember actually, since he always manually partitions
<TheMuso> lifeless: the BIOS/board you are using didn't happen to create an hpa on those drives did it?
<lifeless> wheee terabyte disks are fun
<lifeless> hpa?
<TheMuso> lifeless: since the closest problem I have heard of had something to do with an hpa
<TheMuso> host protected aread
<TheMuso> area
<lifeless> how can I tell
<TheMuso> I *think* dmesg states something about it
<TheMuso> dmraid has bugs filed against it to do with hpas.
 * TheMuso looks
<TheMuso> hrm ok no bugs indicating hpa problems, at least from the descriptions.
<TheMuso> summary even
<lifeless> I'm guessing its a real cylinder size thing or something
<lifeless> but fundamentally I have no idea, haven't written disk level code in 13 years
<TheMuso> Right
<lifeless> what I want to do is get a solid enough patch you'll apply it :)
<TheMuso> Well, looking at the isw header, it only checks one location for the data, which is what makes me think its an hpa. Is it thesame on both disks?
<lifeless> so that when karmic comes out I get to upgrade without building a package in-situ during the install
<TheMuso> the same location that is
<lifeless> yes, the patch in the bug was sufficient to let both disks be found and the mirrored drive activate
<TheMuso> hrm ok
<lifeless> the disks are identical
<lifeless> my wintendo blew up on saturday, this is a replacement.
<TheMuso> right
<lifeless> I'm hoping linux gaming is sufficiently far along that I won't actually *need* windows on it. particularly as its arse.
<TheMuso> At this point, I am not really sure what it could be, since upstream doesn't always appear to be very upfront about changes to bits and pieces like this.
<lifeless> by upstream you mean intel themselves?
<TheMuso> And since intel wrote the code to the isw data recognition...
<lifeless> so
<TheMuso> lifeless: the redhat person who works on dmraid and intel
<lifeless> TheMuso: ah k.
<lifeless> so heres what I propose
<lifeless> I fiddle around once I have an installed system and get a version that does di->size-2115*512
<lifeless> or something like that
<lifeless> you apply the patch as its now 'generic' :P, we send it upstream and see what they say.
<TheMuso> ok thats a start. In the meantime, I'm going to poke upstrea mabout this.
<lifeless> and I'll gather any data people ask for happily.
<TheMuso> ok great
 * TheMuso sighs, dmraid cvs from upstrea has not been updated since last ear or there abouts.
<TheMuso> Getting patches for this piece of crap is like finding a needle in a haystack.
<lifeless> it hurts your fingers and makes you bleed?
<TheMuso> lifeless: something like that. It seems that mdadm will eventually take over dmraid metadata manaemet however.
<TheMuso> management
<lifeless> that would be nice
<lifeless> As long as it works :)
<TheMuso> lifeless: one thing you could do, is when you have a dmraid binary that can actually read the metadata, if you could use the dmraid -rD command to make a dump of the metadata I can send upstream for analysis, that would be useful.
<lifeless> I fully expect the occasional world of pain with this.
<lifeless> sure,  I'll do that now
<TheMuso> thanks
<lifeless> is tat the dmraid.isw dir ?
<TheMuso> afaik it dumps a few files in the current dir, but if it makes subdirs then its likely in there. There should be several files.
<TheMuso> lifeless: what RAID level?
<lifeless> dmaird -rD =attached to the bug report. raid 1
<TheMuso> thanks
<lifeless> argh, ubiquity fail
<TheMuso> ubiquity+dmraid is not tested, which is why dmraid is not on the live CD.
<lifeless> grub failed
<TheMuso> ah ok, thats not so bad.
<lifeless> it would be nice to be told that directly.
<TheMuso> lifeless: ok I've emailed the dmraid list, and will keep you posted via the bug report.
<lifeless> cool, thanks!
<TheMuso> lifeless: np thanks for bringnig it to my attention.
<lifeless> I kinda had to :)
<TheMuso> haha yeah
<lifeless> when I pinged I hadn't created a workaround yet, I was still grovelling through code and docs
<TheMuso> right
<lifeless> I really appreciate your jumping on it enthusiastically though.
<TheMuso> as much as I hate maintaining it in Ubuntu, its not so bad, since I work closely with the Debian maintainer, to the point where I have commit access to the vcs tree used for the packaging, and I have some of the hell spawn hardware myself. Even though I don't use it full time, its handy for testing.
<TheMuso> lifeless: is you don't succeed in installing Ubuntu the way you are now, you could attempt to get dmraid to create the metadata for you, using the original Ubuntu binaries of course. It would be interesting if the BIOS did or did not recognise it. If it did, you'd be out of the woods.
<lifeless> do device mapper raid1 arrays do load balancing?
<mib_44hfkp> how do i setup the resolution of my 19 inchs crt monitor ? i cant get more hten 640x420
<mib_44hfkp> how do i setup the resolution of my 19 inchs crt monitor ? i cant get more hten 640x480
<ion_> echo... echo... echo...
<mib_44hfkp> :)
<mib_44hfkp> sorry
<mib_44hfkp> can anybody help ?
<seb128> try #ubuntu for user questions
<mib_44hfkp> theres only proxy users
<mib_44hfkp> theres nbobody here
<mib_44hfkp> Xlib: extension "Generic Event Extension" missing on display ":0.0".
<mib_44hfkp> how do i fix it ?
<lifeless> mib_44hfkp: #ubuntu for support questions please
<thebloggu> maco, you there ?
<mib_44hfkp> cant join ubuntu because od proxie issues
<thebloggu> got the output of lshal | grep "Wireless" here http://pastebin.com/d1121261d on boot. it is doubled because i ran it twice :P. i was here yesterday because of the network manager applet lag
<persia> mib_44hfkp, That you can't connect to #ubuntu doesn't make this a support channel.  You just won't get help here.
<persia> You might try #ubuntu-CC where CC represents your country code: many of those channels have fewer restrictions, and most offer at least some support.
<mvo> doko: do you have any idea what this error might mean: https://bugs.edge.launchpad.net/ubuntu/+source/python-central/+bug/372126/comments/2 ?
<ubottu> Launchpad bug 372126 in python-central "package update-manager-core 1:0.111.9 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,New]
<thebloggu> My network manager applet takes a lot of time to recognize my network card (says 'network disabled') on boot and then takes a lof of time too to connect to my network. The whole proccess takes like above 5 minutes maybe. the lshal | grep "Wireless" output is here http://pastebin.com/d1121261d on boot. Using openbox with ubuntu jaunty updates.
<pitti> re
<pitti> Keybuk: sorry, went off for lunch and errands; shall I still join #udev?
<Keybuk> pitti: yup, it's a good place to hang out anyway for upstream discussions of this nature
<doko> mvo: corrupt files?
<mvo> doko: ok, I ask him for a fs check
<maco> thebloggu: i'm studying for a final that i have in a half hour. seriously, the people that know how network manager really works are in #nm
<thebloggu> maco, ok, thanks
<thebloggu> maco, btw, good luck
<maco> thebloggu: thanks
 * bigon has some diffuculty to see why some packages FTBFS on buildd and not on his machine with cowbuilder
<bigon> it seems that on buildd the modules for python2.6 are not moved
<bigon> automatically to dist-packages
<james_w> bigon: different versions of cdbs?
<Laney> do the buildds install b-d-i?
<directhex> Laney, yes. mono stuff uses b-d-i extensively
<Laney> I think I'll cut myself now
<soren> lifeless: Yes, device-mapper raid1 devices do load balancing.
<lifeless> soren: sweet, thanks
<lifeless> pitti: are you here by chance?
<pitti> hey lifeless
<lifeless> pitti: is there a way to get jockey to install the 32bit interface for the nvidia driver?
<pitti> lifeless: what's that?
<pitti> lifeless: I guess the answer is "no"
<lifeless> I'm not entirely sure
<lifeless> http://www.cedega.com/forums/viewtopic.php?t=10281
<lifeless> ^ read that, briefly
<lifeless> (its short)
<pitti> lifeless: that sounds pretty crazy
<kim_> Hi, I'm wondering how to get involved in ubuntu?
<pitti> on a 64 bit installation you should use the 64 bit driver..
<lifeless> pitti: I'm pretty sure what it is is a 32lib libdri2
<lifeless> or some such thing
<mnemo> kim_: ask "dholbach" here on IRC, he has a lot of good material on getting started with ubuntu development
<pitti> lifeless: right, that might be; but I don't think we build those :/
<pitti> lifeless: tseliot is our nvidia driver master, he might know more about it
<lifeless> thanks
<lifeless> tseliot: ^
<dholbach> kim_: if you're interested in development and package maintenance, definitely: https://wiki.ubuntu.com/MOTU/GettingStarted - it links to all the important documents
<lifeless> tseliot: I'd like to get to the point of filing a useful bug somewhere about this
<jelmer> Riddell: hi
<kim_> Thanks to both of you :)
<madduck> does ubuntu use postfix as default mta?
<kim_> I'll check it out and then I might be back later :)
<kim_> Bye for now
<lifeless> for now, 1am, crash()
<tseliot> lifeless: the 32bit libraries are already installed by the nvidia driver
<lifeless> tseliot: oh good timing
<tseliot> lifeless: ia32-libs doesn't contain the 32bit libraries for nvidia
<lifeless> tseliot: so cedega wants ia32-libs for other reasons
<LaserJock> Keybuk: fastest meeting minutes evar!
<lifeless> tseliot: and - hah - its detecting all good now. Sorry for the noise.
<tseliot> lifeless: np
<RainCT> Uhm.. How can I know why a new package was rejected? The mail doesn't neither state a reason nor who rejected it
<Keybuk> LaserJock: heh, I always write meeting notes as I go along
<cjwatson> RainCT: you should have got a separate mail, or IRC comment, with a reason
<jdstrand> cjwatson: so, regarding archive reorg and -security. I read through ArchiveReorganisation* (quickly, so I might have missed something) and was curious how security maintenance would be expressed. obviously, now it is via seeds, and nijaba's (and your?) tool will help with LTS. but with archive reorg, there are two things I'm thinking of:
 * cjwatson glares at http://people.ubuntu.com/~ubuntu-archive/architecture-mismatches.txt
<cjwatson> new-binary-debian-universe has a lot to answer for
<kirkland> lool: do you experience https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/357630 with the jaunty ga iso's?
<jdstrand> 1. how easy will it be to determine if a package is supported. it would be nice if we could express that in current packaging/seeds/etc, but it could be an LP API query
<RainCT> cjwatson: I didn't, although perhaps it was send only to the packager (I only gave the 2nd -actually, 3th- ack and uploaded)
<cjwatson> RainCT: I think it would be normal (albeit not ideal) for it to be sent only to the packager
<jdstrand> 2. it seems we'll need to be careful about things possibly 'slipping in' to a maintained status (eg, through a package set)
<cjwatson> RainCT: I've had a bug open about allowing us to specify a reason in the rejection mail for about three years
<cjwatson> jdstrand: 1. it'll appear in a field in the Packages file
<cjwatson> jdstrand: 2. to precisely the same extent as we need to be careful about things slipping into main, I think?
<jdstrand> cjwatson: re 1> excellent
<jdstrand> cjwatson: re 2> yes, but I wasn't sure if part of this would become 'this package set is officially supported' as opposed to 'this package is officially supported'. the former could be problematic. if that is not part of the design, then no problem
<RainCT> cjwatson: I see. Thanks for the info.
<cjwatson> jdstrand: I believe it will be the former, but isn't that the same as saying that main is officially supported?
<cjwatson> jdstrand: certainly archive admins would need to be careful about adding things to that set, the same way they're careful about adding things to main
<cjwatson> s/that set/those sets/
<jdstrand> cjwatson: I think I see my confusion-- just because a person has upload rights to a particular package set, that doesn't mean that the person can add or remove packages from the set (I thought it did)
<cjwatson> jdstrand: it's just the same as it is today, in a sense
<cjwatson> jdstrand: any developer can ask for packages to be moved back and forward between main and universe, and their opinions are given a high weighting, but only the archive team can actually make that change
<jdstrand> cjwatson: ok, that makes sense. there will just be way more components than those we have now. some will be officially maintained, and some not. I suppose there will be some tool to easily tell what package set is officially maintained as well
<jdstrand> (for archive admins mostly)
<cjwatson> jdstrand: s/tool/list/ I think
<jdstrand> cjwatson: cool. thanks for the info :)
<cjwatson> it shouldn't be that long; the sets that we use for deciding which packages are maintained will essentially be the ones that correspond to seeds, rather than the little ones we use for convenience of granting small groups of people upload access to small numbers of packages
<soren> At this point in the release cycle, would it be kosher to upload an SRU directly to Jaunty and pocket-copy it to Jaunty? We usually require that patches live in the curent development release for a bit before putting them into -proposed, but are we really expecting more people to be running Karmic than jaunty-proposed at this point?
<soren> Erm... By "directly to jaunty" I of course mean "directly to jaunty-proposed".
<soren> And pocket-copy to Karmic.
<soren> Wow. That was difficult.
<cjwatson> soren: it's not encouraged, but it can be a reasonable thing to do, at the discretion of the SRU team
<soren> cjwatson: Ok. The bug in question is bug 359447.
<ubottu> Launchpad bug 359447 in kvm "kvm segfaults" [High,Triaged] https://launchpad.net/bugs/359447
<soren> cjwatson: What are the deciding factors?
<cjwatson> soren: gut feel :-) we'll probably say no after alpha 1 or so, once karmic is reasonably usable
<soren> cjwatson: Right. This is for today :)
<ScottK> soren: I thought the main reason for development release first was to ensure stuff didn't get forgotten and we hit a regression later, so 'development release first' need only be by however long it takes to upload the second time.
<cjwatson> ScottK: that too, although in cases such as this the SRU team member accepting it will typically open a karmic task on the bug
<cjwatson> which is also a reasonable way to ensure that it doesn't get forgotten
<soren> Right. We're in the fortunate situation that we can still just do a pocket-copy.
<soren> cjwatson: It's been a while since I've done this.. I, being a core-dev, can accept the Jaunty task, but I still need to subscribe ubuntu-sru and get an ok from them/you, right?
<soren> ...so accepting the Jaunty task means that the bug is considered severe enough to warrant an SRU, but ubuntu-sru ack's the actual debdiff, I suppose. YEs, that makes sense.
<MacSlow> bryce, hey there
<MacSlow> bryce, do you happen to maintain a list of KMS-aware xorg-video-drivers on the ubuntu wiki?
<amitk> MacSlow: there is only one driver that really works ATM, the -intel. -ati is WIP
<MacSlow> amitk, ok... thanks that's about what matches my experience
<MacSlow> amitk, so I'm not missing any new developments on that front
<amitk> MacSlow: not really, rtg did enabled support for KMS in the Karmic kernels on the last upload. You can pass a commandline option to grub to enable it.
<MacSlow> amitk, atm I'm using a unpatch mainline/upstream kernel with karmic
<MacSlow> amitk, I mainly have issues with getting my initrd recreated in a way so that fbcon and i915 are loaded _before_ plymouth starts
<cjwatson> soren: you don't need an ack before upload unless it's going to take a long time to prepare and you think you might want to avoid doing the work if it might just be rejected anyway
<cjwatson> soren: you should still subscribe ubuntu-sru, but normally it's OK for the processing to be done in the queue
<soren> cjwatson: Cool, thanks.
<cjwatson> meep, http://people.ubuntu.com/~ubuntu-archive/testing/karmic_probs.html doesn't look good all of a sudden
<Lazhur> pitti, hi, I am currently need some assistant to restart the build process for libg3d. it failed on different architectures due to some missing indirect dependencies at the moment of the build (see LP: #372236). please correct me if I misunderstood the BuildDaemon section in the ubuntu wiki
<pitti> Lazhur: you want the builds to be retried, i. e. they should succeed now?
<kees> NCommander: say, can you make sure to follow https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines for future patches?  I've added tags to your shadow patch now.
<Lazhur> pitti: hm, i think i have missed something. let me check something first
<Lazhur> pitti: a quick check on packages.ubuntu.com looks good, but I am not quite sure why the dependencies couldn't be resolved as old versions of the packages should have been available on amd64 and co.
<Lazhur> ("old" versions == versions which are new enough to resolv the dependency, but aren't the newest available)
<pitti> Lazhur: looks like temporary arch all:/arch any desync
<pitti> Lazhur: retried
<Lazhur> ok, big thanks :)
<cjwatson> libselinux1 | 2.0.65-5build1 |        karmic | amd64, hppa, lpia, powerpc
<cjwatson> libselinux1 |   2.0.71-1 | karmic/universe | armel, i386, ia64, sparc
<cjwatson> this really isn't clever
<pitti> how can this happen?
<cjwatson> I'm going to flip the --no-override default on new-binary-debian-universe; I'm sure it's what's causing a lot of this
<cjwatson> the libselinux-ruby1.8 binary is new in karmic, so it seems a fair bet that new-binary-debian-universe was used
<cjwatson> and bits of libtool in universe too
 * cjwatson runs around behind whoever it is, trying to repair the archive ...
<maxb> Is there a plan on unwedging the i386 and lpia buildds currently wedged on sysvbanner builds?
<pitti> maxb: I pinged elmo and infinity about it
<maxb> ok, it's on someones todo list, good
<RainCT> What's the policy for syncing a *new* package from Debian multimedia? Let it go through REVU?
<ScottK> slangasek: Do you have a moment to discuss your spec on release synchronization with Debian?
<slangasek> ScottK: hmm, ok
<slangasek> (N.B.: the fact that there's a spec on this, which is mine, may be news to me :)
<ScottK> I may misremember.
<james_w> slangasek: I've seen it too :-)
<ScottK> I'm also suffering from Hotel internet this week.
<ScottK> slangasek: I'll just assume it's you for the moment and look it up later.
<slangasek> ScottK: it's entirely likely that such a thing would be assigned to me - I just don't remember having seen it yet. :)
<ScottK> Anyway, my thought is that what ought to be synchronized isn't the releases, but the freezes.
<ScottK> I think it Ubuntu DIF and Debian release freeze were aligned, that would be the point of maximum benifit.
<slangasek> hmm
<slangasek> it seems to me that having DIF well after Debian's release freeze is better, because it means getting the extra, release-critical fixes from Debian in with no extra work
<ScottK> Perhaps
<ScottK> Regardless of the ideal alignment point, I think it's the freezes that need to be aligned, not the release dates.
<ScottK> https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-lts-debian-release-coordination btw
<slangasek> alternatively, and this was something that had already been discussed for jaunty, we could run extra package sync runs against testing well past DIF...
<ScottK> I could see that.
<slangasek> IME, there is a lot of stuff being crammed into Debian immediately before the release freeze, that then takes a while to shake out - so aligning the freezes also wouldn't necessarily help for getting extra stabilization for the LTS?
<james_w> given the relative lengths of the freezes in the past having them un-aligned would mean that we would end up with different upstream versions of some important packages
<james_w> e.g. kernel
<james_w> is dato going to be at UDS by any chance?
<slangasek> not that I'm aware
<slangasek> good point, re: kernel
<slangasek> though that's a package we don't share with Debian anyway
<slangasek> actually, it may has the same implication for GNOME (and possibly KDE), which is more significant
<slangasek> wow
<slangasek> line edit fail
<slangasek> s/may has/may have/
<all_is_fair> question
<all_is_fair> after yesterdays updates.  I lost all networking and wireless support... any ideas?
<all_is_fair> running a HP Laptop
<all_is_fair> no takers?
<Pici> all_is_fair: This isn't a support channel, try #ubuntu
<all_is_fair> I did
<all_is_fair> it doesn't work
<NCommander> kees, ECONTEXTNEEDED; which shadow patch?
<kees> NCommander: password expiry on arm in 1970. though it looks like upstream already took it
<NCommander> pitti, you around?
<cjwatson> Keybuk: if we're building libblkid from util-linux now, could you stop the e2fsprogs source building it, otherwise the next upload will probably fail? also, libblkid1-dbg is still built from e2fsprogs (as far as the archive knows ...) right now and is therefore uninstallable - I don't know whether it should be built from util-linux, or just removed
<cjwatson> probably just removed if there's no need for a separate debug pass
<NCommander> cjwatson, can I get your opinion on https://bugs.edge.launchpad.net/ubuntu/+source/bluez/+bug/327284? (I've gotten requests for a bluez backport, which brought this bug to my attention). I've been checking bluez's git repo, and there are a *lot* of commits involving fixing bluetooth headphones (to the point I'm not sure I can isolate the commit(s) that fix it in a sane matter). On the other hand, I'm not sure we could sanely release
<NCommander> a new upstream version via SRU to fix this issue ...
<ubottu> Ubuntu bug 327284 in pulseaudio "[Jaunty Alpha4] Bluetooth Headset pairs but freezes the system when used" [Undecided,In progress]
<cjwatson> I've got no problem with a backport there - if nothing else it would make it easier to analyse whether it really does fix the problems for most people
<NCommander> cjwatson, should I prep an SRU for this then?
<cjwatson> NCommander: err, I said a backport not an SRU
<cjwatson> I can't say I'm immediately comfortable with an SRU that people don't understand well enough to unpick the commits
<NCommander> cjwatson, indeed, the package is a rather twisty set of commits (there are about 50 or so between the two releases :-/)
<dtchen> NCommander: please note that to fix the BT interaction with PA, one needs karmic's PA and alsa-lib, too.
<dtchen> NCommander: (PA -> PulseAudio)
<NCommander> dtchen, fun :-/ (backporting PA is NOT my idea of fun; I don't want a repeat of the flash backport)
<dtchen> NCommander: luckily, a backport. Also, jaunty's PA is so outdated that a backport isn't terribly likely to regress.
<NCommander> dtchen, what do you recommend I do? (I can ACK the backport, but unless an audio guy gives it a ruberstamp, I'm not sure I want to do so)
<dtchen> NCommander: you'll want to backport all three pieces (alsa-lib, pulseaudio, and bluez)
<NCommander> oh yay
<NCommander> alsa
<NCommander> can I start running now :-)
<NCommander> dtchen, if you feel like putting your two cents on the backporting request, I'll ack it if you think its sane
<dtchen> sure, i'll look in a bit
<NCommander> dtchen, np
<cjwatson> seb128: do you know why bug 370366 apparently didn't show up in jaunty (or at least people seem to have started reporting it like mad on karmic)? looking at the source it indeed only seems to have entries for up to 8.04
<ubottu> Launchpad bug 370366 in system-tools-backends "[Karmic] Time and Date - platform not supported" [Undecided,Confirmed] https://launchpad.net/bugs/370366
<cjwatson> seb128: is this a case where we should add an item to NewReleaseCycleProcess to update the list for each new release/
<cjwatson> ?
<seb128> no, I don't know but I don't get the issue here on jaunty
<seb128> seems a good idea
<seb128> ideally we could deprecate gnome-system-tools at some point but we still don't have an users-admin equivalent so until there ...
<cjwatson> ok, I've added a note to NRCP
<seb128> thanks
<seb128> that might be fixed when we sync on debian
<seb128> I think they dropped the check there to avoid similar issues recently, I've read a commit about that
<cjwatson> can I consider you on top of this bug and close the window in my browser? :)
<seb128> I'm amazed we already have people filing bugs about karmic ;-)
<seb128> cjwatson: yes
<cjwatson> amazed? I'm scared
<cjwatson> thanks
<seb128> well, let's say I'm surprised that users dist upgraded so early yeah
<cjwatson> pgraner: do you know if linux-meta is going to be updated to 2.6.30 in karmic soon?
 * NCommander is getting annoyed that Launchpad keeps 502ing
<pgraner> cjwatson: it should have been already, I'll pester rtg
<cjwatson> ta
#ubuntu-devel 2009-05-06
<Kano> hi,did you patch busybox in order to boot from ext4?
<MattJ> http://paste.ubuntu.com/165234/
<MattJ> Anyone an idea of what might be going wrong?
<andersk> Maybe your pbuilder chroot is missing universe?
<MattJ> Any idea how to add/check that? :)
<MattJ> I've had pbuilder working before, and I think I did exactly the same as last time
<andersk> `pbuilder --login` might be the easiest way.
<MattJ> libidn11-dev is in main
<MattJ> Ah
<andersk> txt2man is not.
<MattJ> Is there something I can do to make it persist? Changes seem to be lost as soon as I log out
<MattJ> I guess I should go find some pbuilder manual :)
<MattJ> I was following the packaging guide on the wiki
<Hobbsee> use --save-after-login
<Hobbsee> !pbuilder
<ubottu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<MattJ> Thanks
<MattJ> andersk: Looks like you were right, thanks :)
<pedahzur> Hi!  Is there a similar kubuntu-devel list, or is it all done on this channel?
<Hobbsee> pedahzur: sure, #kubuntu-devel
<Hobbsee> and there's a kubuntu devel mailing list, in the same place as the ubuntu devel list
<pedahzur> Hobbsee: Thanks...for some reason it didn't come up when I listed channels.  I should have just tried to join it. Sorry for the noise.
<Hobbsee> pedahzur: no problem.  good luck!
<pedahzur> Thanks!
<the_dark_warrio> What is the Image Magick package for ubuntu?
<TonyTheTiger> hello is this channel for development of ubuntu?
<Pici> TonyTheTiger: yes.
<Hobbsee> the_dark_warrio: apt-cache show imagemagick
<TonyTheTiger> I am interested in writing a driver for a device i have, I dont mind taking time to learn how to do it.
<the_dark_warrio> Hobbsee: Sorry, I'm looking for the dev packages.. I tried installing libmagick-dev, libmagick++-dev, libmagic-dev, etc. But everytime I install a new lib, I get another error trying to compile the code
<TonyTheTiger> is there a channel for driver development for ubuntu?
<Hobbsee> the_dark_warrio: i don't know, you'd have to give a pastebin of the errors
<the_dark_warrio> Hobbsee: I'm getting help on Inkscape channel, I will see if they know what is the bug
<Hobbsee> the_dark_warrio: OK, cool.  They'd probably know better anyway
<the_dark_warrio> Hobbsee: thanks, I think I got it working now
<Hobbsee> the_dark_warrio: hurrah!
<the_dark_warrio> Hobbsee: ;) cia!
<calc> can i get someone to process libbase-openoffice.org it is a new package that has built
<calc> Hobbsee: do you have access for that? :)
<calc> ooo 3.1.0~rc2-1ubuntu1 in process of uploading now :)
<jdong> shiny!
<jdong> will there be a PPA build?
<calc> yea for h/i/j
<calc> now i just have to upload around 600MB over my crap dsl
<TheMuso> ouch
<nixternal> dput-torrent :p
 * calc wished he had access to somewhere will really good upload speed for times like this
 * nixternal has 6mb up
<calc> i have 512k :\
<nixternal> though you can't tell when doing dput
<nixternal> ya, 512 wouldn't cut it for me after getting used to 6mb
<StevenK> calc: Get a VPS and rsync your uploads to it?
<StevenK> % sudo rm -f /dev/sdb
 * StevenK twitches a little
<calc> StevenK: well i do upload to a server before dput but it still takes forever, i guess if i did all my building on a remote server it would be faster but then i would have to download any time i needed to test the packages
 * calc just needs to move somewhere with fios
<StevenK> calc: If your downstream connection is much faster, that sounds worthwhile
<calc> well downstream is only 3M so not too much better
<StevenK> calc: Find a better wet string?
<Amaranth> hahahaha
<calc> i'm about 800ft too far away to get 18/1
<Amaranth> ouch
<calc> i had faster internet than this 9 years ago :\
<calc> back then i had 8/1 dsl
<Amaranth> i've got 5/0.5
<StevenK> Mine is roughly 6/256k
<Amaranth> I used to have 3/256k so I'm moving up
<Keybuk> cjwatson: heh, forgot to upload ;)
<pitti> Good morning
<pitti> NCommander: hi
<NCommander> hey pitti, what's up?
<pitti> NCommander: you pung me over night
<TonyTheTiger> Hello guys how hard is it to write a driver for a device? (assuming I have programming background, but no experience in this topic)
<NCommander> pitti, I think I was curious if I needed something spnsored but I don't remember
<calc> pitti: can you approve libbase-openoffice.org (its stuck at new)
<TonyTheTiger> Where can I view the source code to a driver?
<maxb> i386 buildd has caught up :-)
<lifeless> maxb: :)
<lifeless> maxb: are you still contributing to cygwin?
<pitti> TonyTheTiger: most device drivers are in the linux kernel nowadays (you can browse it in gitweb, or apt-get source linux); but there are all kinds of other drivers around (such as libgphoto for PtP cameras) which live in userspace; you have to be more concrete
<maxb> lifeless: No, I fully extricated myself from Windows a while back
<lifeless> I appear to have finally done that today
<TonyTheTiger> pitti, I want to get my controller supported in ubuntu so I thought Ill go ahead and add support for it myself. Sick and tired of people tell me "do it yourself".
<calc> ok in about 5 hours all 4 copies of OOo should magically appear, the three in the ppa and in karmic
 * calc is headed to bed now
<YokoZar> "All right here's a weird "bug" for you, if you want to call it that. The notifications cause my clock radio, which is about 5 feet away from my tower, to emit an audible vibration and buzzing noise. "
<pwnguin> hahahaha
<savvas> is it usb connected or wireless :p
<dholbach> good morning
<smb> Anybody knows by heart what method/config normally should start metacity and gnome-panel? After playing around with the desktop-switcher this does not happen automatically...
<pitti> smb: gnome-session usually starts those through some .desktop files; seb128 would know more details
<pitti> smb: ah, nevermind
<pitti> smb: it's a gconf setting in gnome-session, /desktop/gnome/session/required_components_list
<pitti>          <default>[windowmanager,panel,filemanager]</default>
<seb128> right
<seb128> the base composents are in gconf keys
<seb128> autostart is for everything else
<smb> Hm, I thought I saw those being there...
<smb> seb128, Looking into the gconf-editor I find those keys. But it does not seem to happen. Any log files I might look into?
<seb128> what did you change to break it ?
<seb128> does it work for an another use on your box ?
<smb> repeatedly using the desktop-switcher to go from the unr desktop to the standard and back
<smb> seb128, let me add one and try
<seb128> you can use the guest session to try
<seb128> njpatel: ^ what is that desktop switcher doing?
<seb128> it seems smb managed to unset required gconf keys by using it
<njpatel> seb128: apart from screwing up some peoples desktops in it's current version in jaunty, it switches from netbook mode to classic mode (normal ubuntu look)
<njpatel> seb128: I've already fixed the bug, and StevenK was going to help with an SRU
<smb> njpatel, So it is a known "feature" then? :)
<njpatel> (i've fixed it in a way that it repairs existing breakage too)
<njpatel> smb: unfortunately. Couldn't get it in before release
<njpatel> i hope we can get an sru soon
 * njpatel hasn't done sru before, so any help would be appreciated
<pwnguin> got the bug number handy?
<seb128> njpatel: can you explain what to do change to manually fix it?
<StevenK> njpatel: Step one: Fix it in Karmic
<smb> Just was about to ask
<njpatel> https://bugs.edge.launchpad.net/desktop-switcher/+bug/349519
<ubottu> Ubuntu bug 349519 in desktop-switcher "Switch Desktop Mode corrupted settings" [Undecided,Fix committed]
<njpatel> seb128: pwnguin ^
<njpatel> StevenK: I've already made a release of desktop-switcher with the bug fixed, could we get that into karmic?
<StevenK> njpatel: It's on LP?
<pwnguin> heh
<njpatel> StevenK: yep,it should be
<StevenK> njpatel: Certainly, I'll do it tomorrow.
<pwnguin> is stevenK still allergic to lp?
<njpatel> StevenK: thanks!
<StevenK> I was allergic?
<pwnguin> perhaps my memory is foggy
<pwnguin> it is 3am here
<smb> njpatel, Thanks for the link. Looking at the runes now
<njpatel> awesome, thanks
<pwnguin> this raises a question for me
<pwnguin> if a bug is known upstream and affects ubuntu
<pwnguin> hmm. i should find, read and then quote what i saw earlier
<pwnguin> rather than attempt to do anything from memory right now
<StevenK> njpatel: Doing it now, since ... I don't know :-P
<njpatel> :)
<pwnguin> ""
<pwnguin> thanks for the report, but there's no need to open the bug on Ubuntu if there's already one on the upstream bug tracker, it only creates extra work for developers and triagers, thanks.
<pwnguin> how does that mesh with the SRU process?
<StevenK> It should be tracked in Ubuntu Karmic and Ubuntu Jaunty for the SRU process
<pwnguin> https://bugs.launchpad.net/ubuntu/+source/evolution-mapi/+bug/351493
<ubottu> Ubuntu bug 351493 in evolution "Evolution mapi plugin uses a lot of memory" [Unknown,Confirmed]
<pwnguin> i guess i dont understand what the triager is asking for on this bug
<pwnguin> dont report bugs in LP if they're already upstream in bugzilla?
<StevenK> njpatel: I'm going to twiddle that bug to add a desktop-switcher task for Karmic and Jaunty.
<StevenK> njpatel: The Karmic task will get closed after I upload
<njpatel> okay, thanks. and I'll hassle seb128 later on today :)
<maxb> Well, there's no real point reporting to LP if it's already upstream, *unless* it's for the specific purpose of nominating for SRU
<seb128> pwnguin: there is no need to report upstream bugs in launchpad if they are already known upstream yes
<StevenK> njpatel: Uploading
<StevenK> s/ing/ed/
<smb> njpatel, cool, manually fixed it here. thanks
<cjwatson> pitti: would you mind if I disabled pkgsanitychecks for udebs? http://launchpadlibrarian.net/26375427/buildlog_ubuntu-karmic-i386.rootskel-gtk_1.15ubuntu1_FAILEDTOBUILD.txt.gz is an interesting build failure - the udeb just installs a /usr/local/etc symlink to work around some problem elsewhere
<pitti> cjwatson: no problem at all
<cjwatson> pitti: while this should probably be dealt with so it doesn't need to do that, none of the checks in pkgsanitychecks really seem all that important for udebs; it's not as though it's important to provide the sysadmin with an area where his local changes will be preserved :-)
<pitti> exactly
<cjwatson> (I've uploaded rootskel-gtk with NO_PKG_MANGLE=1 for now, but ...)
<pitti> I think udebs just weren't taken into consideration when this was written
<cjwatson> this is the first time I've noticed it failing
<cjwatson> is there a bzr branch for pkgbinarymangler?
<pitti> no, this isn't in bzr
<cjwatson> ok
<pitti> Keybuk: \o/ system-tools-backends finally dropped its init script
<pitti> cjwatson: intrepid-proposed doesn't have a matching d-i for the -14 kernel; how important is it to be in sync?
<pitti> cjwatson: the kernel team asked me to move the -proposed kernel to -updates, but I stalled it because I wasn't sure about the impact of this
<cjwatson> pitti: there's one in the queue ...
<cjwatson> the problem with them getting out of sync is that the installer images previously published in intrepid-updates will break
<cjwatson> it won't break people using the images in dists/intrepid/, but I know there are some people using the images in intrepid-updates, due to bug 293586 if nothing else
<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
<cjwatson> so I like to keep them in sync
<cjwatson> people would still have to download fresh installer images; there isn't much to be done about that
<pitti> cjwatson: ok, I'll accept the upload for that (thanks), and let it build, before I move it then
<pitti> cjwatson: also, I was told that after copy-package'ing d-i for hardy, there's some extra magic necessary to copy the netboot images; is that documented somewhere?
<pitti> I'm sure I did that once like a year ago, but I'm afraid I forgot it
<ebroder> pitti: for bug #362691, I guess I need to get approval from ubuntu-sru again?
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,In progress] https://launchpad.net/bugs/362691
<pitti> ebroder: haven't looked at the patch yet
<ebroder> Ah, ok. No worries, then
<pitti> ebroder: but usually, it's more a question of finding a sponsor to upload it
<cjwatson> pitti: documented on ArchiveAdministration now
<pitti> (someone from server team, preferably)
<pitti> cjwatson: thank you
<pitti> ebroder: commented now
<ebroder> pitti: The version numbering still needs to be consistent, right? So this would still be 3.3.0-1ubuntu9.2, not 3.3.0-1ubuntu9.1?
<pitti> ebroder: right, 9.1 got burned now
<Keybuk> pitti: sweet
<lamont> Keybuk: debian bug 527229
<ubottu> Debian bug 527229 in util-linux "The system time is NOT set correctly!" [Grave,Open] http://bugs.debian.org/527229
<soren> Why is it that /etc/localtime is a copy of a timezone file rather than a symlink to it? Is it to make sure things don't fall apart before /usr is mounted or is there more to it than that?
<cjwatson> soren: your hypothesis is correct
<ion_> Letâs get rid of /usr already. :-P
<directhex> ion_, http://gobolinux.org/?page=at_a_glance
<cjwatson> note how it has no users ;-)
<cjwatson> (to a first approximation)
<ion_> directhex: Capital letters in filenames are just bad as long as we have a case-sensitive filesystem. Or have they changed that as well?
<directhex> dunno
<directhex> but points for doing something different!
<directhex> not sure how LSB-compliant they are ;)
<Keybuk> lamont: oh?
<Keybuk> lamont: well, firstly I sent you a patch to use /dev/rtc0 rather than /dev/rtc <g>
<Keybuk> lamont: ask them what hwclock --debug --rtc=/dev/rtc0 says?
<soren> cjwatson: Lovely, thanks.
<Keybuk> seb128: how do I debug telepathy/jabber not working?
<Keybuk> it just says "Network error"
<Keybuk> but it doesn't even look like it's starting telepathy-gabble
<cjwatson> mvo: funky apt-ftparchive failure in http://launchpadlibrarian.net/26391921/buildlog_ubuntu-karmic-armel.debian-installer_20081029ubuntu35_FAILEDTOBUILD.txt.gz
<cjwatson> apt-ftparchive: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol: __sync_fetch_and_add_4
<mvo> cjwatson: sweet
<mvo> cjwatson: I have a look
<cjwatson> ta
<seb128> Keybuk: http://telepathy.freedesktop.org/wiki/Debugging
<cjwatson> slangasek: d-i is in place on i386 now; awaiting build on amd64
<ogra> oooh, there is an image build attempt from last night !
 * ogra didnt notice yet
<cjwatson> it won't be very useful
<ogra> the desktop one ?
<cjwatson> err, and where do you see this attempt? :)
<ogra> http://cdimage.ubuntu.com/ports/daily-live/20090506
<seb128> Keybuk: or ask Zdra or cassidy on the #ubuntu-desktop channel ;-)
<cjwatson> oh, a livefs build attempt
<cjwatson> http://cdimage.ubuntu.com/ports/daily-live/20090506 is pretty useless since it was still trying to build for jaunty
<ogra> yeah, i just see that
<ogra> old kernel and all
<cjwatson> I changed cdimage to default to karmic this morning
<ogra> ah
<ogra> ok, waiting for the explosion of the image with teh next build then :)
<cjwatson> mvo: FWIW, apt-xapian-index is currently uninstallable due to insufficient versions of python-apt and python-debian
<james_w> there is a sponsor request open for the python-debian merge
<mvo> cjwatson: thanks
<mvo> cjwatson: I take care of this too (the python-apt merge is almost ready)
<cjwatson> hyperair: I'm syncing nautilus-share, since it seems possible now and the older version causes livefs build problems (http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090506-i386.out)
<calc> hmm really uploading now, i forgot that i needed to adjust the at time due to uploading from a server not in my own timezone :-\
<hyperair> cjwatson: sure.
<xaaab> Hi. I've been using 8.04 for a long time without problems. but since my upgrade to 9.04, my xorg has a memory leak. when I leave it running for several hours it consumes almost 5 gb of ram and it consumes a lot of CPU time, although I'm not at my PC. is this a known issue? any fixes?
<pitti> xaaab: it certainly doesn't happen for everyone in that magnitude
<cjwatson> you might want to use xrestop to find out whether it's actually the X server's fault directly or whether it's due to some application leaking pixmaps into X
<soren> xrestop, eh?
 * soren apt-gets
 * xaaab just did
<xaaab> cjwatson, so... when I start xrestop, I just have to watch what the "total" column says and identify the culprit?
<cjwatson> it's a place to start to avoid embarrassingly claiming that it's the X server's fault when it's actually a particular application, anyway. I'm no expert so have no more help to offer :)
<calc> ok all of OOo is uploaded now and waiting to build
<mok0> Why does "Build-Depends: a | b" fail, even though b is available?
<mok0> Ah sbuild does that by default.
<slangasek> cjwatson: yippee :)
<directhex> mok0, s/by default/because it hates humans/
<directhex> mok0, as far as sbuild is concerned, anything after a | in a build-dep may as well be a comment
<mok0> directhex: it appears you can change its behaviour... but I can't get that to work either
<TheMuso> dtchen: we have 1.0.20 of alsa. I will check tomorrow to see if there are any kernelspace/userspace differences that need to be sorted before we can bump to 1.0.20.
<mok0> directhex: sbuild -d karmic --check-depends-algorithm=alternatives
<mok0> grrrrr
<directhex> mok0, convince all the debian buildd admins to make that happen and we'll talk
<mok0> directhex: sounds like you know something I don't
<cjwatson> we hacked it in Ubuntu to fall back to non-primary alternatives
<cjwatson> but that was precisely because we weren't Debian
<cjwatson> I mean, the fact that it's done in Ubuntu is not a demonstration that it should be done in Debian - we were doing it because in places we wanted to specifically avoid the primary alternative in Ubuntu
<mok0> cjwatson: it seems that doesn
<mok0> t work...
<cjwatson> in Debian, I fail to see why you wouldn't just put the alternative you want first!
<mok0> cjwatson: right
<cjwatson> mok0: used to, talk to infinity if you have a clear demonstration of the problem
<mok0> cjwatson: "infinity" is a nick, right? :-)
<ogra> heh
<cjwatson> yes
<ogra> for a person, yes
 * apw goes a bit mad ... anyone know what is driving OSD for volume?
<mok0> infinity: are you here?
<apw> (audio volume)
<ogra> apw, hal ?
<ogra> (just a guess)
<apw> i can't see it doing it ...
<apw> it seems to generate a hal event for the volume-up key
<ogra> dbus-monitor should show where its coming from
<ogra> apw, gnome-settings-daemon it seems
<ogra> at least for my system here
<apw> hrm ... obviously
<apw> thanks ogra
<slangasek> cjwatson: the libgnomecanvas2-dbg binary on amd64 is timestamped May 6 01:05, which seems to postdate your new-binary-debian-universe fix; strange
<cjwatson> any archive admin remember accepting libgnomecanvas/amd64?
<seb128> I didn't
 * pitti didn't
<directhex> wasn't me
<jdstrand> pitti: hi! can you look at the debdiff I attached in bug #224365? I'd like to upload, but wanted to make sure I didn't step on your toes. :)
<ubottu> Launchpad bug 224365 in cupsys "Apparmor prevents printing with cups-pdf" [Undecided,Triaged] https://launchpad.net/bugs/224365
<pitti> jdstrand: well, someone already uploaded an ubuntu specific package, so that's fine
<pitti> jdstrand: I'll commit the changes to bzr and sync them back from debian soon
<pitti> jdstrand: so please go ahead
<jdstrand> pitti: thanks! :)
<jdstrand> pitti: looking at this, would you prefer I upload based off of jaunty's ubuntu3?
<jdstrand> pitti: karmic still has the sync'd version from jaunty
<jdstrand> (ubuntu1)
<pitti> jdstrand: you can, but it really doesn't matter much; I'll thrash the ubuntu specific version soon anyway :)
<pitti> jdstrand: so in fact, if you don't consider it super-urgent, just add the debdiff to the bug and assign it to me
<pitti> and I'll get it done tomorrow
<jdstrand> pitti: no, it isn't super urgent. I'll assign it to you to reduce archive churn
<pitti> jdstrand: argh, I'm not going to apply that -- dac_override?
<pitti> jdstrand: that's precisely what I don't want to give to hacks like cups-pdf
<jdstrand> pitti: yeah, it is required when $HOME is 700
<pitti> *shrug* then don't set it to 700 :)
<pitti> 701 is fine as well, you also need it for public_html and such
<jdstrand> pitti: sure, but the problem is that the error message is totally cryptic for the end user
<pitti> jdstrand: I really wouldn't like to see cups-pdf getting more privs that it absolutely needs
<pitti> jdstrand: that should probably be improved then, yes
<jdstrand> pitti: basically, the user sees nothing in the ui
<jdstrand> pitti: and then in kern.log, has:
<jdstrand> kernel: [33228.304167] type=1503 audit(1241581234.818:31): operation="capable" name="dac_override" pid=4905 profile="/usr/lib/cups/backend/cups-pdf"
<jdstrand> to me, that doesn't scream 'you need to chmod 701 your directory' :)
<jdstrand> pitti: also, this isn't as simple as "don't chmod 700 your directory" because encrypted home directories via ecryptsfs do precisely that, and I think in karmic, kirkland is hoping to make this generally available
<jdstrand> of course, he could 701 it...
<pitti> jdstrand: can we just kill cups-pdf then? :-)
<kirkland> jdstrand: sorry, do i need to catchup with this conversation?
<jdstrand> pitti: well, interestinly enough, I tried to do that with an important user of mine (my wife) who has an application that doesn't use the gnome print UI, and had no way to print to pdf without cups-pdf. I tired to kill it locally...
<jdstrand> kirkland: no
<jdstrand> s/tired/tried/
<kirkland> jdstrand: ;-)
<jdstrand> pitti: regardless, I've assigned the bug to you per your request. Feel free to 'Invalid'ate if you think that is the best course (I certainly see your point of view)
<pitti> jdstrand: well, I'll ponder it
<pitti> jdstrand: if the apparmor rules restrict access to /home thoroughly, it's probalby not too bad
<pitti> but it would be able to write stuff into /etc or other places which teh profile doesn't cover
<lamont> slangasek: default-mta provides and exim4/postfix... le sigh, and yeah, I guess their argument wins
<lamont> sadly
<slangasek> which argument?
<slangasek> I think default-mta as a stand-alone package would be a little better for derivs
<jdstrand> pitti: I'm looking at the profile, and I don't see that you gave rw to anything in /etc, so I don't think that is a problem
<slangasek> mvo: hmm; using the update-manager in jaunty-updates, I just had a weird experience where update-manager wanted me to have 50MB free on /usr when the actual update only required 123KB additional space
<mvo> slangasek: 123kb addtional diskspace + 49mb downloaded debs? or were allt the debs downloaded already?
<mvo> slangasek: is it reproducable?
<slangasek> mvo: the .debs added up to < 5MB in size
<slangasek> dunno; I can try downgrading those packages later to see
<mvo> slangasek: right, sorry, I just checked the source and it has this as a safety buffer (min 50mb free) - I admit its a bit much
<slangasek> ah
<mvo> slangasek: its a leftover from the days when the free space checker would only check for release upgrades, then 50mb extra was ok, but for normal updates with just 4 pkgs its not
 * mvo adds it to his todo list
<slangasek> want a bug report? :)
<mvo> slangasek: feel free :)
<mvo> slangasek: otherwise I will file it to my postit notes :)
<slangasek> ok :)
<kees> asac: how do I get n-m TO manage my wired interface?  it seems to ignore it now
<asac> kees: guess you havent configured that in /etc/network/interfaces?
<kees> asac: in /etc/network/interfaces it says: auto eth6  and   iface eth6 inet dhcp
<kees> aarg
<asac> kees: so eth6 is the device you want to see managed by NM?
<kees> asac: right
<asac> kees: do you need it to be configured in there? otherwise just remove the eth6 entry from interfaces
<kees> asac: ah, no, don't need it in there.  removing it will fix n-m to use it again?
<asac> kees: yeah. NM runs in ifupdown-unmanaged mode by default. so everything configured in there will be ignored. two ways to fix this: a) remove that configureation (preferred), b) enable managed mode in /etc/NetworkManager/nm-system-settings.conf
<kees> ah-ha, yes, I see the "managed=false" setting now.  the semantics for what n-m keeps changing.  :)  thanks, I'll give "a)" a shot.
<asac> kees: that didnt change since it was introduced ;)
<jdstrand> pitti: ok, I played with dac_override a little bit to make sure my understanding is correct
<jdstrand> pitti: if dac_override is not set, then DAC is checked first. if DAC doesn't permit it, then no access. if DAC does allow it, then the profile is checked and access is determined there
<jdstrand> pitti: if dac_override is set, then DAC simply is not consulted and only the profile is checked
<pitti> jdstrand: right; root has DAC_OVERRIDE usually, which is what allows him to ignore file permissions
<pitti> so if we give that priv, the policy can't rely on DAC any more, and needs to be super-tight
<jdstrand> pitti: apparmor requires explicitly allowing access to files, so unless the profile is too loose to begin with, there shouldn't be a problem
<jdstrand> pitti: correct
<jdstrand> pitti: however, looking at the cups-pdf policy, it looks super-tight anyway
<jdstrand> pitti: so, I'll defer to your judgement, but adding dac_override seems ok to me based on the current profile
<pitti> jdstrand: I'll look at it again
<pitti> jdstrand: sorry, have to run to sports now
<jdstrand> pitti: np. have fun! :)
<pitti> jdstrand: thanks for the investigations!
<jdstrand> pitti: sure! this actually served as dual-purpose cause I'm going to be working on a test-apparmor.py script this week and dac_override will be part of the tests :)
<slangasek> mvo: do you have plans to merge python-apt soon?  (breaks apt-xapian-index)
<mvo> slangasek: yes, its almost ready
<calc> is there a lpia live cd somewhere?
<slangasek> mvo: cool, thanks
<chrisccoulson> if i propose to merge a bzr branch in to another one (say, my branch in to an ubuntu-core-dev branch), should i assign a reviewer to it? does anyone get notified of the merge proposal if i don't specify a reviewer?
<ScottK> Every core-dev gets notified.
<chrisccoulson> ScottK - thanks:)
<james_w> chrisccoulson: the default reviewer of an ubuntu-core-dev branch is ubuntu-core-dev which leads to a mail to ubuntu-devel@ now, so plenty of people see it
<james_w> however, we need to do better at having a list of outstanding requests, which is something I am working with the LP team on
<chrisccoulson> james_w - thanks. perhaps i would have been better off assigning a reviewer rather than spamming the whole list;)
<james_w> chrisccoulson: it makes sense if there is a particular person. It would be a bit like subscribing that person directly to a sponsorship bug instead of u-m-s, except that u-m-s doesn't cause a mail to ubuntu-devel@
<ScottK> james_w: I'm glad to hear you are working on this.  Thanks.
<james_w> np
<james_w> I'd like to have a better system that what we currently have
<james_w> it's just not that easy because we are slightly odd :-)
<ScottK> I think distro 'development' is different in many respects than upstream development and LP seems more focused on the latter use case than the former.
<james_w> yeah
<james_w> especially for merge proposals so far, as it wasn't available for distributions before
<james_w> they are keen to fix that, there just aren't obvious answers
<mweichert> hello, I'm trying to preseed a hardy installation. I want to slipstream all of the hardy updates on the cd so that after I finish the installation, I'm not left with 200+ packages to upgrade.
<mweichert> to do this, do I just replace /dists and /pool on the live cd with those that are in archive.ubuntu.com ?
<james_w> mweichert: nope, the live install doesn't install from debs
<james_w> you would need to build a new live environment with the updates
<mweichert> james_w, okay, in the squashfs image?
<mweichert> james_w, what's /dists and /pool for then?
<james_w> yeah
<james_w> extra packages that are available, but not actually installed
<mweichert> hmm, ok
<mweichert> james_w, so the installer just copies the squashfs to /target, is that right?
<james_w> not "just", no, but to a first approximation, yes
<mweichert> james_w, sorry - that was over-simplifying.. I guess what I'm trying to determine is that if I edit the squashfs by installing the debs I want, those debs will get installed on /target.
<mweichert> james_w, is that a safe assumption you think?
<james_w> I've no idea whether it will work, sorry
<MattJ> Hmm, does anyone know if it is possible to build for etch using the Ubuntu pbuilder?
<MattJ> The wiki suggests it should be, but I'm having problems
<james_w> it should be
<mweichert> james_w, okay, thanks for your help. I really appreciate it. I've been having a hard time trying to find this information.
<mweichert> james_w, to be sure though, you're certain that /pool just contains extras?
<james_w> mweichert: I guess there aren't enough debs in there to make a full system?
<ScottK> MattJ: Yes.  I do it all the time.
<MattJ> From: https://wiki.ubuntu.com/PbuilderHowto it says use: sudo DIST=etch pbuilder create, but the first line pbuilder prints is "Distribution is jaunty."
<james_w> if there were then you would only be able to use the half the space on the CD for the live environment.
<MattJ> ScottK: I'm using 8.04, could that be an issue?
<james_w> mweichert: #ubuntu-installer is the dedicated channel for this stuff
<ScottK> MattJ: I did it with that too, so I don't think so.
<MattJ> ScottK: I see: Failed getting release file http://gb.archive.ubuntu.com/ubuntu/dists/etch/Release
<MattJ> I tried --othermirror, but it seems to have no effect
<ScottK> MattJ: http://pastebin.com/f78072aa4 is the pbuilder wrapper script I use.  If you name that pbuilder-sid it should just work.
<MattJ> Hmm, I'll try it... thanks :)
<MattJ> ScottK: Excellent, it appears to be working :)
<ScottK> MattJ: Glad to hear it.
<calc> kees: can you process bug 372756 for me? pitti told me it didn't need a MIR
<ubottu> Launchpad bug 372756 in boost1.37 "please move to main from universe" [Undecided,New] https://launchpad.net/bugs/372756
<ScottK> Did we decide 1.37 is the target boost for Karmic?
<calc> ScottK: well we really need to be targeting 1.38 for Karmic but its FTBFS atm
<ScottK> Since Debian is planning on 1.38 for Squeeze, I wonder if it might be better.
<ScottK> Agreed.
<calc> and 1.35 also seems to cause other things to FTBFS if they attempt to use it due to gcc 4.4 (afaict)
<kees> calc: one sec...
<calc> kees: thanks
<kees> calc: approved
<calc> thanks :)
<kees> np
<calc> http://cdimage.ubuntu.com/daily-live/current/ <- is that actually karmic or are we doing new dailys of jaunty?
<james_w> karmic
<calc> probably the description needs updating then :)
<calc> and filenames, etc
<james_w> oh, maybe the ones there aren't karmic then
<james_w> there was a karmic CD build last night though
<slangasek> daily-live/current isn't karmic in any meaningful sense
<slangasek> we don't have successful livefs builds yet
 * calc wonders why ubuntu-mir doesn't also have archive access to do the promotions, heh
<calc> slangasek: so since 327756 is approved now... could you maybe promote it for me, please? 8-)
<slangasek> calc: wrong bug #?
<calc> er 372756
<slangasek> calc: anyway, the process is MIR approval -> reference the package from main -> ends up on component-mismatches -> ubuntu-archive cleans it up
<calc> the references from main is a package depending on it, or something else?
<slangasek> depends, build-depends, or seeded
<calc> ok, so yea OOo 3.1.0~rc2-1ubuntu1 already does that via build-depends
<calc> i somehow forgot to add that to bug report
<calc> added to the bug report
<james_w> calc: it's already on component-mismatches, it should get cleaned up next time an archive admin processes the list
<calc> ok
<bigon> http://launchpadlibrarian.net/26409322/buildlog_ubuntu-karmic-i386.telepathy-farsight_0.0.6-1_FAILEDTOBUILD.txt.gz << I know I've already asked but why this packages build cleanly inside a pbuilder?
<bigon> hahah
<bigon> obscÃ©dÃ© par la repression
<james_w> bigon: different versions of cdbs installed?
<bigon> oups wrong channel for the 2last sencence :p
<bigon> james_w: I don't think so
<NCommander> james_w, its also pkgbinmanagler doing something it shouldn't
<ajmitch> NCommander: it's nor very verbose about it
<NCommander> Hrm
<NCommander> bigon, which PPA is that package in?
<NCommander> Oh, thats a distro upload, isn't it :-P
<james_w> NCommander: what is pkgbinarymangler doing that it shouldn't?
<bigon> NCommander: yeah
<NCommander> james_w, I dunno, I'm going to try and reproduce with a buildd chroot and a normal pbuilder chroot
<james_w> bigon: do you have pkgbinarymangler installed in your pbuilder?
<NCommander> james_w, there are other pieces of voodoo in the chroots :-/
<bigon> james_w: I don't think so
<james_w> NCommander: yeah, but this seems to be a simple case of a file being installed in the wrong place and pkgsanitychecks complaining
<james_w> bigon: well, that's the reason then
<NCommander> james_w, I've *never* seen a build fail because of that before
<james_w> well, we fixed most of them
<NCommander> james_w, we should provide a set of instructions on how to reproduce buildd chroots
<james_w> true
<NCommander> (there is a lot of voodoo with the lpia especially)
<james_w> it needs autoreconfing
<james_w> that should fix it
 * NCommander continues to work on merges
<james_w> nope, that's not right
<NCommander> james_w, ?
<calc> can someone process a couple NEW packages for me (there is a long chain of build depends) - libloader-openoffice.org and libformula-openoffice.org
<DktrKranz> bigon, that's because python2.6 expects to find modules in dist-package, not site-packages and pkgbinarymangler rejects it
<bigon> DktrKranz: yeah but on my pbuilder without pkgbinarymangler I get an explicit message saying that the files inside the site-packages have been moved to dist-packages
<DktrKranz> bigon, weird. did you use python.mk macros?
<DktrKranz> $(call py_libdir, <python version>) and thelike
<bigon> http://pastebin.com/f7bc52325
<DktrKranz> it doesn't seem to use distutils, right?
<bigon> no autotools
 * DktrKranz tries to build it in a karmic pbuilder
<bigon> already done
<bigon> same result it works inside it
<slangasek> calc: will you be coordinating getting the other reverse-deps of boost1.35 transitioned, too, so we don't have to continue carrying that one?
<james_w> heh, it's some quoting weirdness
<james_w> bigon: it does $PYTHON -c "from distutils import sysconfig; print sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX')"
<james_w> which is supposed to return ${prefix}/lib/python2.6/dist-packages
<james_w> but returns site-packages instead
<bigon> mmm
<james_w> well, not quoting weirdness, but that confused my investigation
<james_w> will it want ${prefix} in the path, or is that supposed to be expanded in this path?
<bigon> I can confirm that inside my pbuilder it FTBFS with pkgbinarymangler installed
<james_w>         elif is_default_prefix and 'PYTHONUSERBASE' not in os.environ and 'real_prefix' not in sys.__dict__:
<james_w>             return os.path.join(libpython, "dist-packages")
<james_w>         else:
<james_w>             return os.path.join(libpython, "site-packages")
<james_w> in distutils
<BUGabundo> hi everyone
<rrp81> hi!
<BUGabundo> so todays backport-modules reverted all the good of rt2500 pci??
<BUGabundo> on jaunty
<james_w> so if you pass it /usr as the path, not '${prefix}' you get dist-packages, otherwise you get site-packages
<james_w> which seems to be what python wants
<BUGabundo> apw: ping
<rrp81> today's updates screwd up backport-modules, I can't update them or revert them
<rrp81> I need them for my rt2500 pci
<BUGabundo> rrp81: you can downgrade it.
<BUGabundo> just get the previous version from LP cache
<rrp81> no, i can't, it won't let me
<james_w> so telepathy-farsight trying to preserve '${prefix}' leads to the wrong path being used, and as distutils isn't used cdbs' disutils.mk can't clean it up
<james_w> bigon: does that make sense?
<BUGabundo> $ sudo dkpg -I linux.......deb
<bigon> james_w: I've not followed everything :o
<james_w> bigon: you have two easy options, either make it expand ${prefix} before passing it in there
<james_w> or add a mv in debian/rules (or something with .install) to fix it up
<james_w> I'm not clear on what the effects of the first will be given the fact that it is done that way currently
<bigon> james_w: yeah but without binpkgmangler the file are automagically moved
<james_w> by what?
<james_w> pkgbinarymangler is throwing it out at dpkg-deb time, so it's too late to move by then isn't it?
<james_w> I'm not sure that it interferes before
<bigon> let me check again
<calc> slangasek: i'm not really in platform (more or less) for the next 6 months
<slangasek> oh?
<slangasek> I guess I missed that memo
<calc> slangasek: moved to oem with doko and persia
<slangasek> ... but still dealing with OOo? :)
<calc> i have 20% time for OOo but i doubt that would be enough to do OOo and boost traisntion, not even enough to do bug triage really :\
<slangasek> ok
<calc> gah typing too fast to see my words leads to typos, heh
<BUGabundo> sorry to hear calc! I did a great job up until now
<calc> slangasek: but ideally we will be doing a transition from 1.35/1.37 to 1.38
<slangasek> ah
<calc> 1.38 currently FTBFS though :\
<calc> slangasek: aiui 1.37 is supposed to be removed from Debian sometime soon
<slangasek> hmm, ok
<slangasek> I'll have a look at the 1.38 ftbfs, then
<NCommander> calc, thats a nasty FTBFS :-/
<directhex> boost?
<calc> directhex: yea
<directhex> have fun. extra fun thanks to apps build-depending on specific versions of boost rather than the un-abi'd -dev packages
<BUGabundo> ok, what's boost?
<calc> directhex: iirc the un-abi'd version is 1.34
<calc> yea 1.34.1
<calc> BUGabundo: http://www.boost.org/
<directhex> calc, i'll bite: "why is the default (un-ABI'd version) neolithic?"
<dtchen> TheMuso: from a prelim glance, current git HEAD of linux-2.6 is nearly 1.0.20 without some quirks, but the core and mid-layer are identical
<calc> directhex: no idea
<calc> directhex: probably for historical reasons
<dtchen> TheMuso: i'm chasing a -plugins sig11 atm
<directhex> calc, historical raisins be damned, this is ubuntu, not debian!
<calc> directhex: it may be versioned for newer ones due to api changes (my guess anyway)
<calc> directhex: if is the case it explains why they didn't bother to fix it for 1.34 since the proper fix would be to have no libboost-dev at all
<slangasek> nono, the proper fix would be to have no libboost.* at all ;)
<directhex> slangasek, <partisan> oh dear, then no gnote. what a dreadful shame!
<mathiaz> slangasek: hm - IIUC there is a library transition (or something like that) currently hapening in debian wrt to the upload krb5 1.7 to unstable
<directhex> calc, that seems horribly broken to me - version the deps, fix the software
<mathiaz> slangasek: what does this mean for Ubuntu?
<mathiaz> slangasek: ie - I'd like to get krb5 1.7 synced in karmic.
<slangasek> mathiaz: should just require rebuilds, I think
<mathiaz> slangasek: IIUC the main point is that krb4 is dropped
<slangasek> yep
<mathiaz> slangasek: so - what should I do to get things moving? Ask a sync request and upload all necessary packages?
<slangasek> mathiaz: sounds right :)
<mathiaz> slangasek: should I test that all necessary packages build before asking for the sync to happen?
<mathiaz> slangasek: or ask for the sync and start uploading once the new krb5 is published?
<slangasek> mathiaz: the latter is fine
<mathiaz> slangasek: great - thanks. I'll go get the list of packages to rebuild :)
<directhex> what's the policy on upstream versions for gnome? gnome 2.28 seems to be coming out terribly close to release
<ajmitch> directhex: usually gnome releases at the same time as the beta release for ubuntu
<ajmitch> afaik there's a standing exception for getting new upstream releases of gnome in
<directhex> ajmitch, short version: will tomboy 1.0.0 (part of gnome 2.28) definitely be allowed in, and if so, is it worth making a 0ubuntu1 of the latest development release?
<ajmitch> directhex: ask an RM :)
<directhex> slangasek, i think he means you!
<slangasek> directhex: if tomboy is releasing on time with GNOME 2.28, then yes, please track its dev releases
<directhex> gotcha
<mathiaz> slangasek: hm - I'm not sure I completely understand how the libkrb53 is done in debian.
<mathiaz> slangasek: relevant changelog entries are 1.6.dfsg.4~beta1-7, 1.6.dfsg.4~beta1-8, 1.7dfsg~beta1-2 and 1.7dfsg~beta1-3
<mathiaz> slangasek: the last entry mentioned an change that will be reverted before end of may 2009.
<apachelogger> james_w: do you know if there is any script to create released branches of a given set of development branches (i.e. branch /ubuntu to /jaunty)?
<james_w> "bzr branch"? :-)
<slangasek> mathiaz: hmm, I'm quite confused by that last entry
<slangasek> may have been a no-op, really
#ubuntu-devel 2009-05-07
<mathiaz> slangasek: I don't think it's a no-op
<mathiaz> slangasek: http://git.debian.org/?p=pkg-k5-afs/debian-krb5.git
<mathiaz> slangasek: the last two commits show some version changes in debian/libgssapi-krb5-2.symbols, etc...
<slangasek> mathiaz: changes, yes; but if as stated there's nothing yet using the new symbols, then there's no need to relax the versioned dep...
<TheMuso> dtchen: hrm ok.
<mathiaz> slangasek: ok - I'm gonna ask the debian maintainer what's the purpose of the last change
<mathiaz> slangasek: may be we should go with 1.7dfsg~beta1-2 instead of 1.7dfsg~beta1-3
<andersk> My understanding is that it allows packages built against krb5 1.7dfsg~beta1-3 in unstable to migrate to testing before krb5 migrates to testing itself.
<andersk> Since this doesn't apply to Ubuntu and the change will be reverted in Debian by the end of the month, it may indeed be better to sync -2 rather than -3 (and prevent -3 from being synced automatically).
<slangasek> as best I can tell, the symbol versions in -3 are /correct/ (all these symbols are also provided by the libkrb53 we currently have)
<andersk> The Debian changelog mentions "new functionality", which I assume refers to new functionality in the existing symbols.
<slangasek> which is out of scope for symbol versioning anyway...
<andersk> So it is not in general the case that a package built against krb5 1.7 will work with libkrb53 1.6, even if the package uses only the existing symbols.
<andersk> This just happens to be the case for all packages currently in Debian.
<directhex> what's the current fashion for 0ubuntu1 upstream updates - a mahoosive debdiff, or a new diff.gz?
<andersk> BTW, you're aware that uploading krb5 1.7dfsg before all its rdeps are rebuilt against 1.6.dfsg.4~beta1-7 or higher will break those rdeps, right?
<Ampelbein> directhex: i usually attach diff.gz when it's a -0ubuntu1, debdiff only if we have the same base version in ubuntu as in debian.
<Ampelbein> also i use debdiff when merging
<james_w> directhex: diff.gz and pointer to the upstream tarball please
<james_w> some sponsors ask for .dsc as well
<james_w> the pointer can be in a watch file in the version currently in the archive, but I find that a bit more of a pain
<calc> what is the program that can tell you what nautilus thinks the file type is of a file?
<mathiaz> andersk: yes - the plan is to upload krb5 1.7 and then upload all relevant rdeps
<james_w> calc: "xdg-mime query filetype <file>"?
<andersk> Okay, as long as you're fine with temporarily making lots of Karmic packages uninstallable, skipping 1.6 should be okay.
<mathiaz> andersk: right - karmic is a development release and we're very early in the release cycle
<mathiaz> slangasek: ^^ I think that's ok in the current position in the release cycle
<slangasek> mathiaz: eh, what packages are going to be made uninstallable?
<slangasek> we do have an alpha release next week :)
<andersk> 270 of them. `aptitude search '~D^libkrb53$'`
<pochu> calc, james_w: I'd say gvfs-info, but am not sure
<james_w> sounds more likely
<slangasek> andersk: they're not going to be uninstallable immediately.  We don't remove old binary packages until the reverse-deps get rebuilt
<andersk> Well, right, they'll become uninstallable as soon as the first package depends on libkrb5-3, since you can't install the old libkrb53 along with the new libkrb5-3.
<slangasek> andersk: yes, they can; libkrb5-3 Replaces: libkrb53, but doesn't have a Conflicts: with it
<slangasek> so everything should work fine
<slangasek> mathiaz: ^^ so krb5 sync is no problem for the alpha
<andersk> Hmm, okay.  I didn't notice that.
<mathiaz> slangasek: ok - the remaining question is whether to sync -2 or -3
<slangasek> I think -3 is fine
<slangasek> (and -2 would have to be a fakesync)
<mathiaz> slangasek: ok - so the plan is: 1. ask for a sync of -3. 2. once -3 is built, upload new packages for all rdeps of libkrb53
<slangasek> yeppers
<mathiaz> slangasek: cool - thanks for your input on that issue :)
<slangasek> n/p :)
<hartmans> anders suggested I might want to comment on whether Ubuntu wants krb5 1.7~beta1-2 or -3.
<mathiaz> hartmans: hi - sure. Your input would be useful
<hartmans> -3 was uploaded only  to avoid autobuilders making the transition harder in Debian. -2 will give  more correct symbol versions
<hartmans> OTOH, -3 is relatively harmless as well, so it doesn't matter much
<mathiaz> hartmans: IIUC in a few weeks -4 will be uploaded with the symbol versions reverted to -2?
<hartmans> mathiaz: Correct.
<mathiaz> hartmans: ok. And packages built against -3 won't need to be rebuilt with -4?
<hartmans> mathiaz: I believe that is true for everything in Debian. If you have a package that uses some of the 1.7 extensions  to symbols that exist in 1.6, but uses no new 1.7 symbols, you will get incorrect dependencies generated. For ubuntu that's probably not actually an issue because you will never had had the 1.6 libraries with new names
<hartmans> Such a package would of course work provided that you had the 1.7 libs installed, but might produce strange results (although not a segfault) if you pulled the 1.6 packages that never appeared in Ubuntu
<mathiaz> hartmans: ok. So the easiest option for ubuntu is to use -3 so that ubuntu is kept in sync with debian.
<hartmans> mathiaz: that certainly is a sane thing to do
<mathiaz> Using -2 would require a fake sync and some manual work to get -4 in ubuntu once it's available in debian
<hartmans> Well, feel free to drop me e-mail or give me a call if you run into any questions about the krb5 package now or in the future. I don't currently happen to use Ubuntu much myself, although I've used it more in the past and may well again in the future, but I'm certainly happy to answer questions or coordinate
<mathiaz> hartmans: sure. Thanks for stopping by and giving your input on this.
<calc> doko: do you know why unixodbc-dev is not installable on armel even after depending on libltdl7-dev ?
<calc> gah launchpad is hosed its always giving me error screens :\
<orangey> hello all
<orangey> I'm trying to install martian-modem modules on jaunty, but I'm getting the following:
<orangey> mport.c:8:41: error: asm/page.h: No such file or directory
<orangey> how can I beat that?
<cody-somerville> orangey, Install linux header files
<orangey> cody-somerville: naturally, they are all already installed..
<orangey> then what?
<orangey> I've installed them
<orangey> then done make oldconfig in them
<orangey> I installed the source
<orangey> I followed : https://help.ubuntu.com/community/Kernel/Compile
<orangey> needless to say linux-kernel-devel doesn't appear to exist any more though
<StevenK> linux-libc-dev
<orangey> appears already installed or whatnot.
<orangey> anyhow, can somebody with the right setup maybe try?
<orangey> sudo apt-get source martian-modem
<orangey> then get into the dir and make
<calc> doko: is libgcj.spec missing on lpia, i got a build failure for OOo because gcj couldn't find that file on lpia
<calc> doko: or at least it claims that is why it failed
<calc> doko: hmm make that i think that is what it is saying
<calc> hmm maybe it was just aot-compile.py that broke somehow
<calc> whatever is wrong it worked fine on amd64 :\
<dholbach> good morning
<robert_ancell> dholbach: hello
<dholbach_> hiya robert_ancell
<dholbach_> how are you doing?
<robert_ancell> not bad.  Upgrading to Karmic currently so will be able to tell you in a few minutes :)
<dholbach> robert_ancell: enjoy :-)
<dholbach> robert_ancell: I'm still running it in a VM :)
<robert_ancell> i'm living life on the edge! (not enough space for the VM at the moment)
<dholbach> robert_ancell: I'll start collecting some money for a new harddrive for you :)
<robert_ancell> dholbach: I really just need to get around to resizing the windows partition on it - and you can never have enough space for VMs!
<robert_ancell> dholbach: where are you based?
<dholbach> Berlin, Germany
<robert_ancell> nice city, I look forward to going back sometime
<dholbach> we should pester Mark about having the next summer UDS in Berlin :)
<robert_ancell> +1 from me
<dholbach> woohoo!
<robert_ancell> (I think it's going to take a lot of pestering to get a UDS down under)
<StevenK> One has happened
<dholbach> we had one there... after hoary I think
<robert_ancell> StevenK: and that's why it will be hard to pester again I think :) Especially with the size of the company now
<StevenK> dholbach: Breezy's UDS was UDU
<dholbach> I wouldn't mind going to someplace in Asia - at least you guys down there probably wouldn't have to travel that far :)
<StevenK> (Ubuntu Down Under)
<dholbach> StevenK: so after hoary :)
<dholbach> StevenK: I was there
 * StevenK wasn't
<lifeless> dholbach: asia is very big :P
<dholbach> lifeless: that's why I said "probably" :)
<lifeless> dholbach: hell, spain nearly is asia :>
<robert_ancell> yeah asia would be good.  Could do Dubai as that's not too far from Europe
<dholbach> lifeless: you're exaggerating a fair bit my friend :)
<lifeless> dholbach: a tad ;)
<pitti> Good morning
<Hobbsee> morning pitti!
 * pitti hugs Hobbsee, good morning!
<Hobbsee> :)
<StevenK> Morning pitti
 * NCommander sighs
<dholbach> ArneGoetje: is ibus the way to go in the future?
<NCommander> hey pitti
<tkamppeter> pitti, can you have a look at bug 369850? Why does parport_pc not get loaded automatically any more?
<ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04" [High,New] https://launchpad.net/bugs/369850
<pitti> tkamppeter: it should, it has plenty of modaliases; I'll ask for some debugging
<geser> how detailed should a MIR for dh-ocaml (helper tools for maintaining OCaml-related Debian packages) be? it's needed to build ocaml
<pitti> geser: I'd say a bug report with the most important QA data is enough
<pitti> geser: it sounds trivial
<pitti> geser: don't waste time on a complete wiki page
<pitti> geser: so, security/i18n/etc. isn't an issue, just maintenance and pacakging standard
<geser> pitti: filed as bug 373149. Anything missing?
<ubottu> Launchpad bug 373149 in dh-ocaml "Move dh-ocaml to main" [Undecided,New] https://launchpad.net/bugs/373149
<pitti> geser: looks good to me
<pitti> yay, I managed to push a git branch to people.u.c., and it only took me 20 minutes until it worked
 * pitti *headdesk*
 * dholbach hugs pitti :)
<directhex> git's a git
<soren> pitti: Why not put it on kernel.ubuntu.com?
<soren> pitti: ...let's just say that you wouldn't be the first to put non-kernel-related git branches on there. :)
<pitti> soren: I don't have an account there
<pitti> soren: yes, I have a branch of udev-extras, whose trunk is on git.k.o.
<soren> pitti: Ah, ok.
<directhex> ember, i prepped a 0ubuntu1 for the latest development release of tomboy, hopefully that helps. looks like you've been the one touching that package lately
<pitti> gosh, and it still doesn't work properly
<pitti> this is just plain madness
 * pitti will just use format-patches
<ogra> cjwatson, is it deliberate that armel live images were not built today ? (i cant find a log under http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/)
<NCommander> ogra, I got a build failure when Xubuntu/armel tried to build; probably something gone wrong w/ the build environment :-/
<ogra> well, then there should be a log at least ... to me it looks like it wasnt attempted ... /me checks antimony directly
<ogra> oh, right, looks like there is no livefs on manoao
<NCommander> ogra, I can run the livefs build script and see what went boom
<NCommander> ogra, (I'm running it now, it takes about an hour on my Babbage to do a full run so I'll know then)
<Keybuk> /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
<Keybuk> ...
<Keybuk> I'm guessing there are some issues with the buildds today <g>
<pitti> ah, that's why everything is just blowing up here
<pitti> asm/ seems completely gone from linux-libc-dev
<Keybuk> yeah
<cjwatson> ogra: please don't stress about images
<cjwatson> ogra: we haven't got *anything* working for karmic image-wise yet
<cjwatson> ogra: expecting armel to be the first is ... optimistic!
<ogra> cjwatson, right, but i'm supposed to make 100% sure all mobile images are there for A1 ... sorry if i'm a PITA through checking and asking every day
<ogra> i wont push more but will still check
<cjwatson> feel free to check, just please don't nag about it. everything is already on the list.
<ogra> ok
<NCommander> cjwatson, I've built a few live rootfs's so hopefully when the scripts updated, it should all just work :-)
<cjwatson> what script updated how?
<NCommander> cjwatson, whatever crontabs need to be updated to generate karmic images (if any, I'm not too familar with cdimage's crontabs)
<cjwatson> they already were
<ogra> NCommander, just leave it to cjwatson, he knows whats missing and what needs adding
<ogra> i'm sure we'll be pinged to check if its supposed to work ;)
<NCommander> ogra, oh, I trust cjwatson 100%, I was just noting that from the perpsective of building live rootfs's things seem to look OK-ish
<cjwatson> there's no indication of why it wouldn't have tried to do a build
 * NCommander notes that a few packages are uninstallable on armel :-/
<cjwatson> ah, BuildLiveCD needs to be updated to default to karmic
<elmo> on the buildds?
<cjwatson> yes
<cjwatson> it's clearly already been done on some of them
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/ubuntu/latest/ shows that at least manoao, weddell, and royal need to be fixed, though
<elmo> cjwatson: it was only done on i386/amd64; I've done the rest now
<elmo> (lpia, hppa, powerpc, sparc, ia64 and armel)
 * ogra hugs elmo
<ogra> Keybuk, blkid ? i thought using it was a bad thing because of the chache it uses
<ogra> (/me sees the initramfs-tools upload)
<Keybuk> it doesn't anymore
<Keybuk> it now looks in /dev/disk/by-uuid etc. instead
<ogra> ah, great
<ogra> so it doesnt matter what i use ? or should my scripts also switch over ?
<Keybuk> you should use blkid
<ogra> ok
<ogra> thanks
<cjwatson> elmo: cool, thanks
<cjwatson> superm1: could you change 'include platform.jaunty' in lp:~mythbuntu/ubuntu-seeds/mythbuntu.karmic/STRUCTURE to 'include platform.karmic', please?
<cjwatson> Keybuk,pitti: are either of you chasing up the linux-libc-dev asm/ bug?
<Ampelbein> hi. i got a problem with building jabberd2 in pbuilder. I can't get the current version in the archives to be successfully built. The problem seems to be that configure does not find the headerfile resolv.h. but it is there if i login to the pbuilder environment. can someone give me a hint on where to start debugging this?
<Ampelbein> and building the package with 'fakeroot debian/rules build' works
<cjwatson> Ampelbein: what release?
<Ampelbein> cjwatson: karmic
<Ampelbein> cjwatson: and jabberd2 version is 2.2.1-1.1ubuntu1, grabbed from the source-package's page.
<cjwatson> Ampelbein: probably due to linux-libc-dev being totally busted at the moment in karmic then - it's missing /usr/include/asm/
<devfil_> seb128: can you take a look at bug 372833 please?
<ubottu> Launchpad bug 372833 in pidgin "Pidgin doesn't show all MSN smileys using msn-pecan protocol" [Undecided,Confirmed] https://launchpad.net/bugs/372833
<seb128> the sponsor team seems to be subscribed it will get reviewed
<seb128> I'm attending a sprint right now and I'm too busy to do reviews
<seb128> is there anything specially urgent there than you ping on IRC?
<devfil_> seb128: no, don't worry
<seb128> commented on the bug
<seb128> I'm not sure where this list come from but there should be an upstream pointer there
<seb128> that will not change in jaunty and if the next pidgin version fixes the bug mentioned that will be fixed in karmic
<amitk> cjwatson: I am looking at bug 373214 right now
<ubottu> Launchpad bug 373214 in linux-ports "/usr/include/asm/* is not present in linux-libc-dev" [Critical,In progress] https://launchpad.net/bugs/373214
<cjwatson> amitk: thanks
<amitk> discussion on #u-k
<Ampelbein> cjwatson: thanks! that was indeed the problem. i reverted the version in the pbuilder-chroot and now it works.
<ogra> mumble, nautilus-share FTBFS on lpia and arm ...
<ogra> ah, its gnomecanvas
<ogra> and gnomeui
 * hyperair hears nautilus-share
<devfil_> seb128: replied, thanks
<superm1> cjwatson, sure. switched. thanks for reminding
<ogra> hmm...
 * ogra gives back nautilus-share on armel
<hyperair> /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
<hyperair> this is the error on ppc.
<cjwatson> ogra: while that particular error is fixed, there's really not much point giving stuff back right now
<cjwatson> the linux-libc-dev bug means that lots of builds are completely busted
<ogra> well, there is a weird bonmobo dep issue in the ftbfs log i would like to see if its fixed ... i know it will fail on linux-libc-dev but would like to see it surviving up to there at least :)
<cjwatson> hyperair: ^- this isn't just you and it's being investigated
<hyperair> cjwatson: that's from the build log
<ogra> hyperair, right and its being worked on
<hyperair> i see
<ogra> mvo, any idea about http://launchpadlibrarian.net/26407435/buildlog_ubuntu-karmic-armel.python-apt_0.7.10.3ubuntu1_FAILEDTOBUILD.txt.gz ?
<ogra> ln -sf ../../../../javascript/jquery/jquery.js debian/python-apt/usr/share/doc/python-apt/html/_static/jquery.js
<ogra> ln: creating symbolic link `debian/python-apt/usr/share/doc/python-apt/html/_static/jquery.js': No such file or directory
<mvo> ogra: impressive, I have seen something similar yesterday for debian-installer
<ogra> oh, wait there is a former error further up
<mvo> ogra: the package in jaunty seems to be ok, but a recompile seems to be not ok
<ogra> Exception occurred:
<ogra>   File "/usr/lib/pymodules/python2.6/debian_bundle/debian_support.py", line 25, in <module>
<ogra>     import apt_pkg
<ogra> ImportError: /usr/lib/libstdc++.so.6: undefined symbol: __sync_val_compare_and_swap_4
<ogra> hrm
<cjwatson> hyperair: yes, we're aware
<hyperair> right
<mvo> ogra: I log into the porting machine to have a closer look, but that looks pretty strongly like a libstd++/g++ issue
<ogra> mvo, seems totem has the same prob ... so its /usr/lib/libstdc++.so.6
<ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_lock_test_and_set_1'
<ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_sub_and_fetch_4'
<ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_lock_test_and_set_4'
<ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_add_and_fetch_4'
<ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_val_compare_and_swap_4'
<ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_fetch_and_add_4'
<ogra> collect2: ld returned 1 exit status
<ogra> ^^^ from the totem log
<mvo> ogra: cjwatson had a similar one with debian-installer too
<ogra> hmm
<mweichert> is there a way to suppress or preseed options to "dpkg --configure" when using "apt-get install" in a script?
<mvo> mweichert: what problem do you try to solve this way?
<mweichert> mvo, I'm preseeding an installation. We have a standard config that we deploy and I'm trying a script that gets called as d-i's late command
<pitti> cjwatson: I'll file a bug about it and talk to the kernel team
<mvo> mweichert: thanks, sorry I don't know a great deal about the installer preseeding
<ogra> pitti, happening already bug 373214
<mweichert> mvo, ok, thanks for your help. Though my questions is more about dpkg/apt-get then preseeding.
<pitti> ogra: ah, thanks
<ubottu> Launchpad bug 373214 in linux-ports "/usr/include/asm/* is not present in linux-libc-dev" [Critical,In progress] https://launchpad.net/bugs/373214
<ogra> doko, any idea about the /usr/lib/libstdc++.so.6 stuff above ?
<cjwatson> 15:14 <doko> infinity: libstdc++6 is currently broken on armel. new gcc-4.4 (4.4.0-3ubuntu3) won't build with the 4.4.0-3ubuntu1 version in the archive. any earlier version will do. so one manual build will be
<cjwatson>              needed ...
<cjwatson> 15:15 <cjwatson> ah, is that why apt-ftparchive is busted
<cjwatson> 15:45 <doko> cjwatson: yes, likely
<cjwatson> 15:46 <doko> I hate symbols files for C++ libs
<ogra> cjwatson, TA !
<mvo> mweichert: there is "-o Dpkg::Post-Invoke"
<mweichert> mvo, oh - I'll take a look at that.
<doko> ogra: you could use the debs from rimu:~doko/gcc/install
<ogra> doko, i'm checking whats missing to build a livefs on armel atm i guess that wont help much :)
<ogra> just looking at the broken deps etc, if it gets fixed in the archive within the next 6 days i'm fine
<doko> ogra: not really, lamont is currently working on the manual build
<ogra> good then, thats enough
<apachelogger> james_w: I was thinking about something more productive ;-)
<apachelogger> I guess I'll just have to create one
<james_w> apachelogger: can you explain a bit more about what you want to achieve?
<apachelogger> james_w: branch all the kde packaging branches to /jaunty for SRU use
<james_w> ah, ok
<james_w> I don't think there is anything pre-canned
<apachelogger> james_w: well, shouldn't be a problem to enhance our existing batch-action-script to do that as well
<apachelogger> thanks anyway :)
<james_w> do you really want to pre-populate the branches?
<james_w> wouldn't use just branch when you first want to do something with an SRU?
<apachelogger> james_w: that would mean that $developer needs to know how to branch a revision and how to push it to the proper path ... you really don't want them have to worry about that ... they certainly won't ;-)
<james_w> true
<Unggnu> hi all
<primes2h> jdong: There are a lot of bugs to close about gutsy https://bugs.edge.launchpad.net/gutsy-backports/ but I can't set them as "Won't Fix" because they are backports. Can I set them as "Invalid" instead?
<Scrye> hello, is the quagga maintainer here?
<soren> -> #ubuntu-server, probably.
<Scrye> thank you
<tacone> hello, I'm experiencing freezes on jaunty with gksu2.ask_password_full() (python stuff). everything worked on Intrepid. any clue ?
<imachine> hi
<imachine> I was wondering, are we getting 180.51 nvidia drivers in the repos any time soon?
<imachine> I'm having numerous issues with memleaks, could help testing the new drivers on 64bit too.
<imachine> running jaunty.
<jdong> calc: out of pure curiousity, are the OOo3.1 jaunty packages in ~openoffice-pkgs PPA usable?
<imachine> maybe there's a ppa about nvidia drivers too?
<jdong> imachine: the x-updates PPA you mean?
<jdong> calc: well I guess the two FTBFSes answer my question :)
<imachine> es!
<imachine> jdong, just found it ;-P
<imachine> thanks ;-)
<calc> jdong: hmm?
<calc> jdong: well the ooo-l10n ftbfs yea
<slangasek> calc: just saw the same gcj "libgcj.spec: no such file or directory" error on an amd64 build
<slangasek> seems that the .spec file has moved from libgcjNN-dev to gcj-4.4-jdk?
<mathiaz> sbeattie: hi - re bug 326768 - I'd rather not get this update go to -updates for now
<ubottu> Launchpad bug 326768 in mysql-dfsg-5.0 "mysqld_safe thinks mysqld has crashed when it hasn't" [Undecided,Confirmed] https://launchpad.net/bugs/326768
<mathiaz> sbeattie: it has already landed in -proposed
<slangasek> but that's installed for the build in question here, and there doesn't appear to be any version skew, so no idea why it's not working
<mathiaz> sbeattie: I've remove the verification-needed tag and set back the bug status to confirmed
<mathiaz> sbeattie: however I cannot unsubscribe ubuntu-sru and the sru-verification team
<mathiaz> sbeattie: is there anything else I should do?
<sbeattie> mathiaz: do you still want it in -proposed?
<mathiaz> sbeattie: it's already in -proposed
<mathiaz> sbeattie: I'd rather not get it in -updates
<sbeattie> mathiaz: I'm asking do you want it pulled from proposed?
<mathiaz> sbeattie: ah - yes if that's possible
<sbeattie> slangasek: ^^^
<slangasek> mathiaz: you could set the 'verification-failed' tag?
<slangasek> or is that not actually the issue?
<mathiaz> slangasek: well - technically it's not a verification failed - the proposed solution fixes the symptoms
<mathiaz> slangasek: however I'm not confident enough to push it directly to -updates
<mathiaz> slangasek: I'd have more time to spend debugging the issue
<mathiaz> slangasek: so I wanna make sure it doesn't get in -updates by mistake
<slangasek> well, I'll use the verification-failed tag for that then; I don't think we should retract updates from -proposed if we don't have to
<mathiaz> slangasek: ok - I'll use the verification-failed tag
<mnemo> what happens if a user has a custom PPA version of something and ubuntu issues a security fix? does it uninstall his PPA version or does he miss the security fix?
<ScottK> It depends on how the PPA pacakge is versioned, but generally you miss the security fix.
<mnemo> are security fixes using the same incremental counter as SRU's ??
<mnemo> for example if the current SRU version is BLAH.2 will a security fix be called BLAH.3 then?
<kees> mnemo: generally, yes.
<mnemo> ok
<ScottK> mnemo: There's no guarantee at all about anything about a PPA package, so except for from people you trust, you're already accepting some risk if you use them.
<calc> slangasek: yea i thought it might have been somehow related to the linux-libc-dev mess, but i am not sure
<slangasek> I can't imagine why that would be the case
<slangasek> anyway, your comments were before the broken linux-libc-dev got published, AFAICS
<calc> slangasek: i was going to do a test build locally but by the time i got my build setup it was failing due to the cups issue on i386 also
<slangasek> "the cups issue"?
<calc> slangasek: cups headers can't be "found" now for several archs
<slangasek> url?
<calc> slangasek: see build failure for powerpc: http://launchpadlibrarian.net/26415416/buildlog_ubuntu-karmic-powerpc.openoffice.org_1%3A3.1.0~rc2-1ubuntu1_FAILEDTOBUILD.txt.gz
<calc> slangasek: same thing happens for me when i try to build it on i386
<calc> slangasek: the fact i386 previously failed from the gcj bit makes me think that the cups bit at least is related to the linux-libc-dev header mess
<slangasek> calc: yes, that's almost certainly just linux-libc-dev
<calc> ok
<calc> i'm not sure what the issue is with the armel OOo build failure
<calc> it claims unixodbc-dev can't be installed
<calc> whatever is causing the gcj problem on i386/lpia didn't happen on amd64 which was why i was looking into it when i saw it failed due to cups now :\
<cjwatson> I'm making good progress on the linux-libc-dev bug, and have more or less found what's wrong - just trying to construct a minimal test case for upstream now
 * calc hugs cjwatson 
<slangasek> calc: unixodbc-dev> another instance of a package winding up in the wrong section out of NEW, WTF
<calc> ah
<slangasek> (http://people.ubuntu.com/~ubuntu-archive/architecture-mismatches.txt)
<calc> so i only have on real failure issue to look into, thats much better :)
<slangasek> cjwatson: armel binaries of libtool landed 24h after all the other archs; if libtool was NEWed on those archs before it was available on armel, what happens/is supposed to happen?
<cjwatson> slangasek: each architecture should show up in NEW separately
<cjwatson> (not that this is ideal from the POV of archive admin workflow, and dak was more reasonable about it, but that's how Soyuz has always done it)
<slangasek> kirkland: yesterday was your archive day; do you recall putting a libtool-dev package through NEW on armel?
<slangasek> kirkland: libltdl-dev, rather
<kirkland> slangasek: i did work on archive stuff yesterday, spent my whole day doing sync's, didn't get to any NEW's
<slangasek> ok
<kirkland> slangasek: need help with something?
<slangasek> Riddell: did you do any NEWing yesterday?
<slangasek> kirkland: I'm trying to figure out what's going wrong that's causing all these new packages to end up in the wrong section
<kirkland> slangasek: hmm, sorry, i don't know
<slangasek> given that it's happened all of a sudden, I really suspect (worry) that it's a soyuz behavior change
<kirkland> slangasek: on an unrelated note ...  I need an arch admin to process the rename of the screen-profiles source/binary package to it's new name, byobu
<kirkland> slangasek: any idea where i need to request that?
<slangasek> packages don't get renamed
<kirkland> slangasek: just file a bug, and subscribe arch admin?
<slangasek> you upload a new one under the new name
<kirkland> slangasek: okay, i did that
<kirkland> slangasek: and it's in the new queue
<slangasek> then whoever processes NEW next will get it
<kirkland> slangasek: oh, okay, that's surprisingly easy
<slangasek> infinity, james_w, jdstrand, Riddell, pitti, mdz, Hobbsee, ScottK, StevenK: do any of you remember having done NEW processing of libltdl-dev on armel yesterday (May 6)?
<mdz> slangasek: I don't think I even have an account on the appropriate machine anymore
<ScottK> slangasek: I did not do any.
<slangasek> mdz: can be done through the web interface these days, but ok :)
<mdz> slangasek: ooh, shiny
<jdstrand> slangasek: not I
<jdstrand> or even me...
<james_w> slangasek: nope
<xee> is there a channel for Ubuntu re-branding and derivatives?
<Riddell> slangasek: yes that was probably me
<slangasek> Riddell: ok - just trying to get a handle on why all these NEW binary packages have been landing in universe
<lamont> dear oo.o, more, smaller packages.  srsly. kthx
<slangasek> we can obviously fix them up after accept if we're not sure at first where they belong, but I've been worried there's some systemic problem
<cjwatson> lamont: yes, the findutils bug will get in the way of libstdc++. I'm about to upload a fix which will probably need to be built manually against an older linux-libc-dev
<lamont> yay
<lamont> I see my morning going wonderfully manual
<cjwatson> lamont: OK. I've uploaded findutils 4.4.1-1ubuntu2. That needs to be built with the old linux-libc-dev. Then linux and linux-ports need to be reuploaded (hi, Tim ...) and once findutils is published they need to be built against new findutils and old linux-libc-dev
<lamont> hooray for no-change uploads, eh?
<cjwatson> I'm sure the kernel guys have something to put in there
<lamont> cjwatson: which means I'm most likely to pin linux-libc-dev in the tarball and put the buildds on manual while we cycle through
<lamont> the always do
<lamont> they
<cjwatson> pinning linux-libc-dev in the tarball will let other stuff build anyway
<cjwatson> but yes
<lamont> when I bastardize the production tarball, the buildds go manual... iz RULE.
<cjwatson> lamont: WFM
<lamont> cjwatson: and I'm totally EOD, with family obligations for a few hours... with any luck, I'll manage to smack things a bit this evening wearing my ubuntu-hat, but it might be 1000 UTC before I actually get there :-(
<cjwatson> lamont: right :-/
<cjwatson> lamont: if you can at least stick the buildds on manual so that we stop getting build failures, that would probably be good
<cjwatson> pull the big shutdown switch
<lamont> oh, that's easy
<lamont> but if I kill the buildd sequencer, then we get alarms... I think I'll go the manual route. :-D
<lamont> cjwatson: just to confirm, all buildds, all architectures, but not ppa buildds
<cjwatson> correct
<cjwatson> no PPAs for karmic yet
<cjwatson> oh, hmm
<cjwatson> shutting down all the buildds will kill non-karmic builds too
<cjwatson> maybe best leave them going in case there's something for security :-/
<lamont> ah, right
<cjwatson> or even -proposed/-updates
<lamont> keeps the DC warmer and all that
<cjwatson> we'll just have to cope with the failure mails
<lamont> and then we just mass-give-back karmic when fixed
<imachine> jdong, it's so much better after upgrading to the X.org+friends from ubuntu-x-updates ppa
<imachine> jdong, spot on
<imachine> cheers
<mbana> what's this tracker applet about?
<mbana> i just had a prompt about a corrupt index
<ScottK> cjwatson: There are PPAs for Karmic.
<cjwatson> ScottK: I was told recently that they hadn't been enabled yet, but I didn't check; if they have been, I stand corrected
<ScottK> cjwatson: ubuntu-clamav PPA has one Karmic package in it, so it appears they are.
<cjwatson> fair enough
<slangasek> yes, they're up, with refreshed documentation in NewReleaseCycleProcess
<cjwatson> for anyone who's interested, http://launchpadlibrarian.net/26447089/findutils_4.4.1-1ubuntu1_4.4.1-1ubuntu2.diff.gz is the basic fix; a more complete patch with a test case is on its way upstream
<mheld> anybody know if the 64 bit packages for ubuntu are compiled with SSE2 or SSE3 flags?
<doko> cjwatson, pitti: now that java-gcj-compat is gone, there's a very nice list of java packages ready for demotion :-)
<calc> some of those demotion also are due to OOo needing a different set of packages
<calc> once linux-libc-dev is fixed i will be uploading a new OOo with the new build-deps added
<calc> that reminds me to write the bug report
<calc> erm how do i add another package to a bug report
<calc> i used to replace the previous package name in the url with the new one and a 'also report here' dialog would show up, but it seems to no longer do this
<calc> now it seems too 'smart' and goes back to the previous url
<calc> slangasek: do you happen to know? ^
<slangasek> calc: 'also affects distribution'?
<Ampelbein> calc: 'also affects distribution' -> ubuntu -> packagename
<calc> wow that sucks
<calc> so they now made it from one step into several
<calc> thanks for the workaround though :)
<Ampelbein> calc: i think the 'also report here' caused some trouble so they changed it. i remember seeing a discussion in IRC, probably in #launchpad
<calc> ok
#ubuntu-devel 2009-05-08
<bryce_> calc: interesting, I didn't know about that change
<bryce_> calc: on the plus side, that may result in a reduction of duplicate tasks (I get a lot of tasks that I assign away from xorg, that grow another xorg task after a while - I finally just wrote a script to detect and eliminate these)
<calc> ah
<relnev> what do I need to do to build a replacement snd-usb-audio.ko (a kernel module found in the linux kernel source) that i can load without having to rebuild the kernel and reboot?
<wgrant> calc: It was causing problems because people would click on a bug link in an email after somebody had reassigned a task. They'd then immediately click on the button to recreate the original task. You were always meant to use 'Also affects (project|distribution)...' normally, anyway.
<calc> wgrant: ok
<lifeless> is anyone else seeing oddly high load in jaunty/karmic?
<lifeless> Mine is constantly 10
<lifeless> or 11
<lifeless> but no IO, plenty of cache, cpu at 1% use
<lifeless> oh nevermind, it'll be a stalled sfs process
<dholbach> good morning
<robert_ancell> any karmic users here?  What is the contents of your /usr/include/linux/errno.h?
<robert_ancell> mine points to asm/errno.h which does not exist
<lifeless> robert_ancell: you're missing libc-dev or something I suspect
<lifeless> or being hit by a toolchain transition
<lifeless> <- guessing
<hyperair> there are ftbfs errors regarding that particular header
<robert_ancell> hyperair: ouch
<hyperair> yeh ouch indeed.
<hyperair> gnomeui is having issues
<hyperair> rather, stuff depending on gnomeui
<robert_ancell> hmm, I was going to use the PPA but that will have the same problems right?
<hyperair> indeed.
<dholbach> robert_ancell: try asking the guys in #ubuntu-kernel - they should know what's going on
<dholbach> ... even if I suspect that most of them are sleeping right now
<robert_ancell> dholbach: yeah, it's friday afternoon.  I figure it will be fixed by monday :)  I'll go drink beer instead
<ajmitch> dholbach: it's a known issue, Stuff needs to be done on the buildds I heard :)
<dholbach> ajmitch: oh wow
<StevenK> It's a findutils bug that impacted on the linux-libc-dev binary package
<geser> robert_ancell: it's bug 373214
<ubottu> Launchpad bug 373214 in findutils "/usr/include/asm/* is not present in linux-libc-dev" [Critical,Fix released] https://launchpad.net/bugs/373214
<robert_ancell> geser: thx
<lifeless> robert_ancell: oh right, you're in aus:)
<lifeless> beer sounds good about now ;)
<robert_ancell> lifeless: it's rapidly approaching beer o'clock
 * robert_ancell rubs it in for those who have a day to go
<lifeless> indeed. and we fly 10000 to actually meet soon :P
<Hobbsee> slangasek: I did not.
<slangasek> Hobbsee: right - Riddell confessed :-)
<Hobbsee> slangasek: oh, fair enough.  I'm just looking through my highlights ;)
<Hobbsee> slangasek: I hope you didn't make him walk the plank?
<slangasek> no, I just demoted him to multiverse temporarily
<Hobbsee> haha
<Hobbsee> oh dear
<pitti> Good morning
<pitti> slangasek: libltdl-dev> I didn't
<pitti> doko: nice! is it in c-mismatches?
<StevenK> slangasek: Along with all of KDE?
<slangasek> hah, twitch :)
<ScottK> It would improve the quality of translations.
 * StevenK grins
 * pwnguin gets to attend a public meeting about garmin's use of linux
<pwnguin> anyone have a question they want answered?
<Hobbsee> pwnguin: apart from the obvious ones?  No.  I'd love to know what the answers to the obvious questions are, though.
<Hobbsee> if there's a URL from it
<pwnguin> i doubt it will be publicly recorded
<Hobbsee> darn
<pwnguin> but what are the obvious questions?
<Hobbsee> pwnguin: which devices do they use linux in, what are their future plans with linux and their devices, whether people will be able to mod them / write plugins etc for them, etc, etc, etc
<pwnguin> Hobbsee: http://developer.garmin.com/linux/ i'll let you know if they mention a device that isn't one of those
<Hobbsee> pwnguin: ah, sweet!
<pitti> anyone got a Sony laptop here?
<amitk> ping manjo when he gets online in a few hours if you don't find anybody
<amitk> pitti: ^
<pitti> amitk: ah, thanks
<pitti> directhex: congratulations for your motu badge! well done!
<pitti> cjwatson, smb: hm, why does the new linux upload bump abi?
<pitti> if it's just a rebuild?
<smb> pitti, because i did not found/look far enough/trust the last abi files
<directhex> pitti, thanks. i still need to bug you over stuff in main though ;)
 * cjwatson has no idea but doesn't care enough to worry
<pitti> smb: fair enough; I was just curious
<cjwatson> ABI changes are cheap enough at this point
<smb> pitti, So I bumped abi to be sure it passes the abi checks
<pitti> yeah, we just need to watch out for NEWing
<cjwatson> though it does mean NEW, but meh, lost in the noise of having to deal with the whole thing manually
<pitti> thanks for getting this fixed
<dholbach> cjwatson, smb: YAY! :)
 * TheMuso suspected there would have been an ABI bump for ports also, but avoided enabling checks since all ports kernels are not yet setled.
<TheMuso> anybody else getting LP timeouts?
<pitti> intermittently, yes
 * TheMuso can't seem to view source package pages, i.e lp.net/ubuntu/+source/linux
<TheMuso> hrm working now
<TheMuso> anyway I'm off for the evening, will check in tomorrow morning in case anything is needed ports wise, but I think things should be fine.
<directhex> had intermitent issues with LP since last night. check /topic in #launchpad
<Laney> What's up with these "asm/socket.h: No such file or directory" errors? Seen them failing a few builds now.
<TheMuso> Laney: linux-libc-dev breakage.
<james_w> bug 373214
 * TheMuso thinks a /topic tweak is in order.
<ubottu> Launchpad bug 373214 in linux "/usr/include/asm/* is not present in linux-libc-dev" [Critical,Fix released] https://launchpad.net/bugs/373214
<Laney> yes, it seems to be affecting builds all over the shop
<Laney> james_w: ta
<amitk> TheMuso: More correctly, findutils breakage that caused a linux-libc-dev
<amitk> breakage
<TheMuso> amitk: yes, but linux-libc-dev being broken is enough for most I would think. :)
<TheMuso> anyway, really off.
<apw> on an upgrade would i expect to be seeing linux-generic being uninstalled?
<apw> (on jaunty)
<slangasek> are you using jaunty-proposed?
<apw> yes using -proposed
<slangasek> apw: then it's not surprising; let me check whether the binaries are all built now and ready to be accepted from NEW
<apw> slangasek, how would lacking binaryies trigger a meta to be removed?
<slangasek> the meta packages are currently uninstallable in -proposed, so if you're using the package manager in a way that tells it it's ok to remove packages...
<apw> i am using it in the default way, it said a partial update was the only way forward, and i said yes
<apw> as encouraged to do by the defaults
<slangasek> anyway, lrm/lbm accepted now, which should fix linux-generic with the next publisher cycle
<apw> (with my behaving like a non-clued up user hat on)
<apw> i assume once i had lost linux-generic i wouldn't have got it back... sounds problematic for those users
<slangasek> yeah, I've never quite understood why update-manager calls that a "partial" upgrade; half the time it fails to find a solution at all for me, whereas if I click 'close', it lets me do a real, partial upgrade
<apw> yeah ... i think there is some kind of bug in there offering that to normal users without a fight
* cjwatson changed the topic of #ubuntu-devel to: most builds broken due to bug 373214, being fixed | Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> (obviously if your build doesn't involve compiling anything then it won't fail. I don't care enough to fine-tune the topic)
<smb> slangasek, Were the meta package in error or did something else go wrong?
<smb> slangasek, Have to be off now, but if there is anything that should get back into the linux-meta packages, let me know
<slangasek> smb: no package errors; we just needed some jaunty-proposed NEW processing, which is done now
<smb> slangasek, Ah, ok. Thanks
<apw> cjwatson, i wonder if you would have some minutes to talk about that kexec reboot bug (bug 251242) today
<ubottu> Launchpad bug 251242 in kexec-tools "Always kexecs on shutdown/reboot" [Medium,In progress] https://launchpad.net/bugs/251242
<cjwatson> apw: ah yes. I have a PDR panic day today, but have queued up that bug to look at the debdiffs therein
<apw> cjwatson, heh know _that_ panic ... no worries if busy it'll wait
* lamont changed the topic of #ubuntu-devel to: most builds broken due to bug 373214, being fixed - buildds manual | Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<geiseri_> hi i am having problems creating my own allternates installer.  it gets pretty far but bombs out with an error of "Couldn't find task standard"
<geiseri_> is there anyone who would know more about this? google was not very helpful
<geiseri_> i think i may have missed a step, but im not sure where...
<astrolite> any developers of ubuntu-vm-builder here?
<cjwatson> geiseri_: it's looking for sections with "Task: standard" in the Packages file - if you're missing those then perhaps you generated your own Packages file but didn't use the override file from archive.u.c/ubuntu/indices/ as input?
<geiseri_> yes, i created my own... but i did not include the indices.
<cjwatson> that'll be your problem then
<geiseri_> i can download that or do i need to generate that if i am using my own package set
<cjwatson> start out with the downloaded ones, generating your own is a bit complicated
<geiseri_> okay
<cjwatson> you may need to edit them a bit
<geiseri_> okay
<geiseri_> ill start there
<geiseri_> what files will i need?  all of them fro my dist?
<liw> astrolite, #ubuntu-virt might be a better place to find those people
<astrolite> liw: ok, thanks!
<geiseri_> cjwatson: where would be the documentation no how to generate my own indices files?
<geiseri_> or is it easier to include the tasksel in my Packages file?
<geiseri_> err Task: standard?
<cjwatson> geiseri_: I don't know of any documentation on the subject, but the format should be clear from looking at the first
<cjwatson> file
<cjwatson> geiseri_: apt-ftparchive(1) documents how to refer to the index files
<cjwatson> geiseri_: if you do that properly in your apt-ftparchive configuration, then it will include appropriate lines in Packages
<cjwatson> geiseri_: you'll need all the files for your distribution - the ones with ".extra." in the name include Task fields, while the others deal with getting Priority and Section correct
<cjwatson> (the latter is mostly rather less important but does matter in some cases)
<geiseri_> okay ill read up on ftparchive... i have a feeling i may be making this harder than it needs to be
<geiseri_> because im using my local file based package repo
<lamont> kernel is building on the afflicted architectures now (linux-libc-dev ftw or some such)
<geiseri_> cjwatson: okay i think im still missing something here... apt-ftparchive generates the indices files? or it just creates a Packages file that causes me not to need them?
<cjwatson> apt-ftparchive generates the Packages files, using the .debs themselves and also the files from /ubuntu/indices/ as inputs
<cjwatson> the installer does not itself use the files from /ubuntu/indices/ directly
<geiseri_> ah, so really i need the indices files to include when i run the scanpackages then
<cjwatson> dpkg-scanpackages is what we used to use before we had apt-ftparchive; I don't think it supports "extra overrides" (which contain Task fields)
<cjwatson> (well, for values of "we" = Debian)
<geiseri_> okay, so im better off to use apt-ftparchive then
<Awsoonn> hi guys, bug 312396 is cramping my workflow and I would like to have some guidance in fixing it. Who would be the best person to talk to?
<ubottu> Launchpad bug 312396 in gvfs "Nautilus opens files over SSH as read-only when not owner." [Low,Incomplete] https://launchpad.net/bugs/312396
<cjwatson> Awsoonn: judging from the upstream bug, http://git.gnome.org/cgit/gvfs/commit/?id=4e49395240190526e is supposed to fix it
<Awsoonn> cjwatson: do you think it would be a bad idea to just get the latest version from git and make install?
<cjwatson> Awsoonn: I wouldn't like to say, since I have not looked at the changes in detail; it's entirely possible that that would cause problems
<pitti> infinity: can we do a mass give-back of failed karmic builds after the new kernel is in?
<cjwatson> pitti: lamont's going to
<Awsoonn> I see there are 4 patches on it
<pitti> cjwatson: nice, thanks
<cjwatson> (infinity is off sick, I think)
<pitti> infinity: uh, get well soon!
<cjwatson> Awsoonn: if it were me, I'd backport the change
<Awsoonn> so just make a patch of that one change and make a new patch based on it?
<cjwatson> that would be the approach I'd take, yes
<cjwatson> and report back to the bug if that solves it, of course
<Awsoonn> cool, and adding a patchfile to the patch dir will automagicly cause it to be applied when built right?
<Awsoonn> if that makes sense
<cjwatson> Awsoonn: depends on the patch system; sometimes there's a '00list' or 'series' file that needs to be changed too
<Awsoonn> it does have a series file, so it looks like I should add it ther too, ok. I"m getting the idea now. :)
<Awsoonn> when I build the package with the patch added should I just use .configure make make install or do I need to make a package of it before installing?
<Awsoonn> i hope you dont mind so many questions. I really want to be MOTU someday so I'm still learning as much as possible. :P
<cjwatson> Awsoonn: if it were me, I would make a package of it (so also increment the version number in debian/changelog slightly)
<cjwatson> it's entirely possible for packages to lay files out differently from 'make install'
<Awsoonn> that is what I was fearing, so I will go the package route, thank you cjwatson !
<cjwatson> upload queue index numbers have passed the wow million mark - wow
<cjwatson> err, the one million mark
<Awsoonn> I think you were right the first time :)
<pitti> cjwatson: what was the 1.000.000th upload?
<pitti> (and wow! indeed)
<amitk> pitti: manjo is here now. Hit him with your Sony fixes ;)
<pitti> manjo: hello!
<manjo> hi
<manjo> referesh my mem pls ?
<pitti> manjo: do you have some minutes to try out a new udev-extras package for sony fn key handling?
<pitti> manjo: http://martinpitt.wordpress.com/2009/05/08/devicekit-update-future-handling-of-fn-key-maps/
<pitti> manjo: unfortunately the packages in my PPA didn't build yet (buildds blocked due to kernel bug)
<pitti> manjo: but you can build it from the git branch (http://lists.freedesktop.org/archives/devkit-devel/2009-May/000171.html)
<pitti> manjo: I'm interested in whether this package, and hal-info keymaps disabled, works on sony vaios
<pitti> I need to disappear for 20 minutes for physiotherapy; bbl
<manjo> pitti, my wife took the laptop with her to work... is it ok if I give you results on monday ?
<manjo> amitk, ?
<cjwatson> pitti: what were the odds ... a language pack
<cjwatson>  1000000 | -B | language-pack-gnome- | 1:9.04+20090504      | 43 hours
<cjwatson> language-pack-gnome-om actually
<cjwatson> though confusingly something tried to upload that to jaunty, not jaunty-proposed
<cjwatson> ArneGoetje: is langpack-o-matic still targeting jaunty rather than jaunty-proposed in its changelogs, by any chance?
<cjwatson> ArneGoetje: never mind - I see now that it was actually a PPA upload. Pretend I never said anything. :-)
<ion_> pitti: Could you put the udev-extras package to a separate section in your PPA? Iâd feel more easy about adding it to sources.list that way.
<ion_> I see that itâs the only package in yourppa/karmic, but that can change. :-)
<cjwatson> pitti: oh, is *that* why you have enormous LP karma? it still seems to think all language packs are uploaded by you
<cjwatson> pitti: at least to the ubuntu-langpacks PPA
 * lamont goes to play with karmic
<jeki> Can anyone look at this report? https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/368580
<ubottu> Ubuntu bug 368580 in app-install-data-ubuntu "aMule should be offered instead of aMule AdunanzA" [Undecided,Confirmed]
<pitti> manjo: absolutely; thank you!
<manjo> k
<pitti> cjwatson: a PPA?
<pitti> ah, right
<pitti> cjwatson: oh, we get karma for uploads now?
<cjwatson> I think so
<pitti> Maintainer: Language pack maintainers <language-packs@ubuntu.com>
<pitti> timestamp: Thu 2008-02-14 14:50:13 +0100
<pitti> ^ date of the change
<pitti> I can set it to -core-dev, but I'd really keep it as that alias
<pitti> just curious why I'd get the karma for it personally
<cjwatson> dunno, I was just looking at the display on ~ubuntu-langpacks/+archive/ppa
<pitti> I wonder why I got the Karma then, and ArneGoetje didn't
 * pitti files a bug
<cjwatson> BTW I haven't actually checked whether you got karma for it
<cjwatson> I just saw that the uploader was listed as pitti
<pitti> cjwatson: ~pitti/+karma shows an abysmal soyuz component; it could only be that
<cjwatson> you can't mean abysmal :)
<cjwatson> unless soyuz karma is negative
<pitti> right, seems I slightly misunderstood the word
 * pitti looked into dictionary now and adjusted his vocab
<pitti> like "scary"
 * cjwatson wonders if the opposite of abysmal should be empyrean
<cjwatson> perhaps not :)
<cody-somerville> lol
<pitti> anyway, bug 373772
<ubottu> Launchpad bug 373772 in launchpad "pitti gets karma for language pack uploads" [Undecided,New] https://launchpad.net/bugs/373772
<pitti> I want to compete on fair terms :)
<calc> looks like the archive will be usable again in a few hours :)
<calc> i386/lpia have linux built now
<cjwatson> yeah, lamont and I (mostly lamont) have been nursing things through
<cjwatson> powerpc is done, amd64's nearly done
 * calc hugs cjwatson and lamont :)
<calc> looks like ia64 failed for a strange rason
<calc> er reason
<cjwatson> no it didn't, ia64 is built from linux-ports
<calc> oh i see
<cjwatson> and never had this particular problem in the first place (by luck, I assume)
<cjwatson> sparc was never broken either
<lamont> cjwatson: and IA64 is WINNING on the shortest-queue-depth competition. whoda thought?
<cjwatson> it had all that time of being non-broken to catch up
<geiseri_> if i am generating my iso image from a script is it better to just inject my preseed file right into the initrd vs putting it on the cdrom filesystem?
<cjwatson> hmm, I clearly should have published lpia rather than waiting for amd64 - oh well, it really is nearly done now
<geiseri_> or is it better to put the first three questions on the boot arguments
<cjwatson> geiseri_: if you're rebuilding the initrd *anyway*, then you might as well inject it in there, but otherwise I'd put it on the cdrom filesystem and edit boot arguments
<cjwatson> the only "better" about it is convenience for you
<geiseri_> okay
<shodges> hey, does anyone know of a small command-line utility that wraps the XGetInputFocus function for X11?
<shodges> I want to retrieve the ID of the window in focus, but preferably using a tool that is existing on the system already...
<shodges> My searching so far has retrieved nothing, I've written my own program as a test, but I need to support remote Ubuntu systems over SSH, so transmitting the the binary program over the wire is a less desirable than just piggy-backing on an existing utility
<Awsoonn> cjwatson: I was able to manually apply the changes and it works! but what command should I use to generate a patch for it that i can put in the debian folder?
<Awsoonn> first I guess I'm assuming that I'm not allowed to modify anythign outside the debian directory, correct?
<cjwatson> depends on the patch, I think you should perhaps read documentation under wiki.ubuntu.com/UbuntuDevelopment and wiki.ubuntu.com/MOTU which will be ultimately more rewarding that asking me :)
<cjwatson> s/that/than/
<cjwatson> lamont: publisher's running for the linux* packages that have made it so far, BTW
<cjwatson> I verified that the diffs against older linux-libc-dev seemed reasonable
<lamont> yay
<apw> can anyone tell me where i might find the uptodate source for gnome-power-manager ... both jaunty and karmic point me to the same bzr branch which seems to have no releveance to either
<cjwatson> well 'apt-get source gnome-power-manager' is always up to date - ask the most recent uploader in its changelog
<apw> cjwatson, thanks ... i knew that the apt-get source was always reliable, but it bitches at me and tells me not to use that ... will hastle someone :)
<apw> seb128, pitti you have both updated gnome-power-manager recently.  the package claims to be in bzr but the reference there seems bogus and out of date... what did you use just the package?
<cjwatson> if the branch is already out of date, the hassling is not directed at you ...
<apw> cjwatson, heh yeah :)  but i don't want to make it worse
<seb128> apw: what bzr did you use?
<apw> the one it pointed me to i think in the debian/control file
<seb128> which one is that?
<seb128> let me have a look
<apw> https://code.launchpad.net/~gnome-power-manager-team/gnome-power/trunk
<seb128> ok
<apw> but that as 2.5.99 on it
<apw> and neither jaunty nor karmic are at that version
<seb128> it's lp:~ubuntu-desktop/gnome-power-manager/ubuntu
<seb128> now
<apw> for which karmic or jaunty?
<seb128> dunno about karmic
<seb128> but we usually don't make different versions
<seb128> we just have a trunk which has the unstable version
<apw> they are at rather different versions right now
<seb128> no they are not
<seb128> that's the same project
<seb128> we don't have an hardy bzr, an intrepid bzr, etc
<seb128> just trunk
<apw> gnome-power-manager | 2.24.2-2ubuntu8 |        jaunty | source, amd64, i386
<apw> gnome-power-manager | 2.26.1-0ubuntu1 |        karmic | source
<apw> that tip can't be both?
<seb128> no, as said it's current unstable
<seb128> unstable = karmic
<seb128> we don't keep stable series in a different bzr, we just keep upgrading the bzr
<seb128> if you need to do a sru apt-get source the jaunty version and debdiff on that
<apw> right so ... to make a change in jaunty, should i just produce a debdiff or should i make a new bzr branch off somwhere in history myself
<apw> seb128, ok thanks
<seb128> you're welcome
<seb128> we don't do enough sru uploads to outweight the cost to carry several bzr versions, etc
<apw> i'll strip the vcs link for jaunty too at the same time
<seb128> sru should be minimal changes if you aim for that
<seb128> I'm not sure starting doing cleaning is a good idea
<apw> i would have hoped a branch in bzr would be next to free.  but whatever you are doing is ok with me
<apw> well having stale information in there is rather confusing ... it pointed me to bzr, when we arn't using it, and to the wrong one even so
<apw> but your call, i'll ignore it
<Awsoonn> apw, you may concider submitting your minimal debdiff for the sru and a second one with the updated link for karmic or something that.
<seb128> apw: it's probably next to free, we just don't have a policy for naming, where to store those, how to update the vcs field in control, etc
<Awsoonn> seb128: feel free to correct me on that.
<seb128> apw: since often we will switch to a new unstable without touching the stable source
<seb128> ie we work on jaunty, the bzr used is trunk and that's in the uploaded sources
<seb128> then karmic open
<cjwatson> I'm fine with a Vcs-Bzr correction in an SRU, personally
<apw> seb128, yep some process required for sure.  i would have thought naming by series at the time of release would be appropriate
<cjwatson> apw: it's not worth putting lots of effort into putting that in place across the board now - we'll get it once we switch to the new source package branches scheme that james-w and others are working on
<apw> probabally something someone should bring up at UDS with a view to producing guidance
<seb128> apw: you would need to reupload everything to change the vcs
<cjwatson> it'll then be lp:ubuntu/jaunty/gnome-power-manager etc.
<apw> cjwatson, there is a new scheme ...
<cjwatson> and probably overrides to set Vcs-Bzr
<cjwatson> apw: http://wiki.ubuntu.com/DistributedDevelopment et al
<apw> cjwatson, that makes a lot of sense i suspect
<apw> cjwatson, sounds like its already done
<cjwatson> already extensively discussed, not quite done but we're cloe
<cjwatson> close
 * apw buts out of that one then :)
<seb128> the discussions are for a scheme for the whole archive
<cjwatson> right, which will account for this case
<seb128> the current bzr packaging is not consistent accross the board
<apw> sounds like something to stay well clear of being blamed^Winvolved in
<seb128> ubuntu-desktop is not an heavy bzr user and we picked easy scheme on the way
<seb128> it's probably far from perfect but work for what we have to do usually
<seb128> ie we usually focus on jaunty, spend some times on sru, then switch to karmic
<apw> seb128, no what you are doing is completely fine.  i care not to be fair, just as someone bumping into your package i am not finding it easy.  in fact this is the second time and its moved every time :/
<seb128> that's the first sru done after a karmic change, ie usually one bzr fits the work
<seb128> apw: universal rule is "apt-get source, change, debdiff" and open sponsor request
<seb128> then let the packagers deal with their bzr etc
<apw> and get whined at for ingnoring the bzr line (in my experience)
<seb128> people usually complain when somebody upload without considering bzr
<seb128> for sponsoring a debdiff should not be an issue
<apw> but cool.  i was about to do the right thing, so all is good, which was to push a debdiff to launchpad and ...
 * Awsoonn is now hungry
<Awsoonn> sorry to interupt, but when I built my package and installed it appears another package requires a dependancy update to mach my new version. when I submit to LP do i ned to produce a debdiff for every package that needs a bump?
<cjwatson> that's very odd; such dependencies (that require changes when you *increase* a version) are rare in the extreme. Can you give specifics, please?
<Awsoonn> yea, I and hitting gvfs with that patch, and now libglib2.0-dev seems to be missing a dep
<Awsoonn> strangly enough gvfs is not one it's depends. so i'm really confused there..
<seb128> Awsoonn: could you copy the error on pastebin.ubuntu.com?
<cjwatson> you definitely need to be specific about the exact error message, yes
<calc> hmm did i386 not get published yet?
<cjwatson> it's working on it
<cjwatson> the publisher is not all that quick, be gentle with it
<calc> ok
<cjwatson> I think the guts of it are done now, but it still has to run germinate before poking the mirrors
<Awsoonn> I'll need some help here, when I rebooted after installing the new gvfs update-manager put an error in my notification area and says  Error: BrokenCount >0 This usually means that your installed packages have unmet dependancies.
<Awsoonn> http://ubuntu.pastebin.com/m10bdaae9
<cjwatson> run 'dpkg --configure -a' in a terminal and paste.ubuntu.com what it says
<Awsoonn> kk
<Awsoonn> ohh cjwatson that is very usefull. I think i have found the problem. :)
<Awsoonn> when I installed all of my .debs that were producded from pbuilder I mistakenly installed all of them, including a -dev package. It didn't automagicly pull in teh dependancies since I used dpkg -i to install it and was now complaining that libgvfscommon-dev needed some dependancies. :)
<cjwatson> dpkg -iO is your friend
<cjwatson> (only install packages that were already installed)
<Awsoonn> oh, yea that would have been good to know indeed
<calc> cjwatson: hmm is -i0 documented anywhere? i didn't see it in the manpage
<cjwatson> calc: O not 0
<cjwatson> oh
<cjwatson>        -O, --selected-only
<cjwatson> linux-libc-dev fixed for most architectures (not armel/hppa yet), relevant buildds back to auto
<calc> ok
<cjwatson> give-backs have been queued, please tell me if you still see failures that indicate missing asm/*.h headers (do not tell me about any failure you happen to see!)
 * calc definitely needs new glasses
<calc> cool :)
<cjwatson> and the publisher's back to auto as well
<pitti> seb128: hm, I have used bzr+ssh://bazaar.launchpad.net/~gnome-power-manager-team/gnome-power/trunk
<pitti> apw: ^
<pitti> seb128: and that branch reflects what's in karmic
<seb128> pitti: ok, apparently that's not uptodate
<pitti> hm
 * pitti pushes
<pitti> oops, sorry
<seb128> and I though we agreed to move it to ubuntu-desktop bzr?
<seb128> not that I really care
<pitti> seb128: can do, I don't mind much; would make sense
<pitti> apw: so, if you uploaded something already, I'll just commit it
<seb128> but to have a consistent namespacing
<pitti> apw: anyway, it's current now
<pitti> sorry
<apw> pitti, nothing has happened, we are good
<seb128> pitti: he's working on a jaunty sru so it will not be really useful
<pitti> okay
<pitti> apw: I went through my AH talk and ignored IRC
<pitti> ah
<seb128> which leaded to a discuss about stable versions and bzr
<pitti> feel free to create a bzr branch if you prefer
<pitti> if not, just ignore it
<apw> yeah i am happy.  and know what to do
<calc> yipee new linux-libc-dev is now available from mirrors :)
<pitti> \o/
 * calc rebuilds OOo locally to track down the other bug
 * calc hopes to have OOo 1:3.1.0-1ubuntu1 done today if he can resolve the OOo gcj issue
<pitti> oh, it's released? nice
<calc> pitti: yea was released late wednesday but we then had the linux-libc-dev headers problem, and some sort of weird failure in building OOo due to gcj on a couple arches
<Awsoonn> I'd like to share a bit of happienss in my world with you all... http://ubuntu.pastebin.com/d66e916ad
<mterry> yay for linux-libc-dev, may you never die again
<lamont> mterry: there have been some more interesting events in the past, to be sure, though
<mterry> lamont: Fine.  How about, "May we live in boring times", then.  :)
<lamont> heh
<lamont> "oh meh.  rebuild the archive and then throw the old stuff away. kthx" being my personal favorite.
<mterry> :)
<maco> so uh, when syncing has the archive broken six-ways-to-tuesday and pbuilder can't pull dependencies does it make sense to test that packages builds by using jaunty?
<cody-somerville> maco, sure
<maco> ok thanks
 * maco waits
<geiseri_> grmbl... okay my installer starts now but it keeps complaining that ppoe is not installed.... even though i dont need it... did i screw something up in my preseed file?
<geser> maco: but be aware that it might fail in karmic even if it builds in jaunty
<maco> this early even?
<maco> i didn't think they'd diverged that far yet
<geser> new library versions or gcc-4.4 comes to mind
<cody-somerville> Should one use ${source:Version} or ${binary:Version}? ${binary:Version} will only ever mismatch ${source:Version} if the binary specifies a specific version, right?
<james_w> cody-somerville: or binary rebuilds in Debian
<cody-somerville> james_w, so I should use ${binary:Version} for arch:all packages?
<james_w> any -> all should be source:Version
<james_w> any -> any should be binary:Version
<cody-somerville> okay
<cody-somerville> thanks
<james_w> all -> any should be source:Version
<james_w> I *think*
<james_w> I know lintian knows the rules
<james_w> the last shouldn't be an exact dependency though
<geser> cody-somerville: http://lists.debian.org/debian-mentors/2006/09/msg00230.html and http://wiki.debian.org/binNMU should help you
<cody-somerville> Thanks :)
<james_w> *phew*
<cody-somerville> guh
<cody-somerville> This is going to get hairy
 * cody-somerville is fixing a package with 46 occurrences of ${Source-Version}
<cody-somerville> and mismatch of any and all packages
<cody-somerville> Hopefully lintian will help me
<cody-somerville> sweet, it does. :)
<cody-somerville> james_w, geser: Whats more correct? Lintian suggests to do (>= ${source:Version}) instead of using ${binary:Version}.
<geser> it probably depends on the use-case
<cody-somerville> ok
<calc> cody-somerville: >= ${source:Version} probably is better since it won't break cases where debian has to do binary NMU's (At least I think that is why there is a difference)
 * cody-somerville nods.
<geser> calc: but wouldn't that break -dbg packages? as you could use the -dbg package with a newer package
<Awsoonn> now that I have a debdiff for bug #312396 uploaded should I subscribe someone or e-mail someone?
<ubottu> Launchpad bug 312396 in gvfs "Nautilus opens files over SSH as read-only when not owner." [Low,Fix committed] https://launchpad.net/bugs/312396
<calc> geser: i'm not sure... wouldn't the dbg package be rebuilt as well in the debian case when a binary NMU is done?
<calc> geser: the issue (i think) that source:Version vs binary:Version tries to solve is when there are dependencies between any and all packages in the same source
<geser> calc: they would get rebuilt but the dependency wouldn't force to have matching versions installed
<cody-somerville> should an all -> all use source or binary version?
<calc> geser: ah well that is a good point in that -dbg packages probably should have binary:Version depends instead of source:Version, other things in particular any vs all packages shouldn't
<calc> cody-somerville: this is probably documented somewhere better than just going by my opinion :)
<calc> cody-somerville: though i think it should be safe using either for a all -> all dependency
<calc> cody-somerville: was lintian telling you to use source:Version on dbg packages that depend on other any packages?
<calc> if so that is probably a bug
<calc> although if it isn't i would like to hear the reasoning for that :)
<cody-somerville> No
<geser> source:Version would be more correct but as there aren't any binNMUs for arch:all packages binary:Version should also work
<cody-somerville> Its complaining about meta packages
<cody-somerville> ex., not-binnmuable-all-depends-any pike7.8 -> pike7.8-core
<calc> ok yea that makes sense
<calc> any time you cross the all<->any line you don't want a binary:Version (afaik)
<calc> or even a source:Version without the >= for that matter
<cody-somerville> Won't the source version stay the same though?
<cody-somerville> (everything is built out of the same source package)
<infinity> cody-somerville: The arch:all package might not get rebuilt in a binNMU
<infinity> cody-somerville: We don't actually DO binNMUs in Ubuntu, mind you, because all this mess annoys me.
<cody-somerville> won't the source version for both the rebuilt any package and the not-rebuilt all package be the same though?
<infinity> cody-somerville: But the correct thing for all->any is "Depends: package_any (>= SourceVersion)"
<infinity> cody-somerville: No, source version gets the binNMU version on a rebuild.
<infinity> cody-somerville: binNMU isn't magical, it just increments the source version and pumps through sbuild.
<cody-somerville> I thought binNMU was just bumping the binary version and not the source version *specifically*.
<geser> cody-somerville: yes, but you would probably be more strict than necessary if you use = source:Version
<infinity> cody-somerville: There's no way to do what you think it does.
<infinity> cody-somerville: binNMU is literally forcing the source version to rev slightly, then rebuilding.
<infinity> geser: "= source:Version" breaks, period.  It's not just "too strict".
<calc> infinity: you can rev the output version without changing the source version
<cody-somerville> infinity, I thought the whole point of specifying the version of the source package was to allow for the binary version to mismatch the source version
<calc> infinity: OOo does that itself
<calc> infinity: at least for the case where source version != binary version
<infinity> calc: You can specify versions yourself.  That's not what I'm talking about. :P
<calc> infinity: ok
<infinity> calc: The binNMU process literally just says "now our source version is 1.2.3-4+b1" and rebuilds.
<infinity> calc: What your rules file does with that source version is up to you, obviously. :)
<calc> infinity: won't that cause problems if a package has binary packages that has source:Version in it though?
<calc> infinity: eg (package all) >= source:Version ?
<infinity> cody-somerville: Yes, binary package versions and source versions can mismatch, and often do (see gcc-defaults for some serious fun there), but we're talking about different things here.
<cody-somerville> oh, okay
<infinity> calc: Hence why lintian has checks to make sure you don't use relationships that break on binNMUs. :P
<infinity> calc: And now we've come full circle!
<calc> infinity: hmm i thought it was suggesting to cody-somerville to put those in
<calc> infinity: instead of using eg (package all) binary:Version
<cody-somerville> It says to do: Depends: arch_any (>= ${source:Version})
<calc> infinity: if it actually increments the source:Version then that would break any kind of dependency on arch all packages form an arch any package that tries to do a version
<calc> cody-somerville: ok
<infinity> calc: any->all should pretty much never have a strict source-version dep, no.
<infinity> calc: all->any can have a source-version dep, but it needs to be >=
<calc> infinity: any-
<infinity> cody-somerville: Yeah, for your use case, that's correct.
<calc> infinity: any->all is common on packages who have their shared data split out though, so was that case really not catered for?
<infinity> calc: If you look at such cases, they never have strict deps.
<cody-somerville> infinity, Would you be kind enough to review my control file after I sort out all the binNMU errors out from lintian?
<calc> ah, well seems pretty boneheaded since that can easily cause major problems if not even the same upstream version is installed of the shared data :\
<infinity> calc: (First case I could think of, readline... libreadline5 has an unversioned dep on readline-common)
<infinity> calc: Like I said, there are reasons why I *always* push back against people who want to do binNMUs in Ubuntu, and it's not because I couldn't implement it in short order.
<infinity> calc: It's all very messy for very little reward, IMO.
<calc> infinity: yea
<infinity> calc: From the any->all data perspective, though, my best solution (and I've done this in the past) is "Depends: foo-data (>= $Upstream-Version)"
<infinity> calc: THat should tend to get you the correct data for the runtime, but not worry about debian revisions and other pain.
<calc> is Upstream-Version a defined variable or something you have construct yourself?
<infinity> There are lots of pre-defined ones now, and that may exist somewhere... I construct it myself, though.
<calc> ok
<\sh> a bit late...but congrats to 9.04...I was busy to congrats you all during release time :)
<Laney> congrats to you, \sh!
<cody-somerville> infinity, How does this look? http://pastebin.ubuntu.com/167087/
<\sh> Laney: thx :)
<infinity> Wow, pastebin.u.c has markup for control files?
<infinity> Or maybe it just sees it as rfc822 and goes from there.
<cody-somerville> infinity, sure does :]
<infinity> cody-somerville: How is this changed from grendel's original control files?
<infinity> cody-somerville: (I have a hard time believing his have been horribly broken for years...)
<cody-somerville> infinity, They were all =${Source-Version}
<cody-somerville> And the standards version was 3.6.2.1
<infinity> cody-somerville: At a glance, it looks fine to me.
<cody-somerville> infinity, Awesome, thanks
<cjwatson> geiseri_: make sure your Packages file is sorted alphabetically by package. (Yes, really - there's a bug filed about this somewhere ...)
<cjwatson> geiseri_: bug 362989
<ubottu> Launchpad bug 362989 in anna "custom ISO breaks due to d-i undefined behavior, Packages file ordering affects issue" [Low,Triaged] https://launchpad.net/bugs/362989
<cjwatson> geiseri_: you can just take ppp-udeb off your image as another convenient workaround; you almost certainly don't need it
<cjwatson> hppa buildds back on auto
<cjwatson> infinity: could you do a mass give-back on ia64 and sparc? they weren't affected by the linux-libc-dev breakage, so lamont didn't do a give-back on them, but there was an earlier problem there which made little things like debhelper and gettext uninstallable (due to some component override breakage) and so I think a give-back would be worthwhile
<infinity> cjwatson: Doing.
<cjwatson> ta. I eventually figured it was probably a waste of time having me click around ...
<infinity> cjwatson: Done.
<cjwatson> hmm. can I do a mass give-back, seeing as I'm an archive admin and in launchpad-buildd-admins? or does it need direct access to the buildds?
<infinity> cjwatson: You can probably do it, yes.  But you'd totally make me redundant if you did! :P
<cjwatson> heh
<infinity> Wow.  My brain just shot way in the past.  That can't be healthy.
<cjwatson> (in theory, I know how to do manual builds of single packages on the buildds. that doesn't mean I want to.)
<infinity> drescher.ubuntu.com: forward host lookup failed: Unknown host
<infinity> ^-- Seriously, what now?
<infinity> cjwatson: Anyhow, "buildd-mass-retry" as "lp_buildd" is the command you'd be after.
<infinity> cjwatson: Seems to work from cocoplum just as well as cesium, so.. *shrug*
<infinity> cjwatson: (And it behaves kinda poorly without arguments, so at least throw it a --help)
<cjwatson> fair enough, thanks
<jdstrand> slangasek, Riddell, kirkland, StevenK: has syncbugbot been working for you guys lately? it is failing with "message: An internal server error occurred. Please try again later."
<slangasek> jdstrand: it worked for me on Monday, after I grabbed a fresh lpcookie
<slangasek> LP had logged me out, the week before
<slangasek> kirkland said it wasn't working for him after a cookie change, though, so maybe something else is broken since Monday
<jdstrand> slangasek: yeah, I saw you mentioned that, but the sum on my cookie is the same
<jdstrand> hrm...
<cody-somerville> Whats the best way to deal with a package that requires its self to build?
<slangasek> care to give me a bug num for one you're trying to sync, I'll see if it works for me?
<jdstrand> slangasek: 371796 -f
<slangasek> cody-somerville: the best way is to fix it so it doesn't require that. :)
<slangasek> cody-somerville: the other option is to ask for manual bootstrapping by the buildd admins
<slangasek> jdstrand: WFM
<cody-somerville> slangasek, Does python require its self? I'm working on packaging pike7.8 and one of its module (which is included as part of pike) seems to require pike for a script it runs or something.
<slangasek> python does not.
<Adri2000> Keybuk: you around?
<calc> what is the buildd url on lp?
<cjwatson> calc: which buildd url?
<calc> i guess i was looking for launchpad.net/builders
<cjwatson> that's one possible meaning, yes :)
<calc> ok :)
<cjwatson> I thought you might have meant URLs for particular builds
<calc> wow big queues
<cjwatson> yeah, the give-backs will take a while to churn through
<Adri2000> Keybuk: never mind
<calc> ugh this OOo test build is taking forever :-\
<Nafallo> calc: you act surprised?
<calc> Nafallo: well it is taking longer than i expected, at 3.5hr and still unknown amount of time left
 * TheMuso sighs in relief at the new ports kernel working.
<calc> it finally finished and failed in the same way again
<calc> it builds on amd64 but not on i386/lpia due to claim that libgcj.spec missing
<calc> doko: ^
<calc> /usr/bin/gcj -c -g -O2 -fPIC -findirect-dispatch -fjni LuceneHelpWrapper.jar.1.jar -o LuceneHelpWrapper.jar.1.o
<calc> gcj: libgcj.spec: No such file or directory
<calc> but its there: /usr/lib/gcc/i486-linux-gnu/4.4/libgcj.spec
#ubuntu-devel 2009-05-09
<lamont> infinity/cjwatson "any soyuz host" is what I was told.
<infinity> lamont: Yeah, that seems to be correct. :)
<directhex> hm. is it slangasek or pitti whom i was talking to about /usr/share/doc/monofoo issues before jaunty released? i don't remember
<slangasek> yes
<directhex> i've convinced meebey to allow me to push a solution to clearing symlinks on upgrade to align with debian into the debian packages, on the proviso that i keep those changes strictly to ubuntu-only when building. that much i've done. so now i just want to get the preinst "right".
<directhex> iirc you weren't too happy with a blind "if [ -L /usr/share/doc/foo ] then rm -rf"
<slangasek> I prefer to have it guarded by a version check
<directhex> which is $2, isn't it?
<slangasek> also, there was some inconsistent use of quoting conventions
<slangasek> yes
<slangasek> (I think my comments on this were in the log of the sponsorship bug?)
<directhex> let me find the appropriate bug
<slangasek> bug #344750?
<ubottu> Launchpad bug 344750 in mono "Mono /usr/share/doc symlink problem" [Medium,Fix released] https://launchpad.net/bugs/344750
<directhex> yeah, just re-reading it
 * directhex pulls out dpkg --compare-versions
<cjwatson> infinity: for armel, in case you hadn't noticed, note that the kernel is still in NEW - I'm sorting out its overrides now
<cjwatson> (I see gcc-4.4 is still building anyway)
<infinity> cjwatson: GCC will be at it for a long while still.  But thanks for sorting the kernel.
<cjwatson> kernel's accepted now
<geiseri_> cjwatson: hrm, how do i make sure my packages file is sorted alphabetically?
<geiseri_> sort doesnt seem to cut it on multiple lines
<calc> geiseri_: sort-dctrl?
<geiseri_> will that work on a Packages file that i generate with apt-ftparchive?
<calc> geiseri_: i think so... you can try it anyway
 * geiseri_ will
<geiseri_> calc: like a dream
<geiseri_> do i need to make sure all of my Packages files are sorted, or just the one for the installer?
<calc> well regular apt-get doesn't need them to be sorted afaik
<geiseri_> okay
<calc> but i don't know about the installer
<geiseri_> cjwatson seemed to think that there was a bug associated with an unsorted Packages file
<calc> oh maybe there is, he would more likely know than me :)
<geiseri_> well everyone seems to know more than me when it comes to the guts of what is going on in the installer process
<geiseri_> :D
<calc> i used to know the guts of the installer process back around 2001
<calc> heh, but that was pre-Ubuntu and d-i
<calc> back with original debian boot-floppies, ugh
<geiseri_> haha, well at that point i was still drinking suse coolaid...
<geiseri_> i could tell you all sorts of things to do with that installer process :D
<geiseri_> the d-i stuff is very slick though from what i can see
<geiseri_> and the preseed is also very nice
<calc> yea it works much better than the old debian install process anyway :)
<geiseri_> well when you spend hours a day doing winders slipstream installers, this is a dream come true :D
<geiseri_> crap, even with the sorted package list it still blows up on the setting up of ppoe...
<geiseri_> hrm the real error is required package netcfg is not installed
<geiseri_> is the order in the Packages file the order udebs are installed on the system, or is that defined somewhere else?
<xee> Hi, I had some questions about creating a Ubuntu derivative, is this the correct place to ask?
<geiseri_> is there a way to set the order that the install steps are performed?  so that netcfg is installed and running?
<geiseri_> how does the debian installer decide what udebs to load and in what order?  Is that what the Packages file does?
<ia> hello. i have a question about apport - please, correct me, if i wrong. as far as i understand, if my app provides /usr/share/apport/package-hooks/<my_app>.py file, then, if my app will crash, apport will notify of such crash automatically and offer to send bug report, so i don't need to worry about adding in my app some extra code for bug reporting in crash cases, right?
<sbeattie> ia: not quite. apport collection of crash information is only enabled during the development cycle; it's disabled by default for releases.
<ia> sbeattie: yep, i know about it. so, in everything else am i right?
<sbeattie> ia: apport will do the collection for crashes or if ubuntu-bug is invoked on your software package and offer to submit it to launchpad regardless of whether /usr/share/apport/package-hooks/<my_app>.py exists or not; what adding it lets you do is automatically collect relevant information about your software and attach it to the bug report.
<sbeattie> ia: for example, you can attach your app's logfiles or configuration settings, which apport normally would not attach.
<sbeattie> ia: does that make sense?
<ia> sbeattie: yes :-)
<lifeless> ia: note that my_app is actually a package name
<lifeless> sometimes the package name differs from your app name, if your app is named generically, or with a name another package already has
<mpontillo> Do I understand correctly that when translating software into another language, the goal is to contribute to upstream as much as possible? (rather than cluttering debian/patches?) I'm thinking about how to best fix a bug that requires a change to a user-visible string. It's in the po files, but likely shouldn't have been. (string just "SSH")
<lifeless> mpontillo: 'ssh' or 'SSH' ?
<lifeless> 'ssh' is a command line tool name, and I'd agree with you, but 'SSH' is more of a noun..
<mpontillo> lifeless: "SSH". It's a string in a dialog box. It's "translated" into "SSH" for all languages except one, where it has some additional descriptive text in parentheses.
<lifeless> mpontillo: and whats the change you need to make to it to fix the bug?
<mpontillo> the bug description asks to change the text "SSH" to "SFTP".
<mpontillo> sounds simple enough ;)
<lifeless> assuming thats correct, do it ;)
<lifeless> if there are po files in the source package, updating their translations would seem appropriate to me. however! be aware that be build translations out of rosetta for Ubuntu main
<mpontillo> lifeless: right, so there are two strategies. I could s/SSH/SFTP/ in all the .po files. Or I could just change _("SSH") to "SSH"...
<mpontillo> *SFTP.
<lifeless> ITYM _("SSH") -> "SFTP"
<lifeless> right
<lifeless> I'd talk to the author about the _() removal
<ia> lifeless: yes, i know it. in fact, as far as i know, if my_app package is not part of ubuntu packages, opening page for bug reporting will looks like https://bugs.launchpad.net/ubuntu/+source/my_app/+filebug but should as https://launchpad.net/my_app/+filebug , right? if am i right, how i can change such behavior? latest version of apport have key for 3rd party software (if run it from terminal), but how i can enable "3rd-party-mode" for apport in my app, i
<ia> f it crashes incidentally and apport starts sending bug for this?
<mpontillo> lifeless: right. so I'd say that's a good plan, except for one fatal flaw. what if the text (written in Georgian (./po/ka.po:msgstr "SSH (á£á®áá¤ááá á¨ááá)") says "SFTP". then I'd be making a big mistake!
<mpontillo> sigh, I guess that's what I get for trying to pick something easy to learn how bzr package maintenance is done ;)
<lifeless> ia: I'm not sure
<lifeless> mpontillo: there is a translation today; only the ones that are identical can be machine updated to SFTP
<lifeless> mpontillo: the other one you should mark 'fuzzy' and machine update
<lifeless> that will indicate it needs review
<mpontillo> lifeless: ah, makes sense. where do I go to mark it "fuzzy"? is that directly in the .po file, or on a webapp on Launchpad somewhere? sorry for my ignorance; I've been reading docs, and have found pages on "how to translate", but not the process for manipulating strings as a developer that require translations
<lifeless> if you're patching at this level, I'd say the po file
<lifeless> but consider mailing rosetta-users, or lp-users or ubuntu-devel or ubuntu-motu for clarification
<ia> and another question - could anyone tell me, please, where i can find example snippets (on python and c will be more interesting), which sending crash information, even if crash haven't been occured? I'm talking about implementing "Report a Problem" menu item behavior. Of cource, i can use something like os.system('apport-gtk -f -p my_app'), but i think, that there is a little bit more elegant solution :-)
<mpontillo> lifeless: thanks, will do... looking at a .po file, I see there are translation notes in "#" comments (starting with "Translators:", etc) above each line to be translated, and they match /* */ comments above each string. now, I imagine those are all auto-generated, so I wouldn't want to break that process. I'll look around a bit to see how this works...
<mpontillo> ia: you could just do "apt-get source gedit", which has the "report a problem" menu item. looks like it calls out to /usr/share/gedit-2/gedit-bugreport, a script referenced by its .desktop.in.in file.
<lifeless> TheMuso: I've gotten some time to poke more at my raid signature
<lifeless> TheMuso: feedback solicited.
<cjwatson> mpontillo: maintainers don't normally edit .po files by hand. See the gettext documentation, but normally you can just edit the original source and then some Makefile will take care of it ...
<cjwatson> mpontillo: if you find you need to force it for some reason, then the command to update a .po file from newer source strings in a .pot file is 'msgmerge'
<cjwatson> mpontillo: you definitely shouldn't go about marking strings as fuzzy by hand
<cjwatson> infinity: artigas and sejong are both stuck building debian-installer, I think because silo.postinst is prompting
<infinity> cjwatson: \o/
<infinity> cjwatson: Words can't describe how awesome that is...
<cjwatson> and yet silo has not changed
<cjwatson> since, like, intrepid
<cjwatson> oh well, not going to debug it today
<infinity> The postinst unconditionally calls silo.conf if it's not an upgrade...
<infinity> And I've never had silo installed in the chroots.
<infinity> So...
<infinity> I'm at a loss.
<infinity> Setting up silo (1.4.13a+git20070930-1ubuntu1) ...
<infinity> Non-interactive, skipping silo configuration.
<infinity> And that's... Not happening anymore?
<infinity> cjwatson: Entirely possible that the chroots got their debconf frontend mangled at some point.  Let me kill these off and investigate that theory.
<infinity> cjwatson: If that seems to be the case, I'll upload fixed ones and retry the builds.
 * infinity scratches his head.
<infinity> cjwatson: This is kinda messed up.  Debconf is set correctly, and sbuild exports $ENV{'DEBIAN_FRONTEND'} = "noninteractive"
<cjwatson> I don't know of any debconf changes that might break that ...
<infinity> cjwatson: It's not a debconf issue.  Debconf isn't even running.
<cjwatson> indeed debconf hasn't changed since jaunty anyway :)
<infinity> cjwatson: /usr/sbin/siloconfig just checks $ENV{'DEBIAN_FRONTEND'
<infinity> }
<infinity> And sbuild hasn't changed in eons.
<infinity> Grr.
<infinity> Certainly not that part of it anyway.
<cjwatson> indeed it can hardly be a distro change since intrepid-proposed is breaking too
<infinity> Yeah.
<infinity> And I assume intrepid-release worked.
<infinity> I'm at a loss for it being a buildd change too, though, since they... Haven't changed since the last successful d-i build.
<cjwatson> let's check, best not assume sparc worked
<infinity> So utterly confused right now.
<cjwatson> but yeah, https://edge.launchpad.net/ubuntu/+source/debian-installer/20080522ubuntu28/+build/888434
<infinity> And an entirely unrelated failure in jaunty not that long ago.  But silo installed fine.
* cjwatson changed the topic of #ubuntu-devel to: Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<infinity> Hrm.  I bet I know what it is.
<infinity> cjwatson: Upgraded the buildds from dapper to hardy in that timeframe.
<infinity> cjwatson: I *bet* that sudo is no longer allowed the environment leak to the apt call.
<infinity> s/allowed/allowing/
<lifeless> random question, joining two pipes in shell, I've either forgotten how or its not as easy as it should be
<lifeless> (I have to processes A and B, I want all the output from A and then all that from B, to be piped into C)
<infinity> cjwatson: Testing a fix.
<infinity> cjwatson: (I'm shocked this is the first we've seen of this, if this is what I think it is...)
<infinity> cjwatson: Given that the x86 buildds have been hardy for two cycles now.
<lifeless> bah, I'm silly. (A; B) | C
<lifeless> bai
<infinity> cjwatson: Fixed on artigas, cowboying on sejong.  Will commit to rocketfuel when I'm more awake.
<infinity> cjwatson: Looks like sudo got a lot more strict about environment leak, and apparently NOTHING ACTUALLY CARED except for silo's postinst. :P
<infinity> cjwatson: Of course, your karmic build failed anyway, but not my fault this time. :P
<slangasek> so why is siloconfig not using debconf?
<infinity> Don't know and don't care?
<infinity> Though, I suppose that invoking debconf even just to check for the frontend is still saner than relying on magic environment.
<infinity> But whatever.
<infinity> Checking DEBIAN_FRONTEND in the environment isn't exactly unheard of. :P
<infinity> Just odd that nothing else cared enough to break.
<slangasek> sure - four years ago.  These days things are supposed to be using debconf, not just checking the variable. :)
<slangasek> that's why nothing else broke :)
<infinity> Oh, debconf got promoted to Required somewhere in the last century.  That does make the argument seem saner.
<infinity> I'm still living in the distant past where debconf was something "extra" I installed in my chroots. :P
<infinity> slangasek: If you want to fix silo, be my guest.  Since we still build for dapper, though, I'm going to keep my sbuild fix. :P
<slangasek> no, I don't want to go anywhere near silo :)
<infinity> No sense of adventure.
<slangasek> I'm afraid I'll fall in and suffocate to death amid the grain
<infinity> I find your pun unsatisfactory.
<infinity> Perhaps you need sleep?
<slangasek> perhaps
<infinity> I was tempted to stay up until armel's gcc build was done, but I can just sort all that in the morning...
<infinity> cjwatson: Please don't re-auto the armel buildds, even after GCC is in.  The current armel chroot has all sorts of mangling done to it, and I'm going to replace it with something saner in the morning.
<infinity> cjwatson: And your intrepid-proposed/sparc debian-installer built happily.
<cjwatson> infinity: impressively limited breakage. Thanks
<infinity> cjwatson: Yeah, in spite of vorlon's explanation, I'm still surprised that nothing else has exploded due to the variable going poof.
<infinity> cjwatson: But, whatever.  I'm happy it hasn't.
<cjwatson> I'm not likely to reauto the armel buildds anyway - I'm away until end of Sunday
<infinity> cjwatson: Works for me.
<mdke> When a point release is issued, does the proper name for a particular release include the point version? So is hardy called 8.04.2 or 8.04?
<mdke> the latter still, right?
<infinity> mdke: Depends on which proper name you're looking at.
<infinity> mdke: Check "lsb_release -a" on a hardy system, for instance.
<infinity> Description:    Ubuntu 8.04.2
<infinity> Release:        8.04
<infinity> mdke: The former is the official name/version, which includes the .2
<infinity> mdke: But the release version doesn't increment for the sake of sanity of any tools that might check against that number.
<Amaranth> 8.04.2 sounds like it should have been released 2 April 2008 :P
<mdke> I see that http://www.ubuntu.com/getubuntu/download uses 8.04
<mdke> what I'm looking at is whether, and if so when, in the documentation we should update version numbers
<infinity> mdke: In the docs?  Never, IMO.
<mdke> in some cases it's essential, because links to isos are broken (the iso has .2 in the name)
<infinity> mdke: Any links to download stuff end up symlinked with 8.04->8.04.$current anyway.
<mdke> http://cdimage.ubuntu.com/jeos/releases/8.04/release/ubuntu-8.04-jeos-i386.iso doesn't
<infinity> mdke: And do docs actually link directly to ISOs, rather than pages listing said ISOs?
<mdke> in one place, I think, bug 371773
<ubottu> Launchpad bug 371773 in ubuntu-docs "broken iso link on https://help.ubuntu.com/8.04/serverguide/C/jeos-initial-setup.html" [Medium,Triaged] https://launchpad.net/bugs/371773
<cjwatson> the directory is symlinked but the ISO basename isn't
<infinity> mdke: Yeah, I'd call that a bug in the way the docs are written, IMO...
<mdke> perhaps linking to the directory is a better solution, even if it requires the user to do a bit more work
<cjwatson> anyway, in general I think of 8.04 as the "series" and 8.04.2 as identifying a specific point
<mdke> doing a SRU for the serverguide each time a point release is released is a bit of a pain, especially because it requires translators to redo that particular string too
<mdke> or at least running sed over the translations
<mdke> infinity: so you'd recommend simply pointing to the directory and telling the user to wget the relevant file from the directory?
<infinity> mdke: As much as that's less hand-holdy, I'm seriously failing to see how someone who's expected to understand a CLI-based server with almost nothing installed (JeOS is very minimal) wouldn't be able to sort out an http directory listing.
<mdke> yes, I don't think there is a risk that someone could get that wrong
<infinity> Oh, there's always a risk.
<mdke> heh
<infinity> But, I'm in the "let them keep both halves" camp when it's not a desktop/simple use case.
<mdke> ok. And it seems clear that generally in other cases, 8.04 should be used
<mdke> as the generic name for the distribution
<infinity> I see no reason to document 8.04.2 as a version number anywhere, except to name images, and in base-files, no.
<infinity> It would be about as silly as the Apache section in the server-guide talking about apache_2.2.8-4ubuntu2, and needing an update on every security release.
<infinity> (Well, not quite, but you get the absurdity reduction there, I guess)
<mdke> not quite that silly, surely, but I get the point
<mdke> :)
<mdke> thanks for the assistanced
<mdke> -d
<popogomomo> one of ubuntu machines on network is throwing tons of dhcp inform packets making entire network slow
<popogomomo> how to disable it
<popogomomo> i have already disabled ip6 and sytem is using static address
<popogomomo> why its throwinhg dhcp inform packets
<popogomomo> how do i permanently disable dhcp in ubuntu
<popogomomo> how do i permanently disable dhcp in ubuntu
<popogomomo> its drwoning my network
<Chipzz> popogomomo: wrong channel
<popogomomo> i tried in ubuntu channel also
<popogomomo> looks like a bug
<Chipzz> not getting an answer in #ubuntu doesn't mean this is the place to ask; this is not an overflow channel for #ubuntu
<Chipzz> and te fact that it "looks like a bug to you" doesn't make this the right channel either
<popogomomo> is there any way stop ubuntu send dhcp infor packets ?
<popogomomo> i have removed dhcp client
<ia> hello. could anyone, point me, please, at python snippets, which sending crash information, even if crash haven't been occured? I'm talking about implementing "Report a Problem" menu item behavior. Of cource, i can use something like os.system('apport-gtk -f -p my_app'), but i think, that there is a little bit more elegant solution :-) results like this http://www.google.com/search?hl=en&newwindow=1&q=usage+python-apport tells me nothing, but i suppose, tha
<ia> t for adding apport support i should write in my py file something like "import apport" and add calls of functions from apport python module, but how exactly i should do this? i will be very appreciate for any clues. and, probably, such information will be very useful for apport's ubuntu wiki page. and excuse me for annoying.
<popogomomo> why dont ububtu dev write utility in java rather slow and wiered python
<popogomomo> python sucks
<trip0> hmm... that's really subjective
<trip0> as a developer who doesn't regularly use either, I can appreciate both
<trip0> python syntax requires getting used to... especially if you are coming from a  c style language like java.
<popogomomo> i find java more productive and easy
<popogomomo> also much more easy to maintain
<trip0> both are very productive, 4th gen languages.
<trip0> depends on how much experience you have though
<trip0> a VB.NET programmer may be more productive in VB than he would in java
<popogomomo> quality of code and maintainability is always better in java .......................
<popogomomo> also tools like IDE , frameworks impact productivity which is ample in java world
<jdstrand> slangasek, Riddell, kirkland, StevenK: syncbugbot still causing me problems. maybe launchpadbugs needs an update?
<jdstrand> slangasek, Riddell, kirkland, StevenK: the problematic lines are:
<jdstrand> b.comments.add(Bug.NewComment(text=''.join(output), subject=b.title))
<jdstrand> task.set_status("Fix Released")
<jdstrand> slangasek, Riddell, kirkland, StevenK: fyi, if you hit this I worked around it by commented those out and closing the bugs manually
<jdstrand> slangasek, Riddell, kirkland, StevenK: the problematic lines are: well, I also commented out 'b.commit()' immediately after the above two lines, since there was nothing to commit
<jdstrand> s/the problematic lines  are:
<jdstrand> meh
<kirkland> jdstrand: ah, i hit that too, on Wednesday, was asking about it
<kirkland> jdstrand: i tried updating my launchpad cookie, as it was obviously a problem in the launchpad communications
<kirkland> jdstrand: i gave up on syncbugbot, and just did the syncs manually
<kirkland> jdstrand: and the bug closes
<kirkland> jdstrand: i think it might be worth getting pitti  to have a look at it :-)
<directhex> slangasek, are you here today? can you give me feedback on a preinst before i commit to git?
<jdstrand> kirkland: I think it may be a simple as updating python-launchpadbugs, but we'll see
<kirkland> jdstrand: bdmurray is pretty good with python-launchpadbugs, as I understand it :-)
<jdstrand> kirkland: I familiar with it too, the issue isn't the use of it, but rather plb itself is dying
<jdstrand> I'm
<jdstrand> kirkland: but, we can see on monday
<calc> it looks like armel needs to be set back to auto
<Q-FUNK> I welcome suggestions for an appropriate package to reassign bug #374140 to. :)
<ubottu> Launchpad bug 374140 in upgrade-system "on 8.04 success install cant upgrade to 8.10 because via/openchrome frezz screen" [Undecided,New] https://launchpad.net/bugs/374140
<ash211> Q-FUNK: looks like a driver issue to me
<ash211> ask the poster for the relevant info in https://wiki.ubuntu.com/X/Reporting
<ash211> I think by "frezz" they mean "freeze" :)
<Q-FUNK> yup, it indeed looks like one, but it was reported against the entirely wrong package
<Q-FUNK> yup
<ash211> it's understandable why it went against upgrade-system instead of any driver package
<ash211> that's the program the person used right before it messed everything up
<ash211> (oh nvm, that's the only bug reported against that package, so it must not do what I think it does)
<jdstrand> slangasek, Riddell, kirkland, StevenK, pitti: it just occurred to me that I have some launchpad api code I can steal/use to get syncbugbot working again-- I'll do that first thing on monday
<Q-FUNK> ash211: people regurlary report whatever went wrong during an upgrade against package 'upgrade-system', when there instead should be a separate task to report failed upgrades against.
<Q-FUNK> this is just one of many such occurences
<Q-FUNK> I get a bunch of similar reportes every 6 months, whenever a new ubuntu release comes out - always against package 'upgrade-system'
<a|wen> what is the status of libboost1.37 in karmic, can see that it is in main now ... is it okay to use, encouraged to use, or ?
<james_w> encouraged
<a|wen> okay, thx
<calc> a|wen: we will hopefully get boost1.38 working as well to transition to for karmic
<a|wen> calc: okay... you are the person to talk to for boost?
<calc> a|wen: no, i just looked into it since OOo uses it also
<calc> a|wen: debian wasn't to transition off of boost1.37 so it would be good once boost1.38 can actually build to switch to using it
<a|wen> calc: okay ... thx for info :)
<calc> a|wen: its probably failing to build for us due to using gcc 4.4
<a|wen> calc: most likely ... boost 1.35 looks to be busted as well :(
<calc> yea
<calc> i had to switch OOo to use 1.37 which is why it is in main now
<a|wen> calc: okay; then no wonder i can't make it due much
<a|wen> do even
<calc> they already released 1.39 upstream but still haven't apparently tested it against gcc 4.4 yet
<a|wen> we'll see what happens; i'll switch to 1.37 for now as well then
<calc> there is at least one patch in their bug tracker to fix gcc 4.4 issues
<ScottK> That might be what 1.38 needs.
<calc> hopefully the debian boost people package 1.39 soon then we could just jump to that after any needed gcc 4.4 fixups
<calc> it was released a week ago
<a|wen> 1.37 seems to work "okay" at least
<calc> https://svn.boost.org/trac/boost/ticket/3008 <- gcc 4.4 bug i found
<a|wen> calc: well, compared to 1.35 it is luxury ... this is the file failing for me on 1.35 http://pastebin.com/f44e80488 :(
<calc> heh
<LaserJock> ScottK: any chance of having 1.38 or so in -backports?
 * calc thinks he knows a way to club OOo into building on i386/lpia
<calc> i can just disable gcj entirely, heh :-\
<highvoltage> hey LaserJock
<LaserJock> highvoltage: hola
<kklimonda> what was called the utility which manipulates .diff files?
<geser> in which way manipulate?
<kklimonda> I have a big diff and I'd like to get part of it (only diff for .cc files to be exact)
<geser> filterdiff
<kklimonda> thanks
<Draconicus> I have a small suggestion for the #ubuntu channel's management, and this is the only sane place I can think to present it.
<Draconicus> Ever thought of splitting the channel up with freenode managing an automatic redirect based on a user cap?
<Draconicus> Like #ubuntu1 #ubuntu2 and #ubuntu3 - you already have an overflow channel, but #ubuntu remains massively overpopulated and very difficult to work in. There are plenty of assistants to go around these days.
<Draconicus> I'm sure I'm not the first to suggest this... Perhaps it's futile to try.
<LaserJock> Draconicus: I think #ubuntu-irc might be a better place
<Draconicus> Oho. Sorry. :P
<Nafallo> LaserJock: #ubuntu isn't a loco channel, no :-)
<Nafallo> LaserJock: #ubuntu-ops
<slangasek> jdstrand: hrm, it's still not working for you?  works fine here - you know that you need a cookie for !edge, right?
<slangasek> jdstrand: anyway, launchpadlib isn't really an option, you can't sanely run launchpadlib stuff remotely...
<kklimonda> #ubuntu-irc will be a better place for this discussion
#ubuntu-devel 2009-05-10
<slangasek> doko: I see that calc has assigned bug #373911 to you; will you have time to work on this in advance of alpha 1 (which basically means getting it done by Monday), or should I have a look?  (Or should we defer it until after alpha-1, to avoid OOo breaking the world once we unblock it? :)
<ubottu> Launchpad bug 373911 in gcj-4.4 "gcj fails to build OOo 3.1.0 on i386/lpia due to claim that libgcj.spec missing" [High,Triaged] https://launchpad.net/bugs/373911
<slangasek> I guess the immediate problem can be fixed just by merging up gcj-4.4
<slangasek> calc: ^^
<slangasek> waaah, 7 digit soyuz queue numbers :(
<Nafallo> hmm.
<slangasek> E: collectd: shlib-with-non-pic-code usr/sbin/collectdmon
<slangasek> so very wrong :P
<directhex> slangasek, how does http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commitdiff;h=88098645f7292133a52c5bc068b8fcdc94b12d4e look in terms of mono preinst stuff?
<slangasek> directhex: "dpkg --compare-versions [...] && if"?
<slangasek> directhex: "if dpkg --compare-versions [...] &&" would be more idiomatic
<slangasek> directhex: btw, I think it would look cleaner if instead of generating this snippet in debian/rules, you had a copy of it as a separate file under debian/ that you could append as needed
<directhex> howso?
<slangasek> hmm?
<directhex> you mean pull in a preinst template rather than using echo?
<slangasek> yeah
<slangasek> with a sed for the $$p bits
<slangasek> the existing code is fine, I'm just generally averse to doing significant bits of scripting directly in a Makefile on account of the escaping requiremenst
<directhex> yeah, there were an awful lot of try/retry iterations to get it right
<directhex> i'll look into it tomorrow
<mrhoden2009> Does anyone know how to do RAID configurations on Ubuntu, I have a few questions.
<wgrant> mrhoden2009: You want #ubuntu.
<mrhoden2009> thanks, I tried there but without much luck
<mrhoden2009> do you know a better channel?
<wgrant> I'm not sure, but certainly not here.
<mrhoden2009> I tried ubuntu-server as well
<mrhoden2009> lol okay thanks
<calc> slangasek: i have a workaround that i think i may use... turn off using gcj entirely in OOo
<calc> slangasek: gcj seems to be fairly crap in any case so getting rid of gcj support in OOo isn't really a loss afaict
<maco> calc: mm? what's gcj do that's silly to OOo?
<calc> sorry my desktop stopped accepting keyboard input and my laptop didn't fully work after resuming
<calc> maco: so the issue is bug 373911
<ubottu> Launchpad bug 373911 in gcj-4.4 "gcj fails to build OOo 3.1.0 on i386/lpia due to claim that libgcj.spec missing" [High,Triaged] https://launchpad.net/bugs/373911
<calc> maco: it seems that gcj does not work properly on i386/lpia or perhaps when used with aotcompile
<calc> maco: aotcompile.py is part of gcj though so probably should work, and OOo relies on it working to compile native jars
<maco> fun...what is .spec in terms other than rpm packaging?
<calc> it tells libgcj how to do linking
<maco> ah ok
<calc> the file is actually there or at least should be, its there on my test chroot but gcj seems to be unable to find it
<calc> hmm my keyboard wasn't actually dead it seems firefox ate it
<maco> ive been running into that problem with Qt apps a lot
<calc> i killed firefox and then logged out and back into X and everything works fine again
<maco> type type type and nothing shows up
<maco> ah i just have to change window focus about 10 times or so, then my kbd works again. killing the app thats rejecting input also works
<calc> maco: it ate it to where i couldn't even get a terminal to work
<calc> yea killing firefox in this case seemed to help
<calc> it also seemed to cause my mouse not to work correctly either probably the same issue
<calc> anyone else get a 'disable advertising' button on /. ?
<FloridaGuy> hey guys....keep up the great work....9.04 has approved alot..in preformence..speed...lolks
<DShepherd> hello all
<poningru> 'lo
<DShepherd> my hibernate works! finally! who can i thank for this!!
<DShepherd> it just .. works outside of the box with jaunty
<DShepherd> and I am really thankful. Give me some names .. something.. i wanna thank them for this
<Amaranth> DShepherd: It was all me ;)
<Amaranth> DShepherd: I waved a magic wand over it
<DShepherd> hehehe
<Amaranth> Seriously though, that'd be the kernel team and/or the guys who work on your graphics driver
 * DShepherd praise Amaranth 
<DShepherd> nvidia card here...
<DShepherd> i dont think I am using the opensource driver here
<DShepherd> Amaranth, but thanks for the direction though. I am in ubuntu-kernel channel now
<slangasek> calc: er, I don't see the basis for saying that gcj is "fairly crap".
<slangasek> calc: it just happens to be out of sync with gcc 4.4 right now, as I said.
<DShepherd> Amaranth, dont you do some nvidia driver work?
<Amaranth> DShepherd: nope, in the dapper days I packaged a driver in my PPA that supported GL_EXT_texture_from_pixmap but otherwise I stay away
<DShepherd> Amaranth, ah ok.
<nixternal> mneptok: you sure have a lot of nerve talking about pie on the planet, at least you tried to calm the Chicago waters here, but I have an army who is ready to fight for best pie :p
<jussi01> nixternal: I want pie... give me some!
<nixternal> mmmmm, spacca's tomorrow for some good ol' pie and beer....pizza maffia style :)
<mneptok> nixternal: Chicago pizza isn't pie. it's dough with some red stuff on top. >;)
<nixternal> oh man, you are asking for it!
 * nixternal whistles and summons up the good fellahs
<nixternal> nhandler: help me out dude, lets do this Chicago style!
 * mneptok looks around ABQ and Rio Rancho
<nixternal> hehe
<mneptok> prolly more mafiosi here than there ;)
<nixternal> all you have done there is the sun!
<nixternal> mneptok: depends, can we count the ones who just went to prison here?
<mneptok> three words. "In Plain Sight"
<mneptok> Blagojevich is Italian? >;)
<nixternal> mneptok: they don't count, they are all down there as Paul Smith in witness protection :P
<nixternal> no, blago is just stupid
<mneptok> like Chicago pizza.
 * mneptok runs
<nixternal> oh mna
<nixternal> man
 * nixternal whistles louder
<slangasek> mneptok: OOI, how does "New York, New York" rate on your scale of Portland pizzerias? :)
<slangasek> (and if you know better, please share :)
<mneptok> slangasek: no idea. never been there.
<mneptok> slangasek: if the crust is more than a pinky finger thick, and shows no sign of burning, it's crap. :)
<slangasek> heh
<slangasek> of course it's not more than a pinky finger thick :)
<slangasek> it's New York style, not Pizza Hut style
<mneptok> Pizza Hut isn't pizza. it's ketchup on a bagel with a genetic defect. >:P
<slangasek> lool, doko: I'm having a poke at the gcj-4.4 merge, so that gcj can find its .spec file again, and I'm confused about how it's supposed to be configured on armel because the changelog says "build with --with-float=softfp --with-fpu=vfp", and the debian/rules disagrees - which way is this supposed to be?
<lool> slangasek: We deferred these changes
<slangasek> ok
<lool> slangasek: To only switch when we move up to >= armv6
<lool> Until then, we have compat with non-vfp systems
 * slangasek nods
<lool> Thanks for the merge!
<BUGabundo> pitti: ping. I can't file a bug on apport using apport
<doko> slangasek: preparing an upload now
<MaximLevitsky> I have a patch to fix small bug in open-terminal extension
<MaximLevitsky>  https://bugs.launchpad.net/ubuntu/+source/nautilus-open-terminal/+bug/333462
<ubottu> Ubuntu bug 333462 in nautilus-open-terminal "nautilus crashed with SIGSEGV in strlen()" [Medium,Confirmed]
<MaximLevitsky> How to get it included?
<poningru> MaximLevitsky, attach the patch
<poningru> to the bugreport in launchpad
<MaximLevitsky> poningru: I did so
<MaximLevitsky> a debdiff that is
<poningru> ping one of the core devs? though that is frowned upon iirc
<MaximLevitsky> poningru: isn't there a standard way to mark a bug report as fixed/patch attached ?
<MaximLevitsky> I assigned it to ubuntu-main-sponsors in hope that will help
<Hobbsee> subscribe ubuntu-main-sponsors, and they'll sponsor it
<Hobbsee> (please don't assign them)
<MaximLevitsky> Hobbsee: ok, done
<wgrant> https://wiki.ubuntu.com/SponsorshipProcess
<MaximLevitsky> this package belongs to universe
<MaximLevitsky> so can I unsubscribe main sponsers/
<MaximLevitsky> ?
<james_w> dear fellow archive admins: diffstat isn't installed, which seems to prevent me from running lintian, that's not just me right?
<jdstrand> slangasek: re launchpadlib remotely> I run it just fine remotely here-- am I missing something?
<soren> How do you run launchpadlib non-remotely?
<calc> slangasek: 'fairly crap' was with regards to it causing quite a few bugs over the years with OOo due to not being good enough compared to java spec
<calc> slangasek: before we converted over to using openjdk for OOo we would get bugs about java related code not working correctly on a fairly regular basiss
<directhex> does openjdk run on all arches yet?
<calc> directhex: it apparently has issues on ia64 but afaict I am using it for all other archs now
<calc> directhex: ia64 is still using gcj :\
<calc> i've seen bugs even recently about gcj usage when people have installed the ooo-gcj package so getting rid of it would probably not be a bad thing
<directhex> calc, how odd, sun re-released an ia64 version of java 6 very recently
<directhex> after a big java-shaped drought for itanic users
<calc> directhex: i didn't set ia64 to use gcj rene did, so i'm not entirely sure why he did that, probably due to some bugs
<directhex> perhaps
<calc> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502422
<ubottu> Debian bug 502422 in openoffice.org "openoffice.org_1:3.0.0-2(ia64/experimental): UNO calling Java" [Serious,Closed]
<calc> that was why he disabled openjdk on ia64
<Chipzz> calc: 'fairly crap' is also how I would describe OOo as a whole
<calc> Chipzz: true :)
<Chipzz> OOo is software nobody really wants to use, but uses at a lack of better alternative
<calc> Chipzz: but a java compiler that doesn't compile valid java isn't particularly useful
<Chipzz> yeah
<directhex> Chipzz, waiting to see what happens next w/ Oracle and OOo
<Chipzz> but then, 'fairly crap' is /also/ how I would describe Java as a whole
<directhex> mildly amusing that sun java can't compile sun openoffice, but hey ho
<Chipzz> :P
<directhex> i don't think i can describe java in those terms without starting a CoC debate
<Chipzz> Java is an academic experiment ran out of hand :P
<directhex> java is a trailblazing pioneer
<maxb> Yup. You look at some portions of its APIs, and you think "What *idiot* designed this?"
<calc> looks like doko already fixed gcj for me though so i can retry the builds :)
<calc> directhex: openjdk isn't really sun java, its sun java that has been modified to some extent
<directhex> maxb, i think java combines wild-eyed innocence at its newness, with a very very long backwards-compatibility approach. this may be considered "bad"
<Chipzz> amusingly, for a lot of things I've tried it for, gnumeric and abiword work at least as good/better than OOo
<calc> directhex: afaik sun java itself does build OOo but is non-free so we don't use that
<meoblast001> hi
<meoblast001> i have a question of whether something would be possible or not
<Chipzz> have you tried asking on #ubuntu first? :P
 * calc agrees with the intrepreted languages being not particularly useful (esp due to being very slow) debate ;-)
<meoblast001> i often have a lot of development packages on my system that i only use once
<meoblast001> would it be possible for computer janitor to eventually remove those
<Chipzz> meoblast001: apt-get auto-remove
<Chipzz> now go to #ubuntu please :)
<meoblast001> ok
<Chipzz> (may also be autoremove with the -)
<Chipzz> weird how you can just *feel* that whatever someone is going to ask will be off-topic even before they ask it
<maxb> It must be said #ubuntu is somewhat useless due to its own success :-/
<maxb> One of benefits of running the development release is the ability to use #ubuntu+1 with a clearl concience :-)
<directhex> i ba=rely trust karmic in a pbuilder yet, let alone on a real pc
<calc> maxb: even better to just build in chroots then you don't cruft up your system to begin with
<Chipzz> calc: it's not so much the interpreted nature of java (which isn't even 100% true to start with) I have a problem with
<Chipzz> python is interpreted too
<calc> yea python is slow too :)
<Chipzz> and so is .net
 * calc used to have a link comparing various languages speed 
<Chipzz> mono is a lot faster compared to java last I tried
<calc> yea
<calc> iirc python was something like an order of magnitude slower than c at least in some areas
<Chipzz> one of the few things I don't fault M$ for
<directhex> mono is faster in many cases, but has a juch slower GC
<calc> and .net was a few times slower and java a few times slower than .net
<directhex> python is ~60x slower than mono
<calc> .net being a few times slower than c
<Chipzz> but then, the benchmarks you ran probably aren't very relevant to real world use
<Chipzz> in practice, most of the time, be it in Java, .Net or Python is spent in bindings (ie native code)
<Chipzz> and I doubt there are benchmarks comparing the same program in gtk+, pygtk, gtk# and java-gnome
<calc> yea and for mostly gui programs you just need fast enough code
<calc> most apps aren't cpu bound, they just wait for user input all the time
<Chipzz> and like I said, even the user input waiting happens in C :p
<directhex> Chipzz, and where most time is spent waitring for user input, the important factor shifts to "does writing this code give me a hernia?"
<Chipzz> personally I decide what language to write a program in based on whatever is most suited/fits the idiom best
<Chipzz> or amounts to the least lines of code
<Chipzz> (excluding whitespace/semiwhitespace/comments)
<Chipzz> semiwhitesspace -> things like { and } in C for example
<Chipzz> if (foo)
<Chipzz> {
<Chipzz> bar;
<Chipzz> }
<Chipzz> would be counted as only 2 lines
<calc> slangasek: do you happen to know what is wrong with libltdl7-dev on powerpc i got the same build failure for OOo as the other one that was an arch mismatch but i didn't see it in the mismatch file
<calc> slangasek: http://launchpadlibrarian.net/26510428/buildlog_ubuntu-karmic-powerpc.openoffice.org_1%3A3.1.0~rc2-1ubuntu1_FAILEDTOBUILD.txt.gz
<james_w> calc: that package doesn't exist in karmic
<james_w> probably libltdl-dev now
<calc> james_w: ok
<calc> so then i guess unixodbc is bugged because the last version uploaded specifically depends on libltdl7-dev :\
<calc> "  * (Build)-depend on libltdl7-dev to fix dependencies on armel."
<james_w> well that was an upload to jaunty
<calc> well is now buggy rather since it needs to be updated
<calc> hmm no libltdl-dev provides libltdl7-dev
 * calc checks when libtool was last built on powerpc
<calc> ah it probably was built after OOo failed
<geiseri_> hi, i have a problem with my own generated ftp-archive generated package set, i can debootrap the sysetem, but tasksel fails because it cannot fund task minimal.  i am assuming i missed a step, but i cannot for the life of me figure out where.
<geiseri_> any ideas on my problem?
<geiseri_> what is really strange is i can run the tasksel command and it asks me to select the openssh server
<geiseri_> could the problem be in my preseed file?
<geiseri_> in reality i do not even want tasksel to run at all since i have a full package list i would rather have installed
<vart> I am trying to use kernel set_memory_ro method from asm/cacheflush.h, but it fails when I am doing insmod, says "unknown symbol set_memory_ro", I am using ubuntu 9.04
<dtchen> TheMuso_: linus has merged the last of the stable 1.0.20 alsa-kernel bits.
<maxb> dtchen: Would you perhaps be able to suggest on what package I should report popping/crackling audio *only* when playing from DVDs (on karmic)?
<dtchen> maxb: start with the player, and we'll triage from there
<maxb> hmm, I have reproduced the same in totem and mplayer
<dtchen> maxb: which output was mplayer using?
<dtchen> (-ao pulse or -ao alsa?)
<maxb> I tried it with -ao alsa and -ao pulse, it sounded the same in both cases
<dtchen> then it's pulseaudio or lower
<dtchen> i'd file one affecting pa
<maxb> Ok, will do then, thanks
<geiseri_> *sigh* this tasksel bug is driving me nuts, is there any documentation on how these things work beyond the stock debain installer information?
<geiseri_> it seems there are a few parts missing
<geiseri_> its seems that no matter what is in my preseed file it cannot find task minimal... and its not clear how these tasks are defined from what i can see
<slangasek> jdstrand: how is launchpadlib supposed to launch your browser for the authentication callback?
<slangasek> calc: well, gcj is already fixed now thanks to doko, so there's no reason to drop OOo-gcj as a quick-n-dirty workaround here.  If it should be dropped on its own merits, then fine...
<slangasek> calc: the libltdl7-dev thing was actually that the real libltdl7-dev package was still in the archive but uninstallable; now that it's NBSed out, things should build fine
<james_w> slangasek: you can copy over an auth token just like we do with the cookie
<slangasek> james_w: ah.  well, AFAICS, that's the part that's been Not Working with syncbugbot anyway :)
<james_w> true :-)
<geiseri_> is there a better channel to ask questions on how to customize the installer?
 * ScottK thinks #ubuntu-installer exists.
<geiseri_> its pretty dead in there
<ScottK> !weekend
<ubottu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<geiseri_> hmmm... is there any online documentation on the changes that ubuntu makes to the debian installer that i could look into?
<geiseri_> i am not finding the right google keywords it seems
<a|wen> geiseri_: look in the changelog
<geiseri_> is there a package for the debian installer itself?
 * a|wen would without looking guess at debian-installer
<geiseri_> there is one afaik but i think its like simple-ccd or debian-cd, they are not ubuntufied
<james_w> debian-installer is lots of packages
 * geiseri_ will look again
<geiseri_> i mean i didnt think what i was doing was that hard to do... all i needed was a cd that booted up and installed ubuntu onto a system with a set partition scheme, and package list...
<a|wen> it is not the OEM option you are looking for?
<geiseri_> if it worked it would be close... the rub is im trying to add a few extra packages that are not on the base install
<geiseri_> it seems though when i change the package list all sorts of things break for non-obvious reasons
<calc> slangasek: yea i saw, i think i will just keep it around now
<calc> slangasek: i'll be watching to see if it fails for any other reason and try to get it fixed in time for alpha 1 (tomorrow night is effectively freeze aiui)
 * calc hopes the mass give back doesn't delay the alpha 1 release
<a|wen> calc: working boost1.35 :)
<calc> several of the buildds have 400+ packages still left to build
<a|wen> if anyone has time to sponsor some boost updates to get things into shape (working) again it would be nice :) most importantly bug 373962 and also bug 371617
<ubottu> Launchpad bug 373962 in boost1.35 "merge boost1.35 1.35.0-10 from debian unstable (main) - mpl headers not compiling" [Undecided,Confirmed] https://launchpad.net/bugs/373962
<ubottu> Launchpad bug 371617 in boost1.37 "Installs files to /build/buildd" [Undecided,Confirmed] https://launchpad.net/bugs/371617
<sveinung_> Hello! I'm trying to get a fix for bug 345706 into Ubuntu main. This is the first time I have tried to get anything into Ubuntu main.
<ubottu> Launchpad bug 345706 in packagekit "CMake can't find QPackageKit by default" [Undecided,Triaged] https://launchpad.net/bugs/345706
<sveinung_> I have already done one mistake. (I assumed I needed permission from those responsible for the package before I could subscribe main sponsors) Could anyone check if I have done others?
<sveinung_> By the way: How long should a package be in Karmic before I can suggest a sru to jaunty?
<sveinung_> anything I can do better (more details in the bug report etc) to increace the chanse of it getting in?
<TheMuso_> dtchen: thanks for the heads up.
<dtchen> it amuses me slightly that alsa-tools 1.0.20 lacks all the necessary autotools bits
<dtchen> there's a gitcompile script...and nothing else.
<dtchen> pitti: i'm afraid 345627 is going to have to be tagged verification-failed; even though linux-2.6.28-12.43-generic fixes the symptoms for some users, it presents an awesome regression for others. i feel it's better to live with known breakage than introduce a regression.
<TheMuso_> dtchen: heh well that shouldn't be a problem.
<jdong> dtchen: that's a shame
<jdong> it seemed to make audio a bit less blippy for me in skype under heavy load
<jdong> maybe like all this other audio stuff it's placebo effect :)
<dtchen> jdong: yeah, well, rock..hard place.
<jdong> understood
<dtchen> there's still so much more work to get the _drivers_ stable, much less upper parts of the stack.
<jdong> I see
<lifeless> IIRC 70+% of the bugs of linux [kernel] are in drivers
<jdong> well that's probably where all the sloppy "quick get it out" coding happens.
<jdong> and the long nights with coffee spent futzing with registers until something magically starts working.
<lifeless> dtchen: does alsa-tools still use autoconf?
<lifeless> dtchen: just doesn't ship configure?
<TheMuso_> lifeless: yes I would think so
<lifeless> TheMuso_: so would I, I'm trying to be sure ;)
<lifeless> TheMuso_: also, the ataraid list fails :)
<TheMuso_> lifeless: you're telling me. No response from upstream re your issue.
<TheMuso_> I can't help wondering whether they have abandoned dmraid for the new metadata support going into mdadm 3 or some such.
<lifeless> if so it would be nice to TELL THEIR USERS
<TheMuso_> agreed
<lifeless> anyhoo
<dtchen> lifeless: it normally ships configure. however, it [1.0.20] only ships a one-line gitcompile script. it lacks Makefile.am, configure.ac, ...
<dtchen> kinda fail.
<lifeless> dtchen: wow
<lifeless> TheMuso_: ^ file under assumptions :O
<lifeless> TheMuso_: is danwood76 the debian maintaer of dmraid ?
<TheMuso_> lifeless: no
<lifeless> who then - some random?
<TheMuso_> dtchen: I'd say 1.0.20a or some such will be out within days.
<TheMuso_> yeah
<lifeless> TheMuso_: so I'll whip up a decoder for what appear to be magic bytes on my drives; will you be happy to apply that?
<TheMuso_> lifeless: Sure. I'd say the debian maintainer will be interested as well. I'll be committing it to Debian and karmic, then I'll SRU it for jaunty.
<lifeless> cool
#ubuntu-devel 2010-05-10
<slangasek> cjwatson: hmm, most likely a winbind bug
<slangasek> cjwatson: (re: 576717)
<slangasek> ccheney: the crash is immediate upon trying to switch to slideshow mode
<duongthaiha> hi I am doing some coding with java any one please could give me some advise about java profiler in ubuntu please? Thanks a lot
<hyperair> hohoho java. good luck.
 * hyperair 's sanity level: 30%
<hyperair> i blame it all on java
<duongthaiha> hyperair: is there any wrong with java?? :P
<hyperair> duongthaiha: everything you can think of is wrong with java.
<hyperair> *everything*
 * hyperair highlights, bolds, and underlines everything
 * hyperair circles it even
<duongthaiha> hyperair: java is quite good may be it not the fastest but it work
<hyperair> meh, programming in java is robbing me of my precious sanity
<hyperair> in the last 24 hours:  15 files changed, 620 insertions(+), 243 deletions(-)
<hyperair> all that is java
<rafiyr> I'm not sure which is worse to see, C programmers trying to use java, or java programmers trying to use C.
<rafiyr> I guess I've seen one example of a (supposed) java programmer writing C that probably trumps.
<hyperair> rafiyr: how about C++ programmers forced to use java.
<hyperair> a java programmer writing C is going to nullify all pointers everywhere and expect them to free themselves
<rafiyr> hyperair: hm, that's a toughy
<hyperair> and then complain that there's no System.gc()
<hyperair> well, to summarize: C programmers trying to use java = nothing but static functions. Java programmers trying to use C = memory leaks every damn where, which... hey, isn't too far from using Java straight off.
<hyperair> considering how much memory Java takes
<hyperair> for the love of god, i don't even have a single large data structure worth talking about, and my swing/AWT UI is already taking up nearly 100M of memory.
<rafiyr> A couple weeks ago, I helped a labmate debug a C++ header problem.  The class definition had ifdefs that were indirectly effected by the compile command line.  Missing one flag, the application that was trying to use the classes was seeing different offsets in the class.  Not particularly happy with c++ atm.
<duongthaiha> hyperair:  there is a trade off of thing that java and C can do. I presume that you love C++ and hate java so much to say
<rafiyr> hyperair: fish out of water, or drowning mammal, neither really work.
<hyperair> rafiyr: yes, agreed.
<hyperair> duongthaiha: good guess.
<hyperair> duongthaiha: but my course requires java. so i do it grudgingly.
<hyperair> duongthaiha: but for every moment i spend writing java, my sanity level decreases a little.
<rafiyr> hyperair: its not the language, its the programmer :p
<hyperair> rafiyr: i'll admit, i didn't account for the program architecture swelling up to this level of complexity.
<duongthaiha> hyperair: lol i think u just get used to C++ I can see the different that cause you so much trouble.
<rafiyr> my first experiences with java were for a class, and it was a particularly painful combination of circumstances
<hyperair> duongthaiha: yeah, stuff like *real* multi-inheritance.
<rafiyr> hyperair: clearly you should be using smalltalk
<duongthaiha> hyperair: and that is the sanity level that you mentioned here?? I am a new bee so plz forgive me if that is not rite
<hyperair> duongthaiha: interfaces are *weird*
<rafiyr> hyperair: interfaces has some really nice uses though.
<hyperair> duongthaiha: sanity level, in percentage = 100 - (percentage of how crazy i am at the moment)
<hyperair> rafiyr: somewhat, but they can be completely done using abstract classes.
<rafiyr> hyperair: Are you doing any ui or event based stuff?
<duongthaiha> rafiyr: true it really work for the OO design
<hyperair> rafiyr: everything i'm doing at the moment is event-based.
<rafiyr> hyperair: Then be glad you're not starting with java 1.0, like I did
<hyperair> rafiyr: i just finished stitching together two somewhat-separate UIs using some kind of glue (they're supposed to talk over the serial cable, but i needed to debug them first before unleashing the horrors of rs232 on them)
<rafiyr> hyperair: It was such a mess, and the ground kept shifting as I coded.
<hyperair> rafiyr: i... i... i don't know what to say.
<duongthaiha> rafiyr: omg it must be ice age :D
<rafiyr> Um, yeah, it sucked.  Didn't help that I'd never (well functionally never) written ui or event code before that, also very little graphics code.  First week on getting to college, "write a mouse driven newtonian fractal browser as a java applet".
<rafiyr> hyperair: Try to take some solace in knowing that learning java is probably not going to hurt you in the long run.  And in the short term, take a deep breadth and mediate on not worrying array bounds checking.
<hyperair> rafiyr: i take solace in knowing that java has no future anyway.
<rafiyr> Are you looking forward to your next class forcing you to code in C#?
<hyperair> from what i have heard, oracle's letting java rot. and so be it.
<hyperair> C# >>> java.
<hyperair> now, i haven't actually done C# code before, but i have patched banshee.
<hyperair> in numerous occasions.
<duongthaiha> hyperair: i not quite sure about that Java do have it strong point. and C# is a no no to me
<hyperair> rafiyr: plus, i'm banshee's package maintainer ;-)
<rafiyr> most of what matters has already been opened, is it gpl?  If there's a will, the  community could easily take on java dev.
<hyperair> duongthaiha: why, because... the MICROSHAFT?!
<rafiyr> hyperair: ah
<rafiyr> hyperair: keep meaning to try out c#, but so little motivation, and so many more interesting languages I want to play with.
<hyperair> rafiyr: true that. but it will take a long while to get the ball rolling.
<hyperair> rafiyr: heh i've been interested in looking at vala.
<hyperair> rafiyr: it's the closest to gobject level that doesn't involve actually touching gobject things.
<duongthaiha> i used that for my uni dissertation a long time (it might change now) and it really dontt suite me. I dont like the idea of changing the value of variable using the same method.
<rafiyr> hyperair: So why do you hate java, yet willingly maintain C# ports
<duongthaiha> rafiyr: good quetion
<hyperair> rafiyr: perhaps because i haven't been forced to code extensively in it.
<hyperair> rafiyr: another reason is the efficiency of the runtimes.
<hyperair> rafiyr: get me an efficient java runtime and i'll rethink my hate.
<rafiyr> I've been pretty disappointed with gcj.
<hyperair> java is slow and bloated, mono is pretty damn fast, has Gtk+ support (i mean native support, not the cheap emulation swing does), can interface with C libraries easily, and has a pretty small footprint.
<hyperair> make that Gtk# of course
<rafiyr> hyperair: are you complaining about the ui performance or the raw compute performance?
<hyperair> rafiyr: three aspects.
<hyperair> rafiyr: memory, computing, UI
<hyperair> rafiyr: memory, as well as startup time is where java excels at failing.
<rafiyr> hyperair: I guess I should benchmark java vs C performance for some of my work.  But in general, its not been that bad.
<hyperair> rafiyr: try startup time.
<hyperair> rafiyr: even with everything cached, it takes some time for it to load.
<rafiyr> hyperair: for most of my work, where a batch process runs for minutes or more, a couple of extra seconds is irrelevant
<hyperair> rafiyr: how about a java plugin hanging your firefox for minutes, and rendering your main browser useless.
<hyperair> until it finishes loading
<hyperair> by the way, it took ~5 minutes for it to show the "Do you want to run this unsecured applet" dialog
<hyperair> *5*!!
<rafiyr> As for memory, yes java errs on the side of bloat, but the overhead over the raw data doesn't need to be all that bad.  And well, 6G/$100 (roughly)
<hyperair> er what? 6G?
<rafiyr> hyperair: memory is pretty cheap
<hyperair> rafiyr: try owning a computer that uses DDR1 RAM only.
<rafiyr> Not saying java is good for everything, just that for many environments the costs aren't that bad compared to the benefits
<hyperair> my sanity is a pretty high cost.
<ion> Now go and learn Lisp, Erlang and Haskell. :-P
<hyperair> but my grades are also a pretty important benefit.
<rafiyr> hyperair: Yeah, well my first java experiences were on a p90 and a bunch of sgi indy's.  ddr???
<hyperair> rafiyr: well you were talking about cheapness of memory.
<rafiyr> :)
<hyperair> rafiyr: i'm just saying RAM isn't as cheap as you think.
<hyperair> especially in third world coutnries.. there's so much more you can buy with that money saved from not buying RAM
<rafiyr> hyperair: as I said, java has its place, but that's not necessarily everywhere.  Like embedded systems, wtf, who'd want to run java on a phone.
<hyperair> j2me \o/
<hyperair> lol
<hyperair> and android
<rafiyr> hyperair: I looked into j2me a couple times, but really wtf.
<hyperair> yeah, those are the people who want java on a phone
<hyperair> i dunno, i like the j2me app i maintain (remuco)
<rafiyr> hyperair: sure, as you said there's a degree of insanity here
<hyperair> i just don't program it =p
<hyperair> heh
<rafiyr> what's the min effort to get "hello world"
<hyperair> echo hello world
<rafiyr> you don't need a specialized profile, or a compiler specific to your device?
<hyperair> get bash ported \o/
<rafiyr> :p
<rafiyr> see, there's another one, why use bash when you could use zsh.
<rafiyr> and my phone does run both
<rafiyr> hyperair: Anyway, just remember its not that C++ doesn't have issues, you've just accumulated a tolerance.  Also, knowing C++ should make java pretty simple, once you stop crying morning the loss of overloading and macros.
<hyperair> rafiyr: it's not that it's hard to program in java. it's just that i feel... annoyed.
<hyperair> rafiyr: irritated.
<hyperair> one of the reasons was that java was introduced to me in a module that uses written exam papers.
<hyperair> and you know how longwinded java's goddamned class names are.
<hyperair> and interface names. and exception names.
<hyperair> it's one thing to have code completion do that for you, but it's another thing entirely to write everything out in full.
<hyperair> *handwrite*
<hyperair> speakin of which i should probably go get JDEE working on emacs so i don't have to keep typing out everythign in full.
<nigelbabu> imbrandon: you want to take a course for the UUD?
<imbrandon> nigelbabu: yes i just signed up to lead one ( Command Line Basics 1 & 2 )
<imbrandon> nigelbabu: why, whats up ?
<nigelbabu> imbrandon: oh, w00t, cool.  I'll accept you in once the schedule is confirmed :)
 * nigelbabu just got mail :)
<imbrandon> ahh
<cwillu_at_work> heh
<cwillu_at_work> mental note:  don't set cups-pdf to use /tmp as the destination, it changes the permissions on /tmp
<hyperair> lol i'll kep that in mind =p
<crypt-0> does the ubuntu-server kernel have the XTS modue once installed?
<amikrop> Hello, I ask here, since here are some developers, so they should know: What is the location of the icons of the "featured/default directories (Documents, Videos, Pictures)?
<amikrop> Where can I find Ambiance's folder/places icons?
<andersk> Are there going to be ddebs for maverick?
<imbrandon> there are now ...
<imbrandon> andersk: http://ddebs.ubuntu.com/pool/
<andersk> Thatâs the APT pool for http://ddebs.ubuntu.com/dists/ , which has hardy, jaunty, karmic, and lucid but not maverick.
<imbrandon> as the builds continue i'm sure the ddebs will be added, there isnt any reason why they wouldent
<andersk> Oh I see, the ddebs are in the pool but there is no APT repository for them.
<LucidFox> Bah. Linuxdcpp upstream response to the indicator patch:
<LucidFox> "Oh, ok. I assumed it was something included in the new gnome, but if it's just an Ubuntu solo project we don't need this. I just hope that the patched version doesn't cause any problems, since the bugs are likely reported here..."
<nigelbabu> LucidFox: how unfriendly :/
<ccheney> slangasek: if it is immediate then i don't see it in compiz, will try switching to metacity
<ccheney> slangasek: not able to reproduce under metacity either
<pitti> bigon: smart-notifier> we regularly do that anyway, so don't worry; I did it yesterday
<bigon> pitti: thx :)
<pitti> Riddell, james_w, cjwatson, slangasek: are you currently doing syncs? I wanted to do a few, but there are unflushed syncs in the queue
<james_w> not me
<StevenK> pitti: Not me either
<pitti> it looks flushable, but I don't want to step on someone's toes
<pitti> they were done half an hour ago
<pitti> well, I'll just flush them
<cjwatson> pitti: I was
<cjwatson> pitti: they were OK to flush, but should have been flushed with NOMAILS=-M
<pitti> cjwatson: I did
<cjwatson> ok, good
<wookey_> is there a specific UDS channel? It doesn't say on https://wiki.ubuntu.com/UDS-M/Handout
<james_w> #ubuntu-uds
<wookey_> cheers
<joaopinto> good morning
 * ccheney wonders where the three weeks cut will happen for maverick
<ccheney> oh and where did alpha 1 go for maverick, we start with an alpha 2 it seems
<ccheney> oh nevermind, i misread a-2 as alpha 2
<slangasek> ccheney: hah - so after having downgraded OOo to karmic, and now reupgrading, F5 no longer crashes
<statik> hi lifeless, the debian/sid udd import for erlang is quite out of date, do you happen to know who the right person to poke is?
<mr_pouit> james_w I guess
<cjwatson> statik: all Debian imports are out of date at the moment due (indirectly) to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577759
<statik> thanks
<ubottu> Debian bug 577759 in ftp.debian.org,kde-l10n "kde-l10n has incomplete and contradictory checksum information in experimental" [Important,Open]
<slangasek> erlang, however, is last imported in January, with the failure shown (in unfriendly content-type :) at http://package-import.ubuntu.com/failures/erlang
<cjwatson> it means that (a) Launchpad's debmirror of Debian unstable fails (b) gina (which populates https://launchpad.net/debian) fails (c) package-import thinks it has nothing to do
<slangasek> (not that I can help interpret why that error happens, so --> james_w anyway :)
<cjwatson> mm, well that's a timeout error
<cjwatson> so another attempt might succeed ...?
<slangasek> how to trigger another attempt?
<cjwatson> the OOPS id there isn't available on lp-oops
<slangasek> AFAIK that interface is also a james_w RPC ;)
<txwikinger> Is there a gobby document for the last kubuntu session?
<cjwatson> I assume it's expired
<txwikinger> wrong channel :)
<cjwatson> well, fixing the Debian archive would also wind up triggering another attempt, ultimately
<Laney> cjwatson: the cli-mono set doesn't exist on lucid
<Laney> maverick even
<cjwatson> oh, I suppose that wouldn't have been covered by my migration script
<Laney> can you add pinta to it too?
<statik> cjwatson, thanks for that, it helps quite a bit. i will chase down james_w sometime today. I want to merge the latest erlang from sid into maverick, i was planning to use bzr merge-package, what would be the right way to carry on while the sid branch is out of date? bzr import-dsc perhaps?
<cjwatson> Laney: done and done
<cjwatson> statik: not sure, I tend to wait peersonally :)
<cjwatson> -e
<Laney> cheers
<Laney> I wonder why pinta isn't in NEW
<cjwatson> because we haven't done a new-sources pass yet
<cjwatson> that's separate from the basic autosync
<cjwatson> new-source rather
<Laney> ah
<cjwatson> $ new-source | wc -l
<cjwatson> 417
<cjwatson> may take a while, we do need to do basic checks on the names to make sure we're not accidentally reintroducing deliberately-removed packages
<cjwatson> I'll do pinta now though
<Laney> urgh, LP is still rejecting
<Laney> guess it needs some time
<wgrant> Laney: LP doesn't need any time for that.
<wgrant> It should just work.
<Laney> wgrant: Signer is not permitted to upload to the component 'main'
 * Laney tries once more
<Laney> oh, I don't have cli-mono permissions for maverick
<Laney> this seems somewhat suboptimal
<wgrant> Laney: Yeah, that would be the problem.
<wgrant> => not a bug!
 * wgrant is safe, for now.
<Laney> well, maybe they should copy to new releases by default ;)
<wgrant> Pfft.
<cjwatson> Laney: oh, ok, I'll fix that - thought I already had
<cjwatson> copying over package sets in general is a bit of a pain, I'd like initialize-from-parent to do it automatically really
<Laney> yes, that sounds sensible
<StevenK> cjwatson: Is there a bug for that i-f-p thing?
<cjwatson> StevenK: not yet, sorry
<psusi> what is the proper procedure for correcting errors in the release notes?  it says that dpkg runs slower on ext4... this is not the case.. it runs slower period in order to deal with ext4... it behaves the same on ext3
<cjwatson> psusi: that does not match my personally-conducted tests
<cjwatson> therefore it must be more complicated than that
<cjwatson> I tested very carefully on ext3 and the results were within margin of error
<psusi> cjwatson: how so?  it doesn't check what fs you are using... it does the sync() either way
<cjwatson> psusi: feel free to file a bug on the ubuntu-release-notes project
<cjwatson> and it doesn't slow things down on ext3
<cjwatson> in my experience
<psusi> hrm... that's odd...
<cjwatson> perhaps so.  nevertheless
<cjwatson> this data is the reason the release note is written that way
<psusi> so you didn't see a slow down relative to before the fsync patch?  what about relative to ext4?
<cjwatson> I didn't test on ext4, but others did
<cjwatson> relative to before the fsync patch> correct
<psusi> could be that ext3 basically internally was forcing a sync behavior, so explicitly doing it has no further effect...
<psusi> so without the fsync patch, ext4 was faster, but dangerous, with it, they behave the same
<cjwatson> sorry, I assumed that when you said "it behaves the same on ext3" you had data to support that
<cjwatson> do you not?
<james_w> statik: there's also a failure importing erlang, I'll have to dig a little deeper
<psusi> no... just a working theory so far... I know that dpkg calls sync the same on both ext3 and ext4, and ext3 did not have the problem that required the sync.. if it had no impact on performance, it seems likely that given the lack of change in performance, and the fact that ext3 already was writing in the correct order, that effectively ext3 already was doing a sync so the explicit sync is a noop
<cjwatson> I would suggest that in general it's good to collect data before modifying the release notes, then :)
<psusi> but either way, the notes suggest that ext4 is slower than ext3, and I do not believe that to be the case and it doesn't sound like you have data that indicates that :)
<statik> james_w, thanks!
<joaopinto> psusi, a debootstrap on ext4 takes 10x more time than an ext3, own experience
<cjwatson> psusi: I have certainly received data from other people that indicates that.
<cjwatson> and no data to the contrary that I remember.
<psusi> joaopinto: wha?!
<psusi> cjwatson: that it is slower than ext3, or that it is slower than before the patch also on ext4?
<cjwatson> that before the patch they were fairly close, and after the patch it's much slower on ext4.
<psusi> i.e. just because the patch slowed down ext4 does not mean it is now slower than ext3
<cjwatson> by a factor of 5 in some cases.
<cjwatson> this is trivially reproducible by timing the installer
<cjwatson> Laney: fixed
<psusi> hrm... I'll have to check that out then...
<Laney> cjwatson: thanks
<soren> Do we have a DMB meeting today?
<cjwatson> tomorrow, isn't it?
<soren> Oh, right.
<soren> But it's still on?
<soren> I forget what we decided.
<cjwatson> I think so, but I do need to rearrange the schedule a bit to make a slot for it
<soren> Oh, right, I remembre that.
<Laney> subject: [ubuntu/maverick] tomboy 1.2.1-1ubuntu1 (Accepted)
<Laney> cjwatson: good stuff, all working
<joaopinto> psusi, just try a deboostrap on ext3 vs ext4
<joaopinto> I am mounting ext4 with barrier=0 to have decent performance on sbuilds
<psusi> damnit... debootstrap wants to download all the packages every time rather than cache them
<joaopinto> I am using apt-cacher-ng for that ;)
<joaopinto> psusi, someone commented the other day that the performance difference might be related to the "barriers" option, ext3 default is barriers=0, while ext4 uses barriers=1
<joaopinto> s/barriers/barrier
<psusi> funny... that should speed things up
<psusi> since without barriers it has to do a full sync to commit journal transactions
<joaopinto> http://lwn.net/Articles/283161/  - "So barriers are disabled by default because they have a serious impact on performance. And, beyond that, the fact is that people get away with running their filesystems without using barriers. Reports of ext3 filesystem corruption are few and far between. "
<cjwatson> I explicitly tested this case with ext4 and barriers turned off, and there was no measurable performance difference
<cjwatson> versus ext4's default of barriers being on
<cjwatson> the test was timing the installer's base-installer and pkgsel steps
<joaopinto> my tests were with debootstrap/sbuild
<cjwatson> all I have been able to conclude so far is that nobody understands exactly where the slowdown is, or if they do then they aren't telling
<james_w> statik: when you uploaded 1:13.b.3-dfsg-2ubuntu1, do you know if you dput before pushing to lp:ubuntu/erlang?
<psusi> wow... when I tar up the debootstrap, then time untaring it, it takes about the same on both ext3 and ext4... ~13 seconds... on ext4 with barrier, drops to 9.6 seconds
 * psusi wonders what dpkg is doing that makes unpacking so slow on ext4
<psusi> and this is on karmic, so no sync changes
<joaopinto> my tests were with lucid
<joaopinto> I was using ext4 on karmic without this slowdown, I assume it was related to the dpkg fsync changes
<psusi> yea, but I would expect that to hit ext3 the same exact way
<statik> james_w: re: erlang I think I did bzr merge-package, bzr mark-uploaded, then dput. It is quite possible that I bungled it.
<mterry> persia, can you resubscribe me to ~ubuntu-universe-sponsors?
<james_w> statik: I'm just wondering if there may have been a couple of minutes or more after the dput before the push, as that would explain what I am seeing
<james_w> statik: if you don't remember then I can dig a little deeper to check
<statik> james_w: i think it did it all pretty close together, but i was double checking every step so i could have taken 3-4 minutes between steps
<james_w> statik: right, I tend to push first to avoid this situation; I always knew there was a theoretical race here, but haven't seen anyone hit it before.
<lool> jiboumans: Hey; https://blueprints.edge.launchpad.net/ubuntu/+spec/server-maverick-arm has no assignee, do you know who is leading the session?
<lool> pgraner: Heya!  Got pinged about this interesting session https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-arm-single-zimage which differs slightly from device tree, but I think it's unscheduled; it is aimed at the kernel track, did you want to schedule it?
<mick_laptop> anyone know how i can remotely coonect in to see the ubuntu developer summit?
<crimsun> mick_laptop: as in https://wiki.ubuntu.com/UDS-M/RemoteParticipation ?
<mick_laptop> yes :)
<mick_laptop> crimsun: thanks
<mick_laptop> crimsun: you wouldn't know how to access it via vlc would you?
<Gadi> can someone tell me what replaced asoundconf in lucid to perform the alsa-to-pulseaudio redirection?
<hyperair> Gadi: /usr/share/alsa/pulse-alsa.conf?
<Gadi> hyperair: just what I was looking for, thanks!
<hyperair> np
<crimsun> Gadi: note that asoundconf was never replaced, just obsoleted.
<bryceh> sbeattie, re bug 287215, the tag to add to indicate it really is a problem is 'lucid'.  Running apport-collect I believe should add that tag, or if not I'll have a script search for the needs-testing tag and then look at the Xorg.0.log to get the version, and tag accordingly
<ubottu> Launchpad bug 287215 in xserver-xorg-input-evdev "xmodmap settings not getting honored when keyboard devices are hotplugged" [Medium,Incomplete] https://launchpad.net/bugs/287215
<sbeattie> bryceh: for that specific bug, do you really want apport-collect output attached? It seems.... overkill to me.
<bryceh> sbeattie, for that one, you can probably just tag 'lucid' and set it to Confirmed
<bryceh> sbeattie, fwiw RAOF is maintaining X this next cycle
<bryceh> sbeattie, probably the next step for this bug is to send it upstream, unless you want to try to provide a patch yourself; keyboard mapping issues tend to be among the lower priorities (compared with X crash and freeze bugs)
<ryan22> hey everyone
<Viper550> Is there an easy way to override system tray icons through icon themes for third-party programs?
<txwikinger> hey ryan22
<ryan22> @txikinger: hey
<nemo> Hey guys... After screwing around w/ a bunch of pointless attempts to disable IPv6, I finally got things working over here using:
<nemo> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757/comments/288
<nemo> Whiiiich is fine and dandy for me.  But what about all the other poor users out there.  I was curious if something is LTS if ubuntu could offer something like an alternate glibc or something...
<ubottu> Launchpad bug 417757 in eglibc "[regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups" [High,Fix released]
<nemo> perhaps not appropriate for everyone, but, you know, for those having trouble
#ubuntu-devel 2010-05-11
<crimsun> dholbach: someone mentioned that you might have a greasemonkey script to extract git SHA1s from LP bug reports
<dholbach> crimsun: erm, no - I'm sorry - bdmurray maybe?
<wgrant> bryce mentioned it in a session yesterday.
<wgrant> That he had one, that is.
<wgrant> Or something to do with extracting git SHA1s from bugs, at least.
<james_w> statik: you should be good to go
<sicksquirrel> hi all
<sicksquirrel> anyone there?
<sicksquirrel> hello?
<joaopinto> sicksquirrel, most people is at the UDS right now
<cjwatson> sicksquirrel: the Ubuntu development summit is going on at the moment, and most people are not paying huge amounts of attention to IRC.  In any case, it is better form to simply ask your question, rather than asking whether you may ask it
<slangasek> sicksquirrel: from #ubuntu-testing, where you didn't wait for an answer, I understand your question is about whether 10.04 LTS is "stable compared to 9.04".  That's a question that needs so much more information to answer usefully that I recommend you just try it and see if it works for your needs.
<slangasek> sicksquirrel: if you have further questions, #ubuntu is probably a better channel
<nxvl> just discovered that most of the packages in lp/debian are completely outdated
<StevenK> nxvl: Known bug
<nxvl> StevenK: ubuntu-dev-tools are broken because of that
<crimsun> w3m+PTS+duct tape!
<nxvl> to much work
<StevenK> nxvl: The Sources.gz in sid/main for Debian is being mis-generated
<geser> nxvl: requestsync in u-d-t trunk has some work-arounds for this
<lucas> StevenK: do you have a (debian) bug number for that?
<StevenK> lucas: Indeed. Let me fetch it for you.
<StevenK> lucas: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577759
<ubottu> Debian bug 577759 in ftp.debian.org,kde-l10n "kde-l10n has incomplete and contradictory checksum information in experimental" [Important,Open]
<lucas> thanks
<StevenK> It also affects unstable, but the title doesn't say so
<perlsyntax> What package do i need with my apt-get to make my own deb?
<perlsyntax> ?
<cjwatson> Keybuk: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635#20 suggests that the version of dpkg in my PPA should address your performance problems
<ubottu> Debian bug 578635 in dpkg "dpkg: severe performance degradation at least on ext4 filesystems" [Important,Open]
<ricotz> pitti, hello, me and Laney were just arguing about a SRU for "docky" (2.0.2 to 2.0.3.1) which only contains bugfixes and translation update. this results in a quite large debdiff which was the center of discussion
<pitti> ricotz: if you could attach a debdiff with the autoconf noise and po files filterdiff'ed out, it will make it much easier to review
<ricotz> Laney, could you do this? ^
<Laney> pitti: but it being in the uploaded debdiff doesn't invalidate the SRU candidacy?
<pitti> Laney: the uploaded debdiff still needs to be checked of course
<pitti> but for those cases we just generally ignore the autoconf generated noise
<Laney> yes
<Laney> good, that's what I was hoping for
<Laney> thanks a lot
<ricotz> great
<pitti> bbl
<Laney> jdong: ^^^
<dholbach> who can mark https://code.edge.launchpad.net/~lfaraone/ubuntu/lucid/accerciser/libgail-dep/+merge/23773 as merged/closed?
<Laney> not me
<Laney> which is weird, we had a bug like that fixed recently
<dholbach> james_w can probably help, or cjwatson
<Laney> https://bugs.launchpad.net/bugs/540250
<ubottu> Launchpad bug 540250 in launchpad-code "Cannot edit merge proposals for packaging branches" [High,Fix released]
<cjwatson> if I can, I don't see how
<cjwatson> I thought it was supposed to notice automatically
<cjwatson> oh
<cjwatson> the merge target is lp:ubuntu/lucid/accerciser
<dholbach> I think it's ~ubuntu-branches members?
<cjwatson> was it merged into *lucid*?
<Laney> I should be able to edit the status anyway
<Laney> e.g. if I'm rejecting it
<cjwatson> I'm a member of ~ubuntu-branches, and I don't have any special UI to edit it AFAICS
<Laney> right?
<dholbach> no, a different fix from debian was imported into maverick
<dholbach> usually there's an icon next to "status"
<cjwatson> anyway, I don't know the right way to deal with that and don't want to mess with it
 * Laney suggests an LP bug
<dholbach> cjwatson: ok, thanks anyway
<blendmaster1024> how do i configure something with the autotools configure so that it is compiled in debug mode?
<blendmaster1024> oh wait "not support not app devel"
<sash_> hello, everyone. i am trying to build netbook-launcher in fedora13. i will also have to adopt some libraries, whatever. my problem is that in f13 contrary to f12 the build fails because of a change in f13-s ld-beahviour (read https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking and https://fedoraproject.org/wiki/UnderstandingDSOLinkChange if interested). well. as i see, the configure-script is not compatible to that, so ...
<sash_> ... does anyone know, if and when ubuntu, which is the netbook-launcher-upstream as i see, will adopt that behaviour? or am i completely wrong with my guess?
<Yitzach> I ran a number of programs last night that required more RAM than I had. Did I see correctly that Ubuntu killed one of the programs for the RAM? If so, would it be possible that the next release asks which program to kill before killing it?
<jpds> Yitzach: Are you referring to the OOM-killer?
<Yitzach> I have no idea. The #ubuntu channel is telling me that the kernal will kill processes for RAM if RAM is lacking. I just want it to kill Google Earth which was the source of the problem and not my Internet browser with an open job application.
<Daenyth> Hi
<Daenyth> I have a quick question about upstart and init.d scripts. We have a custom init.d script stopping on runlevels 0/6, but it never gets run on shutdown. Does upstart not send "stop" commands to init.d scripts?
<Daenyth> Also, I haven't been able to tell via a quick look at the docs, but can I do "start on shutdown" in an upstart config file?
<Daenyth> or something to that effect?
<kklimonda> Yitzach: I don't see it being possible to display user with a list of potential processes to kill in case of running out of memory anytime soon.
<Yitzach> I think there are two solutions for killing active processes when RAM is short, ask the user which one, or kill the most recently started one as the user will have done the least with it and then give a message to effect of RAM had run out.
<Yitzach> The reason for the option is it will be the least rude to the user. Likewise, the killing the most recent start for second least rude.
<Yitzach> I understand it will be sometime in comeing. I just wanted to provide feedback on that feature.
<kklimonda> you can't really ask user because it would require both knowledge of how to communicate with user and resources which kernel already doesn't have.
<Daenyth> If the kernel has so little memory as to start OOM killing, it does not have enough memory to ask the user what to kill
<kklimonda> it already tries to kill processes that are the most likely to not cause any loss of work
<Yitzach> Which is why killed the internet browser and not VirtualBox. I think it should put the last opened in que to kill first as it probably caused the short in RAM and the user will have done the least with it.
<Daenyth> I don't really see how that's a FR for ubuntu
<Daenyth> go talk to the kernel developers :/
<Yitzach> And where might they be hiding?
<kklimonda> Yitzach: it does that - the longer process runs the smaller score it has
<Daenyth> Yitzach: LKML seems a likely place to start
<Yitzach> kklimonda: The browser was open for 3 hours; Google Earth, the cause, was just opened. Why did it not kill Google Earth
<Daenyth> :/
<kklimonda> Yitzach: I don't know - probably browser was using much more ram which made it a better target.
<Yitzach> kklimonda: The RAM is what did it. I think time open is the more important consideration. And then a note from the kernal: "Your program died due to insufficient RAM." Thank you. I'll let the kernal development people know my thoughts on that.
<directhex> wait, Yitzach wants the oom-killer to suck less? sgi have been fighting kernel upstream for years to get changes to the retarded oom-killer behaviour
<ibeekman> Has ubuntu mobile (ununtu MID) been discontinued?
<ibeekman> Has ubuntu mobile (ununtu MID) been discontinued, or merged with a different project? (Moblin maybe?)
<ccheney> ibeekman: probably closest version is UNE
<ccheney> ibeekman: though i don't know much about the MID version
<ccheney> ibeekman: UNE is Ubuntu Netbook Edition
<ccheney> http://www.ubuntu.com/getubuntu/download-netbook
<ibeekman> ccheney: so it has been discontinued?  Was it really short lived?  It looks like it was there for 9.x only.
<ibeekman> I want to make a touchscreen beagle board and am trying to figure out what OS to run (ideally some debian derivative, even more ideally an ubuntu derivative)
<ibeekman> maybe maemo or peppermint or something.
<Tm_T> ibeekman: normal Ubuntu wouldn't do?
<abogani> ibeekman: Perhaps #ubuntu-arm is a better place to obtain replies! :-)
<ccheney> ibeekman: yea asking the arm team would be better
<StevenK> Ubuntu MID was only released for 8.04 and 8.10
<ccheney> yuck sony is still releasing new poulsbo netbooks
<ccheney> hmm according to the atom model number it seems intel is releasing new higher speed poulsbo also
#ubuntu-devel 2010-05-12
<jbebel> Is there any more official method of reporting a regression in a package in -proposed than finding the bugs it is supposed to fix in the changelog and reporting there that verification failed?
<ajmitch> https://wiki.ubuntu.com/StableReleaseUpdates says to open a bug with the regression-proposed tag, comment on the SRU bug & tag it verification-failed
<ryan22> i was just wondering how many developers ubuntu has who specialize in accessibility
<zord> Hi all: has anyone worked ion touchscreen apps?
<zord> Anyone here???????
<zord> anyone here hear me or r u not hearing me because i'm here?
<zord> I guess these days nobody develops software for ubuntu, EXCEPT CANONICAL/
<zord> gone/
<ajmitch> oh dear, what a shame
<pitti> Good morning
<nigelbabu> morning pitti :)
<Nafai> Is there a way to use apt-file to search a prior release?
<jpds> Nafai: --sources-list ?
<Nafai> ah
<cotedivoire> Hello everyone I am looking to add a change Ubiquity CÃ´te d'Ivoire in the list of PAys
<markoz> hi
<markoz> I'm deploying ubuntu in my company, what is the best way to have local changes to configuration (pam - ldap) and still have easy way to upgrade etc?
<markoz> I was thinking about deb packages with changes to configuration but would that conflict with oryginal packages owning these files?
<cwillu_at_work> markoz, you can divert and so forth
<cwillu_at_work> many packages also have config dirs instead or in addition to single config files, which you can just dump new files into
<ion> chef/puppet perhaps. (Iâll be switching from puppet to chef due to puppetâs limitations.)
<StevenK> pitti: php5 is currently building on cushaw, thanks to bigjools.
<pitti> yohoo
<markoz> hmm config dir would be good but not sure if every package I need to configure uses that
<markoz> I've read debian policy on conflicts in configuration files
<markoz> best would be to have deb package with modifications to the files I need but fwiw this is not an option
<ion> What i said. :-P
<markoz> we have puppet for servers ;) not an option for desktop imo due to company structure here etc.
<markoz> (long story)
<markoz> what I need is ubuntu + local modifications which can be tracked, maintained, applied, reverted
<markoz> modifications are mainly in configuration files
<markoz> and that's it
<markoz> just not sure how to achieve that so that it would live long and generate no problems with upgrades
<soren> markoz: etckeeper.
<wgrant> pitti: So you uploaded gvfs to lucid-proposed, waited for it to build (except for powerpc, which failed due to some buildd glitch), then copied to maverick, then tried and failed to copy from lucid-proposed to lucid-updates?
<markoz> soren: interesting - will look into this
<pitti> wgrant: pretty much, yes
<pitti> wgrant: oh, did it attempt to build the missing powerpc binaries on maverick?
<wgrant> pitti: Precisely.
<StevenK> pitti: It did, yes, and it was sucessful
<pitti> that explains it; d'oh
<pitti> I should have looked earlier
<wgrant> So the easiest way is probably to reupload to lucid-proposed, make sure it actually finishes building properly, then copy to maverick and lucid-updates.
<pitti> *nod*
<pitti> wgrant, StevenK: thanks for investigating!
<wgrant> Bug #527551
<ubottu> Launchpad bug 527551 in soyuz "Intra-archive copying of a source with a failed build may leave that source uncopyable" [Low,Triaged] https://launchpad.net/bugs/527551
<StevenK> pitti: Welcome *hugs*
<markoz> cwillu_at_work: divert seems like a way to go as well, thanks
<Abhishek_Singh> folks:please telle me how to make a .deb file from a tarball(source code) that doesn't have a makefile
<Abhishek_Singh> Currently it has a install.sh (shell script) to install it
<Abhishek_Singh> During the course of installation it asks for password for postgresql database(that is prerequisite for its installation) several times.
<Abhishek_Singh> I want to have GUI for that too i.e to allow a user to key in the passwords in the GUI Window.
<astraljava> Abhishek_Singh: Might I suggest: https://wiki.ubuntu.com/PackagingGuide
<Abhishek_Singh> ok i will got through that link
<Abhishek_Singh> astraljava:thanks
<astraljava> Abhishek_Singh: #ubuntu-motu is the channel that helps with packaging issues, once you have a pretty solid packaging done. Best is to upload the package to REVU, and ask for reviewing then.
<Abhishek_Singh> what is REVU?
<cjwatson> Abhishek_Singh: first hit on google
<cjwatson> well, first if you google for "revu ubuntu"
<Abhishek_Singh> cjwatson: thanks
<astraljava> revu.ubuntuwire.com, a place that tracks new packages meant to enter Ubuntu repositories. https://wiki.ubuntu.com/MOTU/Packages/REVU
<Abhishek_Singh> ok i will go through the links that you have suggested
<gartral> alright, i dont show my head here often, but today is an emergency, ubuntu's logd is completely brainfucked, for lack of a more apropiate term, as it makes logs, and stores old logs, but just the files, not text inside, completly nullifying the point of logs.. can anyone help me?
<joaopinto> gartral, try #ubuntu for support
<gartral> joaopinto: ... how thick are you people, i've been in #ubuntu for a hour now and not one mention of any four of my problems, like i said, i normally wouldnt come here for supprt, but this is an emergency..
<azeem> gartral: file a bug
<gartral> azeem: im fairly sure this isnt a normal bug, as i can only get my one computer to reproduce the problem
<joaopinto> gartral, this is not an emergency support channel, on #ubuntu there is more people dedicated to support, any kind, from emergency to regular :)
<joaopinto> gartral, a normal bug does not need to be reproducible across different systems
<azeem> gartral: then look into canonical or other paid support, maybe
<gartral> if i wanted that, i'de use redhat
<gartral> well then heres a development question: when is the complete removal of mono from ubuntu going to take place? :)
<jpds> gartral: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-June/000584.html
<gartral> what about development of a seperate strian of ubuntu specifically lacking all closed source/patented materials for use in regions where laws forbid the use of patented software without licensing/approval? (not that the US currently upholds any such laws, but im awear of at least two countries in south america that do)
<kklimonda> isn't it what gnewsense is about?
<gartral> i havent heard of gnewsense
<azeem> "How do you tell if a piece of software violates a patent? Run wc -l on the source; if the number is greater than 1000, it probably does." -- Nat Friedman
<azeem> gartral: maybe you should start researching a bit then
<gartral> azeem: how does that work? ive never heard that before
<gartral> gnewsense is no longer ubuntu-related, leading me back to my previous question: when will an official ubuntu strain, lacking mono/other non free softwares, be availible?
<gartral> kklimonda: ^^^
<kklimonda> gartral: why not use gnewsense anyway?
<joaopinto> gartral, what makes you believe there will be one ?
<joaopinto> and mono is classified as free software, afaik
<gartral> joaopinto: the overall stance cononical and the ubuntu community has twards open source, and the huge social upheval twords mono right now and their sea of lawer-troll-sharks
<joaopinto> gartral, mono is open source, there was a recent statement about mono in Ubuntu
<joaopinto> gartral, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-June/000584.html
<gartral> joaopinto: the framework is opensource, yes, but it doesnt do all it says it should, those of us with mono installed cant use the .net framework to watch movies on netflix, despite meeting every other concevable requirment, and novell and M$ are both concidered great evils..
<ScottK> gartral: If you want an Ubuntu flavor with no mono, Kubuntu includes no mono applications in the default install.
<gartral> ScottK: ah, and why does ubuntu? (im mearly curious, i've gone through and striped as much mono as i can from my installation
<joaopinto> gartral, I hope Ubuntu doesn't turn into a social managed distribution, splitting Evil and God software :)
<gartral> really, i wouldnt mind using mono so much if novell would stop lying about what mono is capable of
<ScottK> I'm not a developer that is focused on the Ubuntu desktop, but my understanding is they are trying to pick the best applications for certain functions and don't care if it's in mono or not.
<joaopinto> gartral, there is an explanation on the link I have provided :)
<gartral> there was talk about mono being used for part of the next x.org.. im truly frightened at that possibility
<joaopinto> gartral, that seems more like an anti mono troll rumour
<gartral> joaopinto: like i said, i heard it somewhere, im deffinatly not officiall supporting the statment!
<gartral> officially*
<joaopinto> gartral, there are too many trolls, start filtering :P
<gartral> lol
<gartral> joaopinto: have to admit thoug, it's a scarey thought
<beuno> pitti, ping
<ari-tczew> cjwatson: could you check package ttf-cjk-compact whether is it ready to sync? from debian/changelog: fix po2ul.rb to work with updated libruby1.8-gettext
<pitti> beuno: pong; please just ask, I'm not on IRC that often during UDS
 * psusi wonders how UDS is going and wishes he was there
<beuno> pitti, hi  :)    what do you know about the offline start page in Lucid?   I think it's gone, and I'd like it back
<beuno> (firefox start page, that is)
<pitti> beuno: It's supposed to be there; chrisccoulson is the man to talk to
<beuno> pitti, thanks, I'll email him
<psusi> what exactly is 10.04.1?
<ari-tczew> psusi: 10.04 with bug fixes
<psusi> are the release images actually going to be respun with the latest SRUs?
<ari-tczew> something like that
<psusi> so basically everything in -updates will be incorporated into a new iso?
<psusi> hrm... interesting... I guess I better get on making an SRU to fix the dmraid breakage then
<ari-tczew> yea, -updates include
<cjwatson> ari-tczew: I looked at it briefly the other day; it still needs the port to python; whether it works with an updated libruby1.8-gettext is irrelevant to the reason I gave in the original changelog
<cjwatson> ari-tczew: the merge is on my list and I will do it
<ari-tczew> cjwatson: ok
<NoobFukaire> if any canonical people are here, apparently valve has announced linux support for their titles and steam
<NoobFukaire> is canonical planning on making any overtures to valve to get steam put into canonical's software repo?
<NoobFukaire> it'd be great to have that ready to go for ubuntu users
<NoobFukaire> http://www.phoronix.com/scan.php?page=article&item=valve_steam_announcement&num=1
<gangil> Hi , when I am using icat <device-name> <<file's inode number> , it isnt shoeing the output  ? what's wrong ?
<gangil> For example , I gave : icat /dev/sda1 132610
<gangil> that's the inode number of a file a.txt that I created on my desktop , and found out uding ls -i a.txt
<gangil> can anyone help :-/
<gangil> here is the link to what i have been tryin
<arand> gangil: Mind that #ubuntu is the proper channel for support, not here.
#ubuntu-devel 2010-05-13
<ForgeAus> ubuntu (or is it apt?) needs either/or dependancy checking (ie gnome support vs kde support, one of either, but not both...)
<ForgeAus> as a kubuntu user to get thunderbird you download thunderbird-gnome-support??? why?
<ForgeAus> ... I get mostly its "assumed" your using ubuntu (as in the main/default gnome-based distro) but unneccessary gnome-based packages are silly so having a either/or check or maybe use provides? ie require a thinderbird-support package, and have thunderbird-kde-support or thunderbird-gnome-support provide that?
<LaserJock> ForgeAus: it's not really assumed, it's not always easy to have a good solution either. I believe on Lucid thunderbird-gnome-support shouldn't be installed from Kubuntu
<ForgeAus> so then why is it a dependancy of the thunderbird package then?
<ForgeAus> it doesn't make sense
<LaserJock> it isn't a dependency
<LaserJock> it's listed as a Suggests
<LaserJock> which is much different than a Depends
<ForgeAus> oh I did a apt-cache showpkg thunderbird and it had it as a dependancy
<ForgeAus> Suggests is ok
<ForgeAus> (I didn't know suggestions show up there...
<ForgeAus> sorry ...
<LaserJock> Depends must me installed with the package, Recommends are installed by default but can be removed, and Suggests are not installed by default
<astraljava> ForgeAus: If you do apt-cache show thunderbird, it shows it a bit clearer IMHO.
<ForgeAus> thx
<ForgeAus> ahh thats what I wanted in the first place, thx :)
<ForgeAus> now I feel like a dolt for complaining about something I was wrong about!
<LaserJock> no problem, it happens to the best of us ;-)
<txwikinger> kmix does not work properly
<psusi> damn, no Keybuck atm.... I had a very productive blktrace session last night and noticed that a lot of boot time is wasted reading files less than 4kb, which ureadahead is ignoring for some reason... it lists the file in the pack, but with 0 blocks so it doesn't read them... only I can't figure out why
<bigcx2> hey all
<bigcx2> i'm building a test debian package with dpkg-buildpackage
<bigcx2> my package builds fine
<bigcx2> but how do i get a diff.gz?
<azeem_> did you get a .dsc?
<cjwatson> you get a .diff.gz by having an .orig.tar.gz with the correct filename in the parent directory when you start the build
<cjwatson> which should normally just be a rename of the upstream tarball
<cjwatson> so if they ship foo-1.0.tar.gz and you want to produce a package which has version 1.0-1, then you need foo_1.0.orig.tar.gz in the parent directory
<bigcx2> azeem_: yes, i got a .dsc and a .changes file from the build
<bigcx2> cjwatson: ok, let me try that
<bigcx2> cjwatson: still no luck
<bigcx2> i grabbed a non-debianized source package
<bigcx2> made a orig.tar.gz tarball out of it
<bigcx2> applied a (older debian diff.gz) to the source
<bigcx2> made some changes in debian/
<bigcx2> rebuilt the package
<bigcx2> but i don't get a diff.gz
<bigcx2> :(
<cjwatson> you almost certainly misnamed the orig.tar.gz - it's a common problem
<bigcx2> ok, the source directory is package-3.8.1
<cjwatson> or else you have the wrong version number, depending on how you look at it
<cjwatson> the name of the source directory is utterly irrelevant
<bigcx2> and the version in the changelog is 3.8.1-0
<bigcx2> so should my orig.tar.gz be package-3.8.1-0.tar.gz then?
<cjwatson> no, absolutely not
<cjwatson> it should be package_3.8.1.orig.tar.gz
<bigcx2> that's what it is now
<cjwatson> note the underscore, the orig, and the absence of -0
<bigcx2> oh wait
<bigcx2> no underscore
<bigcx2> i had a dash
<bigcx2> sheesh
<cjwatson> common problem, as I say :)
<cjwatson> you'll get used to it
<bigcx2> k, one more try!
<ogra> cjwatson, i always thought we should put some reminder into the message that points out that you build natively ;)
<bigcx2> yay, it worked
<bigcx2> !
<bigcx2> thanks cjwatson
<cjwatson> ogra: we do
<cjwatson> <cjwatson@sarantium ~/man-db-2.5.7>$ debuild
<cjwatson> This package has a Debian revision number but there does not seem to be
<cjwatson> an appropriate original tar file or .orig directory in the parent directory;
<cjwatson> (expected one of man-db_2.5.7.orig.tar.gz, man-db_2.5.7.orig.tar.bz2,
<cjwatson> man-db_2.5.7.orig.tar.lzma or man-db-2.5.7.orig)
<cjwatson> continue anyway? (y/n)
<cjwatson> you should just use debuild not dpkg-buildpackage :)
<bigcx2> difference being...lintian?
<cjwatson> and even with dpkg-buildpackage you do get a message
<cjwatson> dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found
<cjwatson> bigcx2: and various other checks and such
<cjwatson> generally, there's no reason not to use the smarter tool
<bigcx2> cjwatson: ok, i'll look into that, it's been a while since i built some packages
<bigcx2> can you tell?
<bigcx2> lol
<bigcx2> cjwatson: how does pbuilder stack up against debuild?
<azeem_> bigcx2: they are orthogonal
<bigcx2> azeem_: different philosophies then? why two different tools?
<azeem_> bigcx2: pbuilder runs something like debuild
<azeem_> as part of what it does; you can't really compare the two
<bigcx2> hm, ok...guess i'll have to play with 'em
<markr_> Is there some "secret place" which doesn't contain as much comment spam as Launchpad?
<markr_> All the "Me too"-comments drive me crazy.
<markr_> Launchpad with an option to say whether you are just reporting a "Me too"-comment, could help against that, but I am not sure whether the users would respect it.
<c_korn> markr_: there is a "affects me too" button
<markr_> c_korn: yes, but the issues are all slightly different.
<markr_> E.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/270798
<ubottu> Launchpad bug 270798 in linux "lockups with default (hpet) clocksource on 2.6.27-2-generic 64-bit" [Medium,Confirmed]
<markr_> In that whole thread there is not a single person who has actually posted the context source code explaining why it happens for example.
<markr_> It is just one long list of clueless users, with the comments by those that can do something about it completely hidden by the mass.
<seb128> does anybody know where jcastro is or could tell him I didn't get the session he asked me to add to schedule there because summit doesn't list it (yet)?
<psusi> it isn't the "me too" that gets me.. what annoys the shit out of me is all of the "I can't believe this was not fixed for the release, this is a huge problem.  It's a shame I have to go back to the old release or another distro"
<crimsun> welcome to my world.
<psusi> there should be a mod button to hide such comments ;)
<crimsun> which is what should be what's being discussed in Mangrove 3 right now
<soren> Can someone tell me what the deal is with zeromq? https://launchpad.net/ubuntu/+source/zeromq exists, suggesting it existed at some point, but the publishing history is empty. It's in Debian testing since early April.
<jibel> psusi, that's coming soon, and bug locking when they are marked closed by a bug supervisor.
<crimsun> soren: the existence date of the package in testing suggests that it simply didn't make it into lucid
<soren> crimsun: ..but should have been synced for Maverick.
<soren> crimsun: Right?
<crimsun> soren: it doesn't seem to have been blacklisted. Oh well. Perhaps an archive admin can peer deeper?
<cjwatson> soren: we haven't done a full new-source sync yet
<cjwatson> soren: I've synced zeromq, since you asked so nicely :-)
<soren> cjwatson: Yeah, I just saw :) Thanks!
 * psusi tries to remember who he was talking to the other day about ext3 vs ext4 debootstrap speed... seems that ext4 is faster with nobarrier... slower with barriers, but it seems that by not using barriers, ext3 is not safe on disks with write caches enabled
<psusi> basically without barriers, the disk reorders requests and combines both journal writes into one, then does the actual modification either before, or after both journal writes.. which defeats the purpose of the journal in the first place... I'm surprised that ext3 corruption on power failure is not very widespread because of this
<Stevinko> anyone skilled regarding radeon driver that could give me a hand ?
<kklimonda> Vala testsuite requires a running and working DBus Session Bus and for some reason it does not (all bits are there, package build-depends on dbus-x11 and make check starts dbus-daemon --session) - you can check bug 580246 for more information.. well, there isn't much yet. Does anyone have experience with running dbus in build environment?
<ubottu> Launchpad bug 580246 in vala "Merge or sync vala 0.8.1-1 from Debian unstable. Failing tests due to dbus session bus not running in pbuilder" [Wishlist,New] https://launchpad.net/bugs/580246
#ubuntu-devel 2010-05-14
<Bsims> I am needing help tracking down why I can't renable system bell I modprobed pcspkr back in... this worked in Karmic any ideas
<wick94> hey guys, i have an idea for a feature tht i was to discuss
<wick94> for ubuntu 10.10
<virtuald> wick94: have you seen brainstorm.ubuntu.com?
<wick94> yes
<wick94> can i login there wth my ubuntu forums account?
<cTn> anyone with some drm-next experience that could give me a hand ?
<psusi> well, I've got my boot time on the old rotational disks down to just under 12 seconds... and I'm not sure I can do any better...
<psusi> I was hoping to see sub 10 seconds, but I suppose that my ssd is only doing 7.85 seconds, so 11.9 on the old disks is pretty good
<MTecknology> webadvisor is still down..... they're down for their allocated 4.5 hours.. and beyond
<MTecknology> sorry... wrong channel
<mum-n-dad> This is just too annoying:
<mum-n-dad> root@mum-n-dad:~/www/apps/test# apt-get uninstall mongrel_cluster
<mum-n-dad> E: Invalid operation uninstall
<mum-n-dad> root@mum-n-dad:~/www/apps/test# apt-get deinstall mongrel_cluster
<mum-n-dad> E: Invalid operation deinstall
<mum-n-dad> root@mum-n-dad:~/www/apps/test# apt-get remove mongrel_cluster
<mum-n-dad> Reading package lists... Done
<mum-n-dad> Building dependency tree
<Nafai> why annoying with the commands are documented in --help and the man page?
<majeru> hi, is this a good place to ask about packaging general issues?
<thekorn> majeru, hi, no it's not, we have #ubuntu-packaging for this kind of questions
<Chipzz> thekorn: actually... if someone asks a packaging question here, ppl are supposed to answer
<Chipzz> something to do with spreading the load among teams or sth
<Chipzz> changed a couple of months ago, I was surprised by it as well
<thekorn> wow, ok
<Chipzz> well, "supposed to asnwer" may be a bit strong. but it is apparently no longer "off-topic" for this channel
<Chipzz> (sth I personally disagree with, but then, who cares about my 2 cents? :P)
<Keybuk> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581625
<Keybuk> Muahaha, it begins
<kklimonda> :)
<bankix> Hi.
<bankix> I'm trying to bootstrap ubuntu from scratch, building a live CD.
<bankix> Everything is fine so far, but how do I get the cdrom/casper/initrd.lz generated?
<bankix> I'm currently dealing with an initrd.gz
<cjwatson> zcat initrd.gz | lzma -9c >initrd.lz
<cjwatson> (livecd-rootfs deals with this)
<bankix> cjwatson: Thanks, that's the manual way. I thought there is some "installation step" I left out or something.
<bankix> cjwatson: Is there perhaps anything like "create-ubuntu-fromscratch.sh"?
<cjwatson> that code is basically what livecd-rootfs does (automatically) when it's building a live CD
<cjwatson> live filesystem rather
<cjwatson> not as a single script, but livecd-rootfs builds the live filesystem part of it
<cjwatson> some assembly required
<bankix> Ah, that's a package...
<bankix> Thanks for that pointer! I didn't know about livecd-rootfs
<cjwatson> it's optimised for running in our datacentre environment rather than for external builds
<cjwatson> live-helper is reputed to be useful too, and we may switch to it for Ubuntu builds at some point, but we don't use it yet
<bankix> I'll have a look into that package
<bankix> Is there perhaps an howto how you build a ubuntu live cd?
<cjwatson> not really, sorry
<cjwatson> there's a customisation howto on help.ubuntu.com/community somewhere which is the best I can offer
<bankix> Without knowing livecd-rootfs I had to put together some own scrpts. They're doing fine sofar, but I was missing the .lz but didn't expect it that easy :-)
<cjwatson> but I'm not aware of any documentation on doing it from scratch, and it's not a priority at the moment
<cjwatson> the .lz is just a space optimisation anyway
<bankix> I like doing it the way as you guys do :-)
<cjwatson> pretty sure you wouldn't like having to set up one server per architecture for the live filesystem builds and then a separate server dedicated to building the CD part
<bankix> I'm currently working on a new version of c't Bankix, this time I'd like to build it from bottom up -- last time I did it the other way by stripping down ubuntu desktop cd.
<cjwatson> that's basically why it's not heavily documented - it's not the way most people actually want to build live CDs locally
<cjwatson> the code's all available though, livecd-rootfs plus 'bzr get lp:ubuntu-cdimage' and the stuff in configs/devel there
<cjwatson> it's just a more ... industrial setup than most people actually want
<Keybuk> cjwatson: Cody Somerville said you were going to change to using some other live cd tools thing ;)
<cjwatson> 14:42 <cjwatson> live-helper is reputed to be useful too, and we may switch to it for Ubuntu builds at some point, but we don't use it yet
<bankix> Thanks, I'll have a look and maybe optimize my scripts.
<cjwatson> that would be that one
<bankix> Bye, have a nice weekend
<pitti> cjwatson: would you happen to have a minute to review my libatasmart karmic SRU (sitting in the queue)
<cjwatson> pitti: queued up, though will probably be this evening
<pitti> cjwatson: thanks; "next week" is clearly enough :)
<mneptok> hrmf. no Kexi package for Lucid?
<astraljava> mneptok: It isn't in testing, which probably explains why it isn't in Lucid. No idea of the reason for this.
<cTn> anyone with some skills in drm-next that could give me a hand ?
<cTn> anyone with some skills in drm-next that could give me a hand ?
<astraljava> cTn: UDS just ended, not many are connected at the moment. Please have patience, and try again later. Next week might be more successful.
<cTn> :(
<TuGa> hi
<TuGa>  i'm trying to install ubuntu 10 on my hard disk SAS. ii started the livecd i can see the SAS disk create a partition for / and finish the instalation process
<TuGa> but wend reboot it gives me the windows bootloader and not grub to go to ubuntu
<TuGa> cant get grub to write
<TuGa> any ideia?
<kklimonda> TuGa: this is not the right channel to look for support - try on #ubuntu or use ubuntuforums.org
<TuGa> ok sory
<rgreening> superm1: yo
<rgreening> you around?
<cwillu_at_work> who wants a compiz-fusion snapping windows patch to make the windows not drag so terribly slowly when dragging parallel to a snapping edge?
<cwillu_at_work> (it's a one liner :p)
<cwillu_at_work> src/snap/snap.c, line 191:  it warps the pointer in addition to the window, which is unnecessary, and interferes with the desired motion
<cjwatson> pitti: libatasmart done now
#ubuntu-devel 2010-05-15
<superm1> rgreening, momentarily if you are
<jihedamine> is there any documentation on the appindicator python API ?
<DavidJHeinrich> tkamppeter, are you there? I have an HPLIP question, and was told you are an expert
<DavidJHeinrich> I'm having a problem printing on custom sizes at all in HPLIP 3.10.5, and also a problem printing on custom sizes with full-bleed (edge-to-edge) on 3.9.12 (it doesn't remember when I turn Off stretch to fit)
<DavidJHeinrich> posted bug reports: https://bugs.launchpad.net/hplip/+bug/508152
<ubottu> Launchpad bug 508152 in hplip "Incorrect paper size or type" [Undecided,New]
<DavidJHeinrich> https://bugs.launchpad.net/hplip/+bug/529293
<ubottu> Launchpad bug 529293 in hplip "Cannot turn off "Fit to Page" in 3.9.12" [Undecided,New]
<reavertm> where in launchpad I can find patch tracker (list of patches applied to particular package in particular release?
<reavertm> for instance all patches applied to original kdelibs-4.4.2 tarball that creates kdelibs5 package, hmm?
<tsimpson> reavertm: do you mean the stuff needed to create a .deb or the patches applied to the source?
<reavertm> the latter
<tsimpson> http://patches.ubuntu.com/ would be the place to look
<reavertm> thanks, hmm, that's a bit closer still it shows diff debian->ubuntu and not vanilla->ubuntu, I suppose it's the best I can get
<reavertm> anyway I think I've found what I was after, thanks
<jarlen> Hey, I think there may be an error in the danish localization for Firefox on Ubuntu. Do you know who could help me look into this?
<Aquina> jarlen, have a look on lauchpad and search for firefox then go to translations.
<jarlen> It's not a translation issue
<jarlen> I think there's a problem with the language code sent in the HTTP-header
<Ng> lifeless: http://paste.ubuntu.com/433767/
<Ng> lifeless; the hacky xinput nonsense i do for trackpoint scrolling
<LucidFox> Is there some site I can read for the rationale of replacing f-spot with shotwell?
<JanC> LucidFox: probably in gobby doc and/or the blueprint?
<JanC> LucidFox: https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-desktop-application-selection & https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-simple-image-management
<Aquina> Who can go to Brussels? Even people like me who arent (official) developers or at least not Canonical employees?
<ivoks> uds is over
<ivoks> anyone can come to uds, it's an open event
<Aquina> Oh I read the newsletter too late. :-(
<Aquina> Thanks anyways...
<aburch> How long does it usually take for packages to be removed from Ubuntu after they have been removed from Debian?
<Aquina> I tking that depends.
<geser> aburch: depends how often the archive admins run the script that does it
<nigelbabu> Nafai: ping
<nigelbabu> Nafai: I think you might be interested in the script "apt-get source $(apt-cache depends gwibber | awk '/Depends/{ print $2  }')"
<nigelbabu> Nafai: maco wrote it actually, but it solves the problem you had at the lightening talk! Change gwibber with whatever app you want to get the source for :)
<L0L> what would be bether: a wrapper for the firewire stack or an udev rule, that allready is in a script that i wrote to the ubuntu wiki, so non-roots can acess firewire
<L0L> hello ? :D
<L0L> no developers online or what :/ ?
<kklimonda> well, it's a weekend after uds so most of developers are travelling home
<JontheEchidna> I suspect most of the U.S.-bound devs are unconcious at the moment
<JontheEchidna> Assuming they left Friday night. (I left Friday morning)
<nigelb> stefanlsd: ping
<nigelb> stefanlsd: well, when you get rid of your jet lag and hangover, we need to chat :)
<JontheEchidna> My jetlag wasn't that bad. I got back home from the airport dead tired at around 11:00 PM, which is a pretty sane bedtime
<JontheEchidna> I was mostly jetlagged on, well, the jet :P
<nigelb> JontheEchidna: you didn't stay for alstars?
 * nigelb will never get the spelling right
<JontheEchidna> what's that?
<nigelb> that party on the last day with singing and tuff
<nigelb> JontheEchidna: where they scratch with nails on metal and call it music :D
<JontheEchidna> oh, guess not. My plane left at 3:45 pm on Friday :(
<astraljava> nigelb: I think that's called a rave. :D
<nigelb> astraljava: not that bad
<nigelb> JontheEchidna: ah, that explains tht, so you missed a session and wrap up, right?
<JontheEchidna> yep
<JontheEchidna> well, more than a session
<JontheEchidna> pretty much anything after lunch, as well as the plenaries
<nigelb> oh yeah 3 hour reporting time
<JontheEchidna> yeah...
<JontheEchidna> oh wellz
<fredfall> Is python 3 the future? In other words, should I learn python 3 instead of 2.6?
<xnox> fredfall, this is not apropriate channel for this discussion =)
<fredfall> Which is?
<xnox> fredfall, 2.7 will be shipped in 12.04 and supported until 2017
<jpds> https://wiki.ubuntu.com/FoundationsTeam/Specs/MaverickPythonVersions
<xnox> there is still limitted amount of libraries ported to 3.0
<xnox> fredfall, you should use 2.6 / 2.7 and pay attention to deprecated warnings =) to make sure your python scripts are compatible with 3.0
<fredfall> OK, thanks xnox!
<xnox> fredfall, plus you can always import from "future"  python module to play around with python 3 features ;-)
<xnox> fredfall, more appropriate channel for these questions is #python =)
<fredfall> Oops! . :)
#ubuntu-devel 2010-05-16
<peturi> Hey
<peturi> I need a point to the right direction
<peturi> Whre can i read more aobut how to get my application accepted to the official repos?
<jpds> peturi: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<xnox> jpds, =) I haven't met you before. What sort of things are you working on ? =)
<peturi> thanks
<psusi> blast... my ureadahead changes and defrag only shaved 5 seconds off the boot time on my new laptop... still takes 30 seconds to boot, all but 5 of which is after ureadahead finishes.. cpu seems to be a little slow
<psusi> on the up side, it didn't hose the fs ;)
<psusi> now to figure out why the ncurses interface didn't work from the initramfs....
<psusi> ohh, heh... the static binary isn't linked against ncurses... heh
<echosystm> im curious
<echosystm> are all packages maintained by canonical staff?
<echosystm> or are some packagse maintaiened by the community
<geser> packages in main are mostly "maintained" by canonical paid devs (but there are also some community devs working on them) where "universe" is community maintained
<nigelb> geser: you beat me that ;)
<nigelb> *to that
<echosystm> i'd like to get into linux development
<echosystm> and eventually maintain a package
<echosystm> got any advice for a newbie?
<echosystm> i dont really know where to start
<geser> the people maintaining the Ubuntu kernel are in #ubuntu-kernel
<geser> (you might need to wait till Monday when everyone is back from the weekend (and UDS))
<echosystm> im not so into the kernel
<echosystm> i meant some userland package
<nigelb> Also, if you're looking at maintaing individual packages, the best thing to do would be to take care of an orphaned package in debian
<echosystm> i guess the obvious thing is to find a package im particularly interested in
<echosystm> or i could do that nigelb
<echosystm> good idea :)
<geser> sorry, just got up (and didn't have a coffee yet)
<nigelb> ubuntu does not have a per package maintainer most of the time, we just have MOTUs who take care of the entire universe
<nigelb> or core devs
<echosystm> oh
<echosystm> hm
<nigelb> there is this big list of orphaned debian packages, taking of it would help what flows downstream into ubuntu
<nigelb> http://www.debian.org/devel/wnpp/
<echosystm> seems like any of the interesting packages require previous knowledge of the packages internal workings
<echosystm> how can people actually know these things straight up? surely most people would have to learn first
<MausP> Hello. At work I get a notebook with SSD. Want to install Lucid. afaik Lucid uses kernel 2.6.32. But ATA TRIM support was included to linux kernel 2.6.33.
<MausP> does anybody know if canonical backported TRIM to their 2.6.32 kernel?
<LucidFox> MausP> You can just update to a newer kernel from the kernel team PPA.
<LucidFox> granted, this is dangerous
<MausP> LucidFox: already found this http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.3-lucid/
<crimsun> MausP: in short, no, but there will be ways of getting newer kernel backports for LTS
<MausP> thanks. just wanted to know if it is possibly needless to install a kernel that's not supported
<rdz> hi all, i would like to test a patch for a certain kernel module (video driver). i figured out, that my trouble starts much earlier. i can compile the original driver, but the resulting module is not loadable.
<rdz> so either, the sources that i downloaded are _not_ the sources for the kernel-image i am currently running, or i am doing something wrong
<rdz> i am running 2.6.31-10-rt and i installed the sources with : apt-get source linux-image-2.6.31-10-rt
<rdz> is anyone able to compile gspca_ov534.ko (drivers/media/video/gspca/ov534.c) from linux-image-2.6.31-10-rt sources for said kernel?
<rdz> compilations goes fine, but the resulting module has mismatching symbol versions
<ScottK> rdz: You might have more luck in #ubuntu-kernel, but not this weekend since most of the kernel team is travelling.
<rdz> ScottK, thanks. nice for them :-)
<crimsun> kees: for a setgid daemon in Maverick, should we be pursuing fine-grained caps instead?
<crimsun> TheMuso: have ossp mostly source-version-3'd, will ask on pkg-pulseaudio-devel
<Sarvatt> would anyone mind hitting retry on libxfont on everything but i386? they build fine now that the other synced packages are caught up - https://edge.launchpad.net/ubuntu/+source/libxfont/1:1.4.1-2
<crimsun> done.
<Sarvatt> thanks!
<crimsun> yw
<psusi> cjwatson, I'm pretty sure that the dmraid regression in lucid is caused by libdevmapper... something changed causing it to add the p to the partition name just before the lucid release, but I can only get lp to show me the very last version... can you think of anything you might have changed that would do that?
<psusi> cjohnston, sorry, I meant libparted
<psusi> BINGO!  found it... now how the hell did that line get there?
<psusi> bah... another change by Hans de Goede
 * psusi sets out to revert another change of his
<mkarnicki> guys, are there any common tools to make GUI mockups (in sense of drawings)? I have seen similarly-themed GUI drawings on ubuntu wiki here and there
<mkarnicki> usually they had dotted background and where drawn with pencil-like lines
<RoAkSoAx> mkarnicki, balsamiq
<andreasn> mkarnicki, actually, it's those are pen and paper: http://incompetech.com/graphpaper/squaredots/
<RoAkSoAx> mkarnicki, i.e. https://wiki.ubuntu.com/TestdriveFrontend
 * psusi prepares to drop an SRU, oh boy
 * psusi shakes his head at his goofy wife
<mkarnicki> RoAkSoAx: andreasn: thank you :)
<mkarnicki> RoAkSoAx: andreasn: yeah, I think both methods are good, thanks!
#ubuntu-devel 2011-05-09
<Viper550> I;m just wondering, has Ubuntu ever offered Debian's graphical installer on the alternate CD?
<wcchandler> I want to jump on the ubuntu development bandwagon.  Is there a wiki page or a newbie howto to jump into contributing?  I come from a hardware tester stand point (been doing it professionally for 6 months) so testing is more up my alley but I would also like to help port deb packages if possible.
<arand> !dev | wcchandler
<ubottu> wcchandler: Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<wcchandler> arand: much love, thanks :)
<Daniel0108> hi
<Daniel0108> who's at the UDS?
<abhinav-> dholbach, I heard that we can keep track of the happenings of UDS remotely , is there an IRC channel ?
<dholbach> abhinav-, there's loads of them
<broder> abhinav-: start with #ubuntu-uds and http://icecast.ubuntu.com:8000/
<broder> and http://uds.ubuntu.com/participate/remote/
<dholbach> thanks broder
<broder> np
<abhinav-> thanks dholbach , broder :)
<dholbach> (I wasn't quick enough to find the links)
* sladen changed the topic of #ubuntu-devel to: Ubuntu 11.04 released! #ubuntu-uds http://icecast.ubuntu.com:8000/ http://summit.ubuntu.com/ | Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | P
* sladen changed the topic of #ubuntu-devel to: UDS-O: #ubuntu-uds http://icecast.ubuntu.com:8000/ http://summit.ubuntu.com/ | Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<abhinav-> vlc-multimedia plugin is crashing :-/
<pitti> cjwatson: yes, dropping python-{rsvg,cairo} was the right thing, thanks!
<pitti> cjwatson: nonexisting-file> seems like a side effect, I'll have a look
<pitti> mdke: yes, the next -base refresh will have gnome help xml from -updates
<mdke> pitti: excellent, thanks. So basically just need to aim to get each SRU done and pushed to -updates before langpacks are exported
<pitti> right
<mdke> great
<alkisg> Will a linux-image-generic-lts-backport-NATTY package be made available in lucid-updates? (currently we can get it from kernel-ppa)
<Q-FUNK> howdy!  could someone please perform a source upload of apparmor?  it needs a rebuild for perl 5.12
<cjwatson> Q-FUNK: yes, I'm tracking the entire Perl transition and doing mass uploads
<cjwatson> the only reason I haven't done apparmor yet is that I want to grab kees and check about the state of its bzr branch
<cjwatson> and it was the weekend with UDS travel
<cjwatson> http://orangesquash.org.uk/~laney/transitions/perl.html
<Q-FUNK> cjwatson: oh yes, UDS. forgot about that as I skipped it.
<kees> cjwatson: "done" apparmor??
<kees> cjwatson: ah, rebuild
<kees> cjwatson: I can do an upload if you need?
<Q-FUNK> yes
<Q-FUNK> it's one of the last few packages that haven't been rebuilt for perl 5.12
<kees> Q-FUNK: okay, give me a few minutes...
<Q-FUNK> kees: cheers! :)
<kees> cjwatson, Q-FUNK: actually, you can sync the package from Debian.
<cjwatson> kees: OK, cool, I'll do a sync
<cjwatson> kees: can I do it in your name?
<kees> cjwatson: yup!
<cjwatson> kees,Q-FUNK: done
<Q-FUNK> cjwatson: thanks!
<ogra_> slangasek, LOL, you made my day with http://i.imgur.com/usftZ.png
<cody-somerville> lmao
<Chipzz> lol :)
<ogra_> RAOF, how much beer does it take to get nouveau support for tegra2 arm boards ?
<RAOF> ogra_: Oh, dear.
<ogra_> hehe
<geser> ogra_: don't forget http://xkcd.com/323/ :)
<ogra_> RAOF, its obviously a GeForce ... just connected to a weird bus it seems
<RAOF> So, from memory the *guess* is that tegra2 GPU has a significantly different architecture to any of the nouveau-supported GPUs.
<RAOF> There's also the problem that I don't think that nvidia provides a binary tegra2 driver for linux, right?
<ogra_> there is one for android
<RAOF> Hm.
<ogra_> (which also works on ubuntu if you use nvidias kernel etc)
<ogra_> (and theor X)
<ogra_> *their
<RAOF> So, you'd need to build an mmiotrace-enabled android kernel and then trace their module.
<RAOF> That'd be a pre-requisite for pretty much any support.  Either that, or docs from nvidia about how to poke it.  I'm not holding my breath for those :)
<dholbach> can somebody review https://code.launchpad.net/~dholbach/ubuntu-dev-tools/bitesize/+merge/60370 please?
<tumbleweed> dholbach: when the patch appears...
<dholbach> tumbleweed, it's there :)
<RAOF> ogra_: So, in short, I think that the beer would be required to be funneled elsewhere in order to get someone to be assigned a couple of months to actually work on it :)
<ogra_> RAOF, well, but your note above should at least get us a dump with the needed info for a start
<ogra_> i'll try to at least get that, so someone intrested can pick up
<RAOF> I don't think anyone in nouveau upstream is currently particularly interested, but it's not inconcievable that someone would come along and be interested.
<sebner> dholbach: we'll see each other on friday \o/
<dholbach> sebner, awesome
<sebner> dholbach: finally :D , /me hopes to meet all the other heroes like ScottK, pitti ,..... (could go on for an hour) too :D
<cjwatson> lamont: is there a reason most of the porter boxes (with the exception of porter-armel) have no oneiric chroots, or should I just file an RT?
<cjwatson> (my oneiric chroot is on my external hard disk, which is annoying to haul out at UDS ...)
<lamont> cjwatson: because it wasn't bootstrapping well at the point where I went to create them.
<lamont> I'll create them shortly, feel free to throw something at RT
<psusi> what is the TZ over there in budapest?
<tumbleweed> psusi: UTC+2
<dholbach> tumbleweed, resubmitted - thanks
<geser> psusi: http://www.timeanddate.com/worldclock/city.html?n=50
<psusi> oh my, so it is already 3:40 pm there?
<tumbleweed> yup
<hyperair> slangasek: that image you posted on ubuntu-devel is win.
 * hyperair ditches emacs and starts using microsoft word to do his debian packaging work
<broder> haha. i didn't look at it before now :)
<hyperair> =p
<tseliot> chrisccoulson: can you ask Jorge to check IRC, please? A user is looking for him in #ubuntu-uds
<chrisccoulson> tseliot, his laptop is dead atm
<tseliot> chrisccoulson: ok, thanks
<broder> cjwatson: looks like i was imagining things. multicore vs. singlecore mksquashfs doesn't appear to have an impact on image size for the images i'm building at work. must have just affected rsync-ability
<saimanoj> hello everyone
<saimanoj> hi
<killown> please FIX IT, The 'sync_supers' thread wakes up every 5 seconds  and writes back all super blocks. It keeps waking up even if there are no dirty super-blocks, http://bpaste.net/show/16089/ very annoying bug
<killown> please developers, work to fix this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560 veryyyyy annoying, I don't want to change de distro again
<ubottu> Ubuntu bug 607560 in linux (Ubuntu) "jbd2 writing block every 5 - 10 seconds, preventing disk spin-down and making noise" [Undecided,Confirmed]
<ntr0py> where is the root fs mount command in initrd located?
<equex> will there be more backports or updates done for 8.04 ? would be nice with one final ultimate 8.04.5 now that the support just officially went out, perhaps with a more recent kernel too!
<infinity> equex: If you want newer kernels and software, you want a newer release.
<killown> Does anyone know how to get ride of this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560 ?
<ubottu> Ubuntu bug 607560 in linux (Ubuntu) "jbd2 writing block every 5 - 10 seconds, preventing disk spin-down and making noise" [Undecided,Confirmed]
<infinity> equex: That said, it's only desktop support that's ended, so anything covered by the "server" seeds (and that includes kernels) will still be getting bugfixes.
<equex> i'd basically just want a 8.04.4 with all updates since then + new kernel (if it doesnt break anything) + maybe there's bugs and annoyances that has been fixed and are ready for deployment but hasn't because 8.04 isn't cool anymore (it is, been using it since it came!)
<killown> Hey developers Do I need switch of distro? this bug affects physically my hardware
<killown> I know a lot peoples who has having this problem
<Keybuk> killown: if a bug is physically affecting your hardware, that strongly implies a kernel or near-kernel bug
<killown> I know it's a kernel related problem, but you guys should looking for another kernel version more stable or patch it soon.. its not a bug that you can just ignore
<Keybuk> in which case it's code shared by all of the distros
<Keybuk> you might want to try a different OS, maybe Windows or OS X
<killown> this just won't stop to make noises em fuc* up my hd
<killown> Keybuk, thanks, but I prefer gentoo.
<Keybuk> killown: do you know which compiler flags fix the bug?
<killown> Keybuk, I know that gentoo is stable enough to not have this bug
<killown> I have gentoo stable installed on my system, so I can confirm this problem doesn't happen with gentoo
<killown> ubuntu is great, but this bug does change my concepts about ...
<killown> bye ubuntu...
<andersk> cjwatson (or anyone working on the Perl 5.12 transition): net-snmp failed to rebuild, which is blocking some other packages from transitioning.  Debian already has this fixed; I filed LP bug 780149.
<ubottu> Launchpad bug 780149 in net-snmp (Ubuntu) "net-snmp FTBFS on oneiric (eval: 1: base_compile+= gcc: not found)" [Undecided,New] https://launchpad.net/bugs/780149
<galfly> Hi fellow ubuntu developers
<galfly> Hey ubuntu folks!
<galfly> A novice developer needs a little insight here
#ubuntu-devel 2011-05-10
<wcchandler> Just so I have this clear, Every time a new release is about to come about, like 11.10.  You guys take a snapshot of the current debian unstable?  And then from there you do all the magic?
<lifeless> o
<lifeless> no
<lifeless> right *after* a release comes out, we grab everything in unstable
<lifeless> then we spend 6 months fixing the result + doing the things we're trying to do that layer on top of it
<wcchandler> Then as updates roll out on debian unstable, are they set aside until everything is polished on the snapshot and then slowly added when they reach the same level as everything else?  Are they added after an initial release (i.e. Alpha, Beta?)  Or are they never touched until the release officially comes out?
<lifeless> we start with everything coming across and then as we get closer to release gradually turn the pipe off
<lifeless> first from automatic to manual, then manual to needing approval, and finally no updates at all
 * wcchandler gets to the section on seeds, germinate and bazaar  :$
<wcchandler> On this page: https://wiki.ubuntu.com/SeedManagement under Supported there are two links "Arch" and "Soyuz" that do not link to an actual page.
<lifeless> oh wow
<lifeless> thats -very- old
<wcchandler> :(  please tell me it's still relavent?
<wcchandler> And I noticed most of the links pointed to Gutsy...  I just assumed as an example?
<lifeless> no, thats when they were written
<wcchandler> Is this page still relevant: https://wiki.ubuntu.com/UbuntuArchitecture
<lifeless> last edited 2010-06-06
<lifeless> so yes, I think so
<cjwatson> broder: oh well
<cjwatson> andersk: thanks, merging
<alkisg> Will there a linux-image-generic-lts-backport-natty package become available in lucid-updates? Now only -maverick is there... http://packages.ubuntu.com/search?keywords=linux-image-generic-lts-backport
<highvoltage> akgraner: hi! do you happen to be close to kazincsky? would like to talk about UWN
<ohsix> hm can the card types available to a card reader generally be read from the device? one of my pet peeves is rolling a udev rule to set the types for the ui & it'd be cool to write a helper for it
<smoser> someone able to help me with http://uec-images.ubuntu.com/server/oneiric/20110510/log.stdout.stderr
<smoser> The following packages have unmet dependencies:
<smoser>  libhttp-daemon-perl : Breaks: libwww-perl (< 6.00) but 5.837-1 is to be installed
<smoser>  libhttp-date-perl : Breaks: libwww-perl (< 6.00) but 5.837-1 is to be installed
<broder> there's a massive perl transition happening
<broder> i'd try again in a few days
<smoser> well its been broken for over a week
<broder> massive>
<smoser> but, fair enough
<slangasek> smoser: yes, it's a deep transition
<Laney> if it rebuilds you can reupload it
<slangasek> and progress is slow during UDS of course
<Laney> that looks like a new package this cycle, so the transition monitor may be missing it ...
<micahg> looks like a dependency loop
<micahg> *circular dependency
<ogra_> cjwatson, ping
<ogra_> cjwatson, https://blueprints.launchpad.net/ubuntu/+spec/other-o-arm-preventing-archive-skew might intrest you
<cjwatson> smoser: I'll look and sort it out
<cjwatson> ogra_: sure, when's it scheduled?
<smoser> cjwatson, regarding pv-grub2, would it be useful to you if you had access to xen at this point?
<smoser> i can probably get you access to something.
<cjwatson> smoser: hm, I think on the whole I probably just need to sort it out on my laptop or something
<cjwatson> but hold that in reserve :)
<cjwatson> smoser: libwww-perl> actually, can I make this your problem again?  the problem is that several MIRs need to be written for the new libwww-perl
<cjwatson> smoser: you can find them by looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt and searching for libwww-perl
<cjwatson> smoser: you might need to search recursively to make sure you've got them all
<smoser> cjwatson, so you're asking me to do some MIRs?
<smoser> pff... i can [reluctantly] do that.
<cjwatson> yup, if you could :)
<cjwatson> well, somebody who cares needs to own MIRs, generally
<cjwatson> and you seem to care :)
<smoser> yeah, no probably. i understand.
<smoser> thanks cjwatson
<cjwatson> if it still fails to build after all that, I'm happy to attempt to sort it out from a perl-transition point of view
<cjwatson> but this doesn't look like intrinsically part of the perl 5.12 transition - it's just new deps from an autosync
<Chipzz> hrrrrm, I see libwww-perl has several -perl reverese build-deps.. but is that actually needed (as opposed to reverse deps)?
<Chipzz> does parrot byte code get compiled at build time?
<cjwatson> I expect that it needs them to run its test suite
<cjwatson> parrot> irrelevant
<Chipzz> ah k tests make sense
<lifeless> slangasek: if you need a concordence of all the paths in the archives, the conflict checker sqlite db has that
<lifeless> slangasek: I don't know if thats less work.
<lifeless> slangasek: but I'm sure it would be less than unpacking everything. :P
 * lifeless is gone
<slangasek> lifeless: ta, notated
<cjwatson> I also mentioned ravel.debian.org:~cjwatson/docscanner/
<ogra_> cjwatson, i think it is about to be scheduled, it was only created yesterday afaik ... NCommander works on getting it on the schedule atm
<NCommander> ogra_: ok, i just poked robbie on that spec to get scheluded
<ogra_> NCommander, make sure colin is subscribed so we dont cause conflicts ;)
<NCommander> ogra_: k
<tbf> appmenu for gtk3 apps - someone having time to review that minor patch and merge it? https://code.launchpad.net/~hasselmm/appmenu-gtk/gtk3/+merge/60326
<tbf> also have the required packaging changes in my ppa
<tbf> fixes this bug: https://bugs.launchpad.net/appmenu-gtk/+bug/701295
<ubottu> Ubuntu bug 701295 in Ayatana Ubuntu "appmenu-gtk GTK3 support" [Medium,Triaged]
<dpm> pitti, if you've got a minute during UDS, may I ask you to copy the PPA langpacks to natty-proposed, and then I'll do a call for testing?
<Q-FUNK> cjwatson: are you still on the perl transition?
<cjwatson> Q-FUNK: yes
<Q-FUNK> cjwatson:  these seem to be giving me problems: libany-moose-perl libgnupg-interface-perl libmouse-perl
<cjwatson> yes
<cjwatson> I'm working on them
<cjwatson> that lot will be fixed later today
<Q-FUNK> cjwatson: ah, ok. thanks!  I was trying myself at libmouse-perl, but the builder barfed on the perl version installed
<cjwatson> libmoose-perl was blocked on a newer libpackage-stash-perl, which is now rebuilt
<Q-FUNK> ah, that would explain it.
<cjwatson> so should be retriable shortly
<cjwatson> Q-FUNK: libmoose-perl retried, and a while after that I'll be able to do the bits of the stack that depend on that
<cjwatson> Q-FUNK: you can rest assured I am very actively tracking all this, anyway :)
<Q-FUNK> cjwatson: cheers! :)
<bigon> https://bugs.launchpad.net/ubuntu/+source/cdbs/+bug/745828 could somebody have a look at this
<ubottu> Ubuntu bug 745828 in cdbs (Ubuntu) "python-module.mk incorectly call dh_python2 with unexisting --prefix parameter" [High,New]
<bigon> ?
<geser> bigon: have you checked where the difference is? does Debian's dh_python2 support this option or does Debian cdbs' call it without that option?
<tumbleweed> geser: no debian doesn't support it (that I know of) looks bug-ish
<bigon> debian cdbs doesn't include this --prefix thinh
<bigon> thing
<tumbleweed> oh, duh
<tumbleweed> +    - 1/class/python-distutils.mk.in, 1/class/python-module.mk.in: Add
<tumbleweed> +      --prefix support for pysupport by DEB_PYTHON_PREFIX_ARG (LP #625581)
<ubottu> Launchpad bug 625581 in Quickly "quickly ubuntu templates should install apps in /opt not bin" [High,Fix released] https://launchpad.net/bugs/625581
<geser> the test suite for this change forgot to check if other python packaging systems didn't break with this change (it only checks if pysupport works)
<tumbleweed> the equivalent of --prefix in dh_python2 is just to specify the full path to the private directory. Don't know why they didn't use dh_python2 for this in the first place...
<micahg> I just saw bug 780479, but don't have an answer for it, I'm guessing this was space related?
<ubottu> Launchpad bug 780479 in Ubuntu "missing debug symbols for hardy" [Undecided,New] https://launchpad.net/bugs/780479
<real_ate_> hi guys! quick question ... our company had to patch a deb package that comes with ubuntu and want to keep an eye on when that package updates so that we can reapply our patch
<real_ate_> is there any sort of automated mailing list that can notify you of a change of a particular package in ubuntu?
<micahg> real_ate_: lists.ubuntu.com, there should be a $RELEASE-changes list
<real_ate_> i.e. when libxyz is updated you get an email with a subject "Package libxyz has been updated" etc ....
<micahg> real_ate_: also, if it's appropriate for others as well, you could try to get it into Ubuntu and/or upstream
<micahg> real_ate_: no, the list shows almost all changes to the release except for mass auto-sync from Debian
<micahg> real_ate_: but that doesn't happen in a stable release anyways
<real_ate_> micahg: its not realy apropriate... it for LTS and it is choosing to configure with libxml for axis2c because of a bug in the built in xml parser... too big of a change for a SUR (or whatever the achronym is )
<micahg> real_ate_: ok, you could get the fix in for the next LTS though if appropriate :)
<Chipzz> real_ate_: you could install apticron; that will send out a mail whenever new packages are available
<cjwatson> real_ate_: you can also subscribe to the 'derivatives' keyword for a package on packages.qa.debian.org - IIRC that gets all Ubuntu uploads
<cjwatson> (I don't recall how much else it gets though)
<Chipzz> real_ate_: if you pipe the mail through a script you could grep for the package name
<Chipzz> (I'm doing sth similar, but not for watching a specific package; I rather put all available updates in a db)
<real_ate_> Chipzz: cool i will have to look into this
<micahg> you could filter by subject if you have the changes list set to individual mails as well
<Chipzz> real_ate_:
<Chipzz> # grep apticron /etc/aliases
<Chipzz> apticron: |/usr/local/bin/wf-apticron-parse
<Chipzz> that's with postfix
<Chipzz> don't even have to install procmail or anything
<real_ate_> Chipzz: i will have to look into that solution but for now i will go with the list... it means that we can have a single setup not dependant on a particular machine being up
 * real_ate_ is working on a cloud system
<real_ate> thanks for all your help
<saimanoj> hi
<smoser> cjwatson, http://paste.ubuntu.com/605732/
<smoser> that includes the majority of the new perl libraries that we'll need.
<Laney> which package creates sources.list?
<Laney> ubiquity, debootstrap, â¦?
<broder> Laney: not debootstrap. i think it would be one of the d-i components that ubiquity pulls in
<Laney> broder: debootstrap does, otherwise how do chroots get their sources.list?
<Laney> debootstrap/functions:879
<broder> yeah, but that's a dummy that's not actually used by anything
<Laney> apt in a chroot?
<maxb> Laney: apt-setup udeb?
<Laney> maxb: yeah, looks good. Does that affect both d-i and ubiquity installs?
<maxb> Uh. Unsure. I only every use d-i
<maxb> *ever
<tumbleweed> didrocks: I see you broke cdbs :) I was just about to start looking at it
<didrocks> tumbleweed: hum, really? I didn't touch it for month
<tumbleweed> maybe it was a merge after it. bug 745828
<ubottu> Launchpad bug 745828 in cdbs (Ubuntu) "python-module.mk incorectly call dh_python2 with unexisting --prefix parameter" [High,New] https://launchpad.net/bugs/745828
<didrocks> tumbleweed: yeah, seems an incorrect merge from someone then
<didrocks> I think I ignored dh_python on purpose
<seb128> iz pitti fault
<tumbleweed> I didn't see anything that checked fro dh_python2, but I wa sreading the patch during a session...
<broder> Laney: ubiquity takes snapshots of a bunch of udebs and then uses them. apt-setup appears to be one of those
<Laney> good
<Laney> :-)
<didrocks> seb128: always pitti ;)
<Laney> http://paste.ubuntu.com/605754/ is this enough?
<Laney> cjwatson: ^
<Laney> (sorry, you weren't in the session â we decided to have this enabled in the default sources.list now that NotAutomatic should make apt DTRT)
<cjwatson> Laney: I think so, could you please post a merge proposal against lp:~ubuntu-core-dev/apt-setup/ubuntu though?
<Laney> cjwatson: yes, I am doing. Didn't want to post a wrong diff.
<cjwatson> smoser: all promoted, thanks
<broder> ScottK: does the backports process currently use the triaged bug state? it seems like that would be good for "someone has looked at this and determined someone needs to do testing" if not
<ScottK> broder: Not everyone can set Triaged.
<broder> oh, hmph. well...can *i* start using it for that? :-P
<ScottK> Currently "Confirmed" means ready for ubuntu-backporters review.  It seems a bit backwards to use Triaged for needs testing.
<hallyn> regarding bug 780479 - hardy is still support on servers iiuc, so shouldn't ddebs.ubuntu.com still show hardy?
<ubottu> Launchpad bug 780479 in Ubuntu "missing debug symbols for hardy" [Undecided,New] https://launchpad.net/bugs/780479
<hallyn> pitti: ^
<hallyn> (just bc i see you posting in the past about ddebs :)
<hallyn> (nm, i suppose -dbg should work)
<saimanoj> hello.
<jhunt_> Hi Scott - got time for a gtalk chat?
<lamont> ScottK: postfix 2.8.3-1 uploaded to debian, you wanna do the no-changes-needed sync sometime?
<hallyn> if a particular library's makefile wants to install into /usr/lib64, is the right thing to do to force those into /usr/lib?
<hallyn> (for the debian package)
<hallyn> I can't *just* put it into /usr/lib64, bc then a package using it ends up using /usr/lib/libfoo, and then I get dpkg-shlibdeps: error: no dependency information found for /usr/lib/libfoo
<infinity> hallyn: It should be in /usr/lib, yes.
<hallyn> infinity: ok, thanks
<hallyn> is that to be found in the debian guide?
<hallyn> (probably;  reading)
<infinity> hallyn: Perhaps somewhere in some library packaging guide or some such.  It's been a long time since I've paid attention to what lives in which policy.
<infinity> hallyn: But, basically, our 64-bit architectures are treated as "first-class citizens" and given the same file layout as 32-bit arches.  Which puts us (Debian and Ubuntu) at odds with LSB and most other distributions.  With any luck, multiarch will gain widespread adoption and no one will care anymore. :P
<hallyn> i'll need to read up more on multiarch
<hallyn> didn't pay enough attention to theannounce
#ubuntu-devel 2011-05-11
<ScottK> lamont: Thanks.  I want to backport that.  I think we need the multiarch stuff for oneiric (or did you shove that in too - I'll look)
<lamont> ScottK: multiarch is there
<ScottK> OK.  Thanks.
<lamont> ScottK: I've been informed that the multiarch patch is safe-for-debian, by he who knows best
<ScottK> This is the same guy that did the patch that led to postfix being sru'ed in Natty already?
<ScottK> ;-)
<Daniel0108> hi MacSlow
<MacSlow> Mahlzeit Daniel0108
<alex6567> hello all! Did you know it posible use unicode on ncurses lib? http://ubuntuforums.org/showthread.php?t=1755327
<mdke> I wonder if anyone could give me some guidance on who might be able/willing to help out with my query here: https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/033095.html
<slangasek> alex6567: note the topic's suggestion to use #ubuntu-app-devel for app development questions.  But for starters, if you want widechar support you need to link against libncursesw, not libncurses.
<alex6567> thanks try to google
<slangasek> bdmurray, bryceh_: do either of you have a good way to mass-mark a group of bugs as duplicates?
<slangasek> (https://bugs.launchpad.net/~fadly87)
<slangasek> (all duplicates of bug #780877)
<ubottu> Launchpad bug 780877 in pam (Ubuntu) "package libpam0g 1.1.1-2ubuntu5.1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script killed by signal (Segmentation fault)" [Undecided,Invalid] https://launchpad.net/bugs/780877
<sbeattie> slangasek: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/responses/is-duplicate
<cjwatson> slangasek: lp-set-dup?
<cjwatson> (in ubuntu-dev-tools)
<slangasek> cjwatson: ta :)
<ogra_> cjwatson, for oneiric we want to drop the netbook seed, i was wondering if we have an easy way for doing that transition through the seed management or if i need to roll an empty dummy package to do that transition
<ogra_> .oO(how did we handle it for UNR->desktop ?)
<jelmer> pitti, hi
<jelmer> pitti, did the bzr packaging session get cancelled?
<cjwatson> could somebody in ubuntu-mir review bug 780591 reasonably soon?  it's blocking part of the perl transition (indirectly)
<ubottu> Launchpad bug 780591 in libencode-locale-perl (Ubuntu) "[MIR] libencode-locale-perl" [Undecided,New] https://launchpad.net/bugs/780591
<kees> sladen: regarding capabilities, this is one review of the isolation failure issues: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522
<sladen> kees: loooong read.  I only know from the vserver perserpective (and no several years out of date); but none of the first 19 are/were given to container ruid=0 by default (so empty /dev and no mknod())
<sladen> kees: and CAP_NET_RAW only given explicitly (in this case to get ICMP ping to work)
<kees> sladen: right, with a very restricted cap bounding set, you can feel much safer in a container
<kees> sladen: I think the addition of syscall filtering will make that even stronger. (currently being discussed upstream, driven by the chromium folks)
<sladen> kees: can apparmour already provide that level of syscall filtering (either complete denial, or explicit validation of syscall parameters)
<kees> sladen: no, MACs (SELinux, AppArmor, etc) filter a higher level of access, but don't filter syscalls.
<kees> sladen: for example, when new syscalls are added to the system, the MAC may not have any hooks into it, so an attacker has a certain subsets of the attack surface to use
<sladen> kees: nod, ah
<kees> it's all crazy :)
<kees> SECCOMP (and soon SECCOMP mode 2) is what will do the syscall filtering. see "man prctl" for SECCOMP
<cjwatson> ogra_: I'm not convinced we *did* handle it for unr->desktop (except perhaps in update-manager?)
<cjwatson> ogra_: there's no way to do it in seed management - better and clearer to build an empty package by hand
<cjwatson> ogra_: but if you can make update-manager help out, so much the better
<alex6567> i have idea what libncursesw5-dev have problems. in src #include <ncursesw.h> say file not exist
<highvoltage> if Martin Pitt is pitti, then why isn't Martin Pool called "pooli"?
<Amaranth> highvoltage: you could be cartej :P
<Amaranth> oh, I added an extra character
 * Amaranth needs a nap
<broder> cjwatson: if i run backport-helper against staging, where i've "approved" a backport of a single package to multiple releases, that bug comes up once for each series/backports project: http://paste.ubuntu.com/606144/
<broder> does that not work for you?
<cjwatson> broder: yes - that's not the point at which stuff is awkward for multiple target series
<broder> oh, hmm, i guess i misunderstood the issue, then. what's the current problem?
<cjwatson> broder: it's that the backports are all generated into a single directory, and the script doesn't like it when a file already exists
<cjwatson> so .orig.tar.gz tends to clash
<broder> ah, ok. so this is actually totally not my problem at all. got it :)
<cjwatson> it's not a major problem, it just means us doing stuff in a couple of passes
<hallyn> jdstrand: libvirt needs to be rebuilt for oneiric to find the new brctl (in /sbin/ not /usr/sbin now).  It doesn't need any changes, configure will find it.  How do I kick off the new build?
<hallyn> i will take lxc integration, in cooperation with dlezcano
<hallyn> we'll add it to the agenda for the lxc sprint in august
<hallyn> doh
<micahg> hallyn: someone just needs to upload a no change rebuild, dch -R to create the changelog
<hallyn> micahg: ok, thanks
<TerminX_> heh, I was bored so I decided to try upgrading a 32-bit install to a full 64-bit kernel/userland in-place without a reinstall
<TerminX_> I actually made it work ;D busybox-static, 10 years of dpkg experience and some nasty hacks with sed on the contents of /var/lib/dpkg for the win
<ogra_> infinity, poke
<Cas07> is there a specific name for the special mode dash (Alt+F2) in unity?
<tseliot> tjaalton: are you there?
<tjaalton> tseliot: at my room
<tseliot> tjaalton: do you already know what kind of food we're aiming for?
<tjaalton> nope
<tseliot> ok
<tseliot> tjaalton: ok, let's talk downstairs then
<tjaalton> yeah, meet you there
<tseliot> bryceh: are you there?
<bryceh> tseliot, yep, on my way down
<bryceh> didn't find sarvatt
<tseliot> bryceh, tjaalton: can you both join #dinner please?
<hallyn> is htere a way to force lp to import from the package?  libvirt is two versions behind...
<geser> hallyn: import to where in LP?
<hallyn> geser: lp:ubuntu/oneiric/libvirt
<hallyn> for now i'm just doing the sync by hand
<geser> hallyn: this happens when the importer hits a bug, it stops importing any future version till this gets fixed (see http://package-import.ubuntu.com/status/libvirt.html#2011-03-29%2015:05:13.895974)
<hallyn> geser: so how does one fix it?  do I bzr push a clean version cloned from the package?
<geser> hallyn: ask james_w ; but probably pushing yourself won't improve the situation (you would need to take care of importing Ubuntu revisions and Debian revisions in the right order to have a proper history)
<hallyn> geser: thanks
<hallyn> james_w: ^
<odla> will gnome3 be officially supported in 11.10 and beyond?
<hallyn> jdstrand: do you happen to know why X-Python-Version in libvirt's debian/control is listed as 2.6?
<infinity> ogra_: You poked?  I've been out all day.
#ubuntu-devel 2011-05-12
<pitti> jelmer: yes, it overlapped with the control-panel porting one, so that half of the relevant people werent' there any more
<jelmer> pitti: aha
<broder> small nit about the sru process i just realized - since average people can't accept sru nominations in lp, devs can get stuck in a position where the bug is fix released. how do you guys feel about changing the sponsorship queue to include bugs of *any* status that have ~ubuntu-sponsors subscribed?
<broder> (i looked - there are currently about 80 bugs that are fix released but still have ~sponsors subscribed, so it would be a one time cleanup)
<micahg> broder: MOTUs can accept universe nominations and core-devs all, unless that changed recently
<broder> micahg: yeah, but if we never see the nominations in the first place...
<micahg> broder: maybe just add it to the list if there's a nomination there
<broder> that could work. i'll see if i can query for that
<highvoltage> what happened with https://wiki.ubuntu.com/ArchiveReorganisation ?
<highvoltage> that process didn't quite seem finish yet and there doesn't seem to be any sessions on it
<broder> micahg: but also, the ability to even nominate was restricted some time recently, so this still might be a stumbling block for non-~ubuntu-dev members
<micahg> broder: yeah, that's a good point, idr what the wiki says to do ATM about that
<broder> it says to nominate, which you can't do unless you're in bugcontrol or something like that
<micahg> broder: yeah, we should fix that to be a process that everyone can do or have an option for people that can't nominate
 * micahg would suggest asking to ping in IRC for a nomination
<broder> yeah, the problem is that the nominate link was restricted because it was overused
<micahg> broder: maybe there's a session we can discuss this in?
<broder> unfortunately, i think that session just ended this morning :)
<micahg> ugh, yeah
<broder> dholbach: do you think there's room for that sru discussion in the sponsorship session?
<dholbach> broder, let's see how much stuff we have to go through
<Laney> highvoltage: I think it stalled... persia or cjwatson might know more
<cjwatson> it's stalled for now, yes
<Laney> Much of the metadata needed to solve these problems already exists, but is not exposed to users in any useful form; instead, everything of concern to "supported" derivatives is conflated into "main", losing the ability to express very much more than a binary state.
<Laney> [BOTTOM][TOP]Tracking of packages
<Laney> erg
<Laney> let me disable x paste!
<jerry256> ..
<micahg> slangasek: bug 779174 is the one, thanks
<ubottu> Launchpad bug 779174 in ca-certificates-java (Ubuntu) "package ca-certificates-java 20110426 failed to install/upgrade: fix path to libnss3 for multiarch" [Critical,Triaged] https://launchpad.net/bugs/779174
<slangasek> micahg: oh, *that* nss, right ;p
<micahg> slangasek: heh, yeah, I remember some of the recent conversions on debian-devel about the other NSS
<slangasek> micahg: if you can find jamespage, he's probably in a better position than I am to fix that
<micahg> slangasek: k, I'll try to track him down, thanks
<slangasek> micahg: he already fixed a similar bug in some java packages before natty release, so he knows the landscape very well
<alex6567> hello! i can't find out gtkmm-3.0
<alex6567> please help me
<sladen> alex6567: --> PPA
<tseliot1> Sarvatt: are you around?
<bryceh> tseliot1, he's in the multiarch session with me
<tseliot1> bryceh: ok, thanks
<jdstrand> hallyn: re X-Python-Version: it should be upped to 2.7 I think
<hallyn> jdstrand: ok, that's what I did
<hallyn> jdstrand: I'm trying to get more info on the 'test-poll' failure, but other than that the package is IMO ready to be pushed
<jdstrand> hallyn: I haven't had time to look at the package yet btw. it is likely I will not before tuesday
<hallyn> jdstrand: do you prefer I wait?
<jdstrand> hallyn: I culd do a shallow review before that perhaps
<hallyn> nah, you've got enough to do
<hallyn> one more day of UDS!
<jdstrand> hallyn: well, aiui, a) needs a simple rebuild in oneiric, and b) needs to be merged
<hallyn> ?  what are a and b?
<jdstrand> hallyn: I thought you msgd me about a libvirt needing a rebuild and you having a merge
<jdstrand> hallyn: am I imagining things?
<hallyn> for now I"ve pushed a patch to just comment out test-poll from gnulib/tests/Makefile*
<hallyn> oh,
<hallyn> the libvirt rebuild is done
<hallyn> (for brctl)
<jdstrand> ok good-- I was going to suggest that :)
<hallyn> so now I"m just looking to sync 0.9.1-1 from debian
<jdstrand> cool
<hallyn> jdstrand: let's just talk on tue or wed I guess
<hallyn> if you want to take a look, people.canonical.com has my current package
<jdstrand> hallyn: well, you have per-package upload rights now, you could upload if it's good. If you want me to look at it you know I will take a lot of time testing it myself ;)
<jdstrand> (which means tuesday)
<hallyn> heh, tha'ts why i'm tempted to wait
<jdstrand> hehe
<jdstrand> I just have a dinner tonight, then all day tomorrow, and an event tomorrow, then travel and holiday on monday
<jdstrand> hallyn: if my review is going to be worth anything, I need to wait a bit :/
<hallyn> jdstrand: no problem.
<hallyn> jdstrand: actually, feh, I think I just found another snafu
<hallyn> debian's support of non-linux os is killing me :)
<hallyn> well this is weird, for some reason
<hallyn> ifneq (,$(findstring $(DEB_HOST_ARCH_OS), linux))
<hallyn> is parsing as false in debian/rules
<hallyn> bug dpkg-architecture -qDEB_HOST_ARCH_OS gives me 'linux'
<hallyn> ah, i see
<p0s> SpamapS: hi. how's the raid startup bug?
#ubuntu-devel 2011-05-13
<soreau> Is there a way to check if a package is installed by default for a particular release of ubuntu?
<kb3gtn> soreau: try looking at the dependencies for the virtual packages..  ubuntu-desktop for instance..
<soreau> kb3gtn: I was hoping maybe there was an easy, reliable way through some web interface like packages.ubuntu.com
<kb3gtn> http://packages.ubuntu.com/natty/ubuntu-desktop
<kb3gtn> I think there is a vritual base package too.. not 100% sure..
<kb3gtn> else there is always dpkg -l on a fresh install..
<soreau> Of course but I was trying to find an easy reliable way without booting a live session
<kb3gtn> I am sure the guys that do the installer know what that information is..
<StevenK> ubuntu-standard
<StevenK> ubuntu-minimal
<kb3gtn> ah.. see :-P
<kb3gtn> just search for those packages on packages.ubuntu.com and they will show the list of packages they grab as dependencies.
<soreau> Somehow I doubt the dependencies of ubuntu-standard listed on packages.ubuntu.com is the complete list that would be equivalent to dpkg -l on a live cd
<cdbs> cjwatson: there? Can you please rebuild libpurple0? Its the last remaining library which remains to be rebuilt with the new perl
<cjwatson> cdbs: I already tried, but it failed to build (https://launchpad.net/ubuntu/+source/pidgin/1:2.7.11-1ubuntu3).  Feel free to figure out a fix
<infinity> cjwatson: That's a curious failure...
<infinity> cjwatson: Given that libgnt.la should have been produced literally a second earlier...
<cjwatson> infinity: yeah, indeed
<cjwatson> I haven't got round to reproducing it locally yet, and was sort of hoping somebody who cared about pidgin would do it ;-)
<infinity> I might care enough to look if no one beats me to it while I'm asleep.
<cjwatson> http://orangesquash.org.uk/~laney/transitions/perl.html is basically down to things that failed for non-trivial reasons now.
<cjwatson> I see at least one there that'll be resolved by the next autosync, too ...
<cjwatson> ah, awesome, Debian fixed libgstreamer-perl
<infinity> claws-mial-extra-plugins was just thwarted by the implicit pointer conversion check, that should be straightforward enough.
<tmottabr> Hi all... i have a hp pavilion dv2840se with a nvidia 7150 video card... i am using ubuntu 11.04 with the defaul nouveau card and it is working, but when i set the correct resolution for my laptop (1280x800) it flickrs and runs unusable, it was working fine in 10.10 with nvidia drivers.
<tmottabr> i did some research and found that my card was detecint the TV as connected, already managed to disable it, now it detects the correct resolution at boottime, but still flickers...
<tmottabr> i did not found much info on where to go next... can anyone give a sugestion?
<infinity> Dearest libtool, die.  No love, Adam.
<SuperLag> :)
 * vila falls from his chair
<vila> jam: what do you use to replace diff -rsubmit: ??
<broder> hmm...why can't i change the status of https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-fix-774265/+merge/60182 ?
<jam> vila: bzr diff -rancestor:../other
<jam> since it works between all branches
<vila> wow
<vila> H-z m is bound to diff -rsubmit: here as I always have parent_location and submit_branch set correctly so I never have to type this longer form, you really surprised me there..
<jam> I have it set correctly, just rarely use it
<vila> I think I use diff -rsubmit: less than diff alone but far more than all other forms combined
<vila> muscle memory I presume
<vila> broder: you'd get more precise answers in #launchpad, but I suspect only the reviewers can do that
<vila> broder: and I don't precisely know how lp decides you're an "official" reviewer
<broder> vila: it used to be the case that i could change the status for merges against packages i can upload
<vila> broder: can't help there :-/
<broder> i'm wondering if something weird is going on because it's an "sru" now
<wgrant> Which branch?
<vila> broder: hehe #launchpad is leaking here, listen to wgrant :)
<broder> wgrant: https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-fix-774265/+merge/60182, merged into lp:ubuntu/natty/meld
<wgrant> broder: Ah, I see.
<wgrant> So, you can no longer upload that package.
<wgrant> Because it's in the release pocket of a stable series.
<wgrant> So it doesn't see that you have any privileges over the branch, so you can't touch the MP.
<Laney> I thought that was a known bug
<wgrant> Bug #612391
<ubottu> Launchpad bug 612391 in Launchpad itself "Cannot change status for merge proposals that target a released series" [High,Triaged] https://launchpad.net/bugs/612391
<Laney> should they be moved over to the next release as part of its initialisation?
<Laney> see, I'm even subscribed :-)
<wgrant> I think the restriction is sensible, but it should perhaps be easier to retarget it to the new series.
<wgrant> It would be nice if it could be targeted to a moving "development series" branch.
<broder> that would be awesome
<wgrant> But I don't see an immediately feasible way of doing that.
<wgrant> Bugs welcome.
<slangasek> !grub
<ubottu> GRUB2 is the default Ubuntu boot manager since 9.10 (Karmic). Lost GRUB after installing Windows? See https://help.ubuntu.com/community/RestoreGrub - For more information and troubleshooting for GRUB2 please refer to https://help.ubuntu.com/community/Grub2 - See !grub1 for releases before Karmic (9.10)
<kcin1> pitti:I  would like to build a udev168 package,how do i start
#ubuntu-devel 2011-05-14
<soreau> Where can I ask about problems with packages.ubuntu.com like this one? http://packages.ubuntu.com/search?searchon=contents&keywords=aclocal&mode=exactfilename&suite=natty&arch=any
<soreau> It fails to find which package aclocal belongs to somehow..
<cdbs> cjwatson: Rebuilding pidgin should fix the issue I suppose, the proper irssi libs are there now. Just re-build the failed packages without uploading anything
<cjwatson> cdbs: OK, I've given it back, thanks
<cdbs> cjwatson: It failed again, seems like we need some la file cleanup
<cjwatson> feel free to sort that out :)
<broder> hmm...how does having NotAutomatic backports impact PPA builds that have backports set as a dependency?
<muneeb> it seems that in Natty the directory structure for /usr/lib is changed and that is causing me problems while installing my printer's driver. How can i resolve this?
<broder> muneeb: fix the driver
<broder> more seriously, are we talking about an open- or closed-source driver?
<muneeb> broder: i'm not a  developer :(( it's closed source
<broder> ok. well, you should point them at https://wiki.ubuntu.com/MultiarchSpec
<broder> it's not something that's easily worked around by anybody but the driver developers
<muneeb> broder: they haven't updated their drivers since ages.. i don't think they care about linux anymore.. i'm still not sure whether it's closed source or OSS.. lemme check
<muneeb> broder: i think it's open source.. http://support-in.canon-asia.com/contents/IN/EN/0100188102.html
<muneeb> broder: how can i fix these.. if you can point me.. i'll try.. btw what are changes in 10.10 and 11.04 regarding this /usr/lib and if anything else
<JanC> muneeb: the changes were done to allow installing software for more than one CPU architecture on one system
<muneeb> JanC: okay.. i'm reading that page..  but now what should i do to make it work? any coding is required?
<muneeb> anyone?
<JanC> muneeb: I think the main differences are where libraries are installed to and loaded from; most projects have an option for that in their build system
<JanC> in case of printer/scanner drivers, there might be additional issues with CUPS & SANE
<muneeb> JanC: hmm.. so i need to dig around a bit.. when i was trying to install this it was complaining  about not able to fine libc6 and more libraries but i had them installed..
<JanC> muneeb: do you have the developer libraries installed?
<muneeb> JanC: yes.. libc6-dev
<muneeb> JanC: i have whole tutorial written by myself for Maverick and below distros.. but it doesn't work for Natty now
<muneeb> JanC: i think it tries to find libraries in /usr/lib or some kinda location which are moved now in Natty
<JanC> muneeb: maybe you can ask the developers who are more experienced with multiarch in some days (most developers are on their way back from UDS, I think)
<JanC> and I agree it probably has something to do with changed locations
<muneeb> JanC: okay... thanks for the help btw.. i'll try to understand the source code till that time.. but i ain't developer :((
<Ampelbein> muneeb: can you pastebin the error and what command you invoked?
<muneeb> Ampelbein: i reinstalled Maverick for now.. i had pasted those errors on paste.ubuntu.com in #ubuntu channel.. i'll see if i can get those..
<muneeb> here's pastebinned error.. http://paste.ubuntu.com/607453/
<nacef> Hi there
#ubuntu-devel 2011-05-15
* broder changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Hootch> ipony, suche schnell Ibm
<Hootch> ,help
<dlbike76> Is this the right place to discuss building the development gnome-session-daemon?
#ubuntu-devel 2012-05-07
<ok2cqr> Hello,
<ok2cqr> does anyone know how long does it take to delete files from my personal ppa after request, please?
<ok2cqr> I did it about 10 hours ago and still getting error that files already exist
<soaringsky> ok2cqr: you can try to delete them again. in my experience things get deleted quickly
<ok2cqr> soaringsky: I don't see them in the package list
<ok2cqr> but if i want to copy the same package from  other ppa, I get error that it already exists :-(
<soaringsky> ok2cqr: strange. try asking in #launchpad
<ok2cqr> I'll try, thank you
<lifeless> pitti: btw, fixed the setuid() problem I was having
<lifeless> pitti: added allow_other to the fuse mount rule
<lifeless> pitti: so yeah, setuid seems to error when the cwd isn't accessible by the process
<lifeless> pitti: mmm, spoke too soon :(
<directhex> what do you call the opposite of a regression, where a totally unrelated fix seems to resolve a problem you're having?
<lifeless> serendipity
<directhex> of course, it's hard to +1 a fix in -proposed where you can't repro (and don't care about) the bug it fixes, but it seems to help an unrelated issue
<lifeless> pitti: otoh I've gone to the simple chroot/setgid/setuid now and it works where it wasn't before, so I think allow_other is what I'm going to write it up as.
<zaytsev> hi guys, i'm looking at the source code for usb-creator
<zaytsev> is it possible to remove the filter that makes it show only the usb devices
<zaytsev> i want to create an image from inside a virtual machine on a virtual sata drive
<zaytsev> it is not shown however, because it's not an usb device
<penguin42> zaytsev: Just apt-get source the package
<zaytsev> penguin42: right, so i did, but where is the trick? i'm looked at the backed code, but didn't find it. now trying to understand how the gtk frontend is working
<penguin42> zaytsev: Hey I don't know - not looked at it
<cjwatson> --show-all
<cjwatson> zaytsev: ^- IIRC
<cjwatson> or possibly --allow-system-internal, one of those
<zaytsev> cjwatson: you are too awesome!!! thanks again, this is exactly what i wanted. now i can also see the filtering in _add_partition...
<pitti> lifeless: interesting, I didn't know that setuid() would check the directory; but I guess it makes sense, otherwise the user could see a potentially inaccessible dir
<ogra_> pgraner, skaet, rsalveti (if you know anyone lese i.e. not sure victorp would like to be in it ) ... https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-drop-preinst-images
<ogra_> s/lese/else/
<dholbach> broder, happy birthay! :)
<broder> dholbach: thanks :)
<broder> (are you here?)
<dholbach> broder, that depends on where exactly you are :)
<broder> err, "in oakland" :)
<dholbach> yes :)
<ogra_> heh
<broder> awesome
<dholbach> room 201 :)
<Laney> uh oh
<ajmitch> so birthday party for the MOTU BOF?
<broder> haha. i'll consider allowing it if we finish early :-P
<penguin42> I hear birthday parties at conferences can be messy
<rsalveti> ogra_: great
<kees> apw: http://www.outflux.net/blog/archives/2011/12/05/pgp-key-photo-viewing/
<melodie> hi
<melodie> I have finished my first package, with openbox-menu in it, and registered to 2 places where I will try to find devs likely to be interested in openbox and dynamic menus generation. (the mentors ml and a place where I registered as maintainer for this package). if someone here is interested to try the package I can provide a link to the build dir tarball.
<melodie> is there someone here who likes Openbox as a standalone destkop ?
<melodie> desktop
<sconklin> slangasek: seen this? http://e4rat.sourceforge.net/
<slangasek> sconklin: no - whee
<slangasek> that looks... safe? :)
<slangasek> xnox: ^^
<broder> definitely not the word i would have chosen :-P
<xnox> slangasek: noted
<slangasek> xnox: what do you think of the idea of using it?  I guess it would provide only incremental benefit over ureadahead
<micahg> sounds like the rat might steal the cheese and hide it in the wall
<xnox> slangasek: do we have usecases where ureadahead does not work / not supported. need to read up on it.
<slangasek> and ureadahead is a bit quicker...
<slangasek> xnox: not AFAIK
<slangasek> well, there are certain corner cases where the ureadahead pack isn't available early enough to do any good
<slangasek> but that's not a case to cater for
<xnox> slangasek: I want to know how they choose what to reallocate where and how different their logic is to the ureadahead
 * slangasek nods
 * xnox the typicall FLOSS question: ditch, switch or steal features
<cnd> pitti, skaet, slangasek: on bug 968845 there is an xserver-xorg-input-synaptics task that is fix released in quantal
<ubottu> Launchpad bug 968845 in Xserver Xorg Input Synaptics "bcm5974 touchpad doesn't work after S3 on MacBookAir" [Medium,In progress] https://launchpad.net/bugs/968845
<cnd> there is no precise series task
<cnd> when I try to nominate, precise isn't available
<cnd> any ideas what's going on?
<micahg> cnd: are you in the ubuntu task context?
<cnd> micahg, yes
<cnd> I worry that in the p->q transition something got messed up
<cnd> like there was a p series task
<cnd> and it's magically disappeared
<slangasek> cnd: yes - not magically, someone must've clicked the button to remove it
<slangasek> you're needing to SRU this package for the bug?
<cnd> yes
 * slangasek tries something
<slangasek> cnd: I've deleted the other 'p' task, which has only made things worse
<slangasek> I was hoping it would make 'p' available again for targeting... it did not
<slangasek> cnd: escalate to Launchpad, please; this is basically an LP regression introduced by the added support for deleting bug tasks
<cnd> slangasek, ok
<cnd> thanks
<infinity> Oh, that's a special behaviour...
<slangasek> yes
 * micahg guesses it might be possible to set through the API
<Robint91> hi all
<Robint91> I want to investigate something
<Robint91> this bug report
<Robint91> https://bugs.launchpad.net/ubuntu/+bug/996176
<ubottu> Launchpad bug 996176 in Ubuntu "scroll wheel doesn't work with VmarkerUSB" [Undecided,New]
<melodie> hi
<melodie> I have sent a request for sponsor at Debian mentors ml
<melodie> http://lists.debian.org/debian-mentors/2012/05/msg00088.html
<melodie> for the package jtaylor and a few other persons helped me do yesterday.
<melodie> just wanted to let it know. :)
<spena> what team do I have to be member of to edit UDS etherpad documents ?
<ogra_> spena, just having an LP account should be enough
<spena> ogra_, thanks, I have an account
<spena> ogra_, and I am signed in
<tumbleweed> spena, ogra_: no it's not enough. you need to be added to the ubuntu-etherpad group
<ogra_> make sure you are logged in ;)
<tumbleweed> ask in #ubuntu-uds
<spena> tumbleweed, thanks, I will ask there
<spena> ogra_, thanks to you too
<ogra_> tumbleweed, ah, i knew someone else would know details if i answert ;)
<tumbleweed> :)
<tumbleweed> all developers and loco teams are added to that group already
<spena> tumbleweed: I'm not an ubuntu developer, so maybe that's why I cannot see it
<tumbleweed> other people are added on request
<melodie> gn
<melodie> oh tumbleweed !
<melodie> news : I have done the package for openbox-menu and done the other steps to ask for a sponsor at the debian mentors ml
<melodie> thought you would want to know
<melodie> gn now
 * ogra_ hugs pitti ... thanks for the gles compiz in -updates :)
<pitti> slangasek, cnd: yeah, once you delete a task you can never bring it back unfortunately
<pitti> I accepted the SRU without a precise task now
#ubuntu-devel 2012-05-08
<cnd> pitti, what are we supposed to do then for srus?
<cnd> I assume from your response that lp knows of the issue already?
<xnox> Laney: if you are up and about can please merge /dima branch into the junk tracker, yet again please =)
<xnox> this time around this is for foundations-q-python-versions blueprint
<xnox> with barry as responsible point of contact =)
<Laney> heh
<Laney> I don't know if that script should be in with the configs
<Laney> can you put it somewhere else and just add a comment or something linking to it?
<SpamapS> why oh why are my fans running at max speed when my CPU is 50C below "high"
 * SpamapS drops them to 3000 to see what happens
<twb> http://packages.ubuntu.com/precise/msmtp is returning a 500 for me - not sure why yet
<twb> it doesn't show up from the search form on packages.ubuntu.com either, but it is listed in rmadison... ?
 * twb finds the dsc URL by brute force instead
<Terminus_> twb: that's weird. doesn't show up on packages.ubuntu.com but shows up with aptitude search. =|
<Terminus_> twb: oh... you just need the dsc? https://launchpad.net/ubuntu/+archive/primary/+files/msmtp_1.4.26-1.dsc
<twb> Yeah that's the only reason I go to pdo/puc
<micahg> twb: have you seen pull-lp-source?
<twb> No, launchpad-tools went into the "too hard" basket for me, along with all of lp
<micahg> twb: it's in ubuntu-dev-tools :)
<twb> Grmph, gratuitous bump of dh compat from 7 to 8
<Terminus_> anybody here using winbind? not working here and logs don't show much info. and by not working, i mean it's half working and seems to fail when calling wbcGetpwnam()
<twb> (The actual end goal, is to get an msmtp that supports TLS cert checking, on lucid.  It's a minor headache to just cherry-pick that patch due to unrelated changes to the same C enums.)
<twb> IIRC I "fixed" this last time by just building msmtp 1.4.20 from source and dropping the binary in /usr/local/bin/
<Terminus_> oh yeah, the winbind problem i'm having is on 12.04.
<twb> Grah, apparently dget + lp + my curlrc will implicitly inflate the .diff.gz
<twb> Which then means .dsc will crack the shits even if I deflate it again, because the sums will be wrong
<micahg> !ohmy | |twb
<ubottu> |twb: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<twb> Sorry
<SpamapS> twb: seriously.. pull-lp-source. You're spending a lot of extra time for no gain. Also backportpackage.
<micahg> backportpackage doesn't work when the build deps are versioned too high :)
<SpamapS> sure it doedes
<SpamapS> backportpackage debhelper
<SpamapS> backportpackage msmtp
<SpamapS> :)
 * SpamapS wonders how deep that rabbit hole goes
<micahg> SpamapS: you really want to go down that rabbit hole?
<micahg> haha
<twb> SpamapS: too deep, because msmtp has gnome deps for one of its builds, and at a minimum I'm throwing that part away in my backport
 * SpamapS curses Canon for only providing i386 drivers for their scanner.. and depending on libgimp2.0 which is not multiarch yet
<twb> SpamapS: you are lucky -- $customer has a "scan to email" MFD, and they finished moving all their mail to google apps then called me "hey btw the scan-to-email isn't working anymore for some reason"
<SpamapS> Still.. the fact that I can install it (after removing amd64 gimp) and get a scan from my wifi scanner in 5 seconds is so nice compared to the bad old days. :p
<SpamapS> twb: I love IT by rote. It used to feed me back when I was a consultant.
<twb> BTW if I turn -o compress off in my .curlrc, dget works as expected.
<twb> SpamapS: "IT by rote" indicates you need a sysadmin to script that job away
<twb> Anyway I grabbed 1.4.20 instead of 1.4.26 and that backports cleanly to lucid with no fuss other than throwing out the gnome version
<SpamapS> twb: exactly, thats what I was.. the guy who scripted away bad IT admins' jobs. :)
<twb> http://paste.debian.net/167811/ hmm, what's that error about?
<twb> oh, I know
<twb> It's _all not _amd64.  Stupid copy-and-paste error
<eagles0513875_> hey guys is there a plan to migrate unity away from using X and to using wayland
<redwan> Hello, everyone. I'd like to ask several (maybe) questions. I want to begin contributing to Ubuntu, but I don't know where to start.
<redwan> I installed development and package tools, read some techtalks from Ubuntu Developer Day, but I still have a lot of questions, such as: where I can choose bug
<redwan> which bug to choose from the list, etc
<redwan> Can anyone help me with it?
<twb> Hmm, is there a wnpp-alert equivalent for Ubuntu?
<twb> redwan: there are ways to contribute other than writing code, too.  e.g. localization teams
<redwan> twb: i'd like to write code.
<twb> Fair enough.
<geser> redwan: see if you find an easy task for you on http://harvest.ubuntu.com/ or try to fix an issue which annoys you
<redwan> geser: thanks! so I choose task there, complete it, make diff and then send it to verify?
<twb> geser: ah, neat.  I was sure there'd be such a tool, just wasn't sure what it was called :-)
<twb> Haha, "nmap has no watch file".  That's low-hanging indeed.
<twb> Where it says "5 hidden opportunities", how do you unhide them?  AFAICT not by clicking on anything...
<twb> OH, I see, if I scroll down there is a "difficulty" check list and by default only "bite size" is shown
<geser> redwan: yes, see https://wiki.ubuntu.com/SponsorshipProcess on how to get your changes sponsored into Ubuntu
<dupondje> anyone a list with merges ?
<dupondje> alternative for the MoM :)
<geser> dupondje: see https://launchpad.net/ubuntu/quantal/+localpackagediffs to find candidates for a merge
<dupondje> thx geser  :)
<dupondje> bored today, so ... :D
<verwilst> hello, maybe not the right place to ask, but the IM appindicator menu has counter 'bubbles' for email for example. Anyone knows where to find a code snippet on how i can implement this in my own appindicator menu?
<verwilst> http://developer.ubuntu.com/resources/technologies/messaging-menu/ works here, but it seems the python lib doesnt have an equivalent
<dupondje> libhdf5-openmpi-dev : Depends: libhdf5-openmpi-7 (= 1.8.8-9) but it is not going to be installed
<dupondje> odd, any idea's? Package seems to be published, test build worked fine
<azeem_> what does apt-get install libhdf5-openmpi-7=1.8.8-9 say?
<dupondje> ok https://launchpad.net/ubuntu/+source/octave3.2
<dupondje> this is the reason
<nigelb> bryce_++
<nigelb> that was an awesome email :)
<nigelb> (Not the football team)
<xnox> Laney: I've pushed an update to /dima again. Just the ben file this time around
<ogra_> pitti_, did you have a consolekit session planned (that just came up in the multiseat session) ?
<melodie> hello
<melodie> do someone have a clue about why the officiel Ubuntu LTS new versions are default provided with a pae kernel ?
<micahg> melodie: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System_requirements
<melodie> micahg, I look, thanks
<melodie> micahg, it says, however it does not say why
<micahg> melodie: if you need a non-PAE install disk, just use lubuntu or xubuntu ISOs
<micahg> the why is that most machines should have PAE enabled at this point
<cgregan> zyga_: I added you to the Checkbox Core meeting. It will not happen this week, but will begin again next week. We can discuss combining efforts then if you are able to make it.
<zyga_> cgregan, I can attend remotely next week
<cgregan> zyga_: yeah...we do google hangout
<cgregan> cool
<zyga_> cgregan, I strongly believe that the sooner we combine efforts the less resources we'll waste in the long term, we are really doing exactly the same thing today
<zyga_> cgregan, excellent, looking forward to it
<dupondje> https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 clipboard patch for quantal added, if somebody could review :)
<ubottu> Launchpad bug 937522 in remmina (Ubuntu) "rdp clipboard sync doesn't work anymore." [Undecided,Confirmed]
<melodie> gn
<dupondje> damn couchdb is prehistoric in Quantal
<dupondje> not merged for years :(
<pitti_> ogra_: we don't have a CK session; it's a JFDI thing mostly, maintaining the current state
<ogra_> ok, thanks, we werent sure what seat machanism would be used while discussing multiseat
<broder> is anybody still getting utility out of having lintian.uw.o point at precise? (any reason i shouldn't just re-point it at quantal?)
 * ogra_ supposes having a percise instance available until 12.04.1 might probably sense
<ogra_> +make
<broder> i don't think i have the space to run both precise and quantal
<broder> (the lintian lab + archive mirror is about .5T last i checked)
#ubuntu-devel 2012-05-09
<larsdues1ng> short question, what to do with bug, which are 3+ years old, and depend on ubuntu 8.04?!? I cannot set "won't fix"...
<larsdues1ng> -> https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/296036
<ubottu> Launchpad bug 296036 in aiccu (Ubuntu) "upgrade to 8.10 blocked by aiccu" [Undecided,New]
<larsdues1ng> oh, ok  8.10 :)
<dupondje> Release has reached EOL
<dupondje> If the specific release has reached EOL per https://wiki.ubuntu.com/Releases and there is not enough information to work on the bug, then you can set to Incomplete and use the following response (Note RELEASE and DATE are placeholders):
<dupondje> https://wiki.ubuntu.com/Bugs/Responses#Release_has_reached_EOL
<larsdues1ng> oh... ok
<larsdues1ng> thanks
<sivang> hi all
<sivang> There are some nice scrollers (that look suspiciously suitable for touch interface) in Unity 2D, it is using Qt right?
<sivang> (sorry of this question is offtopic here..)
<cjwatson> broder: as far as I'm concerned, lintian.uw.o would be a lot more useful pointed at quantal
 * sivang just noticed there's an u-d-d list. /me looks for the same irc channel
<sivang> is it okay to ask general devel discussions here?
<balhau> Hi guys. Is someone here able to speak about bluetooth troubleshooting?
<balhau> Or can someone point me a irc channel to speak about that?
<melodie> hello
<melodie> I wonder if the core version can be used to make a spin. is there a how to for that purpose somewhere ?
<melodie> https://wiki.ubuntu.com/Core
<mterry> cjwatson, hello!  if you're actually able to get this on the uds wifi, I'd like to chat with you about a proposed change in update-manager.  If you see me in the halls, stop me!  :)
<cjwatson> mterry: OK, though not entirely a relevant expert
<maco> wouldnt that be mvo's territory?
<mterry> cjwatson, well, it involves package metadata, not UI stuff (the ability to know if a package will want a restart ahead of installing it)
<cjwatson> mterry: Mm, that is actually mostly mvo - currently it's a script that postinsts can run, IIRC
<mterry> cjwatson, oh, OK.  I'll bug mvo instead.  Yeah, it's a postinst thing right now, but I need to find out whether it's even possible to add it to package metadata somehow.
<mterry> mpt is writing checks that Ubuntu can't cash  :)
<cjwatson> mterry: Right, I'm not sure of the answer
<mpt> mterry, we had a session on it at UDS Lucid
<mterry> cjwatson, OK!  Well, are there any packages you know that conditionally call that script?  Like only sometimes want a reboot?
<mterry> mpt, oh good.  I'll try to find the notes
<mpt> mterry, https://blueprints.launchpad.net/ubuntu/+spec/upgrading-running-software
<mpt> hm, not that helpful
<mpt> ah, https://wiki.ubuntu.com/UpgradingRunningPrograms
<mterry> mpt, that still looks like it only deals with finding out about the need after the fact?
 * mterry reads
<mpt> mterry, I remember there was discussion of a flag for each update representing whether it require restart ... Maybe it got lost in the mists of time
<mterry> mpt, yeah in the whiteboard, there's a link to a more relevant spec that is superceded by this one....  so it must have gotten folded in
<cjwatson> mterry: dbus.postinst
<cjwatson> mterry: gconf2.postinst, initscripts.postinst, libc6:i386.postinst
<mterry> mpt, it looks like the goal was to avoid the need for most restart packages by just having them magically update at next program start
<cjwatson> mterry: libpam0g:i386.postinst, libssl1.0.0:i386.postinst
<mterry> mpt, maybe the Software Update spec needs to be updated to drop that bit of the UI?
 * mterry looks at all these postinsts
<cjwatson> in fact, the majority of packages on my system that do this are conditional in sosme way
<mpt> mterry, maybe
<mpt> cjwatson, are you saying that determining whether an update will require a restart is equivalent to solving the Halting Problem? :-)
<mterry> cjwatson, yeah...  mostly around whether the package is in use at the time it seems
<mterry> mpt, is UI that says "this package *may* cause a reboot" awful?
<mpt> mterry, no, that would be fine
<mpt> imo
<mpt> Then if it doesn't, yay, bonus
<maco> hang on
<maco> cause or require
<mterry> maco, require
<mterry> sorry
<maco> k, cuz the way you wrote before sounds like microsoft's reboot-whether-you-want-or-not
<mterry> maco, :)
<mterry> mpt, I'll talk to mvo about the possibility of adding metadata for any package that can possibly flip the reboot required flag
<mterry> cjwatson, thanks for the investigation!
<mpt> In an ideal world that would be another step, i.e. "we're updating the sort of stuff where trying to use Ubuntu during the update process would be an absolute misery"
<mterry> mpt, didn't we have an "updating on shutdown" plan at one point?
<mpt> mterry, yes, it didn't go anywhere <https://wiki.ubuntu.com/FoundationsTeam/Specs/KarmicUpdatesOnShutdown>
<mterry> mpt, your spec involves grouping packages.  Did you have ideas about the boundaries of that grouping?  (like, group packages from the same source?)  And throw anything without a .desktop into "Ubuntu Core"?
<mterry> mpt, also the spec has a "to think about section" about how it would involve dropping the distinction between security and regular updates (and 3rd party).  Didn't know if that had rattled around in your brain since the spec was last updated
<mpt> mterry, I didn't write it down, but by "Ubuntu Core" I meant "anything that's a dependency of ubuntu-desktop, but neither (a) a graphical application nor (b) only there because it's a dependency of one graphical application"
<mpt> mterry, I haven't rattled recently, but yes, probably we should retain the security distinction somehow
<mterry> mpt, does the phrasing of "Ubuntu Core" perhaps change now that we have a distinct spin of Ubuntu called Ubuntu Core?
<mpt> mterry, probably
<mterry> mpt, OK well, commence rattling when you get a chance.  :)
<mpt> sure thing
<melodie> hi again
<melodie> cjwatson, I would like to ask you if you remember a patch you did on a program having for name "openbox-xdgmenu" ?
<slangasek> we have a distinct spin of Ubuntu called Ubuntu Core?
<slangasek> oh, you're talking about the one we already have ;P
<melodie> slangasek, yes
<jussi> slangasek: https://wiki.ubuntu.com/Core i think
<melodie> https://wiki.ubuntu.com/Core
<slangasek> so yes, there's a conflicting definition of Ubuntu Core, which is definitely not compatible with mpt's definition above
<melodie> can that be used to make a spin ?
<slangasek> there's very little spinning involved with https://wiki.ubuntu.com/Core ;)
<melodie> I am looking for an elegant solution and for a howto if there is one.
<mpt> It's a well-known fact that velocity of spinning increases as you get more distant from the core
<slangasek> mpt: hah
<mpt> I'll get me coat
<melodie> and perhaps not that much the velocity of the final product ? or do I mistake
<melodie> ?
<melodie> else, can a Mini Ubuntu be used for that purpose ?
<dholbach> ivoks, congratulations! :)
<ivoks> dholbach: yay :)
<broder> kicked off initial quantal lintian build. first report eta: 3 days
<broder> for bonus points, it has a patch that should prevent it throwing unknown-field-in-control original-maintainer on any package we've modified
<broder> s/any package we've modified/all packages/, actually
<xnox> doko: i have a solution pointer on how to check packages in *all* ongoing transitions.
<doko> xnox, already solved for my purposes
<xnox> doko: ok. The transition tracker repository has a trasition, collision python script which can be trivially changed to print all packages in transitions which are good/bad/unknown
<xnox> doko: that is all.
<doko> xnox, I was pointed to http://release.debian.org/transitions/export/packages.yaml
<xnox> doko: ok. that works as well ;-)
<xnox> doko: would it be useful to add a script/program to query packages in transition in the `[ubuntu-]devscripts' ?
<doko> xnox, I don't think so. there's always nbs, which you can consult
<xnox> doko: ok.
<Bluefoxicy> Does Ubuntu have an option to load the CD to RAM?
<Bluefoxicy> or even better, auto-loading of the CD to RAM if you have more than, say, 2GB of RAM
<Bluefoxicy> hmm how would that be done
<ogra_> no ... patches accepted :)
<Bluefoxicy> no I mean this is actually tough I just realized
<Bluefoxicy> because in theory the ideal situation is to start copying everything to RAM, compressed, even after boot
<ogra_> not as tough as you might think
<ogra_> but it would be slow since you would have to copy the squashfs from CD to a tmpfs
<Bluefoxicy> You don't want to wait 15 minutes for the whole CD to copy the SquashFS to RAM
<broder> cat /cdrom/casper/filesystem.squashfs >/dev/null will probably get you some percentage of the way there :)
<Bluefoxicy> ogra_: modprobe zram
<ogra_> how does that help the IO ?
<Bluefoxicy> zram makes a block device in RAM that's compressed :)
<ogra_> zram only gets you more ram
<Bluefoxicy> see the problem is if you copy the squashfs to a tmpfs, it stays compressed BUT you can't mount it through before it's done copying
<ogra_> i know i use it on most of the arm images by default
<broder> copy the squashfs from CD to a tmpfs> why would you do that instead of just using buffer cache?
<lifeless> broder: well, I had a case where that woul dhave been useful
<Bluefoxicy> broder:  remove the CD, cache everything ahead of time, etc
<Bluefoxicy> and, if you say ... load X
<lifeless> broder: I was shuffling partitions around, TB of data, pushed the CDROM right out of page cache
<Bluefoxicy> the files that are mapped in are on the CD, and you can't swap that under
<lifeless> so every time I moved the mouse it spun up
<broder> fair enough
<Bluefoxicy> the next computer I build is going to have 16GB of RAM and 2 open slots ready for another 16GB
<Bluefoxicy> a CD is 700MB
<Bluefoxicy> this is turning into a thing
<Bluefoxicy> It's not a bad idea to arbitrarily say, "Well, we can load the CD to RAM, if the system has [8GB] then let's eat 2/3 of a gig for that"
<Bluefoxicy> but anyway zram
<ogra_> what about it ?
<Bluefoxicy> you can make an ext2 fs on /dev/zram0, mount the squashfs, and copy its contents into the zram0
<ogra_> we have support for it in all kernels and zram-config is in the archive
<ogra_> +8providing the upstart job to initialize it)
<ogra_> oh, i see what you are saying, you dotn use the zram device for swapping
<Bluefoxicy> a modified unionfs would be able to copy the underlying file being read to the zram fs automatically, while also copying the entire contents of the base fs in as a background task (say on an ioctl)
 * ogra_ didnt get that before, sorry
<Bluefoxicy> that way you'd be able to use the target memory-based mount point as your root device immediately, and have it remain compressed in RAM
<Bluefoxicy> albeit, CPU intensive
<ogra_> well, machines with 16G should hve an equally powerful CPU
<Bluefoxicy> but you could start booting immediately, you could wait until the desktop comes up to trigger the background copy or make it a low-priority task or whatnot
<Bluefoxicy> yeah
<Bluefoxicy> a 16G machine might have a Core I5 or I7 with 4 cores
<Bluefoxicy> or it might be a server with 8 or 16 cores
<ogra_> a server would probably rather use a netinst image though
<Bluefoxicy> anyway what got me is I realized I can spend $60 on an OCZ SATA3 SSD 60GB
<ogra_> (which isnt live)
<Bluefoxicy> or buy two of those
<Bluefoxicy> and stripe them
<Bluefoxicy> at 6Gb/s theoretical (768MB/s, a whole CD in 1 second) and a little more than half a gig per second practical, doubled by striping
<Bluefoxicy> you could install Ubuntu in under a second
<Bluefoxicy> ... no, you're going to be waiting for the CD to spin that whole time.
<Bluefoxicy> so during the entire boot process, if you have ridiculous amounts of RAM, the CD could be caching everything to RAM
<ogra_> right, as i said, on such a device a local mirror and netinst would be cleverer
<Bluefoxicy> ogra_:  I did say an SSD costs about $60 :P
<Bluefoxicy> home users might not have local mirror/netinst but might have some ridiculously fast system with $100 of DDR3 in it
<ogra_> (and indeed your argument stands and falls with the existance of a server livecd install :) )
<ogra_> (which doesnt exist yet)
<Bluefoxicy> well
<Bluefoxicy> I'm talking about desktops
<Bluefoxicy> I mean like
<Bluefoxicy> http://www.amazon.com/Corsair-Vengeance-1600MHz-Memory-CMZ16GX3M2A1600C10/dp/B006EWUO22/
<Bluefoxicy> http://www.amazon.com/gp/product/B004Z0S6RU/
<Bluefoxicy> $120 + $70
<Bluefoxicy> that's going to turn into "Common use case" :P
<lifeless> Bluefoxicy: you can install Ubuntu extremely fast by mounting the iso over NFS w/netboot.
<Bluefoxicy> lifeless:  if you have a second PC up yeah.
<lifeless> Bluefoxicy: and syslinux's netboot mode.
<lifeless> Bluefoxicy: there are some very very small PC's around these days... like android tablets ;)
<stgraber> balloons: ping
<stgraber> balloons: you've a session in grand ballroom a
<stgraber> balloons: https://blueprints.launchpad.net/ubuntu/+spec/qa-q-iso-testing-process
#ubuntu-devel 2012-05-10
<lifeless> ev: I'd love to do a lightning talk, little tricky...
<ev> lifeless: we could skype you :)
<micahg> lifeless: lightning talk by phone and VNC?
<lifeless> ev: nah, gets fiddly; a longer talk perhaps, but not a 3-minute (or even 5) one :)
<lifeless> ev: have a good session though!
<ev> lifeless: sure, and thanks!
<ev> ps. we should touch base post UDS
<ev> to discuss where things stand on the crash db and future plans
<lifeless> absolutely
<ev> cool
<ev> lifeless: we have a number of sessions on it tomorrow throughout the day. The first general session is at your 4am, but the follow up session is at your noon. If you'd like to participate we can skype you in along with mpt.
<lifeless> ev: wicked cool
<lifeless> ev: also, while I have you, can I suggest that we replace mean with something more useful, e.g. median, or 99%th percentile
<lifeless> ev: by more useful, I mean a better predictor of users experience; perhaps multiple metrics e.g.(10%ile 50%ile 99%ile)
<ev> lifeless: yes, we're going to discuss that at length tomorrow - though mpt is probably the better person to talk to about this.
<lifeless> ev: cool
<ev> as he can more eloquently describe the intent and current plan for a better implementation that factors in decay
<lifeless> mean + distribution + distribution parameters would do too, but I think most folk get percentiles more easily
 * mpt checks Wikipedia and apparently we should be calling it MTTF instead...
<ev> wow, I wish I saw http://en.wikipedia.org/wiki/Mean_time_between_failures earlier
<mpt> oh, and "Failures which occur that can be left or maintained in an unrepaired condition, and do not place the system out of service, are not considered failures under this definition."
<mpt> So we should use a totally different term anyway
<ev> yeah
<mpt> ATBE? :-)
<lifeless> http://www.eventhelix.com/RealtimeMantra/FaultHandling/reliability_availability_basics.htm#Software%20Failures
<lifeless> is good
<mpt> ev, btw, maybe you saw, but I rewrote the rationale
<mpt> in preparation for tomorrow
<ev> mpt: I did! I thanked you for it in an email :)
<mpt> oh :-)
<nixternal> infinity: hey, using live-build to build out an image, but when i use casper/ from the build out, i get that 'no /dev/zram0' error. my iso has a .disk. any ideas/help would be great
<`26> I must be stupid or otherwise -- for the past few hours, I've been unsuccessfully been searching for information on how "Ubuntu Alternate" ISO images are built. Of course it's a script that makes calls to debootstrap, mksquashfs, mkisofs, etc., but where is it?
<mwhudson> i think a locked toilet with a sign saying "beware of the leopard" may be involved
<cnd> pitti, I uploaded a new xserver-xorg-input-synaptics sru a few days ago, but it hasn't been approved yet
<cnd> do you know what is holding it up?
<Laney> cjwatson: do you want to look at ben some time?
<cjwatson> Laney: yeah, maybe this evening after the keysigning, if we don't have some other free period?
<infinity> cnd: There's this thing called UDS going on.  I imagine that might be slowing some of us down. ;)
<Laney> cjwatson: I think we have the team dinner tonight :/
<Laney> and I'm leaving tomorrow PM
<cnd> infinity, other SRUs have been processed as normal, so I thought I'd ask in case there was something wrong with it
<infinity> cnd: To be fair, I haven't looked at it.  Let me see.
<jibel> pitti, zenity 3.4.0-0ubuntu3 in precise-updates introduced a regression - bug 968534
<ubottu> Launchpad bug 968534 in zenity (Ubuntu Quantal) "zenity crashed with SIGSEGV in zenity_tree_dialog_response()" [High,Fix committed] https://launchpad.net/bugs/968534
<Saurabh_123> Hey, will ubuntu 12.10 include HUD with speech?
<cjwatson> Laney: oh, hmm, OK, I'll see if I can carve out time then
<roaksoax> cjwatson: hi! I want your input with something I'km working on with installing a squashfs from d-i. So I'm doing this: 1. PXE Boot mini ISO image. 2. From d-i, download a squashfs filesystem (stored in /cdrom/casper) 3. d-i sets live-installer/enable boolean true & live-installer/mode string live 4. installation completes successfully, however, grub (even though it seems that it installs correctly) doesn't seem to detect there's a root bootable partition
<roaksoax> cjwatson: any ideas fo why that might be, and/or what am I doing wrong?
<cjwatson> roaksoax: do you have something I can come and look at?  this'd be easier in person
<cjwatson> (not necessarily *right* now)
<cjwatson> roaksoax: oh, er, why mode live rather than mode normal?  seems a very odd choice
<cjwatson> roaksoax: you surely want to end up with a normal installed system, rather than a copy of the livefs that still boots in live style
<roaksoax> cjwatson:  mode normal seems to just continue a normal install. When would it be better for you to look at it?
<cjwatson> roaksoax: mode normal is what you want, I'm pretty sure.  maybe late morning sometime?
<roaksoax> cjwatson: works for me, just let me know ;)
<pitti> cnd: yeah, sorry about that; UDS and all that..
<cnd> pitti, ok, np
<pitti> cnd: feel free to ping RAOF and SpamapS as well, to increase the chances
<cnd> pitti, oh, RAOF can do it?
<cnd> I'll bug him then since it's X related
<pitti> cnd: yes, there's quite a number of people in ~ubuntu-sru :)
<jono> kees, hey, yeah the validation server got wedged
<jono> your accomplishments should be verified now
<EvilResistance> is totem considered 'core'?
<mpt> EvilResistance, it's in Main and installed by default, so probably
<mpt> It isn't part of "Ubuntu Core", though
<EvilResistance> that's what i wanted to know about
<EvilResistance> if it was considered part of the Ubuntu Core
<ogra_> sadly that term is massively overloaded
<EvilResistance> ogra_:  hence me asking what is considered part of Ubuntu Core
<ogra_> well, the question is *which* ubuntu core ;)
<ogra_> we have at least three
<EvilResistance> there's a bug against 'totem' with an undecided level of importance, if totem is core, it becomes medium, if totem is non-core, its low (based on the bugsquad documentation for importance)
<ogra_> there are the ubuntu-core images and there is the ubuntu "core" packageset
 * ogra_ tries to remember the third
<mpt> glatzor, hi, in what kind of tasks would you encounter ERROR_REPO_DOWNLOAD_FAILED? For example, would you get it if you clicked "Check" in Update Manager while not connected to the Internet?
<ogra_> EvilResistance, totem is definitely in the set of supported apps
<ogra_> which this specific "core" probably refers to
<EvilResistance> ogra_:  i've made a note about that in my bug importance recommendation to bugcontrol
<EvilResistance> ;P
<EvilResistance> (because sometimes i'm incorrect in judging what is/isnt core)
<EvilResistance> i know 'Universe' and 'Multiverse' are non-core ;P
<EvilResistance> but that's a given :P
<ogra_> well, i would just not use that term :)
<EvilResistance> problem is its what determines in cases a severity of Medium vs. Low
<micahg> EvilResistance: we should probably discuss the wording in the next bugsquad meeting
<EvilResistance> micahg:  i agree, 'core' needs defining
<EvilResistance> in explicit terms
 * micahg would just s/core/default/
<ogra_> ++
<EvilResistance> micahg:  you're bugcontrol right?
<micahg> yes
<EvilResistance> micahg:  care to visit -bugs?
<micahg> am there :)
<EvilResistance> did you see the messages i just posted there?
<EvilResistance> (IMO, all bugcontrol should highlight on bugcontrol being stated)
<lifeless> ev: I'm around from here on in, ping me when you want me on skype
<ev> lifeless: yay
<ev> we've got a session on bucketing crashes at 3pm our time and part two of our general chat about the crash database at 5pm our time
<ev> lifeless: would be great if you can attend both or at least the general one (so we can discuss whatever we're calling MBTF)
<lifeless> should be totally able to
<ev> wonderful
<lifeless> its 12:30 for you now, right ?
<dholbach> asomething, thanks a bunch for your work on the packaging guide
<dholbach> lifeless, yes
<asomething>  dholbach, no problem!
<melodie> hello
<dholbach> asomething, I fixed the singlehtml symlinking as well and updated the publishing script
<dholbach> asomething, with the next recipe build we should have this all reflected
<dholbach> (assuming we get the other merge proposal in as well)
<asomething> dholbach, just saw that. I'll give the singlehtml branch a quick look and land it
<dholbach> awesome :-D
<psusi> I'm a little confused by a session today... why would you want upstart in the initramfs?
<IntuitiveNipple> Would it help avoid degraded raids that prevent the system booting?
<psusi> I don't see why
<broder> psusi: in a session now so can't really talk, but the current serialized initramfs is slow and can be racy, and using upstart would fix this and let us share more code between initrd and rootfs
<lifeless> ev: so, is the session now ?
<ev> lifeless: G. Ballroom A
<ev> yes
<psusi> broder, what is an example of something that we normally do in upstart that you might want in the initrd?  afaik, the few things we also want in the initrd are handled via udev, not upstart, and that's already in the initrd
<lifeless> ev: you mentioned skype, or did you mean the icecast stream ?
<psusi> the example given in the blueprint is luks, but I don't see why you would want luks to be handled by upstart
<ev> lifeless: I can skype you in
<lifeless> cool
<ev> mpt: would you like to be skyped in as well?
<mpt> ev, to what?
<ev> bucketing improvements
<lifeless> bucketing improvements
<lifeless> bwah
<mpt> ev, oh, no thanks, I unsubscribed from that one -- I doubt I would be useful there
#ubuntu-devel 2012-05-11
<ev> mpt lifeless: I'm going to skype robert in, ted will skype matthew
<melodie> gn
<broder> cjwatson: interested in spot-checking a backporter-executed backport upload? (bug #994424)
<ubottu> Launchpad bug 994424 in Precise Backports "Please backport gnome-do 0.9-1 (universe) from quantal" [Undecided,In progress] https://launchpad.net/bugs/994424
<broder> Hmm...backportpackage should probably generate an LP closer
<broder> tumbleweed: ^
<tumbleweed> patches accepted... :)
<broder> not sure what cmd line option to use. -b and -B are both taken already :)
<tumbleweed> ouch
<broder> -c, --close?
<tumbleweed> or rename -b to --test-build
<tumbleweed> naah, maybe that's horrible
<broder> ...oh right. closer doesn't help because backports bugs aren't filed against ubuntu
<broder> bah
<broder> (still kind of want one, though)
<tumbleweed> fix launchpad, clearly
<broder> i can make ajmitch do it, right?
<ajmitch> broder: *cough*
<psusi> so who's having beers over there in california right now? ;)
<psusi> and more importantly, is anyone who was at the event based initramfs talk here?
<psusi> guess everyone is having fun drinking the free beer
<tjaalton> no free beer tonight :P
<psusi> now I don't feel so bad I couldn't make this one
<foursixnine> Hi guys, i have a question, currently at the company where i'm working, we need to add support to a Intel Cedarview VGA chip... This chipset is supported on a 3.3.x series of the kernel, but we need it on ubuntu 11.04 >=
<Sarvatt> foursixnine: install newer kernel on 11.04, X will use fbdev and be just as supported as it is in quantal, ???, profit?
<Sarvatt> the gma500 kernel driver changes are way to huge to ever remotely get backported to 11.04, it doesn't even work in 12.04 outside of OEM contexts with the proprietary drivers  where it will be pushed in the 12.04.1 timeframe and will never work in 12.10, i have some proprietary driver drops here if it helps but they assume 12.04 X and mesa - http://kernel.ubuntu.com/~sarvatt/cdv/drops/
<foursixnine> Sarvatt: we would love to use just the module... recompiling the kernel would have some impact on other hardware we use (since we develop our own drivers)
<foursixnine> Oh...
<foursixnine> That then changes the scenario
<lifeless> Sarvatt: linux finally got open gma500 support?
<maco> a week after my boyfriend rebaselined to windows after his failed experiment with gma500+ubuntu? dang
<ion> Unless i have old information, it lacks video and 3D acceleration. :-\
<Sarvatt> lifeless: only completely unaccelerated support, but at least you get a native resolution now :)
<lifeless> still
<lifeless> an improvement
<foursixnine> Sarvatt: well.. we're on the urge for that.... and backporting the module was one solution... the other one was trying to get someone from the inside (like Alan Cox) getting to work on the driver...
<maco> oh. yeah, he wouldnt consider unaccelerated to be worth it
<foursixnine> 'cause of the support thing for our own hardware :/
<Sarvatt> foursixnine: if its cedarview, intel has been making us drivers with acceleration made to work for 12.04 that havent been uploaded yet but its guaranteed they will abandon them with 12.04 and 12.10+ wont work. 2d or 3d acceleration in the gma500 module is pretty much guaranteed never to happen (but video acceleration might) because of imagination who makes the sgx 545
<foursixnine> Sarvatt: by "us" you mean ubuntu? or linux in general?
<Sarvatt> yeah sorry, us as in ubuntu
<foursixnine> I saw alan cox its working directly on it
<Sarvatt> they make cedarview drivers for meego also
<Sarvatt> which is basically ubuntu 10.10 userspace, with a 3.0 kernel
<foursixnine> Hmmm... very interesting that would work
<pp7> how do u control the change of the top panel in my theme?
<foursixnine> Sarvatt: do you have any links?
<Sarvatt> to the meego stuff?
<Sarvatt> i can dig them up, its public
<foursixnine> Sarvatt: more like the intel dropping support and so...
<foursixnine> just to cover my back before i fire up an email saying they did wrong in picking up such hardware 2 months before project delivery LOL
<doctorpepper> hi guys!!!
<doctorpepper>  is anyone from appmenu/libdbusmenu  team in here ?
<mpt> mvo, hi, #ubuntu-uds-room-204 could benefit from your presence :-)
<mpt> They're wondering how the "Updates provided:" text in USC is generated
<mvo> mpt: hi, thanks! I was at dinner
<doko> infinity, do you plan to show up at the x32 session?
<PaoloRotolo> Hi all!
<dholbach> asomething, let's see how much new blood we find this way: http://daniel.holba.ch/blog/2012/05/uds-is-a-great-time/ :)
<asomething> dholbach, looks good!
<faginbagin> Is this the right place to ask questions about ubuntu development. I've got questions that aren't answered on https://wiki.ubuntu.com/UbuntuDevelopment
<slangasek> it's a good place to ask such questions, yes
<slangasek> though not a great time, since this is the last day of UDS and many people are not paying attention to the IRC channel ;)
<Resistance> mhm
<faginbagin> OK, so when is a good time to come to IRC channel?
<Resistance> not during UDS :P
<Resistance> probably tomorrow at the earliest
<slangasek> faginbagin: well, you're here now so you might as well try to ask your question :)
<Resistance> indeed
<Resistance> you're still allowed to ask ;)
<faginbagin> Or, Any time of the day? Or are certain hours better?
<Resistance> you're here now, so just ask :)
<faginbagin> My first question is whether I can do anything useful with the machines I already have, which are running 10.04 and 10.10 (mythtv boxes)
<Resistance> 10.10's EOL btw
<Resistance> so with that, not really
<Resistance> !10.10
<ubottu> Ubuntu 10.10 (Maverick Meerkat) was the thirteenth release of Ubuntu. !End-Of-Life on April 10th, 2012, see http://ubottu.com/y/maverick for details.
<faginbagin> Or should I find sppace to install 12.04
<faginbagin> I realize 10.01 is EOL, but what about 10.04?
<faginbagin> OK, guess I'll spend some time installing 12.04 somewhere and check back here early nest week (after Mother's day weekend).
<mirabilos> is there a package that is in ubuntu but not (and never will be) in debian, with low footprint, so I can do something like 'packagethatisonlyindebian | dummydependsforpackagethatisonlyinubuntu' in build-depends? kinda like type-handling
<mirabilos> something officially usable for this purpose, that is (otherwise i could just pick, say, language-pack-en)
 * mirabilos is a bit surprised this doesn't pop up more, save for the one mention in buxy's blog
#ubuntu-devel 2012-05-12
<pdtpatrick> Question - would someone please explain/help me with .deb packaging. I'm using deb helper and i've gone through the PackagingGuide.pdf -- and i still cannot understand how you move files around. For instance, if i want the .deb file when installed to have files in /etc/ and then /home/user/.filename  .. where/how do i do that ?  would this be the dh_installdeb helper script ?
<mirabilos> you can't write files into users' homes
<cjwatson> ScottK: I'd appreciate your thoughts on the kdelibs5-dev and pykde4 bugs I just filed in Debian for Python 3 support (#672552 and #672553, mainly the latter).  I'd love to get that into Ubuntu soon so that I can upload a Python 3 version of ubiquity.
<cjwatson> When you get a chance, obviously.
<nixternal> infinity: hey, one last problem with live-build. it builds the binary for me (binary/casper), however when i use that to create an ISO, and boot, i get that 'unable to open '/dev/zram0''...any pointers will be great
<nixternal> also tried out lp.net/offspring, but that is a mess & a half, and the ubuntu-cdimage stuff seems to be private to ~canonical only :/
<cody-somerville> nixternal, What version of live-build are you using and is your config/image available anywhere?
<cody-somerville> nixternal, And what problems did you have with Offspring?
<nixternal> 3.0~a24-1ubuntu32
<nixternal> i can't get offspring to build. i have been getting a crash with offspring-master
<nixternal> if i am correct, i need master, web, & slave. i have those 3 on the same machine
<cody-somerville> nixternal, There's an API incompatibility with python2.7 in trunk at the moment.
<nixternal> start slave first, then master, followed by web. at first i wasn't getting errors with master, then after a restart I was getting an IOError in regards to xml-rpc
<nixternal> cody-somerville: right, i have installed 2.6 on my server
<nixternal> though, damn, i didn't check if virtualenv was using 2.6
<nixternal> for my slave/lexbuilder the status was always UNKNOWN
<nixternal> if i could get offspring working, that would be the most perfect thing for my client. that would remove me from the equation once it is setup
<cody-somerville> That means the master probably hasn't been successful in running.
<cody-somerville> nixternal, Neat. I'd be happy to help you. If you could file a bug with the traceback/log, I'd be happy to look into/fix issue for you.
<nixternal> rock on bro, I will do that. i will reinstall everything and start from scratch on my server and make sure virtualenv is using 2.6
<nixternal> it is fine for slave & master to be the same machine right?
<nixternal> if so, what the proper start up sequence.... slave, master, then web? or master, slave, then web? or....
<cody-somerville> nixternal, That's fine, yes. I wouldn't necessarily recommend it though since a rogue build could cause both services to be affected (say due to doing fork bomb or something) which is especially problematic if you have a farm of builders.
<cody-somerville> nixternal, You can start them in any sequence.
<nixternal> ok
<nixternal> thanks!
<nixternal> i was going to attack you anyways for offspring as I saw your name all over it :p
<nixternal> thanks to Daviey though for linking me to it last night
<cody-somerville> nixternal, the load induced by a build will most certainly affect apache2 + postgresql so hosting web on same machine might be problematic fyi
<nixternal> so you are saying it is best to have slave running on other systems? so if for starters I have i386 & amd64, they should each be on a separate machine. web & master ok to be together on the same machine though?
<cody-somerville> nixternal, Cool. There is a mailing list FYI. It's very low traffic currently but it'll be good for keeping up to date if there are major changes we plan to introduce / place to discuss dev + support issues.
<nixternal> ok, i will join that so i can follow along. if this works out for me, i am building my own farm and selling access to clients then :)
<cody-somerville> nixternal, web + master should be fine to be on same machine yes load wise. However, in our setup we have master on it's own machine where we also host the NFS server for storing the results - this is because master obviously requires access to slaves and we don't want our assets or slaves to be compromised so we keep them tightly firewalled and thus if web host gets compromised in some fashion it isn't as big of a deal.
<cody-somerville> as for i386 & amd64, you can just have single amd64 host and it can build both those arches
<nixternal> yeah, but for load i thought about separating them
<nixternal> oh, my live-build config, let me paste that if you are still interested in looking at it
<cody-somerville> sure thing. if you can put image somewhere too that would be even better and I'll try it out myself to see whats wrong.
<cody-somerville> nixternal, re: load, in that case I would just have two machines both amd64 - unless you specifically want to have i386 only machine for cost or queueing priority purposes.
 * nixternal did 'sudo lb clean' :)
<nixternal> right
<cody-somerville> if you run into problems, I recommend 'sudo lb clean --purge'
<nixternal> what does purge do?
<nixternal> i always remove cache just to be safe
<cody-somerville> purge removes everything, including all caches. The config directory is kept.
<nixternal> ahh
<nixternal> cody-somerville: http://paste.ubuntu.com/982823/  my config
<nixternal> foobar is my fake project name, so i don't give my client info away in public :)
<cody-somerville> ah. you use auto/config (I'm not a personal fan of the feature, lol)
<nixternal> should my config have 'noauto' added to the lb config?
<nixternal> or, is there a config out there i can use as an example
<nixternal> i think i snooped all of linaro & oem services for one, as well as cjwatson's 3 million bzr repos :)
<cody-somerville> I don't have one for lb 3.x. This is fine. I'll do a build with this and see what pops out.
<nixternal> well, it won't work with foobar, so i will message you
<ScottK> cjwatson: I saw the Debian bugs.  I think its great you got it sorted.  yofel_ is ~close to uploading KDE SC 4.8.3 to precise, so I think he should include your changes.
<ScottK> I'd discuss it with him.
<vibhav> Pornview looks dead upstream, and is very crash prone, should I file a request to get it removed?
<vibhav> Also, can https://bugs.launchpad.net/ubuntu/+source/meep/+bug/990137 be nominated for oneiric?
<ubottu> Launchpad bug 990137 in meep (Ubuntu Precise) "meep looking for 'libctl' in wrong location" [High,Fix released]
<larsdues1ng>  /j #perl
<larsdues1ng> ups :) sorry
<larsduesing> Is ubuntu having any problems with the line "Architecture: linux-any kfreebsd-any" in debian/control ?
<larsduesing> (upstream debian change from "Archtitecture: any")
<larsduesing> arghs Architecture I meant :)
<larsduesing> and this line "Depends: iputils-ping [!kfreebsd-i386 !kfreebsd-amd64]
<chrysn> are there any ways to debug what's happening on ubuntu build servers?
<chrysn> i'm getting errors in its build logs, but not on my own precise building vm
<JonEdney> o/
<melodie> hi
<JonEdney> o/ melodie
<melodie> hi JonEdney !
<melodie> I would like to get feedback for a package having for name openbox-menu. It is useful when using Openbox as only environment and can also be used while having Openbox in a DM environment
<melodie> anyone interested ?
<Bluefoxicy> things to be aware of:  mount NOTHING anywhere except under /home
 * Bluefoxicy mounted a drive with disk images on it under /var/vm/ and it was summarily erased even though there's no such folder and he didn't instruct it to format...
<Bluefoxicy> The installer warns you that if there are system files in that path it'll erase them
<Bluefoxicy> and of course just erases the whole thing >:|
<PaoloRotolo> Hi all!
<Bluefoxicy> Why not make locales for every application in every language, but store them in different repos?
<Bluefoxicy> main security universe multiverse locale-en locale-de locale-es locale-jp ...
<Bluefoxicy> and teach dpkg to depend conditionally
<Bluefoxicy> DEPENDS: debian-locale-de ? gnome-terminal-locale-de
<Bluefoxicy> DEPENDS: debian-locale-ja ? gnome-terminal-locale-ja
<Bluefoxicy> etc
 * Bluefoxicy watches the language pack installer bring in firefox-locale-ja when he doesn't have firefox anything installed
<melodie> gn
#ubuntu-devel 2012-05-13
<elgaton> Hi everyone, anyone knows the procedure to request backports? The wiki (<https://wiki.ubuntu.com/UbuntuBackports>) mentions the requestbackports tool, but it isn't in the ubuntu-dev-tools package
<micahg> elgaton: it's available in precise on
<elgaton> micahg: Thanks
<micahg> and it's called requestbackport
<elgaton> Yes, sorry for the typo
<vibhav> Should I merge or sync for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667320 ?
<ubottu> Debian bug 667320 in pdfedit "pdfedit: ftbfs with GCC-4.7" [Serious,Fixed]
<vibhav> (for Ubuntu)
<geser> vibhav: what do you want to merge there? pdfedit has no Ubuntu delta
<micahg> vibhav: no need to do anything, it'll come in the autosync next week (May 21)
<vibhav> geser: I thought a minimal change might be better
<geser> vibhav: as we are at the start of the development cycle, syncs are preferred
<vibhav> ok
<rokr1> indicator-datetime-service memory leak any solution ?
<cjwatson> larsduesing: Those Architecture lines should work fine with Ubuntu, just as with Debian.
<vibhav> Can https://bugs.launchpad.net/ubuntu/+source/sphinx/+bug/480913 be nominated for onerirc and lucid?
<ubottu> Launchpad bug 480913 in sphinx (Ubuntu) "Template translations not shipped with sphinx" [Medium,Fix released]
<melodie> hi
<melodie> I want to open a ppa at launchpad, I have signed the code of conduct, put my gpg key there and I would like to know what is best for the url : should I just put the name of the package I did as last directory name ?
<melodie> I am also looking for someone who would try the package in an install using Openbox
<melodie> anyone here using Openbox who would be willing to test openbox-menu package ? (it's at debian mentors repos since a few days)
<melodie> I have also 2 questions : is it possible to add a post-install message in a package ? and is it possible to package a set of configuration files ?
<Resistance> melodie:  the name for what you use for the PPA name can be the package / program you're putting there, or it can be descriptive of the package, for instance i have two PPAs for backports, one for staging/building and one for use
<Resistance> as for testing, i'm not able to help you there.
<melodie> Resistance, thanks
<Resistance> and for adding messages into the installer post-install, you *can*, but i dont see it often done.  and for a set of configuration files, you should include default / template config files
<Resistance> or a configuration tool to be run
<Resistance> (which can be done post-install, and probably should only be done if confs dont already exist)
<melodie> the problem is that once the config files installed, they can be tweaked by the user, hence the next install for update should not bring config files again. In another distro the problem has been solved by creating a separate package, send the files to /usr/share/the_program_name, with a post install message which explains what to do with it.
<melodie> then each new set of configuration file uploaded can be an update too, if some improvements have been done.
<melodie> and be a new version.
<melodie> it's just that I don't know how to do that with deb packages
<melodie> I would need advise from someone who would test the package and the config files. a dev who knows as well packaging as be an Openbox user
<geser> melodie: have you already read the Debian Policy manual, especially http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
<melodie> geser, I have not read everything for sure. I am a packager newbie. thanks for the link
<broder> cjwatson: working on an in-queue backport verification tool. how much less useful is it if it can't automatically figure out where we're backporting *from*?
<broder> (i.e. it's easy to extend queuediff to do this if you can give it a source release)
<melodie> anyone on board ?
<melodie> I am reading this page : http://www.debian.org/doc/debian-policy/ch-files.html# this chapter:  10.7 Configuration files" because I think I should make a package out of the following configuration files : http://meets.free.fr/debian/openbox-menu-configuration.tar.bz2
<melodie> I am not sure if I should think of making a package which will copy the files under /etc as said in the page of the doc, or rather under /usr/share as I have seen in another distribution, and from where the user can get the files and copy them himself to his home.
<melodie> there is exactly one line very necessary in the menu.xml file, the 3rd line.
<melodie> and the rest of the files can allow to have a complete environment working as a real desktop, but only with Openbox, and a few programs such as tint2 or lxpanel, pcmanfm or any other file manager, feh...
<melodie> and even some desktop effects with xcompmgr and xsnow which can be started or stopped on the fly from the menu.
<melodie> could someone tell me what exactly can be put into /usr/share (concerning packages and their contents) and what can't go there ?
<melodie> reading docs and docs and can't find my case
<melodie> I mean can't find the one thing I want to do
<geofft> melodie: are you packaging openbox itself, or a package to configure it, or?
<melodie> hi geofft I have packaged openbox-menu which is a dynamic menu generator for openbox - think pipe-menu - and I would like to add configuration files as optional depends
<melodie> I try to find a simple way to do that : have the files in /usr/share would be better than in /etc in order not to make the config wide, but just available in case of need
<melodie> and I would also need to learn to write a post-install message (this was my first package)
<geofft> I don't know anything about openbox, but one sensible thing might be to make a separate session type you can choose from the login menu that starts openbox with this config (and leave the default openbox config alone)
<melodie> not really
<melodie> you can have these configuration files in lxde and not use them, or xfce and so on... then it all depends if the user sets his desktop to display the menus of the wm or not
<melodie> here is the package done : http://lists.debian.org/debian-mentors/2012/05/msg00088.html
<melodie> if you have default configuration files, you will want to merge some parts eventually. then the message at post-install will just say : the files are there for you, read the readme, and save your original files then install these ones.
<melodie> it is not too easy to merge xml files automatically I think. the possibilities are infinite and the user know their files (if not they will have the all made ones)
<melodie> geofft, and what login menu would that be ? startx ? lightdm ? gdm ? kdm ?
<melodie> so this does not talk much to me.
<geofft> Every *dm package looks in the same place for login menus, I believe
<melodie> where could I find a doc on how to make a package for providing configuration files for users ?
<geofft> If this is per-user configuration (not global configuration), then you should just put defaults in /usr/share (maybe /usr/share/doc/openbox-menu/examples?) and not use /etc
<melodie> geofft, do you think or are you sure ?
<melodie> yes
<melodie> geofft, I would like to put them to /usr/share/openbox-menu
<geofft> (But if this is per-user, then a post-install message will only reach the one sysadmin doing the install)
<melodie> geofft, this is right, only the sysadmin must administrate packages anyway.
<melodie> he knows what is good for all.
<melodie> if he wants he can install the files for all, or not, install them also under /etc/skel/.config if he thinks it relevant
<geofft> by the way, you have seen update-menus, right? I can't tell if it's related, but I think it is.
<melodie> I have seen openbox-xdgmenus
<melodie> I have marked it as conflict
<melodie> I look about the one you say
<melodie> geofft, no result in precise
<melodie> where did you see update-menus ?
<geofft> sorry, that's a command, not a package. I think it's in the menu package
<melodie> ok
<melodie> I have been told menu uses debian-menus and that it is not nice
<melodie> openbox-menu uses libmen-cache1 from the lxde project and the desktop files : the menus generated are compliant with the freedesktop.org specifications
<melodie> and also it keeps them up to date automatically : nothing to do or redo once installed and the openbox-menu command line set in the menu.xml
<melodie> the set of configuration files I have tarballed have been done along several years and contain additional things for the comfort
<melodie> libmenu-cache1 (forgot a u)
<melodie> gn
#ubuntu-devel 2013-05-06
<pitti> cjwatson: right, same polkit upgrade problem as with suspend; but that was fixed, if you upgrade now it should just work
<pitti> good morning
<pitti> xnox: postgresql> yes, known; fixed in bzr
<dholbach> good morning
<pjotr> Hello, I noticed that you can't set a jpg picture anymore as background for Grub, in Ubuntu 13.04.
<pjotr> Strangely enough, it's still possible in Lubuntu 13.04.
<pjotr> I've filed a bug report for it:
<pjotr> https://bugs.launchpad.net/ubuntu/+source/grub/+bug/1176820
<ubottu> Launchpad bug 1176820 in grub (Ubuntu) "Setting a jpg picture as background for the Grub menu, no longer works" [Undecided,New]
<pjotr> cjwatson: maybe you can take a look at it? I miss my beautiful holiday picture of the mountains in Saxony... :P
<cjwatson> Not today, public holiday
<pjotr> No hurry.... enjoy the spring sun. :-)
<mlankhorst> ogasawara: ping? why is cirrus modesetting not enabled in raring?
<didrocks> hey slangasek! I just upgraded to saucy and got stuck with bug #1176910 FYI (thanks pitti for the debugging)
<ubottu> bug 1176910 in pam (Ubuntu) "pam-auth-update can fail during raring -> saucy upgrade leading you to a broken session" [Undecided,New] https://launchpad.net/bugs/1176910
<ogasawara> mlankhorst:  I know in quantal it was disabled as a workaround per bug 1038055
<ubottu> bug 1038055 in linux (Ubuntu) "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [High,Fix released] https://launchpad.net/bugs/1038055
<ogasawara> mlankhorst: but I see it is re-enabled in raring
<stgraber> pitti: hey there, had a good trip back home?
<stgraber> pitti: I just spent 30min trying to change the timezone on my laptop (saucy) and wonder whether that's somehow related to the logind change. Basically selecting a new timezone in the indicator does absolutely nothing and trying to change the timezone in Time&Date Settings just makes g-c-c crash. I ended up changing /etc/timezone and /etc/localtime by hand
<seb128> stgraber, pitti: the commit that ported indicator-datetime to systemd was only in 13.04 and not trunk, and they landed an update from trunk on friday which broke it
<seb128> cyphermox was supposed to do a new landing on friday
<seb128> seems like he didn't...
<seb128> the fix is in trunk
<stgraber> seb128: ah, that'd explain it, thanks
<mlankhorst> ogasawara: yeah I thought so too, penguin42 said he was using -cirrus though, dno why :/
<penguin42> ogasawara/mlankhorst: This is todays Saucy iso
<penguin42> on a raring host
<cyphermox> seb128: stuff was still missing so yeah I didn't have time to do it
<cyphermox> I'm looking now
<seb128> cyphermox, jenkins is broken according to didrocks
<didrocks> yeah, we'll need to bypass and kill the autopilot jobs again
<didrocks> the nodes are not up and nobody with those rights are available it seems
<cyphermox> dah
<cyphermox> ok
<cyphermox> no biggie for this
<didrocks> cyphermox: I'm killing all the jobs though are there is as a consequence a deadlock
<mbiebl> seb128: heya, got a minute?
<mbiebl> I noticed that Ubuntu submits popcon data to popcon.debian.org
<mbiebl> someone suggested that this might be due to a borked merge from Debian
<mbiebl> e.g. I found around 10000 submissions with a 1.56ubuntu1 version number
<mbiebl> seb128: could you have a look at this or tell me who I should notify?
<ScottK> xnox: There's a PyQt5 snapshot available now and it doesn't need the deprecated functions in Qt5.
<mitya57> PyQt5 snapshot? \o/
<ScottK> Someone just needs to package it.
<mitya57> mbiebl, seb128: lp:~mitya57/ubuntu/saucy/popularity-contest/fix-sync-issues should fix that
<seb128> mbiebl, mitya57: ok, will look at the merge request
<mitya57> seb128: should I file it?
<seb128> mitya57, the bug? or submit a mr?
<mitya57> seb128: https://code.launchpad.net/~mitya57/ubuntu/saucy/popularity-contest/fix-sync-issues/+merge/162631
<mitya57> (I don't know how to test it, but my diff is equivalent to what we had in quantal, so it should work)
<seb128> mitya57, thanks
<mitya57> seb128: btw, do you still plan to look at poppler or should I subscribe ubuntu-sponsors there?
<seb128> mitya57, me looking doesn't prevent sponsors to be subscribed ;-)
<seb128> mitya57, please subscribe them, I still plan to do but if somebody beats me to it I will not complain
<mitya57> seb128: will subscribe after I get okular building (investigating that right now)
<mbiebl> mitya57: that MAILTO is commented out is intentional?
<seb128> mitya57, ok
<mitya57> mbiebl: it's not my change, it was commented out in quantal
<mitya57> so I don't know :)
<mbiebl> mitya57: I guess it also need a fix for raring?
<mitya57> mbiebl: I think yes
<mitya57> when we verify it's working in saucy
<seb128> mbiebl, does anyone really care about popcon datas?
<mbiebl> nod
<seb128> mbiebl, we have debian people who asked in the past that we just send ubuntu datas to debian since it would be useful there as well
<mbiebl> seb128: sure
<seb128> mbiebl, though it seems the server side could use improvement to display derivatives datas
<mbiebl> seb128: I talked about that with pabs, who wanted to include dpkg-vendor data
<mbiebl> which definitely makes sense imho
<seb128> right
<mbiebl> but Bill is apparently blocking that / not interested
<seb128> :-(
<seb128> ok
<seb128> mbiebl, mitya57: the mailto is commented because of:
<seb128> "  * default.conf:
<seb128>     - comment out MAILTO because we do not support sending in
<mbiebl> so I dunno what the way forward is regarding that
<seb128>       popcon data over mail"
<mbiebl> k, thanks for the info
<seb128> mbiebl, ok, I will just merge the fix/sru it, that will be good enough for me ;-)
<mbiebl> thanks
<seb128> thanks for pointing the issue
<mbiebl> btw, I think sending the Ubuntu popcon data to popcon.d.o has value
<mbiebl> but oonly if we can differentiate it
<mbiebl> if it is mixed into the Debian data, not so much
<seb128> right
<cjwatson> pitti: OK, I've been trying for half an hour to figure out why openssh sessions in saucy don't quite register with logind correctly (to reproduce: 'ssh localhost', run gnome-control-center, go to "User Accounts", and observe that the Unlock button is insensitive), and I'm lost in a twisty maze of policykit.  It seems to be set up roughly the way http://www.freedesktop.org/wiki/Software/systemd/multiseat says it should ...
<cjwatson> ... (i.e. a session but no seat).  Can you help figure out what is or isn't happening here?
<ScottK> Are the retracers for apport running?  I've got a bug pending retrace since yesterday.
<mitya57> my bug 1170384 is pending retrace since 2013-04-18, so probably no
<ubottu> bug 1170384 in qtbase-opensource-src (Ubuntu) "[sna] Xorg crashed with SIGABRT in memcpy_blt() - <Address 0xb8070f48 out of bounds> when using ReText with Qt5" [High,In progress] https://launchpad.net/bugs/1170384
<ScottK> pitti: Who's minding the retracers these days?
<mfisch> The UDD guide states that debian versions are auto-imported into launchpad from debian experimental and testing. where would I find those branches? Specifically I'm looking at gnome-terminal (https://code.launchpad.net/ubuntu/+source/gnome-terminal)
<infinity> mfisch: s/ubuntu/debian/
<mfisch> gah thats so simple and obvious
<mfisch> thanks
#ubuntu-devel 2013-05-07
<slangasek> stgraber: how is pulseaudio supposed to be starting in saucy?  Because it didn't for me
<slangasek> hmmm, possibly because I have a non-standard ~/.pulse/default.pa that goes looking for consolekit
<pitti> Good morning
<pitti> stgraber: hey! had an ok trip back home, but fell to ubuflu again, so I was mostly offline yesterday, sorry
<pitti> stgraber: hm, I changed the timezone yesterday with the indicator/g-c-c, that worked fine; so if it wasn't what seb128 said, we need to debug interactively
<pitti> ScottK: we don't yet have saucy retracers for Launchpad, as we didn't enable LP uploading of crashes yet
<ScottK> pitti: This was raring.
<pitti> ScottK: they should go to errors.u.c. though; ev, did you create saucy retracers already?
<pitti> ScottK: argh, then probably they crashed again and I didn't get cron mail
<ScottK> The problem is that e.u.c was failing to retrace them.
<pitti> indeed, since May 4; restarting
<ScottK> So I re-enabled apport to send to LP in the hopes of getting something.
<ScottK> Thanks.
<pitti> cjwatson: that's because /usr/share/polkit-1/actions/org.freedesktop.accounts.policy only allows org.freedesktop.accounts.user-administration for local consoles
<pitti> cjwatson: we could set allow_any to auth_admin for that
<pitti> cjwatson: (that's not related to CK vs logind); you can check your session with "loginctl" (list) or "loginctl show-session c2" (details about a session)
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #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> pitti: Ah, OK, so ssh to a raring/CK system would've behaved the same way?  I guess that's a regression from, um, whenever I did the CK work in openssh originally.  Yeah, I'd found loginctl - just wasn't quite sure how to interpret it in the light of the behaviour I was seeing, so thanks
<pitti> cjwatson: so your ssh integration was basically to create a session which was "local"?
<cjwatson> pitti: No, in the original case it was to create a session at all
<cjwatson> pitti: And I think to accurately pass DISPLAY
<pitti> for a non-local ConsoleKit session, PK in raring behaves the same way, yes
<pitti> e. g. you cannot mount any USB devices and the like
<pitti> for control-center, the policy could certainly allow authentication in remote sessions
<cjwatson> pitti: I suspect that it's still true that logind doesn't accurately know about DISPLAY for an X-forwarded ssh connection, but I don't know if/where that matters
<pitti> ssh -X joe@localhost
<pitti> $ echo $DISPLAY
<pitti> localhost:10.0
<pitti> joe@donald:~$ xeyes
<pitti> that works for me at least
<pitti> logind doesn't know about the display indeed (as it's not on a seat), but ssh does the forwarding just fine apparently
<cjwatson> Sure, that's what I meant :)
<cjwatson> DISPLAY forwarding on its own has nothing to do with logind
<cjwatson> I guess that if the display is necessarily associated with a seat in logind-speak then given that the docs say there's no seat for ssh connections it's OK for logind not to know about it
<pitti> yes, that's how I understand it
<cjwatson> (though it seems a bit odd to *specify* no seat for ssh connections, but whatever)
<dholbach> can somebody please reject https://code.launchpad.net/~bkerensa/ubuntu/saucy/kde-artwork-active/fix-for-1169931/+merge/162656? (there was a debdiff already available for it)
<dholbach> can somebody please reject https://code.launchpad.net/~bkerensa/ubuntu/saucy/software-center-aptdaemon-plugins/fix-for-1175101/+merge/162654 as well? (same reason)
<dholbach> mvo, does software-center-aptdaemon-plugins have its own LP project or can I just go ahead and upload a fix to the archive?
<dholbach> nevermind, found it
<dholbach> mvo, can you pull from lp:~dholbach/software-center/software-center-aptdaemon-plugins?
<mvo> dholbach: sure
<dholbach> mvo, hugs!
<mvo> dholbach: well, not really, you need to propose a merge and I can approve it
<dholbach> ...
<dholbach> sure
<mvo> dholbach: its tarmac that is doing the merging these days
<dholbach> ah ok :)
<dholbach> mvo, https://code.launchpad.net/~dholbach/software-center/software-center-aptdaemon-plugins/+merge/162729
<dholbach> mvo, you might be interested in https://code.launchpad.net/~mitya57/software-properties/lp1047424/+merge/161625 too
<dholbach> ogra_, does the patch in https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1174791 make sense?
<ubottu> Launchpad bug 1174791 in live-build (Ubuntu) "missing raring version string "13.04" in ./.disk/info" [Medium,New]
<ogra_> dholbach, hmm, i thought xnox did some testing of usb-creator prior to release
<ogra_> i wonder if he just uses a very old usb-creator
<ogra_> dholbach, the patch makes sense but i'm curious why that issue doesnt/didnt show up in pre-release testing at all
<zyga> hrw: hi
<hrw> zyga: ho
<zyga> hrw: back in canonical? :-)
<hrw> zyga: not yet
<ogra_> dholbach, though on a sidenote i think we originally put .disk/info in place using debian-cd
<dholbach> I have no idea - I just thought you'd be a good person to review it
<ogra_> well, it definitely isnt wrong to add this ... but i suspect it might not help
<dholbach> hm
<dholbach> ok
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hoangchuongduong> hi every body
<pjotr> Hello, does anyone of you deal with langpacks for the localizations?
<pjotr> I'm a member of the Dutch Ubuntu translators team, and I've noticed that a .mo file is missing from the Dutch langpack (and possibly from other langpacks as well)
<pjotr> This concerns xscreensaver. I've filed a bug report about it: https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/1177324
<ubottu> Launchpad bug 1177324 in xscreensaver (Ubuntu) "xscreensaver: there's no translation file in the Dutch langpack anymore" [Undecided,New]
<pjotr> micahg: maybe you can take a look at it? This bug is pretty visible in Xubuntu...
<infinity> pjotr: Fix uploaded.
<pjotr> infinity: great! Is it still in Proposed?
<vibhav> dholbach: thanks for sponsoring im-switch
<infinity> pjotr: I literally uploaded it when I said I did, so yes. :)
<infinity> pjotr: https://launchpad.net/ubuntu/+source/xscreensaver/5.15-2ubuntu2 <-- Still building.
<pjotr> infinity: thanks for your immediate help!  :-)
<dholbach> vibhav, no worries
<infinity> diwic: D'oh.  Nice catch on the autogenerated alsa header.
<diwic> infinity, yeah, what bothers me is how the original patch could sort-of work, because it did resolve the error for you, or didn't it?
<infinity> diwic: I probably only tested on a locally-installed header, instead of rebuilding, reinstalling, and building against it. :/
<diwic> infinity, ok...autopkgtests ftw?
<infinity> diwic: An autopkgtest that tries to build a few random rdeps might catch this sort of thing, yeah.
<infinity> kees: Your changelog for faketime/raring seems to be living in the past (glibc 2.7 indeed).
<diwic> infinity, also it bothers me that other rdeps should have been failed building during the time it was in the archive
<infinity> diwic: You'd think, right?  Maybe it was just sheer luck that nothing tripped on it.
<infinity> diwic: I know the bug report I was initially responding to was someone building something out-of-archive, not an FTBFS in Ubuntu.
<infinity> diwic: So maybe we just never (re)built anything that was affected.
<diwic> infinity, like, all the others just happened to include sys/types.h above asoundlib.h or something?
<infinity> diwic: Something like that, yeah.  It's not exactly uncommon to pull in types.h via other means.
<diwic> infinity, on another note, upstream shouldn't ship asoundlib.h if it is generated during build. IMO.
<infinity> diwic: That would certainly have eased my confusion. :P
<infinity> (And yes, I'm a big fan of clean/distclean targets removing autogenerated files)
<infinity> kees: Also, you didn't fix it in saucy (or were you planning to copy from raring to saucy once it was built?)
<ekarlso> anyone here concidering https://bugs.launchpad.net/precise-backports/+bug/1162529 ?
<ubottu> Launchpad bug 1162529 in Quantal Backports "Please backport openvswitch 1.9.0-0ubuntu1 (main) from raring" [Undecided,New]
<tumbleweed> ekarlso: someone needs to do the testing
<stokachu> could I get someone on SRU team to approve bug 1169740 for precise/quantal?
<ubottu> bug 1169740 in rsyslog (Ubuntu Quantal) "rsyslog hangs loading modules" [Undecided,New] https://launchpad.net/bugs/1169740
<cjwatson> Daviey: You seem to have discarded several Ubuntu-specific changes from debmirror?
<stokachu> vanhoof: do you have bits for the sgs2 for ubuntu touch?
<zyga> tedg: hey
<zyga> tedg: in http://bazaar.launchpad.net/~ted/+junk/upstart-app-launch/view/head:/application.conf.in you can probably use env UBUNTU_APPLICATION_ISOLATION=1 and use exec rather than script
<tedg> zyga, Ah, cool.
<tedg> zyga, Still learning the upstart job stuff :-)
<zyga> tedg: it's not much different but it's pretty cool
<zyga> tedg: I love the concept
<zyga> tedg: I wonder and worry, though, about child processes
<zyga> tedg: so if you run gedit and gedit runs python console and there you subprocess.call("") something that won't be killed
<zyga> tedg: but that's upstart limitation I think (and jodh correct me if I'm wrong)
 * zyga would wish people would use git repos rather than lp/+junk 
<tedg> zyga, There is some discussion on whether it should use cgroups to overcome that limitation.
<tedg> zyga, Though, that's above my pay-grade :-)
<tedg> zyga, Not sure of all the trade-offs
<zyga> tedg: yeah, I guess that's the only viable option
 * zyga would love to be allowed to write that code
<jodh> zyga: upstart can only follow two forks, as daemons shouldn't need to perform more. However, now we have upstart in the user session, that may need to be reconsidered. See too https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations.
<zyga> ahh
<zyga> thanks for that link
<zyga> jodh: to be fair I think that deamons can easily do more than that
<zyga> jodh: eg, celery having children
<zyga> jodh: apache using forks
<zyga> jodh: or ssh having client connections
<jodh> zyga: there are a very small number of exceptions, but most well-behaved daemons follow conventions to fork up to twice before being "ready". However, wrt the exceptions, you might want to look at https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-service-readiness
<zyga> jodh: looking at that blueprint I don't see "0) Cannot track processes spawned by the job at all" which seems like the root of all of the other issues
<zyga> jodh: yeah, some daemons don't need that but there are some widely used exceptions :/
<zyga> jodh: service readiness is orthogonal a bit but I see why it is relevant
<zyga> s/relevant/important/g
<jodh> zyga: ...and we've dealt with those exceptions by, for example, running sshd in non-backgrounding mode.
<stgraber> cyphermox: any idea on bug 1174418? I'm clearly not seeing this behaviour on any of my desktop machines and it looks like it's a desktop thing so might be somehow related to NM.
<kirkland> infinity: ping
<ubottu> bug 1174418 in netbase (Ubuntu) "Privacy Extensions are set by default on Ubuntu 13.04, but no temporary address will be generate" [Undecided,New] https://launchpad.net/bugs/1174418
<infinity> kirkland: Sup?
<kirkland> infinity: re: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1173209, what if we just set stamp=/var/run/release-upgrade-available
<ubottu> Launchpad bug 1173209 in ubuntu-release-upgrader (Ubuntu) "Prompted about New Release for 13.04 again after dist-upgrade and a restart" [Low,Triaged]
<zyga> jodh: apache? celery?
<cyphermox> stgraber: NM doesn't do privacy addresses for you; let me check
<kirkland> infinity: so that it gets cleared on reboot?
<zyga> jodh: I don't see any way to deal with those in general
<kirkland> infinity: simple/clean/easy fix, right?
<zyga> jodh: you'd need new semantics to trace that
<kirkland> infinity: (and the upgrade check would run at least once per boot)
<infinity> kirkland: I suppose you could abuse /var/run for that, but then you'd still have long-running systems showing you upgrade available to the "wrong" thing.
<infinity> kirkland: Say, people who ksplice through a release, and we now want to tell them there's a new new one available.
<cyphermox> stgraber: I don't know, I have temporary addresses here?
<kirkland> infinity: fair enough;  part of the do-release-upgrade process should clearly rm that flag
<stgraber> cyphermox: right, I definitely have that stuff working as expected here, so I'm a bit confused as to what that user is actually seeing...
<infinity> kirkland: I just see two bugs here.  1) The upgrader should wipe out the file entirely, and 2) update-motd fragment shouldn't assume "populated = good", and still refresh occasionally.
<kirkland> infinity: agreed
<cyphermox> stgraber: possibly not seeing the temporary addresses because there is no prefix received?
<cyphermox> or because they use the wrong tool to try and display it?
<stgraber> cyphermox: yeah, that's what I'm wondering. I'm posting a comment asking specifically how is his IPv6 setup
<cyphermox> anyway, if they don't get a temporary address maybe it's the kernel not generating one?
<stgraber> cyphermox: because you clearly won't get a temporary address if you're using static or stateful DHCPv6. You only get the privacy stuff if you're doing stateless
<smb> infinity, Bloody heck. I brain-dead uploaded lucid ec2 to main archive instead of ckt ppa. If you could rip that out of the new queue please (Lucid). Given it will not be accepted I believe I can redo the upload to the ppa
<stgraber> cyphermox: alright, commented asking for a whole lot more information
<cyphermox> stgraber: indeed, no way to correctly generate tempaddrs for dhcpv6 :)
<infinity> smb: Rejected.
<smb> infinity, thanks
<pitti> stgraber: hey Stephane, how are you?
<pitti> stgraber: FYI, I integrated the veth setup into NM's autopkgtests, that works fine so far; NM does recognize the devices, I thought you said that regressed?
<pitti> (or was I talking to cyphermox about this?)
<stgraber> pitti: yep, that was a regression from quantal. Back in quantal a veth device was considered equivalent to a physical device if it's not called "veth*"
<pitti> stgraber: NM recognized the renamed "eth2", but ignores the non-renamed veth0
<pitti> (in raring and upstream)
<tedg> zyga, thanks!  http://bazaar.launchpad.net/~ted/+junk/upstart-app-launch/revision/10
<stgraber> pitti: hmm, weird, I don't quite see that here, hold on a sec, re-testing
<pitti> stgraber: I'll add some actual tests for these now, perhaps I just wasn't looking deep enough yet
<pitti> stgraber: don't worry about re-testing for now, I was mostly interested in understanding what you saw
<zyga> tedg: cool, my pleasure :)
<stgraber> pitti: so are you seeing that if you do:
<cyphermox> pitti: well your test seems to be proving that things might be fine?
<stgraber> ip link add type veth
<zyga> tedg: do you plan on landing that in saucy desktop?
<zyga> tedg: for user sessions?
<stgraber> ip link set name eth2 dev veth0
<stgraber> pitti: you then get a usable eth2 in NM?
<tedg> zyga, I think there's still more discussion to be had, as well as figuring where it belongs.  But, I'm positive on it right now.
<stgraber> *saying
<pitti> stgraber: that's what I'm about to write a test for; so far I just created the devs, but didn't use them yet
<pitti> stgraber: so in that scenario you expect eth2 to work, but veth1 to be ignored, right?
<stgraber> pitti: correct
<zyga> tedg: ok, I cannot wait to see what's discussed at UDS then
<pitti> stgraber: ack, thanks
<stgraber> pitti: but what I'm actually seeing is both of them be ignored (not showing up in nm-tool)
<cyphermox> stgraber: gah, you didn't mention this when we spoke about it :)
<stgraber> cyphermox: what part didn't I mention? :)
<cyphermox> NM will only detect the devices when they are attached; if there is enough of a delay between addition and rename, it won't be seen as a non-veth device :)
<stgraber> cyphermox: oh, that's interesting
<zyga> tedg: have you thought about using upstart for things like updating apps?
<pitti> oh, that's it perhaps; I'm doing coldplug tests for the most part
<pitti> I also have a hotplug test, I'll add veth hotplugging there, too
<pitti> coldplug -> set up devices and AP, then start NM
<pitti> hotplug -> start NM, then set up devices/APs
<pitti> it usually takes NM some 30 seconds to pick up a newly appearing AP, thus these tests are painfully slow
<pitti> and I do most of them in coldplug mode
<tedg> zyga, ?  In what way?  You mean to shut them down after upgrade?
<cyphermox> stgraber: well, it's also apparently not the issue; even if you actually add the right device it doesn't seem to be picked up
<zyga> tedg: no, for just upgrading, like 'start update-app APP_ID=...' which would figure out how to update that particular application
 * zyga feels that all the task names should have rev dns notation :P
<pitti> NetworkManager[8164]: <info> (eth42): carrier is OFF
<pitti> nmcli dev -> eth42      802-3-ethernet    unmanaged
<mlankhorst> eth42?
<tedg> zyga, I don't think that'd work as most apps work with a system level DB of upgrade items.  But, it is an interesting concept.
<pitti> "guaranteed not to exist in the environments we are concerned about" :)
<infinity> mlankhorst: It's the network that connects him to life, the universe, and everything.
<zyga> tedg: sure but that could be customized
<pitti> cyphermox: there doesn't seem to be an nmcli command to connect to eth, is there?
<cyphermox> yes
<pitti> running "dhclient -v eth42" works fine
<zyga> tedg: eg, it could be 'apt-get install $(packages-for-app $APP_ID)' in the general case
<cyphermox> nmcli con up id "name of connection"
<cyphermox> stgraber: btw: sudo ip link add name foo1 type veth peer name bar1
<pitti> cyphermox: ah, "nmcli con list" doesn't have anything
<cyphermox> pitti:
<cyphermox> try nmcli con up id "Wired connection 1"
<cyphermox> let me double check that's the correct name
<infinity> Mine's called "Auto Ethernet".
<pitti> I guess it doesn't see a link beat on that one yet; the veth apparently only sends a link beat when it's up
<pitti> chicken-egg
<pitti> nope, not that one
<pitti> I guess it actually has to appear in nmcli con list
<cyphermox> pitti: well, it wouldn't, because that's an automatically created connection
<cyphermox> there has to be a trick
<mlankhorst> infinity: oh btw since lts-raring kernel is now in precise-proposed, can I upload the rest of xserver stack to precise-proposed too?
<pitti> cyphermox: I guess I can request it via libnm-glib (I'm using the gir bindings in the tests)
<mlankhorst> it should be just a matter of rerunning lts-stack raring at this point
<pitti> cyphermox: nmcli is just handy for manual testing
<cyphermox> pitti: yeah, see what the list of connections give you
<infinity> mlankhorst: Sure.  I won't get to reviewing it this week, but maybe someone will.
<pitti> stgraber: ok, I can reproduce your issue
<cyphermox> pitti: maybe you just can't do that with nmcli yet
<pitti> cyphermox: there's none
<pitti> cyphermox: yes, apparently
<cyphermox> :/
<cyphermox> pitti: let dcbw know :)
<pitti> cyphermox: I actually had expected NM to auto-connect to ethernet without explicitly telling it
<mlankhorst> I pity the poor person reviewing, it's actually less work for me to generate the entire stack at this point ;)
<cyphermox> yeah
<cyphermox> pitti: that's what should happen
<pitti> cyphermox: but I guess real ethernet devices would have a link beat
<cyphermox> pitti: well, a veth alone won't if it's not hooked to another end
<cyphermox> pitti: sudo ip link add name foo1 type veth peer name bar1   <-- I get both recognized
<pitti> cyphermox: I gave the other end an IP and added dnsmasq on it
<pitti> cyphermox: oh, "peer name" -> what's bar1?
<cyphermox> they get brought up immediately
<cyphermox> just a random interface name
<pitti> cyphermox: nice, I used "ip link add type veth; ip link set name eth41  dev veth1"
<pitti> cyphermox: so with that single command that should even be atomic
<pitti> niice!
<pitti> cyphermox: thanks
<pitti> NetworkManager[8164]: <info> Added default wired connection 'Wired connection 1' for /sys/devices/virtual/net/eth42
<cyphermox> yeah ;D
<zyga> pitti: what are you guys doing?
<pitti> zyga: pretending to have ethernet :)
<cyphermox> zyga: figuring out how to test fake ethernet devices
<zyga> oh
<zyga> testing?
<pitti> zyga: I am adding ethernet tests to NM's autopkgtest
<zyga> awesome
<pitti> zyga: I already have a nice collection of wifi tests
<zyga> pitti: we should organize a mini sprint one day, so that our wireless/wired network tests could be themselves tested without real hardware
<pitti> zyga: the wifi tests don't use real hw either
<pitti> mac80211_hwsim FTW
<zyga> pitti: yeah I understand
<zyga> pitti: my point is that we (Certification) have tests that validate if hardware actually works
<zyga> pitti: and those tests are sometimes buggy or regress
<zyga> pitti: we'd love to be able to run tests against 'virtual' hardware for each merge for example
<pitti> yeah, that's what we do with autopkgtest
<zyga> pitti: to essentially be able to unit test a script that checks if wifi works
<pitti> once autopkgtest is properly wired into britney, a NM, dhclient, wpasupplicant, kernel, some library, or whatever that breaks any of those will cause the package to not get into ubuntu
<zyga> pitti: it would be equally good if we could write and run tests that our vefification programs (test is so overloaded in this context) would never regress
<zyga> pitti: and not having to run them against, eg, real access point and wifi card
<pitti> well, we still need tests against real hw
<zyga> pitti: I don't yet understand how those would work
<zyga> pitti: we do
<zyga> pitti: and we run tests on real hardware for cerfification
<pitti> above autopkgtests ensure that the userland is okay, but they don't cover any driver of course
<zyga> pitti: but for each commit that lands to our project, we should also tests stuff that normally depends on hardware
<zyga> pitti: testing on real hw is much more problematic and we don't do it
<zyga> pitti: (for development)
<Laney> mterry: yo dawg, any chance I can hassle you to look at / merge https://code.launchpad.net/~laney/lightdm/fix-lightdm-qt-pcfile/+merge/162797 quickly?
<Laney> I want to upload it to saucy soonish as it's needed to unstick lightdm from proposed
<zyga> plars: hey
<zyga> plars: do you have the time for utah sync meeting?
<mterry> Laney, I believe I already updated that in trunk
<Laney> you did for qt5 but not the other one
<kirkland> infinity: fyi, https://code.launchpad.net/~kirkland/ubuntu-release-upgrader/1173209/+merge/162798
<mterry> Laney, guh, I must have misread it then.  Thought the qt4 one had already been changed
<Laney> :-)
<Laney> for an upload, can I just distropatch as normal?
<mterry> Laney, yeah.  I approved the branch
<Laney> sweet, doing that then
<Laney> merci
<plars> zyga: probably not today
<zyga> plars: could you please move the meeting to a slot that suits you?
<plars> zyga: sure, I'll look in a bit
<zyga> plars: thanks!
<Laney> hmm, do we not have up-to-date udd branches for saucy yet?
<Laney> xnox: ^?
<pitti> cyphermox: would you know why "ip link set dev eth42 up" (i.e. the peer) works and brings up both devices, but up'ing veth42 doesn't work?
<pitti> well, I guess that's just a quirk of veth
<pitti> I wouldn't like to up the client-side eth myself, as NM is supposed to do that
<pitti> but without it I don't seem to get a link
<pitti> ah, when I run that while NM is already running, it works
<pitti> it just doesn't pick it up at startup
<Laney> xnox: ah, nm, it's just that ubuntu:package gets release not proposed
<cyphermox> pitti: not sure, like you think i'd say it's a quirk of veth
<ekarlso> I get gpg: /tmp/debsign.Cw0XdNLo/openvswitch_1.9.0-0ubuntu1~ubuntu12.04.1~ppa1.dsc: clearsign failed: secret key not available
<cjwatson> you can ignore that if you don't have a key set up
<ekarlso> when doing: backportpackage -u ppa:endre-karlson/virtualization -s raring -d precise openvswitch
<ekarlso> cjwatson: yeah, but it fails ...
<cjwatson> ah, if you're planning to upload to a PPA then you do need to fix that
<ekarlso> :)
<cjwatson> look up your key ID in 'gpg --list-keys' and put DEBSIGN_KEYID=that-key-id in ~/.devscripts
<cjwatson> is the simplest way to override if it's not autodetecting
<cjwatson> lack of autodetection probably means that your key doesn't have an ID for the e-mail address you're using in your changelogs
<Riddell> siretart: who maintains UEHS?
<bdmurray> stgraber: bug 1176580 doesn't seem possible to me but I don't see anything in casper preventing it
<ubottu> bug 1176580 in casper (Ubuntu) "Raring Suspend on Install" [Undecided,New] https://launchpad.net/bugs/1176580
<stgraber> bdmurray: I don't remember casper having any code for that, however ubiquity sets a bunch of gsettings key which IIRC includes suspend settings
<bdmurray> stgraber: having it ubiquity would make more sense for using live media
<stgraber> bdmurray: I'm also susprised that suspending messes up the install. We clearly don't recommen closing the lid or installing on low battery but I'm not sure why this would lead to failed data copy.
<siretart> Riddell: what's uehs?
<mitya57> http://qa.ubuntuwire.com/uehs/
<Riddell> wgrant: is uehs your baby?
<wgrant> Riddell: Yes, though it hasn't been "maintained" as such in probably 5 years.
<Riddell> wgrant: is the source code somewhere?
<wgrant> Riddell: lp:dehs, IIRC
<wgrant> I just import it from Debian and rebrand it slightly, I think
<infinity> Daviey: You dropped a ton of changes from debmirror when you force-synced it...
<cjwatson> infinity: Yeah, I commented on that earlier too.  I guess he's busy sprinting
<infinity> cjwatson: I uploaded a proper merge just now.
<cjwatson> infinity: Thanks
<bdmurray> stgraber: could you have a look at bug 1176046?
<ubottu> bug 1176046 in isc-dhcp (Ubuntu) "isc-dhcp dhclient listens on extra random ports" [Medium,Triaged] https://launchpad.net/bugs/1176046
<Daviey> infinity / cjwatson: Ugh. My bad.  Thanks for resolving.
<Daviey> infinity: In future, do just raise it - i'll clean up my mess. But thanks for doing it. :)
<stgraber> bdmurray: I saw the bug report but I don't think we should disable the feature so for now I'm just keeping it as it's waiting for more people to comment (or will just won't fix it in a little while if nobody does)
<stgraber> (we're no different from Debian on that bit, I don't think it's a big security risk and corp environments need the feature)
<bdmurray> stgraber: okay, sounds good
<stgraber> mdeslaur: maybe you have a different opinion on this, but to me this sounds like a feature that's actually used, has been around for years and isn't a huge security risk (considering dhclient runs under apparmor anyway).
<mdeslaur> stgraber: I agree
#ubuntu-devel 2013-05-08
<melodie> hello
<melodie> I would not want to bother with a problem related to bugs, but I think I would like to know something about jobservice and jobs-admin tools.
<melodie> I would like to know if there are plans to work on the code of this program
<melodie> here is our findings so far, about it : it does not work in a way which allows managing services.
<melodie> here is the best post I could write after I tried to dig in and test:
<melodie> http://beta.linuxvillage.net/index.php/topic,297.msg2231.html#msg2231
<melodie> and after I have been commenting on one of the latest bugs reported regarding this program.
<sarnold> melodie: heh, the changelog.Debian.gz doesn't paint a pretty picture. it looks quite stale
<melodie> hi sarnold
<sarnold> melodie: what I think you actually want is an .override file -- no gui, no dbus involved :)  http://upstart.ubuntu.com/cookbook/#override-files
<sarnold> melodie: just echo manual >> /etc/init/whatever.override and that 'whatever' job will not start automatically at boot
<sarnold> (finding this feature was what made me prefer upstart over sysv-init :)
<melodie> sarnold what I wish is not an override-file but a handy tool fit for newcomers (the ones who are ready to use their brain and learn how to deal with an Ubuntu distro)
<sarnold> melodie: ah, darn. :)
<melodie> sarnold if I need a special setup in Archlinux, and do things by hand I'll do it, but in Ubuntu, I don't believe it :D
<RAOF> melodie: So what you want is an upstart job GUI? That shouldn't be super-hard.
<melodie> RAOF the gui exists, but some things don't go straight in the code and the man who wrote much about it had done a fix which he accidentally deleted.. in 2011 and never replaced as it seems
<melodie> you can notice in Raring it is the same version used:
<melodie> http://packages.ubuntu.com/search?keywords=jobservice&searchon=names&suite=raring&section=all
<melodie> RAOF i mean the code of the background : jobsystem. the gui might be fine.
<RAOF> melodie: I'm not entirely sure what you're after? Do you want to work on the code? Go ahead! Do you want someone at Canonical to make it their job to work on the code? That's probably not going to happen.
<melodie> in fact all is really beautiful in Ubuntu, so many nice User interfaces, just this one does not work
<sarnold> melodie: most users only have services installed that they want to run anyhow..
<melodie> RAOF if I would know I would try, but I don't have that knowledge. I know only about the system, testing, bringing pieces together.. I participate as I can but don't code
<melodie> sarnold this is less and less true. see cups ?
<melodie> it can be installed and runned only once a while, or bluetooth or...
<sarnold> melodie: this specific tool looks like it was written with upstart 0.6 in mind; 1.3 and newer provide the override files that would make the tool only about a thousand times easier to write...
<RAOF> melodie: Why not code? This is probably a good project to start with âº
<melodie> RAOF I just registered this year to two places to try to learn a little. at coursera.org and at  cs50.tv : and I have a very full life, so it's not going to be easy.
<melodie> I just wanted to know if Ubuntu is planning to review this code which looked very promising.
<RAOF> I do not believe that anyone is currently planning to touch that code.
<sarnold> melodie: I'll try to keep this in mind next time someone comes forward and says "I want to help but don't know where to start" :)
<melodie> example, at cs50.tv they have provided an appliance under the shape of a Fedora tweaked for the needs of the course. I don't know much about Fedora, and there are a bunch of things which I really prefer in Ubuntu.
<melodie> just their job service management tool : we would all like to have the equivalent in Ubuntu :P
<melodie> see for the testing purpose and for the post written I have taken a pair of hours. I wanted to have a talk about it with people who know the value of good user interfaces in Ubuntu. This is done now. (and it's very late in the night here. :) )
<sarnold> :D
<melodie> sarnold you say something strange : if I'd know how to debug a python code I could try to bring better feedback; what tool do you use to debug a python script ?
<sarnold> melodie: I try to replicate problems in the python REPL interative interpreter -- copy-and-pasting function definitions as I modify them from another file, when they grow too large..
<sarnold> melodie: it isn't very good :( but it works for me well enough that I haven't looked much further
<melodie> I thought I would try to find who maintains it, but it seems the original maintainer is not involved anymore : http://packages.ubuntu.com/raring/jobservice
<melodie> " python REPL interative interpreter" : no idea what it is.
<melodie> I might discover it later if I can stick to the courses online... or perhaps not.
<melodie> sarnold RAOF thanks to both
<melodie> I can read here: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss among else:
<melodie> " Point of contact for Ubuntu users to reach Ubuntu developers
<melodie> "
<melodie> so I think I'll try to post there once about this issue.
<melodie> I'll test it on more versions before, to be a better idea of the extent of the issue
<melodie> good night
<sarnold> oh bother, too bad she's gone while I was away.. there's really no point to her investigating that program further, it's been abandoned for over two years...
<infinity> ScottK: kde4libs is trying to yank a ton of stuff into main.  Looks like a few suggests got upgraded to recommends.  Any idea if that was intentional or a merge oops?
<infinity> ScottK: Hrm, based on history in the package, I'm going to assume it was just a merge oops, and upload a fix.
<infinity> Daviey: Can you get someone on your team to take ownership of the MIRs required for the new puppet and python-testtools rdeps?
<infinity> Daviey: See http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<ScottK> infinity: probably.
<ScottK> Go for it.
<ScottK> Riddell: ^^^
<pitti> Good morning
<dholbach> good morning
<vmlintu> Hi.. Could anyone point me forward with this lightdm issue? I'm trying to figure out how to make a proper fix for this as this shows up on diskless workstations all the time..  https://bugs.launchpad.net/lightdm/+bug/1172752
<ubottu> Launchpad bug 1172752 in Light Display Manager "Race condition in lightdm greeter setup" [Undecided,Confirmed]
<RAOF> vmlintu: Hm. Seems reasonable. I don't suppose you can get a reliable test case that we could add to the testsuite? :)
<RAOF> vmlintu: You've got two options to take that forward - branch lp:lightdm, apply that fix, and propose a merge back to lp:lightdm, or hope someone else does that.
 * RAOF heads to the shops for a bit.
<vmlintu> RAOF: I haven't been able to change the environment so that the race condition would show up all the time, so no test case at this point..
<vmlintu> But I really don't like the fork()->vfork() fix I wrote in the launchpad bug report as it just hides the unnecessary fork()->execlp()->kill() cycle. Getting rid of that would make the fix unnecessary..
<Laney> Is errors.u.c having a sad day? "An error occurred while trying to load the most common problems"
<zyga> cjwatson: I so much want to work on the new app installer / packaging format
<ogra_> zyga, i think there are UDS sessions next week
<zyga> ogra_: I'll be there if I can
<zyga> ogra_: but this is something I wanted ubuntu to have for a long time
<zyga> ogra_: and now there is both the desire and the actual need
<zyga> I was thinking about dependencies though
<zyga> classical dependencies cannot be allowed
<zyga> but I was thinking about base os dependencies that might make this applicable to many more packages, without adding any additional issues that the proposal is trying to avoid
 * zyga so much wants to talk to cjwatson about this later
<cjwatson> Right, as I mentioned briefly in my post I was considering permitting a few base profiles; it'd be useful if you have experience of what other systems call things there
<cjwatson> The way I'd be inclined to implement this would be to allow packages to install files in /usr/share/click-package/profiles/ whose presence indicates that a profile is present
<zyga> cjwatson: I don't think I understand base profiles exactly, I'm somewhat familiar with what gnome is trying to build now but I wasn't aware of any profiles there
<cjwatson> I initially called this "base system", but somewhere in my research I ran across the term "profile", I think via the GNOME app bundle stuff, and I prefer that term
<cjwatson> http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/ mentions it
<cjwatson> Well, he calls it variously "ABI" and "profile" there
<zyga> cjwatson: ah, I understand what that may be now
<cjwatson> Maybe "ABI" is clearer
<zyga> cjwatson: I was thinking about allowing dependencies on a subset of current packages, specifically those marked as 'pure' (no maintainer scripts). The pure set would be garbage-collected with the root set being all the installed apps from the new model. The pure set might be applicable to some non-default libraries, static files, etc
<zyga> cjwatson: but this is not for the tablet / phone target, more like a liberal view of what packaging of desktop might look like later
<cjwatson> The problem with using system package names in this is that you can very easily end up needing to scan the system dpkg database
<zyga> cjwatson: dpkg being slow, you mean?
<cjwatson> Indeed
<zyga> cjwatson: yeah, that would be a pain
<cjwatson> Which is why I'd prefer to have a separate namespace for ABIs applicable to app packages
<zyga> cjwatson: also, the new package format might be tuned to 'non-critical' stuff so it might not fsync that badly
<zyga> cjwatson: separate namespace makes sense, yes
<cjwatson> Eh, I just turned off fsync :-)
<cjwatson> Doing so made a very noticeable difference to overhead
<zyga> cjwatson: well, you may still want some 'fsync'-like thing for base os
<cjwatson> Base OS remains with dpkg
<zyga> cjwatson: a few years ago I toyed with something I called dpkg-connector
<cjwatson> This is absolutely not intended to replace dpkg
<zyga> cjwatson: basically a way for foreign system to tell dpkg that it installed something
<zyga> cjwatson: I know
<zyga> cjwatson: then dpkg would know about those new files and could be, eg, asked to remove that package
<cjwatson> Mm, I was trying to keep complexity down by keeping things separate.  The other thing is that we may be permitting multiple versions to be unpacked in parallel with symlink-flipping, which makes some sense with something like a multi-user tablets
<cjwatson> *tablet
<cjwatson> I suspect it may not be guaranteed to fit into dpkg's view of the world very well :)
<zyga> cjwatson: so while I installed a game through steam or some python code with pip, dpkg could see and remove that, it would also prevent clashes if files colided
<cjwatson> There are certainly plenty of possibilities
<zyga> cjwatson: yeah, multi version is interesting
<zyga> cjwatson: as are non-root and free-path usage in general
<cjwatson> There'll never be clashes in this model (well, assuming no dpkg package ever installs under /opt/apps.ubuntu.com/ or whatever)
<zyga> cjwatson: well, ideally, true
<cjwatson> Pretty much guaranteeably
<cjwatson> The above is the only caveat
<zyga> cjwatson: as for that, do you think stuff like SD cards are an issue
<zyga> cjwatson: eg, I want to install this game to SD cards and that game to root memory (or the system chose to do so)
<cjwatson> You mean installing some apps to phone memory and some to SD cards?
<zyga> cjwatson: yes
<zyga> cjwatson: then you'd need to either make /opt/apps.ubuntu.com a magic fs or allow for some flexibility
<zyga> cjwatson: I wonder if SD card story is at all specified for ubuntu touch
<cjwatson> I confess I haven't thought much about that; the model would make it moderately straightforward if we wanted to though, since the multi-version thing implies having apps run from symlinks
<zyga> cjwatson: so symlinks would glue that back?
<cjwatson> So it's not difficult to have symlinks into more than one all-the-apps type directory
<zyga> cjwatson: indeed
<cjwatson> (*handwave*)
<zyga> cjwatson: do you think that package model is bound to apps?
<zyga> cjwatson: so that people never have apps != packages
<cjwatson> can you rephrase?
<zyga> cjwatson: sure, sorry
<zyga> cjwatson: do you think that your proposal assumes that each thing being delivered by the new package format is a single application
<zyga> cjwatson: so non-app payloads and multi-app payloads are forbidden
<cjwatson> At present yes
<zyga> cjwatson: do you think there is value in having something like that back on the desktop?
<cjwatson> Well, the only thing stopping non-app payloads would be making sure they don't deliver a desktop file I suppose
<cjwatson> Multi-app payloads, not sure of the use case
<zyga> cjwatson: so that some things could be delivered this way later
<cjwatson> desktop file> or whatever the integration there is
<zyga> cjwatson: for non-app payloads, app management is an issue
<cjwatson> Right.  Somebody else's problem ;-)
<zyga> cjwatson: users would need to be presented with two views "what you see on the app launcher screen" vs "what you have installed"
<ogra_> cjwatson, that mail should probably go to the ubuntu-phone ML in parallel
<cjwatson> ogra_: feel free to forward/bounce it
<cjwatson> I don't wish to spread discussion across multiple lists though
<zyga> cjwatson: mulit-app, not sure but I know that many phone apps from single vendor really suffer (bigger than needed) because they cannot share anything
<zyga> cjwatson: it might be a niche use case, but I wanted to ask
<ogra_> done
<zyga> cjwatson: it's also a management problem a bit, when you want to remove application, like you currently do in the desktop, that removes, eg, other apps for some reason
<cjwatson> I think that's more data sharing than multi-app payloads
<cjwatson> I'd like to put that on the shelf for now though
<zyga> cjwatson: ok
<melodie> hello
<cjwatson> I would like to have some answer for that at some point, but probably not for 13.10
<zyga> cjwatson: one thing I'd love to see out of this is a way to see this system on the desktop eventually
<cjwatson> Sure, the buzzword is "convergence" :)
<zyga> cjwatson: not for everything but for some use cases and growing
<zyga> cjwatson: as it's far easier to grasp than current packaging, I suspect
<cjwatson> I'm sensitive to many desktop applications having necessarily much more complex structures though
<zyga> cjwatson: have you though about 'in-app purchase' so to speak, where you get one app but then get additinal slivers of data (magazines, levels) that are also downloaded and stored?
<melodie> cjwatson I am glad you are here, I have a question related to some bug reports around a gui admin program.
<melodie> may I ask ?
<zyga> cjwatson: I don't think that is the case, look at all the steam games, there are classes of apps that would just fit right in
<cjwatson> So I know it's something that not least my management would like to have - but I want to make sure it doesn't cause massive scope creep
<cjwatson> zyga: in-app purchase might fit into the broader project but not into my slice of it; ask aquarius
<zyga> cjwatson: I don't know how other platforms handle that, I suspect that in-app thingh is totally separate and the data they get is just not managed by the package system
<cjwatson> melodie: I'm likely to be a terrible person to ask about anything GUI
<zyga> cjwatson: ok
<zyga> cjwatson: in-app purchase is just the keyword, I'm not interested in the actual purchase path, just the data
<cjwatson> You could have the in-app-purchased data files be a click package, so you have com.valve.steam.half-life and com.valve.steam.half-life.more-guns, sure
<zyga> yeah, that might work
<cjwatson> However you'd have to be careful about lookup paths and such, since click packages aren't allowed to install integration points for other packages
<melodie> cjwatson there are bug reports still not solved since about 2010 or 2011 concerning jobservice which affect the use of jobs-admin, at the bugzilla. I'd be very happy and many other users too I'm sure if the devs would look at it closely. I thought I would drop a word about it at the ubuntu-devel mailing list : do you think it is a good idea ?
<cjwatson> (A core requirement is for them to be totally declarative)
<zyga> then the app could request that thing to be installed either at high (via the store) or low (download by itself and ask the package manager) level
<cjwatson> melodie: No idea, sorry
<melodie> cjwatson ok, thanks anyhow
<zyga> cjwatson: integration points?
<cjwatson> melodie: I mean I don't object to the mail as a moderator, but I don't know if it's useful
<zyga> cjwatson: also sandboxing might be an issue
<zyga> cjwatson: where com.vendor.app cannot see com.vendor.app.addon
<cjwatson> zyga: Well, if you want to have apps (or click packages, anyway) hooking into other apps, they'd likely need to link files around and stuff, the sort of thing that's done by hooks provided by system packages
<melodie> cjwatson I don't either, but I don't quite see what would be better to get someone have a close look there
<zyga> cjwatson: I don't thing links are needed
<cjwatson> (so, say, we might have a dbus-service hook that lets you link files into /usr/share/dbus-1/services/ so that dbus-daemon can see them)
<zyga> cjwatson: perhaps enumeration of some sort
<zyga> cjwatson: ah
<zyga> cjwatson: I see what you mean
<melodie> cjwatson do you know of someone in the Ubuntu dev team who I could try to join preferably ?
<cjwatson> and packages typically don't want to enumerate some not-specified-up-front list of directories looking for files - it's an awkward thing to do
<zyga> cjwatson: it's easy to stray to related but not quite same fields in this conversation
<cjwatson> melodie: perhaps James Hunt can help, though he doesn't seem to be around right now
<zyga> cjwatson: no, I meant, eg, some game wanting to enumerate its add-ons
<cjwatson> (jodh)
<cjwatson> zyga: Right, but I think it's a similar problem
<melodie> cjwatson I'll keep his name in mind. thank you
<zyga> cjwatson: where the game knows the add-on identifier
<zyga> cjwatson: 'eg com.vendor.game.add-ons'
<zyga> cjwatson: and each packaged thing can declare to be that
<cjwatson> I suppose since we're using a reversed-internet-domain scheme for app names we can have a facility to enumerate things under a domain
<zyga> cjwatson: anyway, I don't want to steal your time, I'm looking forward to the UDS conversation
<cjwatson> don't worry, this is interesting even though I don't have all the answers (and don't expect to)
<zyga> cjwatson: having a rev-domain might be security issue though
<cjwatson> Yeah, well, it depends on how you're using the results of the enumeration
<zyga> cjwatson: eg, can anyone distribute packages that hook into my domain?
<zyga> yeah, exactly
<zyga> internal vs public
<zyga> it's also interesting on the desktop a bit
<zyga> or actually
<zyga> on the shell / cli
<zyga> cjwatson: imagine where shell you get is empty, and you install apps into your profile explicitly
<zyga> cjwatson: and apps only declare what they provide (commands)
<zyga> cjwatson: scripts are tricky then (they would need to 'pull in' commands given some long / unique ID)
<zyga> cjwatson: but namespace clashes
<zyga> cjwatson: and general mess of command line might be eventually cleand up
<cjwatson> Yeah, right now I don't see this working very comfortably for tools you run from the command line
<zyga> cjwatson: yeah
<cjwatson> You'd either need a ridiculous path or some proprietary shell extension
<cjwatson> That said, nothing to stop a system hook linking script-like commands into a single directory
<zyga> cjwatson: /*/bin/ would likely remain as it is forever for compatibility
<cjwatson> Namespacing would make the names awkward though.  I don't think you really want to invoke com.ubuntu.shiny-command from a shell
<zyga> cjwatson: but then you could use app store app to add 'some-tool' into your profile
<cjwatson> As I say, I don't actually feel the need to solve all problems with this :)
<zyga> cjwatson: scripts would, you would import the short name of your choice
<zyga> cjwatson: :)
 * zyga has a brainstorm inside his head
<cjwatson> I mean, I'm OK with confining this to solving a smaller problem well if that's what it takes to keep the scope manageable
<zyga> cjwatson: I fully understand that
<zyga> cjwatson: I'm just excited to see that topic being touched and the possibilities it opens down the road
<cjwatson> Not that I want to shut down discussion; but perhaps a sensible division is to think about things that aren't currently being reasonably well-served
<zyga> cjwatson: I think what you mentioned in your email is a great start: no deps/no conflicts, confined directories, new package / install tools
<cjwatson> (proprietary shell extension, above> by which I mean proprietary as in "our own", not as in licensing)
<zyga> cjwatson: :-)
<zyga> cjwatson: I would see that as a patch to [db]ash eventually but perhaps as a symlink farm now (shell stuff)
<zyga> anyway
<cjwatson> I do expect to take some heat given that there are other tools like this out there, the why-didn't-you-just-contribute-to-them thing
<zyga> cjwatson: do you keep the code in any project yet?
<zyga> cjwatson: yeah, I think what you are doing is okay
<zyga> cjwatson: other tools usually birng impedance
<zyga> cjwatson: and might diverge in goals later
<cjwatson> Still open to using something else if it's sufficient; the problem as I saw it was that they were all kind of 50% solutions so it wasn't clear it would actually help either us or them
<zyga> cjwatson: though we should look at reusing ideas and maybe forking something if that saves time
 * zyga checks your email again
<cjwatson> It will be in the click-package project; just trying to get the proof of concept slightly less PoC-y first
<cjwatson> There will definitely be branches there before UDS
<zyga> cjwatson: as for existing systems, is there anything other than android that you looked at?
<zyga> cjwatson: it might be good to enumerate all existing solutions (including those that we cannot use at all, eg, proprietary stuff)
<zyga> cjwatson: I'd love to help with that if you want
<cjwatson> I mentioned several briefly in my mail
<cjwatson> I would definitely appreciate help with a better competitive analysis
<cjwatson> I looked through most of the mobile app store packaging formats I could find
<zyga> cjwatson: I guess one thing that is blurry is if this is really defining the packaging system (however app centric as it may be) or actual applications themselves
<cjwatson> android, tizen basically zip files with varying layouts and manifest files specific to their requirements; sailfish seems to be RPM though I couldn't find the specifics; iOS I did look at briefly although the answer does not appear to have stuck in my head
<zyga> cjwatson: that's about right
<zyga> cjwatson: to be fair I'd use zip as well
<cjwatson> I think we definitely want fairly strong conventions for how things like QML and HTML5/CSS apps for the phone/tablet are laid out
<zyga> cjwatson: deb == ar + tar + compression
<zyga> cjwatson: and that sucks for some purposes
<zyga> cjwatson: zip is rather better in general
<zyga> cjwatson: agree on conventions
<zyga> cjwatson: eg, random access
<zyga> cjwatson: also pure python solution is easy to build on top of zipfiles
<zyga> cjwatson: have you thought about delta updates
<zyga> cjwatson: on the desktop that's not used in practice (in ubuntu at least)
<cjwatson> don't really care about random access and pure python solution is easy either way
<zyga> cjwatson: but on the mobile with lots of data vs little code it might be essential
<zyga> cjwatson: well, zip's do both
<zyga> zips
<cjwatson> (tarfile is built into the python stdlib and writing ar is ~100 lines)
<zyga> cjwatson: ar is not
<zyga> cjwatson: well yeah
<cjwatson> it's trivial
<zyga> cjwatson: I know, had to do it too
<zyga> cjwatson: still, what is the value of looking like a deb?
<zyga> cjwatson: that dpkg -i can (perhaps) install it?
<zyga> cjwatson: it will probably bork unless you also plan to ship DEBIAN in each package
<cjwatson> more that it reduces impedance mismatch with other tools we already have
<cjwatson> I have deliberately arranged that dpkg -i will refuse, but you can use dpkg -c and so on
<zyga> cjwatson: so what existing tools would be able to work with the new-format packages?
<cjwatson> I don't think the container format is really a desperately big deal either way
<cjwatson> honestly
<zyga> cjwatson: it might be, it really depends on where it is used
<zyga> cjwatson: delta updates, store indexing, etc
<cjwatson> it just meant I got to use dpkg to unpack and that means that if we need to do things like in-place upgrade in the future then it's a trivial matter rather than having to write a bunch of new very delicate package management code
<zyga> cjwatson: it's not a deal-braker but a good format definitely helps
<cjwatson> I trust dpkg for that kind of thing way more than anything I might write
<makara> i created a lunar clock in python. I want to add it to Ubuntu Unity taskbar. How 2 do?
<zyga> cjwatson: dpkg supports in-place upgrades?
<cjwatson> er, kind of obviously
<zyga> cjwatson: IIRC it still unpacks stuff on the side
<zyga> cjwatson: then replaces
<zyga> cjwatson: that's not in-place
<cjwatson> no, I mean in-place as opposed to click-package's current intended model of unpacking each version in a totally separate directory and re-symlinking
<zyga> cjwatson: you can run out of space
<zyga> cjwatson: ah
<zyga> cjwatson: I see
<zyga> cjwatson: I think that dpkg is too crazy for that, eg, all the failure modes, package states
<bhavesh> makara, #ubuntu-app-devel for Ubuntu application development :)
<cjwatson> you're mistaken; basically all the failure modes there relate to maintainer scripts
<zyga> cjwatson: and all the integrity in dpkg, if you drop all the package states, is just fsync
<cjwatson> nonsense
<zyga> cjwatson: yes
<zyga> cjwatson: but maintainer scripts cause all the package states
<zyga> cjwatson: otherwise there would be none
<cjwatson> dpkg had excellent integrity for many years before it started being forced to use fsync by hostile filesystem implementations
<cjwatson> fsync is a red herring
<zyga> cjwatson: after all, in the end you just unpack the container into the filesystem
<zyga> cjwatson: done, ditto
<cjwatson> you also need to keep track of which files to clean up afterwards, you still need to do the rename-over-the-top anyway otherwise you can have problems with executables in flight, etc.  all problems dpkg solved many years ago.
<cjwatson> no point redoing any of that
<zyga> hmm
<zyga> clean up - maybe not - depends on how you structure
<cjwatson> it's simply not a problem I'm interested in re-solving
<zyga> rename-over-the-top - can you explain?
<cjwatson> open(2)
<cjwatson>        ETXTBSY
<cjwatson>               pathname refers to an executable image which is currently being executed and write access was requested.
<zyga> ah
<zyga> interesting
<zyga> I wasn't aware that existed
<cjwatson> dpkg is correct about many things most people have had no need to think of :)
<zyga> cjwatson: I was aware of some of the things dpkg was doing
<zyga> cjwatson: but some of those are the fauls of the system design
<zyga> cjwatson: and dpkg is still doing a non-solution
<zyga> cjwatson: eg, ripping libraries / data underneath from an app
<zyga> cjwatson: firefox updates
<cjwatson> (can you press enter slightly less frequently?  this is a bit overwhelming)
<zyga> cjwatson: none of that _has to happen_ it just does because of what dpkg was designed to install
<zyga> cjwatson: sorry, I guess I should get back to my usual work now
<cjwatson> no, just having trouble keeping up :)
<cjwatson> so, you either do what dpkg does, or you have problems with ETXTBSY, or you end up with intermediate states where files are only half-written (IME one of the worst possible outcomes), or you unpack into completely separate directories and avoid all those problems at the cost of a bunch more space at least transiently - all the options have their problems
<cjwatson> the only two viable ones IMO are completely-separate-directories and what dpkg does, and I'd like to leave the door open to having the choice between them in future, because dpkg's approach is likely to be better than completely-separate-directories for very large apps
<zyga> cjwatson: I see your point
<zyga> cjwatson: I suspect that a higher-level solution is needed though
<cjwatson> (well, OK, it's probably also possible to have a mess of special cases where e.g. you defer removing files, but I would prefer not to go there if possible)
<zyga> cjwatson: eg, telling app to stop for update, ensuring it really is, doing some in-place update from partial download, etc
<zyga> cjwatson: full-copy app update is probably going to be cost prohibitive, you'd have to write O(N) bytes for each O(1) change, flash burns out
<cjwatson> That kind of thing makes sense in a phone model; not sure it's good for convergence later
<cjwatson> I do want to do delta updates, but it won't make the first cut.  The main thing we need to ensure up front is just that we're using something like an rsync-friendly compression method in case we want to go that route
<cjwatson> Which reminds me, is it possible to do an equivalent of gzip --rsyncable in Python directly or do I need to use a gzip subprocess?
<zyga> cjwatson: I'm not sure, I never needed to do that. I suspect yes but manually by creating separate blocks on rsync boundary
<zyga> cjwatson: but I suspect that rsync won't really be what you want to do in the end, code updates are not costly, assets are, and those are replaced, you only want to compress and send the files that are being changed. Trying to do in-file delta updates feels like a waste of effort, especially if it entails rebuilding a full package to install, locally
<zyga> cjwatson: my point being that you probably want to ensure that you can send an efficient representation of ver-to-ver change and install _that_ rather than trying to rebuild the package locally
<zyga> cjwatson: even if you really rsync a package from a remote server having that same package installed
<cjwatson> Indeed.  Given I'm using deb I suspect I might find that debdelta is a pretty close approximation of what I want
<zyga> cjwatson: debdelta rebuilds debs locally, doesn't it?"
<cjwatson> I'm not sure that's required, but haven't really looked yet
<zyga> cjwatson: so I do see a lot of value for research on top of dpkg, I'm still sceptical if that's the right choice in the end, the same as with other existing systems, it may just be not close enough after all the requirements are assembled
 * zyga needs to switch to another topic
<zyga> cjwatson: sorry for taking that much of your time, I'll see you at the vUDS :-)
<cjwatson> Partly I will admit that I wanted to demonstrate that most of the performance and reliability problems with dpkg are not inherent
<cjwatson> xnox: ed can be synced, I think?
<sergiusens> infinity: question, have you started with the bionic based armel cross toolchain?
<pitti> slangasek: replied to bug 1177828
<ubottu> bug 1177828 in systemd (Ubuntu) "no ACL set for USB sound device after upgrade to saucy" [Undecided,New] https://launchpad.net/bugs/1177828
<slangasek> pitti: thanks
<stgraber> pitti: FWIW, I seem to be getting the same kind of problem here after suspend/resume
<pitti> stgraber: missing ACLs? for what kind of dev?
<stgraber> pitti: I have working sound before suspending and no sound after resuming. Pulse still lists the soundcard but no sound comes out. Restarting pulse only gets me a dummy output.
<pitti> oh, fun
<pitti> stgraber: this is an internal sound card, or also USB?
<stgraber> pitti: internal
<pitti> stgraber: again, udevadm info --export-db output would be helpful (if possible, before/after suspend)
<infinity> sergiusens: Haven't started looking at it yet.  I've been dead with some sort of ubuflu since the sprint.
<stgraber> pitti: gah, can't reproduce the bug anymore... just did a couple of suspend/resume and the ACLs are fine and sound works...
<sergiusens> infinity: ack, no problem, just wanting to organize my work :-)
<stgraber> oh, actually, could have been something else as I remember that I rebooted the machine to fix it (had a call so didn't have much time to figure it out) and noticed that my user wasn't allowed to reboot the machine (dropping back to lightdm instead), so maybe it was something wrong with logind then...
<pitti> I might have botched the uaccess backport in udev in some way
<pitti> stgraber: that sounds like "no foreground session" indeed
<pitti> slangasek: actually, it seems I get no ACLs on my scanner when plugging it in; that might be the same problem; the device has the "uaccess" tag, but doesn't get an ACL
<pitti> I guess it's time to bite the bullet and upgrade to current udev
<pitti> (the main obstacle is that we accumulated a set of patches which are nontrivial to forward-port as they have very little explanation and have never been forwarded upstream either)
<pitti> but as an intermediate step I might just put it into a PPA without these
<slangasek> I don't see how that's a useful intermediate step.
<pitti> for re-testing this bug
<slangasek> I'm certainly not going to run a udev that drops the distro patches on the floor
<pitti> not all of them of course, mostly just avoid-exit-deadlock-for-dm_cookie.patch and avoid-exit-deadlock-for-timely-events
<slangasek> yeah, those are absolutely not patches I'm going to be running without
<slangasek> I fully expect I would hit those deadlocks if I did
<pitti> ok, your udevadm output looks like my scanner situation - uaccess tag set, but no ACL applied
<roaksoax> slangasek: howdy! I wanted to check with you how likely is this to be approved for SRU? We need celery in main for the MAAS SRU (precise), and in Quantal, we needed to drop the dependency. https://launchpad.net/ubuntu/+source/celery/2.5.3-1ubuntu1
<psusi> cjwatson: I'd like to resync the debian and ubuntu parted packages... would you sponsor an upload to debian, and if so, what format would you like it in?  a git patch against the debian git repo I assume?
<slangasek> roaksoax: I'm not sure I understand the question.  Are you proposing pushing that same version of celery from quantal to precise?
 * pitti waves good night, see you on Friday (public holiday tomorrow)
<roaksoax> slangasek: Sorry, not the same version, just the same patch we applied to celery in quantal
<roaksoax> slangasek: so I want to SRU this: http://launchpadlibrarian.net/109389843/celery_2.5.3-1_2.5.3-1ubuntu1.diff.gz
<cjwatson> psusi: some kind of git patches or git bundle or something, yeah
<psusi> cjwatson: should I break it into one commit per patch then instead of just one big merge of all ubuntu patches?
<slangasek> roaksoax: the purpose of this is to remove the out-of-main build-dep on celery, so it can be moved to main in precise-updates to enable maas to use it in precise?
<roaksoax> slangasek: yes
<cjwatson> psusi: Yes please
<cjwatson> With updated justifications in patch headers where necessary
<slangasek> roaksoax: and this change is needed for the maas SRU that's already been done, or for another upcoming one?
<psusi> ok... then bundle it will be
<roaksoax> slangasek: for the MAAS SRU (it hasn't yet been released)
<slangasek> roaksoax: yes, I'll accept that change
<roaksoax> slangasek: ok awesome! I'll get it done then! Thanks!
<halfie> In Ubuntu 13.04 hardening is not enabled for LibreOfffice package. Any ideas why?
<halfie> Debian seems to have hardening support in LibreOffice package
<cjwatson> Sweetsha1k: ^-
<roaksoax> slangasek: Uploaded to precise-proposed! Thanks again!
<halfie> what is the output of "dpkg-buildflags --get CPPFLAGS" on Ubuntu 13.04 AMD64 system?
<cjwatson> halfie: -D_FORTIFY_SOURCE=2 - same as on Debian (wheezy or sid)
<halfie> cjwatson, I am talking about PIE and RELRO options
<halfie> cjwatson, ohh I see. thanks!
<halfie> cjwatson, would you happen to know if PIE and RELRO are enabled in Debian's LibreOffice?
<cjwatson> those are in CFLAGS.  I think you may be seeing a change made by the Debian maintainer that became visible to you in Ubuntu first
<cjwatson> no
<cjwatson> but the revision history kind of suggests the explanation above ...
<cjwatson> however, I highlighted Sweetsha1k above who should know better than I do
<Daviey> infinity: funnily enough, i am looking at python-testtools already.
<ricotz> jamespage, hi :), it would be great if you could look into updating libunwind -- https://launchpad.net/~ricotz/+archive/staging/+sourcepub/3185829/+listing-archive-extra
<infinity> Daviey: Huzzah.
<infinity> cjwatson: So, now that we have component-mismatches-proposed (and it APPEARS to be accurate), just how much pain do you think it would be to make britney's installability checks take component into account, so we avoid pre-MIR migrations?
<infinity> cjwatson: I fear the brute force method would be multiple britney runs at each level of the ogre model, but there must be a more clever way.
<Daviey> infinity: python-testtools dropped from main as it became unseeded, but based on bug 1108897 i am going to change it now.
<ubottu> bug 1108897 in python-extras (Ubuntu) "[MIR] python-extras" [Undecided,Fix released] https://launchpad.net/bugs/1108897
<Daviey> err, python-extras
<infinity> Daviey: Oh, shiny, I didn't realize it had been previously MIRed.
<infinity> Daviey: component-mismatches might need to look for fix released MIR bugs too...
<infinity> Daviey: I suspect the new puppet deps might be slightly less simple.
<Daviey> infinity: I probably can't make that a priority this week, with the sprint and all.. but will certainly file a holding bug.
<infinity> Daviey: Sure.  Or just find one of your minions who looks bored and make them do a bit of MIR paperwork. ;)
<Daviey> infinity: Team Coca doesn't get bored. :)
<infinity> Daviey: Did you already promote python-extras?  If not, I'll do it right now.
<Daviey> infinity: i did
<infinity> Hrm, weird.  I don't see the pending publishing record.
<Daviey> infinity: hmm, best wait a little?  changing twice in one publisher run is bad, right?
<infinity> Only in weird corner cases.
<infinity> But yeah, I'll wait and tidy up later if something went sideways.
<infinity> Don't worry about it.
<halfie> which package provides "dpkg-buildflags"? Installing dkpg-dev didn't do any good
<geofft> a newer version of dpkg-dev. :)
<zerwas> halfie: you can always check which file is in which package on which distribution version on http://packages.ubuntu.com/
<halfie> zerwas, thanks!
<halfie> geofft, I am using the latest version of dpkg-dev
<geofft> are you running an old release? it's new as of 1.15.7, which postdates e.g. lucid
<halfie> gema, I am running 13.04 which was just released
<halfie> I will reinstall the package. might help
<infinity> halfie: /usr/bin/dpkg-buildflags is shipped in dpkg-dev, what is the actual error you're seeing?
<halfie> infinity, trying to reinstall that package. dpkg-buildflags file is missing.
<infinity> As in "ls /usr/bin/dpkg-buildflags" returns "No such file or directory", or some higher level error (in, say, a Makefile) is making you believe it's not there?
<sarnold> halfie: you may wish to instead pastebin the -actual- error you're getting..
<infinity> I mean, I suppose it's possible you accidentally deleted it, but that seems pretty unlikely in the general case. :P
<halfie> figured out the problem, "sudo aptitude install dpkg-dev" says that it failed to download one specific package (g++) but still aptitude proceeds with unpacking and setting up files.
<halfie> it should have quit right away
<infinity> Yet another nail in the "why use aptitude?" coffin.
<halfie> heh, that is the first thing i install :( old habits
<infinity> apt-get's resolver tends to be saner these days.  I can't actually come up with a good reason for aptitude.
<infinity> But everyone has their preferences.
<geofft> I use aptitude to get a more verbose error message out of dependency resolution than apt-get is willing to give me.
<geofft> Also search syntax.
<infinity> Yeah, well, I suspect many people would discount my opinion straight up because I still prefer dselect over aptitude (though I don't use either anymore).
<halfie> geofft, +1 I use it for search feature
<sarnold> dselect? eww :)
<geofft> dselect still _works_?
<sarnold> I'd be surprised if anything changed to break it. hehe.
<infinity> dselect may not be entirely multiarch friendly, but then again, aptitude's still lacking in that area too, in some ways.
<infinity> On single-arch systems, dselect still resolves more sanely and makes me less sad than aptitude.
<infinity> (But, like I said, I don't use either anymore, I've come to terms with reading apt-get/apt-cache output)
<doko> apw, your fix for the linux-mako issue is building. would be worth to know if current arm kernels are functional when built with 4.8
<apw> doko, thanks, yeah that is on my list to check
<mterry> pitti, is logind's Lock() method supposed to work?
<mterry> I try to poke it via d-feet and I get an AccessDenied error
<mterry> (I mean, obviously it is supposed to work, just curious if it's a known problem)
<doko> xnox, you might want to give some insight about build failures for debian #704032
<ubottu> Debian bug 704032 in release.debian.org "transition: boost-defaults 1.53" [Normal,Open] http://bugs.debian.org/704032
<infinity> doko: That gcc-4.8 upload included the dropped locales build-dep.  You might want to remember to turn that back on.
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<stokachu> cjwatson: is there any plans in the near future to enable grub-installer support for grub's cryptodisk?
<stokachu> ref: bug 1062623
<ubottu> bug 1062623 in grub-installer (Ubuntu) "enable grub-2.00 boot-from-luks support" [Undecided,Confirmed] https://launchpad.net/bugs/1062623
<roaksoax> 4/win 8
<evfool> hi all, on a normal ubuntu install, what should set the DISPLAY environment variable for unity?
<evfool> I have a problem of unity not starting by default on 13.10, I have to get to another tty and start it manually, and it complains that DISPLAY is not set
<sarnold> evfool: :0 on my laptop, though local configuration may cause it to be different.. (say, start several X servers..)
<evfool> sarnold: I know that :0 should be the value, but whose responsibility is to set it? should it be set by lightdm?
<sarnold> evfool: lightdm seems likely to me, but I'm not positive
<evfool> robert_ancell, could you please help us out with this?
<roaksoax> 3/win 8
<branchman2> hello, could someone post me contents of his /proc/modules file? (I wonder, whether it is correct to have so many forced modules)
<sarnold> branchman2: http://paste.ubuntu.com/5646071/
<infinity> branchman2: They're not forced, they're loaded by udev based on what hardware you have and what services/filesystems/etc get requested from userspace.
 * sarnold idly wonders why he has xfs and btrfs modules loaded...
<infinity> sarnold: Dunno.  I don't.
<branchman2> sarnold: thanks, it is exactly like for me - that (F) means forced loading
<branchman2> sarnold: I have it too, somehow
<infinity> In fact, you have a ton of filesytem modules loaded.  Curious.
<branchman2> infinity: yes, but should they get (F) there? It is like insmod --force, that can cause problems with compatibility
<sarnold> infinity: hrm. I may need to look into this non-idly at some point :) that could be a fair bit of unswappable memory on a more constrained system than mine..
<infinity> Ran some sort of prober that loaded them all?
<sarnold> infinity: I did plug my sony reader into usb a few weeks back, perhaps something probed those devices for all the filesystems?
<branchman2> sarnold: it is not about device - I have plugged no USB devices since boot and I have that modules too
<roaksoax> ./win 8
<geofft> grub-install probes a bunch of filesystem modules.
<infinity> branchman2: I'm not sure that F means what you think it means.
<infinity> branchman2: I'd have to dig into the source, but I can't fathom that it means anything was force-loaded.
<branchman2> infinity: what it means, then? I am just finding a reason, why it writes me, that kernel is tainted - and I have some oopses and friend advised me to get rid of that tainted flag caused by forcibly loaded modules (I have empty /etc/modules)
<geofft> Anything that taints the kernel should print a message indicating what it was, IIRC.
<geofft> what are your taint flags?
<infinity> branchman2: Taint has nothing to do with forced loading, it has to do with licenses of modules.  fglrx, nvidia, etc.
<branchman2> geofft: GF
<geofft> Ah, that _is_ all-GPL'd modules plus forced loading, okay
<branchman2> infinity: according to manual, F tainted flag really means forced loading
<geofft> infinity: Taint is a lot of things. Usually the taint I see is the "dead" flag (previously oopsed)
<infinity> Erm, it also doesn't help that we taint pretty much the world due to not signing modules now.  Whose bright idea was that, I wonder?
<branchman2> infinity: sorry, do you request more info? I don't understand such clearly
<infinity> See http://lkml.indiana.edu/hypermail/linux/kernel/1301.2/00125.html
<infinity> branchman2: See above.  Your taint and (F) is coming from us not signing modules (and not requiring them to be).
<infinity> This is a pretty questionable upstream behaviour, IMO.
<branchman2> infinity: oh, I see - it is *very* questionable
<branchman2> infinity: thanks for noting it
<infinity> apw: Have any opinions on that?
<infinity> apw: Thanks to us not enforcing or requiring module signatures, half the world is given a TAINT_FORCE flag.
<infinity> apw: Which is, I suppose, not world-ending, but confusing and a bit wrong, IMO.
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> stokachu: it's an excellent idea but I don't know when I'll have time for it
<stokachu> cjwatson: not a problem just wanted to make sure it wasn't already done and i missed it somewhere
<cjwatson> I think there may still be a patch in grub2 itself that I need to drop (and test the result) too
<cjwatson> mkconfig_skip_dmcrypt.patch
<cjwatson> At the very least it probably wants to be a bit smarter nowadays
<stokachu> yea seems like there are a few moving parts to this working properly
<stokachu> i think infinity said he wanted to re-write grub-installer in perl to make it "smarter" :PPP
<cjwatson> That would be quite a feat considering that it runs in d-i which doesn't have perl.
<stokachu> perl doesnt need perl to run :X
<cjwatson> Anyway one of these days I'll probably decide it's time to drop GRUB Legacy support from grub-installer (I've been opposed to that in the past, but times change ...), which will get rid of the worst of its complexity.
<stokachu> ah ok
<stokachu> cjwatson: last question, would it be safe to assume this type of feature is a no-go for precise if requested
<cjwatson> (Hmm.  There's still a claim that multipath requires legacy.)
<cjwatson> stokachu: Definitely, given that precise's grub2 didn't have cryptodisk support.
<cjwatson> That would be an unacceptably enormous backport, I think.
<stokachu> understood, this gives me a better idea to handle a few requests :)
<infinity> pitti: Say, remember when we had a conversation long ago about making ddebs be empty packages that depend on -dbg packages, for sources where the -dbg package (or packages) is/are fully populated?
<infinity> pitti: That might not be a bad idea now that we're about to stuff ddebs in the librarian.
<cjwatson> Even the initial basic support was a 4000+-line patch, and that's without looking at any extra commits it would depend on or the further improvements that have been applied since.
<cjwatson> (It wouldn't surprise me if it depended on lazy device scanning, for example, which is complex and intrusive.)
<stokachu> wow
<infinity> It's funny how quickly one goes from learning about a feature in software to deciding it needs fixing.
<stokachu> yea im going to be pretty firm on these feature requests
<infinity> (Last Monday, I didn't even know that lesspipe handled debs, today I realized it doesn't do ddebs and *had* to fix it... Stupid OCD)
 * infinity giggles at update_excuses today:
<infinity> Depends: rainbows unicorn (not considered)
#ubuntu-devel 2013-05-09
 * Fudge enjoys reading your conversations guys
<hdon> hi all :) can anyone tell me how to get Ubuntu's patches for gcc 4.7 in ubuntu 12.10 ? i don't have ubuntu 12.10 i have ubuntu 12.04
<RAOF> hdon: You can install the ubuntu-dev-tools package, which contains pull-lp-source, which you can run as âpull-lp-source gcc-4.7 quantalâ, which will get you the source package for gcc-4.7 in 12.10.
<hdon> RAOF, perfect answer. thanks!
<RAOF> I might have the order of the pull-lp-source arguments around the wrong way, but it should be fairly obvious if I've done that :)
<ScottK> The syntax is correct.
<lifeless> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-image-based-updates is very interesting to us (openstack-on-openstack) - we're heading that way anyway to do operations at scale.
<lifeless> slangasek: it might be nice if we can collaborate somehow
<slangasek> lifeless: perhaps you could discuss with stgraber next week during UDS?  (If those times work)
<lifeless> slangasek: I'll try, I'm in CA next week, so it may work well...
<lifeless> slangasek: if I can't I'll get someone else on the team to chat
<slangasek> lifeless: great :)
<lifeless> slangasek: where is the schedule ?
<slangasek> lifeless: http://summit.ubuntu.com/uds-1305/; the foundations track for some reason hasn't autoscheduled yet though, looking at this now
<lifeless> kk
<lifeless> slangasek: I can't do monday, as I fly in on Monday
<slangasek> the sessions are Tue-Thu anyway
<slangasek> ah, evidently I misread and there's no autoscheduling
<slangasek> hand-scheduling it is, then
<slangasek> lifeless: provisionally scheduled for Tuesday, if that's ok
<lifeless> slangasek: cool; what time?
<slangasek> lifeless: 1800UTC
<lifeless> slangasek: so, 11am in CA I think?
<slangasek> yes
<lifeless> slangasek: cool, I should be able to do that.
<lifeless> \o/
<infinity> slangasek: Hrm, if you're manually scheduling, can you do specless meetings too?
<slangasek> infinity: technically yes, but at the moment I'm heading to bed.  Shoot me an email with details? Or create a spec? :)
<infinity> slangasek: I was going to register a pointless spec for "review the release schedule with flavor leads and interested parties", but since it's likely to generate zero work items, a meeting would be easier.
<infinity> slangasek: I'll email.
<infinity> slangasek: Done.
<lifeless> smoser: where is the right place to report bugs on cloud images?
<smoser> lifeless, if its not a pakcage, file just in ubuntu and tag a s 'cloud-images'
<smoser> and subscribe utlemming and i
<lifeless> smoser: thanks. the thing is that 'vga=normal nomodeset' is needed on the kernel command line to not break ILO's.
<lifeless> smoser: I consider unbreakme options bugs :>
<smoser> i think you dont need vga=normal
<smoser> i think the nomodeset is enough
<lifeless> smoser: what package would need to change to make nomodeset not be needed on Ubuntu server?
<lifeless> by default, not by grub setting it.
<lifeless> smoser: filed https://bugs.launchpad.net/ubuntu/+bug/1178115 for you
<ubottu> Launchpad bug 1178115 in Ubuntu "nomodeset is needed on server environments for ILO to be usable" [Undecided,New]
<lifeless> smoser: enjoy :)
<mitya57> pitti: FYI, I've just uploaded mathjax 2.1 to sid (so calibre is no longer blocked)
<zyga> cjwatson: hi
<mitya57> hi Mirv, is that expected that we don't have a qtbase5-doc package?
<zyga> cjwatson: lots of interesting feedback on your proposal so far
<cjwatson> Yes
<zequence> stgraber: I suppose you are the guy who makes this happen? http://people.canonical.com/~stgraber/package_sets/saucy/ubuntustudio
<zequence> stgraber: I guess some packages don't need to be there, like automake1.7? No problem for me. But, everything we use otherwise should be there, right (i.e. nothing is missing)?
<zequence> bwt, is there some place where flavor developers could put cron job scripts, to check up on things, and then if something interesting was found, mail that to a mail list? I'm thinking of setting things like this up for Ubuntu Studio
<cjwatson> if automake1.7 is there it's because something in ubuntustudio is (directly or indirectly) using it, but the core system isn't.
<mitz> t
<mitya57> Mirv: ping (if around)
<jdstrand> jodh: hi! what is the status of cgroups in upstart?
<tseliot> ogra_: I have updated nvidia-graphics-drivers-tegra3 and nvidia-tegra-codecs-cardhu to the latest release in this PPA (in case you want to upload them in saucy): https://launchpad.net/~canonical-x/+archive/x-staging
<jodh> jdstrand: still at the consideration stage. do you have a use-case?
<jdstrand> jodh: I think they might become quite interesting for application lifecycle. ted blogged about gould.cx/ted/blog/Application_Centric_User_Experience, which is something we can do immediately
<jdstrand> jodh: if apps are launched via users like this, that provides a place for resource monitoring and controls
<jdstrand> jodh: which the application lifecycle guys are likely interested in
<jdstrand> jodh: I was more just curious. I saw something on the mailing from scott on how it might work and didn't know if anything came of it
<jodh> jdstrand: right. The plan this cycle is to work on section 2.3 of https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html. Have to see if we can stretch as far as 2.3.3 :-)
<stgraber> jdstrand: IIRC what we discussed back at the sprint is to simply have the pre-start stanza of the job create the new cgroup and move itself to it
<jdstrand> jodh, stgraber: ack, thanks
<cjwatson> jdstrand: iptables is in the merge-blacklist (a text file only on the merges.ubuntu.com master machine which causes it to silently ignore merges - I hate it, but haven't got rid of it yet), so it's well behind Debian.  Do you have any idea if there's a particular reason it shouldn't normally be merged?
<cjwatson> I'm sort of guessing that at one point it broke MoM, but I don't actually know
<jdstrand> cjwatson: no, not otoh. there is definitely a delta that we want to keep, but I don't see why we would not want to include it in MoM
<jdstrand> err merges.ubuntu.com
<cjwatson> Yeah, that's what I thought
<cjwatson> I've kicked it out now, so with any luck it'll appear on merges.u.c in the next run
<jdstrand> cool, thanks :)
<cjwatson> (or else it'll crash and I'll cry)
<jdstrand> heh
<sonne> just wondering: any reason why there isn't a package for libxenapi?
<Riddell> cjohnston: I made a session, how do I subscribe people and get it scheduled? http://summit.ubuntu.com/uds-1305/meeting/21779/kubuntu-and-uefi-and-lts-backports/
<cjohnston> edit meeting to subscribe people, and ask the track lead for scheduling
<Laney> does it need to be client-s-?
<Laney> or whatever the prefix is
<sonne> libxenserver, pardon
<cjohnston> since it was created in summit and not as a blueprint, no
<Laney> sweet
<Riddell> cjohnston: what if the people don't appear in the people list?
<cjohnston> Riddell: then tell them to register
<Riddell> cjohnston: how do I find out the track lead?
<cjohnston> the emails that have been sent out, summit, fridge, planet, etc
<Riddell> cjohnston: how come the track lead for foundations is on holiday during uds?
<cjohnston> I don't make the rules
<Riddell> slangasek: could you schedule http://summit.ubuntu.com/uds-1305/meeting/21779/kubuntu-and-uefi-and-lts-backports/ before 17:00UTC on any day?
<cjohnston> slangasek: if your on vacation next week, should we have another track lead?
<slangasek> cjohnston: yes, I've already asked mhall119|away to make cjwatson and bdmurray the track leads, but it seems this isn't done yet - could you take care of it?
<slangasek> Riddell: scheduled for Wednesday
<Riddell> slangasek: thanks
<Riddell> cjwatson: are you registered for UDS?  I didn't see you in the people I could subscribe
<cjohnston> slangasek: neither are registered.
<slangasek> cjohnston: they have to be registered to be made the track lead?
<cjohnston> yu
<cjwatson> Riddell: yeah, I just remembered from the above conversation that I needed to ...
<cjohnston> p
<slangasek> yeesh
<slangasek> bdmurray: ^^ please register for UDS :)
<bdmurray> slangasek: done
<cjwatson> clearly we suck
<cjwatson> Riddell: FWIW the problems you blogged about look awfully like the ones that Steve McIntyre fixed at the 11th hour before wheezy
<Riddell> cjwatson: uefi ones?
<cjwatson> Yeah, specifically Debian #698914
<ubottu> Debian bug 698914 in grub-efi "grub-efi booting Windows 8 in UEFI mode" [Serious,Fixed] http://bugs.debian.org/698914
<cjwatson> I pulled half that fix into saucy today - other half is bug 1178072 and should be soon
<ubottu> bug 1178072 in os-prober (Ubuntu) "Update to 1.58" [Low,In progress] https://launchpad.net/bugs/1178072
<cjwatson> slangasek,cjohnston: registered now
<cjohnston> ack
<Riddell> cjohnston: how can I add cjwatson to my session?  if I follow Review Attendeed I just get an empty page http://summit.ubuntu.com/uds-1305/attendee_review/21779/kubuntu-and-uefi-and-lts-backports/
<cjohnston> the same way as last time..
<cjohnston> cjwatson has been added as a lead, I'll add bdmurray when it imports
<bdmurray> slangasek: so I'm working on this phased updates / regression detection stuff and ran across an interesting case in https://errors.ubuntu.com/problem/a6b1afd5be6decd8e488e35a98b69d1535246d83
<bdmurray> Its showing up as a new bucket for zenity version 3.4.0-0ubuntu4
<bdmurray> however, we can see it was reported about 3.4.0-0ubuntu2
<bdmurray> its just that 3.4.0-0ubuntu3 had no reports of this crash
<bdmurray> and our query uses previous_version=3.4.0-0ubuntu3 and new_version=3.4.0-0ubuntu4
<bdmurray> I guess there is a possibility it was fixed in 0ubuntu3 and then unfixed in 0ubuntu4
<mitya57> bdmurray: the diff looks clean to me, is that bug 968534?
<ubottu> bug 968534 in zenity (Arch Linux) "zenity crashed with SIGSEGV in zenity_tree_dialog_response()" [Undecided,New] https://launchpad.net/bugs/968534
<mitya57> bdmurray: nevermind, that probably happens because -0ubuntu3 was never released
<bdmurray> mitya57: never released?
<mitya57> the difference between two versions is just 6 days
<bdmurray> hrm, I couldn't find anything the source package publishing history in the launchpad api indicating it was not published
<slangasek> bdmurray: hmmm, interesting
<slangasek> bdmurray: I can't think of a good way to automatically distinguish this case from the case of a genuine regression
<mitya57> https://launchpad.net/ubuntu/+source/zenity/3.4.0-0ubuntu3/+publishinghistory doesn't have any "Published" entry
<bdmurray> mitya57: ah, thanks I'll poke some more then
<bdmurray> slangasek: yeah, I was thinking this may happen with packages that are quickly superseded
<mitya57> and your guess is also wrong because the only bug fixed in -0ubuntu3 was #968534
<bdmurray> mitya57: what guess are you referring to?
<mitya57> <bdmurray> I guess there is a possibility it was fixed in 0ubuntu3 and then unfixed in 0ubuntu4
<bdmurray> right that was very hypothetical
<bdmurray> zenity 3.4.0-0ubuntu3 was released - you can see that on the precise changes mailing list
<roaksoax> slangasek: howdy! So I was thinking... would it be possible to automate SRU processes using autopkgtests?
<mitya57> bdmurray: ah right
<mitya57> -0ubuntu3: Mon May 7
<mitya57> -0ubuntu4: Fri May 11
<mitya57> so there's still a little change someone could trigger that bug in just 4 days
<slangasek> roaksoax: automate in what sense?
<slangasek> roaksoax: if you can provide autopkgtests for the bug being fixed in the SRU, *and* you have robust tests for the rest of the package, then the SRU verification could be almost entirely automated
<slangasek> but most packages aren't there
<roaksoax> slangasek: yeah so that's exactly what I mean. There's going to be SRU bugs that are easily reproduceable, which we can write tests for and have the whole process automated
<roaksoax> slangasek: that would hugely improve the whole process, and I believe it would also free engineering time that's being "lost". Also allowing us to reduce the time it takes to release the fixes
<slangasek> roaksoax: sure; the more automation the better
<slangasek> this is largely what the security team does already, though not with the autopkgtest framework
<roaksoax> slangasek: right! Yeah I think if we are able to provide that for the SRU process, it would be great (My idea came from doing a theorical escenario of automating the SRU process for a class on Total Quality Management I took this past semester)
<kirkland> $ unity --reset
<kirkland> ERROR: the reset option is now deprecated
<kirkland> so how do I unfsck my desktop nowadays?
<jtaylor> zul: why did you add ubuntu branding to nginx? its not even main
<jtaylor> + it broke it: bug 1174158
<ubottu> bug 1174158 in nginx (Ubuntu) "Nginx fails to start on 13.04" [Medium,In progress] https://launchpad.net/bugs/1174158
<mdeslaur> jtaylor: seems like adding branding to track market share is a good way to get it to main, no?
<jtaylor> if that is stated in the changelog fine
<jtaylor> neither the patch nor the changelog give any indication why this was done
<jtaylor> I know now, so if you fix it I'm happy
<mdeslaur> jtaylor: doesn't the patch in the bug fix it?
<TheLordOfTime> mdeslaur:  there's only ONE patch in the bug
<TheLordOfTime> and it's a reversal of the introduction of the branding
<TheLordOfTime> introduced in comment 5
<jtaylor> I don't know, probably, though it would be common courtesy if the person who broke it fixes it
<infinity> TheLordOfTime: There's also my "verbal patch" in the bug.
<TheLordOfTime> infinity:  which in -motu we'll test via a ppa
<TheLordOfTime> if that doesn't fix it once I get my raring VM loaded again, then we're back at comment 5's fix
<mdeslaur> jtaylor: sure, ping zul and ask him to fix it...he's at a sprint this week I believe, so wait until he gets back, and I'm sure he'll be glad to fix it
<infinity> TheLordOfTime: I would have just uploaded that define swapping patch of mine, but I don't use nginx, nor do I have a sane way to test it, so I figured I'd leave it to someone who does and can.
<TheLordOfTime> infinity:  if you could upload it as a .patch to the bug that'd make my job easier
<infinity> (Of course, just reverting entirely, and then trying different options later is also sane)
<TheLordOfTime> infinity:  my thought is to drop the ubuntu-branding patch as is and recreate it using your verbal patch in comment 7
<TheLordOfTime> at least for testing
 * TheLordOfTime doesn't feel a need to add a new patch to fix the other patch
<TheLordOfTime> if that works, i'll debdiff that and submit
<infinity> TheLordOfTime: http://paste.ubuntu.com/5648561/
<infinity> TheLordOfTime: Please test. :)
<TheLordOfTime> that works too
<infinity> Err.
<infinity> Wait.
<TheLordOfTime> infinity:  got to deploy my raring vm first.
<TheLordOfTime> :P
<infinity> Let me fix that with brackets.
<infinity> TheLordOfTime: http://paste.ubuntu.com/5648563/ <-- There, that one.  I'll toss that at the bug too.  Still untested, mind you.
<TheLordOfTime> infinity:  the testing is going to be done by me anyways
 * infinity test builds that to make sure he didn't do sometihng dumb.
<TheLordOfTime> infinity:  this is why ppas can be useful :P
 * TheLordOfTime has quite a few test PPAs
<infinity> TheLordOfTime: Well, test-building on my laptop is probably only a few minutes, it's testing the actual package that is a bit tougher for someone who's never used it.
<TheLordOfTime> infinity:  then thank goodness i'm here? :P
<TheLordOfTime> actually, better, thank goodness I track all the nginx bugs :P
<infinity> TheLordOfTime: But, if you can test this for me, I'll happily do the uploads and babysit it through.
<TheLordOfTime> infinity:  that's the plan, the only time I don't test something is when it's an upstream diff that fixes the bug and is already built in Debian xD
<TheLordOfTime> anyways... lemme finish getting my VM up.
<infinity> It at least built successfully here, so that's something. :P
 * TheLordOfTime kicks the unity launcher
<TheLordOfTime> try to open a terminal and it opens Skype...
<TheLordOfTime> >.>
<infinity> TheLordOfTime: Attached the debdiff to the bug too, for safekeeping.
<TheLordOfTime> infinity:  ack
 * infinity test locally because he's feeling pedantic.
<TheLordOfTime> infinity:  heh
<TheLordOfTime> hmm... this'll probably sit on the amd64 queue for a while...
<TheLordOfTime> hmmm...
<infinity> At least 'nginx -t' passes.
<TheLordOfTime> wonder if I can get this bumped up in priority.
<infinity> TheLordOfTime: Want my binaries? :P
<TheLordOfTime> infinity:  please.
<TheLordOfTime> but...
<infinity> TheLordOfTime: (I can bump your builds too, but this is faster)
<TheLordOfTime> put them somewhere I can wget
<TheLordOfTime> :P
 * TheLordOfTime is working off of a server VM so.... :P
<infinity> TheLordOfTime: http://lucifer.0c3.net/~adconrad/nginx/
<TheLordOfTime> got it, just finishing up the VM
<TheLordOfTime> because the VM is being slow :/
<TheLordOfTime> (can't test on this system i'm on because precise :/)
<infinity> TheLordOfTime: So, testing here, nginx -t doesn't complain, and once started, the version string looks sane:
<infinity> (base)adconrad@cthulhu:~/foo$ HEAD localhost | grep ^Server
<infinity> Server: nginx/1.2.6 (Ubuntu)
<TheLordOfTime> infinity:  lemme confirm, then if it works fine, i'll let you know.
 * infinity nods.
<infinity> Now, I should push this to Debian to do something clever with dpkg-vendor, instead of us carrying a silly branding delta forever.
<nemo> So. Just spent an hour figuring out why our game didn't run in Ubuntu
<nemo> Turns out it was badly packaged in 13.04 :(
<nemo> (I mean, working w/ a user who said the game wasn't running for him)
<nemo> Specifically, has a dependency on freeglut3 in the build that ubuntu packaged (is an optional dep for video recording) that was not put in the dependency list :(
<mitya57> infinity: that will be nice, given that this is the only change in our delta (except for some temporary patch)
<infinity> nemo: File a bug, for bonus points, attach a patch, and read https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<nemo> infinity: I already told him to do that
<nemo> although it possibly should just be mentioned in the build bug
<nemo> https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1073730  I assume
<ubottu> Launchpad bug 1073730 in hedgewars (Ubuntu) "Hedgewars 0.9.18 FTBFS on 13.04" [Wishlist,Fix released]
<mitya57> maybe we should even make it append " (Debian)" on Debian...
<nemo> infinity: as for patch, I have no clue as to .deb packaging
<nemo> https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1073730/comments/44
<ubottu> Launchpad bug 1073730 in hedgewars (Ubuntu) "Hedgewars 0.9.18 FTBFS on 13.04" [Wishlist,Fix released]
<debfx> nemo: it's already fixed but hasn't propagated to -updates yet
<debfx> https://launchpad.net/ubuntu/+source/hedgewars/0.9.18-0.2ubuntu1.1
<nemo> ok
<nemo> thanks
<infinity> debfx: Lovely.
<infinity> (Shame no one fixed the FTBFS in the same SRU)
<TheLordOfTime> gah, kernel updates... :/
<infinity> "The Blue Systems sprint has spent a lot of time confirming this fix allows you to again play the game"
<nemo> infinity: FTBFS  is some backport thingy?
<infinity> Hahaha.
<infinity> Riddell: Glad to see you're hard at work.
<TheLordOfTime> FTBFS = fail to build from source
<nemo> ah
<nemo> huh...
<TheLordOfTime> techie term for "WHOOPS YOU BROKE IT!"
<nemo> is that our fault?
<TheLordOfTime> (in a manner of speaking)
<TheLordOfTime> um... i'll let someone else answer that one
<nemo> our deps did change...
 * TheLordOfTime goes back to stabbing nginx
<infinity> nemo: I believe you provided us with a patch to fix the build on arm/powerpc, we just didn't apply it yet.
<nemo> oh. arm.
 * infinity nods.
<nemo> infinity: so, hopefully in a very very short period of time we'll have clobbered the final 0.9.19 bugs
<nemo> and we'll get to go through the whole multimonth process w/ ubuntu all over again :D
<nemo> usually is a minor miracle if ubuntu users are able to play other linux users/OSX/Windows ;)
<infinity> nemo: I'm sure we can sort out clever ways to speed that up.
<nemo> s/ubuntu/ubuntu|debian/
<nemo> if we are lucky enough to time our release juuuust before the ubuntu release we can usually get at least some ubuntu users (full upgraded ones) on it
<nemo> but we missed that window this time
<nemo> and there was playdeb, but that shut down
<infinity> If the package is cleanly backportable, it would be trivial to just update in the development release and backport to other supported releases.
<infinity> If that's not the case today, I suspect you might be able to talk someone into helping make it so (Riddell appears to play the game, he may have an interest in being helpful, for instance)
 * TheLordOfTime groans
<TheLordOfTime> stupid computer
<nemo> infinity: 0.9.17 wasn't cleanly backportable but Evan got it patched and out the door a mere 2 months after release, which is "quite fast" for ubuntu ;)
<TheLordOfTime> infinity:  has anyone reported a problem with apt where it doesn't install dependencies?
<nemo> infinity: although even for current version would be nice. and usually that seems to take months.  not so for gentoo/opensuse/bsd/fedora/whatever
<nemo> infinity: hrm. correction date fail. .17 was released 11-19 and Evan had backport patch a mere 2 days later!
<nemo> was the .16 release that was september
<nemo> so. I think that was probably the fastest ubuntu turnaround ever. possibly faster than any other distro actually
<TheLordOfTime> ah there we go
<TheLordOfTime> infinity:  works
<TheLordOfTime> infinity:  jtaylor: the latest patch/debdiff seems to correctly fix the situation
<TheLordOfTime> so you should be OK to use that as a solution for Raring
<TheLordOfTime> (for Bug 1174158)
<ubottu> bug 1174158 in nginx (Ubuntu Raring) "Nginx fails to start on 13.04" [Medium,Triaged] https://launchpad.net/bugs/1174158
<infinity> TheLordOfTime: I'll just steal the bug and upload.
<infinity> TheLordOfTime: Could you do me a huge favour and add the SRU boilerplate to the bug description?
<TheLordOfTime> infinity:  the wha...
<TheLordOfTime> oh you mean the template
<TheLordOfTime> um... sure...
<TheLordOfTime> if i had the link to it still
<infinity> \o/
<jtaylor> TheLordOfTime: https://wiki.ubuntu.com/StableReleaseUpdates
<infinity> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<infinity> Or https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template even.
<infinity> TheLordOfTime: Uploaded to both saucy and raring.
<TheLordOfTime> infinity:  adding the description shortly
<TheLordOfTime> mitya57:  ping, update your merge stuff!
<TheLordOfTime> infinity:  added SRU boilerplate
<TheLordOfTime> infinity:  any way to skip -proposed for Raring on this?
<TheLordOfTime> (or did you upload directly to -updates)
<infinity> TheLordOfTime: Skip, no.  But I can expedite the SRU once it's been built and verified.
<TheLordOfTime> awesome
<infinity> TheLordOfTime: It doesn't need the 7-day baking period, given the current broken state, but I still want the final binaries tested at least once.
<TheLordOfTime> mmkay
<infinity> bdmurray: Feel like being a charitable SRU team member, since it seems a bit silly for me to review/accept my own upload? :P
<bdmurray> infinity: sure give me a bit though
<infinity> Oh, hrm, I should have merged with Debian for saucy instead of uploading this version.  La la la.
 * mitya57 is looking
<TheLordOfTime> infinity:  hehe
<mitya57> err, infinity uploaded that? :(
<infinity> mitya57: ?
<mitya57> infinity: did you see https://code.launchpad.net/~mitya57/ubuntu/saucy/nginx/1.4.1 ?
<mitya57> it was linked to that bug
<infinity> mitya57: Ahh, well, feel free to upload 1.4.1, but please use the new branding patch instead of dropping it.
<mitya57> ok, I'll rebase my branch that when your change hits the udd branch
<mitya57> s/that/then/
<infinity> Also:
<infinity>   - Modify default site configuration file to correct a typo
<infinity>     that prevented out-of-the-box usability (LP: #1162177).
<ubottu> Launchpad bug 1162177 in nginx (Ubuntu) "nginx-light: invalid parameter "ipv6_only=on"" [High,Fix released] https://launchpad.net/bugs/1162177
<infinity> ^-- Isn't that merged upstream correctly now?
<infinity> s/upstream/with Debian/
<TheLordOfTime> infinity:  i don't know yet i just saw a bug on that...
 * TheLordOfTime opens his emails
<mitya57> infinity: that is merged, but the correct parameter name is "ipv6only" (without "_")
<TheLordOfTime> Debian Bug #707332
<ubottu> Debian bug 707332 in src:nginx-common "nginx-common: Typo in conf/sites-available/default" [Normal,Open] http://bugs.debian.org/707332
<infinity> Well, their sites-available/default looks a lot like ours now.
<TheLordOfTime> infinity:  then they didn't close their bug :P
<infinity> Oh, nevermind.  I missed the underscore.
<infinity> So, yeah, we still have that 1-char delta. :P
<mitya57> TheLordOfTime: #707332 was filed by /me today's morning :)
<TheLordOfTime> mitya57:  eheh
<TheLordOfTime> yeah, so it's not fixed yet :P
<infinity> TheLordOfTime: *nod*... I misread their adding the keyword as them having added it correctly. ;)
<infinity> bdmurray: While I'm bugging you, I'm going to need your superpower to edit meta-release today.
<bdmurray> infinity: okay, what SRU did you want looked at?
<infinity> bdmurray: nginx/raring
<hallyn_> stgraber: any discussion a tthe sprint about default cgroup config for users at login (i.e. for memory controls)?
<stgraber> hallyn_: nope. We briefly discussed potential use of the freezer cgroup for apps but that's about it
<hallyn_> ok, thanks
<cjohnston> bdmurray: you are a track lead now
<bdmurray> cjohnston: thanks
<plars> thomi: ping
<thomi> plars: hey
<plars> thomi: I'm trying to install latest autopilot-touch and it wants python-ubuntu-platform-api, where's the best place to get it from?
<thomi> plars: for raring?
<plars> thomi: yes
<thomi> plars: ok, the best place is ppa:autopilot/ppa - but I just had to binary copy the package, since it hadn't landed since we switched PPAs
<thomi> plars: so, give it 10 minutes maybe
<plars> thomi: ah, ok. That's where I was trying to pull from but it wasn't finding it
<plars> thomi: thanks, will check back in a bit
<thomi> plars: yeah, we switched the PPA, but since we haven't merged anything into trunk autolanding never triggered
<plars> understande
<zequence> Anyone know a nice way to be notified of changes in a package set, such as http://people.canonical.com/~stgraber/package_sets/saucy/ubuntustudio?
<stgraber> zequence: I can have queuebot join your IRC channel and announce the changes there. Note that any packageset change is also announced in #ubuntu-release by queuebot
<zequence> stgraber: I was actually looking at forwarding to a mail list. Didn't think about IRC. I think that would be nice, if we were only alerted of our own package set
<vertab7> good evening all from the UK
<zequence> Just got the script make_report.py, and realized there may be LP API that can be used
<stgraber> zequence: yeah, you can easily query through the API but there's no e-mail subscription for that part
<stgraber> zequence: I can have queuebot join your channel and just show changes related to your packageset or you can write your own script (you probably want to look at edit_acl query -P ubuntustudio -S saucy in lp:ubuntu-archive-tools)
<zequence> stgraber: Ah, thanks. I'll have a look :)
<doko> directhex, ping
<slangasek> cyphermox: hi, did you happen to see my follow-up on bug #1004775?
<ubottu> bug 1004775 in network-manager (Ubuntu Precise) "NetworkManager restarts dnsmasq and adds host route on every IPv6 route lookup" [High,In progress] https://launchpad.net/bugs/1004775
<cyphermox> slangasek: argh, I hadn't seen it
<cyphermox> you're obviously right, I forgot to re-apply this change
<doko> barry, online?
<barry> doko: yep
#ubuntu-devel 2013-05-10
<mwhudson> bah
<mwhudson> second hang today in raring :(
<pitti> Good morning
<pitti> infinity: I don't remember that conversation TBH; what would empty ddebs be good for?
<infinity> pitti: For 1:1 mapping of binaries to ddebs, I suppose.
<infinity> pitti: How else does apport-retrace magically find debug symbols?
<pitti> infinity: it tries -dbg, and if that doesn't exist, -dbgsym
<infinity> pitti: But -dbg is often mapped to source package.  It gets that right?  Fair enough.
<infinity> pitti: In that case, we just shouldn't have ddebs at all for sources that produce -dbg, but that doesn't seem to be true either.
<pitti> takes some binary<->source mapping, but it's mostly working okay
<pitti> yeah, some more consistency there couldn't hurt
<infinity> pitti: I still sort of like the ddeb->dbg mapping idea, just because it give you a consistent interface to debug symbols.
<infinity> pitti: So, if I have libfoo1 installed, I can install libfoo1-dbgsym and not worry about the fact that the debug symbols are actually in foosrc-dbg
<pitti> yeah, fair enough
<pitti> that should actually be not too har
<pitti> d
<pitti> we already compute that mapping to place the Conflicts:, after all
<infinity> Exactly.
<pitti> so we'd just need to swap this around to a Depends:, and make it empty
<infinity> So, you just flip the Conflict to a Depends and em... That.
<infinity> pitti: The motivation here was making sure we don't have duplicate gratuitously huge packages stuffed in the librarian, but it also seems vaguely close to an elegant solution, until someone talks Debian into ddebs.
<pitti> sounds good
<pitti> infinity: how are things looking wrt. ddebs in the librarian now?
<infinity> wgrant: ^
<wgrant> pitti, infinity: There are a couple of override bugs left. Will hopefully sort them out early next week unless more things come up.
<wgrant> And we need to check with IS that the SAN is prepared to die.
<infinity> wgrant: Yeahp, leave IS to Pete and I.
<pitti> ah, thanks for the heads-up
<infinity> wgrant: That timeline works for me, though.
<wgrant> Oh, and need to stop them from actually hitting disk, but that's trivial
<wgrant> The override bugs are the messy bit
<infinity> pitti: If we could do the empty-ddeb thing before we land wgrant's shiny in production, then we'll never have duplicate debug symbols in the librarian, that'll make elmo happier.
<wgrant> What empty ddeb thingZ?
<infinity> wgrant: Scroll back.
<wgrant> If there's a -dbg then pkgbinarymangler will just produce empty ddebs depending on the -dbg?
<wgrant> s/pkgbinarymangler/pkg-create-dbgsym/
<infinity> *nod*
<infinity> Whereas, right now, you end up with two massive debug packages.
<pitti> ok, putting that on my list then
<wgrant> I think -dbgs should just die instead, but...
<infinity> wgrant: Carrying that as a delta from Debian would be insanity.
<wgrant> Certainly
<infinity> wgrant: So, this is a decent workaround until Debian gets off the pot about their own ddebish thing.
<wgrant> But we can hope that Debian might adopt something like our 7 year old working solution eventually
<wgrant> Right
 * pitti adjusts bug 1003234
<ubottu> bug 1003234 in pkg-create-dbgsym (Ubuntu) "Build dummy -dbgsym for packages which already have a -dbg" [Medium,In progress] https://launchpad.net/bugs/1003234
<pitti> in fact, there had been a GSoC Debian project about this already
<RAOF> I suppose it's too much to expect Debian to actually implement something ddebish in the next (Debian) release cycle, isn't it. :/
<pitti> but just like so many of them, it seems to have died
<infinity> wgrant: There's near unanimous agreement among most DDs that ddebs (or something like) are a Good Thing, just the usual faffing about with implementation concerns.
<infinity> RAOF: I think the best way for it to happen in Debian will be for someone to just put together a working set of patches to dak and debhelper and let it speak for itself.
<infinity> RAOF: Our motivation to do so it low, since we have a vaguely working solution (though the debhelper integration could probably be a bit more joeyh-friendly).
<infinity> RAOF: But maybe one of us should try to bridge that gap anyway.
<RAOF> Right. And my only motivation would be because someone asked for a colord-dbg package, and I thought that it was goddamed ridiculous that I needed to do that.
<infinity> pitti: Hah, I knew we'd had this conversation before.
<infinity> pitti: And there was even a bug to prove it. :P
<pitti> yeah, LP clearly beats my brain :)
<pitti> or, my brain forgets things once they are noted down :)
<infinity> pitti: A sane implementation for Debian might need to be split into two helpers instead of one.
<infinity> pitti: I just thought of a fun corner case we don't handle.
<pitti> what would be the second one?
<pitti> non-debhelper packages?
<infinity> pitti: dpkg-gencontrol -v
<infinity> pitti: Your dbgsym depends on the deb with an = relationship to make sure they match (I assume, right?), but that won't be right if people mangle the version after dh_strip.
<pitti> oh, that
<pitti> indeed
<infinity> pitti: So, the Right Way would be to have a strip helper set the bits aside, but build the actual packages at builddeb time.
<YokoZar> I'm a bit surprised that apt-key update actually does anything (in my case it just made apt-get update work again on a raring system)
<YokoZar> naively I expected that sort of thing to always be done already
<bkerensa> pitti: ping
<pitti> bkerensa: hello
<bkerensa> pitti: PM maybe?
<pitti> sure
<pitti> slangasek, stgraber: fixed udev uploaded for dynamic ACLs; oops! I'll see if I can write an autopkgtest for this
 * hyperair just realized there's a libc6-x32 package
<hyperair> do we have anything using it?
<hyperair> oh, ew, we have libx32foobar
<hyperair> this reeks of the pre-multiarch days
<mitya57> Mirv: around?
<Mirv> mitya57: here
<mitya57-mobile> Mirv: I've packaged qttranslations5
<mitya57-mobile> github.com/mitya57/qttranslations-pkg
<Mirv> mitya57-mobile: \o/ awesome! that was indeed the last one missing
<mitya57-mobile> can you please push it to pkg-kde git?
<Mirv> mitya57-mobile: will do, thanks a lot!
<mitya57-mobile> also, svuorela says he'll add me to the team if you ask him, so you may do that instead :)
<Mirv> mitya57-mobile: http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qttranslations.git;a=summary
<Mirv> mitya57-mobile: ok, asking :)
<Mirv> mitya57-mobile: have you applied?
<mitya57-mobile> not, let me apply
<mitya57> done
 * mitya57 has a terrible wifi connection so has to use 2 devices :)
<mitya57> Mirv: also, do you know what's the status of qtdoc? i.e. is there anything blocking the upload?
<Mirv> mitya57: I don't know anything blocking as such (after installing it it shows up in qt creator for example)
<mitya57> ok, then my last question: when will we sync everything from debian?
<jtaylor> are our builders still running hardy kernels or have they been updated?
<mitya57> (as your blog post says, it's everything except two or three packages)
<mitya57> Mirv: or should I file a sync request myself?
<Mirv> mitya57: I think the order would be a) upload qtbase from lp:~kubuntu-packagers, b) sync those that can be synced (eg. qtxmlpatterns, qtscript, maybe qtjsbackend) / upload those that can't (qtdeclarative, qtwebkit, ..)
<Mirv> mitya57: but first I'm trying to get all build for saucy at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper once
<Mirv> I think the uploads/syncs could be started already, but I'd kind of like seeing eg. ubuntu touch image functional on top of that PPA before starting new uploads to saucy
<Mirv> and that'd be around late next week
<Mirv> since it's the main Qt5 user at the moment
<Mirv> there would be also a need to revisit the syncing, both Debian and us have some new changes after the last sync
<mitya57> Mirv: the plan looks good to me
<mitya57> Mirv: I will now look if we have some delta we have some unforwarded changes
<mitya57> *if we have some delta or unforwarded changes
 * mitya57 looks if there are some build failures in the ppa he can help with
<mitya57> there is a qtwebkit ftbfs in <= quantal
<Mirv> mitya57: thanks! I'm not immediately thinking of anything else than qtbase's gcc 4.8 fix that may be interesting, but it's mostly just that another pair of eyes looking at the diff wouldn't hurt ever
<Mirv> (gcc 4.8 is coming early enough to Debian so that the fix does make sense before Qt 5.1 release)
<Mirv> mitya57: that <= quantal armhf failure appeared with 5.0.2. not sure if it's actually relevant to either Ubuntu or Debian
<Mirv> we don't use <= quantal on armhf anymore, and Debian sid should be around raring or newer
<mitya57> dpkg-deb: building package `libqt5webkit5-dbgsym' in `../libqt5webkit5-dbgsym_5.0.2-0ubuntu1~quantal1~test5_armhf.ddeb'.
<mitya57> tar: ./usr/lib/debug/.build-id/63/1c4bc8259068bd755f8ac650310f8e62ac0fad.debug: File shrank by 1077493997 bytes; padding with zeros
<mitya57> weird
<Mirv> yeah, those also sound like random arm builder failures which have happened before. pretty weird anyhow.
<mitya57> Mirv: in Debian qttools is missing add_license_files.patch
<mitya57> (ah, a similar patch should also be applied to qttranslations, will do it later today)
<mitya57> the same for qtxmlpatterns, plus the d/copyright doesn't have an entry for *.qdoc
<Mirv> mitya57: they should be now all in 5.0.2, as I submitted them upstream to all modules
<Mirv> mitya57: debian's qtxmlpatterns does also have *.qdoc entry, I think it just changed places
<Mirv> mitya57: are you up-to-date on the branches, I removed the license patch already from qttools?
<mitya57> right, ignore that
<mitya57> I'm reading commit messages, not files :)
<Mirv> :=)
<Mirv> what I've done is just pure manual diff -urN debian/qtxmlpatterns/debian/ ubuntu/qtxmlpatterns/debian/
<Mirv> if there's only changelog, maintainer and vcs-bzr changes, then there's nothing to consider
<mitya57> Mirv: this is definitely missing from Debian: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/qtjsbackend-opensource-src/saucy/revision/3/debian/control
<Mirv> mitya57: true, and there are some other packages with similar arch defs and those are not in Debian yet
<mitya57> I can fix that myself if I get commit rights :)
<mitya57> Mirv: "they should be now all in 5.0.2, as I submitted them upstream to all modules" â qttranslations 5.0.2 doesn't have any license file :(
<Mirv> mitya57: oh? :( it was merged, but maybe it's in 5.1 only https://codereview.qt-project.org/#change,47243
<Mirv> right, it took some time over there, longer than with some others
<mitya57> Mirv: I've DEP5-ified your patch and pushed to my github branch
<mitya57> ok, I don't see any delta in !base !webkit except for the Architecture: one
<mitya57-mobile2> doko_: someone in gnome bug 697475 asks me to ping you debian #675008
<ubottu> Gnome bug 697475 in general "New tab is not opened in same directory as previous tab" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=697475
<ubottu> Debian bug 675008 in bash "bash: should handle /etc/bashrc.d (or similar) for non-login interactive shell" [Wishlist,Open] http://bugs.debian.org/675008
<mitya57-mobile2> s/someone/gnome-terminal upstream developer/
<zyga> rsalveti: ping
<zyga> pitti: around?
<pitti> zyga: hey
<zyga> pitti: we need a second opinion on debian packaging question, would you mind looking at something?
<pitti> just ask :)
<zyga> pitti: http://bazaar.launchpad.net/~sylvain-pineau/checkbox/plainbox-packaging-policy/revision/11
<zyga> pitti: two packages provide one file
<zyga> pitti: both provide a virtual package
<zyga> pitti: how should Conflicts/Replaces look like
<pitti> Usually Conflicts:/Provides:/Replaces: virtual-package-name
<zyga> pitti: according to http://www.debian.org/doc/debian-policy/ch-relationships.html (7.6.2) it looks okay
<zyga> pitti: ok thanks, that's all I wanted to know
<pitti> that means "you can only install one of the "providers" at a time
<zyga> exactly
<pitti> zyga: you need those on plainbox-secure-policy too, though
<zyga> oh
<pitti> i. e. the C/R
<pitti> maybe apt can figure out that direction from the other direction, but it's best to just keep it completely symmetric
<ogra_> is plainbox the new name ?
<zyga> ogra_: plainbox is a core library for new checkbox
<zyga> ogra_: and a development tool for test authors
<ogra_> ah, nice
 * ogra_ thought you were renaming ... and it sends you cash instead of cheques now :)
<zyga> ogra_: we also have jobbox and cloudbox :)
<ogra_> haha
<zyga> ogra_: so jobbox has the data for checkbox which is using plainbox insternally
<zyga> ogra_: and cloudbox is up up in the sky^Hcloud
<ogra_> neat
<Mirv> mitya57: can you be at OFTC network as well and join #debian-qt-kde?
<mitya57> Mirv: I'm on #debian-kde, didn't know that there are two channels :)
<mitya57> joined
<stgraber> pitti: thanks!
<mitya57> Mirv: what's happening there? are they going to add me? :P
<Mirv> mitya57: if I read correctly, since they don't know yet (before yesterday) they prefer if you continue to commit via me for now. so I guess let's continue so that I review and push your git changes, and we'll ask later about approving.
<mitya57> Mirv: ok, then please push my updated qttranslations branch
<ScottK> pitti: Did the retracers die again?  1176464 is waiting several days for retrace.
<pitti> slangasek, cjwatson: I'm currently packaging/testing a current udev (working well so far, just two remaining patches to port, but I got all the other bits sorted out)
<pitti> ScottK: checking..
<Mirv> mitya57: done
<pitti> slangasek, cjwatson: by default, it now uses the BIOS/vendor/slot based network interface naming, e. g. in qemu you get "ens3" (cf. biosdevname)
<ScottK> Thanks
<pitti> slangasek, cjwatson: right now I set it up so that on upgrades that is disabled, i. e. you still get "ethN", with possibly a 70-persistent-network.rules; but on new installs I'd like to enable the new names, as they are more persistant and also easier to remember; opinions?
<pitti> ScottK: so it did, restarting
<pitti> argh unreliable cron mail
<ScottK> Great.
<pitti> slangasek, cjwatson: also, the generator for 70-persistent-net.rules doesn't exist any more (an existing file still works, of course)
<stgraber> pitti: I'd be very very careful about that kind of new interface naming. We did something similar on a very limited subset of servers a while back with biosdevname and that resulted in quite a few bugs
<stgraber> don't underestimate the number of tools that look for eth*
<ogra_> whats the new interface name ?
 * ogra_ found ethX always quite descriptive)
<pitti> it's derived from ACPI/BIOS/vendor properties, i. e. it's named like the product name and the slot
<ogra_> describing an ethernet interface at least :)
<pitti> therefor it's easier to see what is what, and the numbering is persistant
<ogra_> but you wont know which media it uses now
<pitti> there has been a discussion about this on u-devel@ quite some time ago ("biosdevname")
<ogra_> which the old name told you
<pitti> well, it still starts with "e" or "w" AFAIK
<ogra_> ah
<ogra_> so how would that work on arm ?
<ogra_> :)
<pitti> it wouldn't
<pitti> it would just continue to be called ethN
<ogra_> it could
<pitti> this only works if the acpi/bios actually defines a name
<ogra_> you would just have to pull it out of the platform data
<pitti> ah, sure
<ogra_> (which you could possibly also do for x86 and had a consistent arch independent interface)
<pitti> well, I don't know which interface it currently uses
<mitya57> does anybody here know how britney works?
<pitti> perhaps this already works
<ogra_> heh
<mitya57> if I have a package that is "Architecture: i386, amd64, armhf", change it to "any", and it will FTBFS, will britney allow it to -release?
<ogra_> we'd see if we had any arm builds that used a recent kernel :)
<ogra_> oh, wait, server might have one
<mitya57> (the case is qtjsbackend-opensource-src, where the Architecture line is the only diff with Debian, and Debian maintainers refuse to add it)
<stgraber> mitya57: britney will prevent the migration of any package that has one or more FTBFS
<mitya57> stgraber: it will be more logical if it prevented only packages with regressions
<mitya57> (i.e. previous version built, but current doesn't)
<mitya57> <mitya57> I think we need it in Ubuntu, because if package FTBFS on powerpc, it won't migrate from -proposed to -release
<mitya57> <pinotree> fix the ubuntu architecture then
<mitya57> <mitya57> it's pretty normal to not release a package if it FTBFSes, isn't it?
<mitya57> <pinotree> if it doesn't build and it never did, on debian is not a RC bug
<stgraber> well, just keep the delta with Debian then, a one line change like this won't cost us much to merge
<pitti> we could also P-a-s it?
<pitti> or doesn't that exist any more?
<debfx> are you sure it won't migrate such packages to release? when you look at the ftbfs page you see lots of packages that migrated even though there are build failures.
<ogra_> i think it still does (iirc it also defines sync exclusions)
<stgraber> I believe we have/had an exception for powerpc because of build slowness (though not that relevant anymore thanks to sagari), we've also been pushing some stuff from proposed to release even though one arch FTBFSed
<stgraber> cjwatson would know for sure but he's out till Monday
<mitya57> ok, we'll sync with Debian, and if something goes wrong, reintroduce the delta
<mitya57> Mirv: ^
<Mirv> mitya57: ok, sounds god
<Mirv> +o
<mitya57> ok, I have to go now
<jwp> Hi there! I want to build a SW package with a newer version than the existing one Ubuntu 12.10 default distro, and make it available through an Ubuntu repository. Newer versions of this package already exist in Ubuntu 13.04 and the latest on Debian. Can any one help doing this? I was trying to follow this HOWTO : https://wiki.ubuntu.com/MeetingLogs/devweek1107/MergingFromDebian
<jtaylor> jwp: if it is already packaged in 13.04 backport is the way to go
<jtaylor> https://wiki.ubuntu.com/UbuntuBackports
<jwp> Ok, I will try that, but the latest is only available in Debian...
<jtaylor> jwp: it will go into 13.10 then soon
<jtaylor> from there it can be backported too
<apw> doko, do i remember correctly when i remember you saying that gcc-4.8 should be ok for my arm builds now ?
<doko> apw, I did say, that the warning issue was addressed
<apw> doko, ahh now that makes more sense than what i was remembering, thanks
<apw> doko, are the crosscompilers updated too?  as i was hitting that one there as well i believe
<doko> apw, I think it would be better to check if a recent 3.9 kernel works on arm when built with 4.8
<doko> then see, what probably needs backporting to 3.4
<apw> doko, yep that is meant to be being test, but has not yet
<jtaylor> are builders still running hardy kernels or have all been updated?
<ScottK> IIRC, except for powerpc, they were all updated to lucid and then precise after they were released.
<bdmurray> ubuntu-release-upgrader requires some free space in /tmp for dkms.  Does 5M seem like enough?  I'm not very familiar with how much space dkms modules need to build.
<jtaylor> so powerpc still has hardy?
<jtaylor> need to know for zeromq, they have some ugly compile time kernel feature check
<jtaylor> SOCKCLOEXEC, which is not there on hardy
<ScottK> jtaylor: No, I think ppc is on precise now too, but they ran dapper until close to when it EOLed.
<ScottK> I don't think they ever ran hardy.
<jtaylor> k then I can drop the runtime detection patch (upstream never accepted it)
<jtaylor> thx
 * mdeslaur hugs barry for PEP 435
<jdstrand> tedg: hey, so I was playing with http://gould.cx/ted/blog/Application_Centric_User_Experience
<jdstrand> tedg: specifically with:
<jdstrand> $ start application APP_ID=gedit
<jdstrand> $ stop application APP_ID=gedit
<jdstrand> and those work great
<jdstrand> tedg: however, if I do:
<jdstrand> $ start application APP_ID=gedit
<jdstrand> then close gedit without using 'stop', upstart gets cranky
<tedg> jdstrand, Yeah, that's a known bug right now.  I switched it to desktop files, and apparently the glib function there does 9 forks, which confuses upstart.
<jdstrand> tedg: this is because of: http://upstart.ubuntu.com/cookbook/#expect
<tedg> jdstrand, I need to make it so that we just do it the simple way and don't fork'ing fork so much.
<jdstrand> tedg: ok, yeah, it was 7 here, but glad you know
<tedg> Yeah, the best laid plans to clean things up :-)
<jdstrand> I adjusted desktop-exec to use raise(SIGSTOP) so I could do 'expect stop', but then 'stop application APP_ID=gedit' didn't work
<jdstrand> which, makes sense
<jdstrand> anyhoo, it's known, so I'm good for now :)
<tedg> Hmm, yeah.  Good idea.
<jdstrand> 7-9 forks feels excessive btw
<jdstrand> :)
<jdstrand> maybe we need 'expect 7-9 forks' :P
<barry> mdeslaur: :)
<psusi> so can we finally kill hal this cycle? ;)
<psusi> it's only been 4 years ;)
<infinity> psusi: I beleive that's one of pitti's big goals this cycle, yeah.
<psusi> thank god.
<geser> is it intended to have/keep "fglrx-legacy-driver" in multiverse? (it got synced from non-free into saucy)
<slangasek> pitti: thanks for the udev fix :)
#ubuntu-devel 2013-05-11
<bl4de> hi to all! :)
<bl4de> (and good morning to those who just woke up) :D
<siretart> stgraber: any idea why steam-lxc / python3-lxc doesn't write any logfiles to /var/log/lxccontainer.log? - I currently find it quite hard to debug, to be honest
<siretart> stgraber: just curious, did you test steam-lxc with either fglrx or nvidia, or only with intel?
#ubuntu-devel 2013-05-12
<redtape|renegade> OT | BTW it isn't real, the Samsung u1000 :: :http://www.omgubuntu.co.uk/2013/05/the-samsung-u1000-ubuntu-phone-isnt-real ::
<Dry_Lips> Hi, I'm not sure if this is the right place to ask about this. Does Canonical accept community patches for Unity?
<mlankhorst> I don't see why it would reject patches
<mlankhorst> http://unity.ubuntu.com/getinvolved/development/unity/
<Dry_Lips> mlankhorst: Thanks a lot!
<l0ll0lll> hi all. How can I get CC'ed by default to a package's bug reports on launchpad?
<tumbleweed> l0ll0lll: click subscribe on https://launchpad.net/ubuntu/+source/$PACKAGE
<l0ll0lll> tumbleweed: oh, didn't notice that, thanks :)
#ubuntu-devel 2014-05-05
<teward> how would one typically add hardening flags to a package's compiler options?  I'm kinda confused by the hardening documentation i was able to dig up from Debian...
<jtaylor> depends on how the package handles flags
<jtaylor> if everything is well behaved see man dpkg-buildflags
<jtaylor> if not, you have to dig through the source
<jtaylor> or just test if it accepts flags during its configure equivalent
<pitti> Good morning
<pitti> mitya57: owncloud-client> ah too bad, I sent him a fix just a few months ago
<pitti> mitya57: ah no, mixed that up with something else; yes, will do
<infinity> darkxst: http://launchpadlibrarian.net/174466954/gnome-shell_3.10.4-0ubuntu6_3.10.4-0ubuntu7.diff.gz
<infinity> darkxst: "session" isn't spelled with an "s" on the end.
<darkxst> infinity, ah oops!
 * darkxst wonders why I didn't get an email for build failure there!
<infinity> darkxst: It didn't fail to build.
<infinity> darkxst: But it's failing to migrate.
<infinity> gnome-shell/i386 unsatisfiable Depends: gnome-sessions
<infinity> darkxst: There's no reason it would fail to build, that was a dep, not a build-dep (in fact, that was your change).
<darkxst> yes, of course, I will fix it
<jamesh> mardy: hi.  Are you around to talk about online accounts a bit?
<mardy> jamesh: hi! Yep
<jamesh> mardy: I got side tracked with other tasks, but finally got around to turning on the extra debugging in signond
<pitti> chrisccoulson: I suppose firefox was forgotten to get copied to utopic as well? (bug 1313464) can do now
<ubottu> bug 1313464 in firefox (Ubuntu) "Update to 29.0" [Undecided,Fix released] https://launchpad.net/bugs/1313464
<jamesh> mardy: when trying to retrieve the access token, it seems signond thought the token had expired
<jamesh> mardy: SoundCloud does not set an expiry time on their tokens in the OAuth2 response, which online-accounts was treating as Expiry==0
<jamesh> So when I tried to retrieve the token, it discarded the token
<mardy> jamesh: ouch, that sounds like a bug in our OAuth plugin, then
<mardy> jamesh: can you please file a bug on signon-plugin-oauth?
<jamesh> mardy: this is the problem code, right? http://code.google.com/p/accounts-sso/source/browse/src/oauth2plugin.cpp?repo=signon-plugin-oauth2#444
<mardy> jamesh: yes
<jamesh> I'll file the bug
<jamesh> mardy: filed here: https://bugs.launchpad.net/ubuntu/+source/signon-plugin-oauth2/+bug/1316021
<ubottu> Launchpad bug 1316021 in signon-plugin-oauth2 (Ubuntu) "OAuth2 Tokens from providers that don't provide an expiry date are incorrectly expired on first use" [Undecided,New]
<jamesh> Does that have enough information?
<mardy> jamesh: yes, more than enough :-)
<mardy> jamesh: I'll see if I can add a unit test for this
<mardy> jamesh: the fix itself should be very easy
<chrisccoulson> pitti, thanks. i normally upload the firefox beta to the devel release, but I haven't had time yet
<LocutusOfBorg1> Hi ubuntu developers I have a big big problem with a gcc flag
<LocutusOfBorg1> the problem seems to be in the gcc package ---> doanac
<LocutusOfBorg1> doko,  :=
<LocutusOfBorg1> :)
<LocutusOfBorg1> https://github.com/Ettercap/ettercap/issues/547
<LocutusOfBorg1> the problem is that "-Wl,-Bsymbolic-functions" makes the make test fail
<LocutusOfBorg1> but in debian everything succeeds, while in ubuntu does not
<LocutusOfBorg1> how can I trace down the problem?
<RAOF> LocutusOfBorg1: So, building without symbolic-functions works?
<RAOF> LocutusOfBorg1: Does ettercap do something strange like define empty functions providing the decoders and expect them to be overridden with the symbols from the main executable?
<LocutusOfBorg1> yes it works
<LocutusOfBorg1> and with symbolic-functions works in debian
<LocutusOfBorg1> so the bug seems to be in ubuntu
<LocutusOfBorg1> RAOF, this is the test we run https://github.com/Ettercap/ettercap/blob/master/tests/test_ec_decode.c
<LocutusOfBorg1> just a stub, the real testsuite isn't implemented yet :p
<LocutusOfBorg1> but my question is: the bug seems to be for sure in gcc ubuntu version, since I tried the debian/check package and it is working
<LocutusOfBorg1> (I mean giving the same failure)
<caribou> xnox: ping
<RAOF> LocutusOfBorg1: Huh. Where do those decoders get added?
<RAOF> LocutusOfBorg1: I'd _guess_ that passing --dynamic-list-data would get you a âworkingâ test there.
<RAOF> 'cause you appear to be relying on the fact that something is going to call add_decoder(decode_data) and resolve decode_data to your function pointer declared in the test, rather than in the library?
<LocutusOfBorg1> what shoud this dynamic-list-data be passed?
<LocutusOfBorg1> *where
<pitti> chrisccoulson: ah, so I guess it wouldn't hurt to copy it for the time being to get the security updates?
<chrisccoulson> pitti, yeah, that's fine. thanks :)
<LocutusOfBorg1> RAOF, why the delta from debian? shouldn't be gcc almost equally behaving?
<RAOF> LocutusOfBorg1: Debian doesn't pass -Bsymbolic-functions to ld by default?
<LocutusOfBorg1> yes good catch RAOF !
<LocutusOfBorg1> it isn't passed
<RAOF> LocutusOfBorg1: I don't think Debian *do* automatically add -Bsymbolic-functions; it's not in the buildlog you linked, and it's not in LDFLAGS from dpkg-buildflags in SId.
<LocutusOfBorg1> so what do you propose for solving?
<LocutusOfBorg1> yes RAOF I see now
<RAOF> You can either remove -Bsymbolic-functions from LDFLAGS, or you could add --dynamic-list-something-or-other to LDFLAGS.
<LocutusOfBorg1> I didn't try in pbuilder to see the exported
<RAOF> Well, or you could modify the test case to not assume you can interspose symbols in that way.
<RAOF> s/rsp/rp/
<LocutusOfBorg1> removing ubuntu LDFLAGS seems not a good thing...
<caribou> lovely, ubiquity has decided that it did not want to terminate the upgrade of my desktop : Bug #1316032
<ubottu> bug 1316032 in ubiquity (Ubuntu) "ubiquity fails to complete automated upgrade with python traceback in _restore_package_selection_in_cache" [Undecided,New] https://launchpad.net/bugs/1316032
<LocutusOfBorg1> how can I try the --dynamic-list-data feature?
<RAOF> LocutusOfBorg1: Frankly, I'd modify your test to test something more useful instead :)
<LocutusOfBorg1> mmm how? I didn't write the test, and I don't know what does it do
<LocutusOfBorg1> :)
<RAOF> Check that add_decoder() works, check that get_decoder(...all those standard decoders...) returns non-null.
<RAOF> Basically, remove the decode_* declarations at the top of the test file, and replace the checks with == NULL.
<RAOF> (If I understand what's happening correctly, obviously âº)
<dholbach> good morning
<LocutusOfBorg1> RAOF, I'll check them asap
<LocutusOfBorg1> thanks for the useful hints!
<pitti> dholbach: hey Daniel, wie gehts?
<dholbach> hey pitti
<pitti> dholbach: what do I need to do to update http://packaging.ubuntu.com/html/auto-pkg-test.html ?
<dholbach> pitti, https://code.launchpad.net/ubuntu-packaging-guide :)
<pitti> dholbach: I'd like to show the way that production CI uses now, and also point to the in-depth docs
<pitti> dholbach: splendid, thanks
 * dholbach hugs pitti
 * pitti hugs back dholbach
<pitti> dholbach: how does this magic work: The `libxml2 tests <libxml2_>`_ are very similar.
<pitti> dholbach: so that's `link text <link_target>`_ apparently? but how does "libxml2_" get translated to https://bazaar.launchpad.net/+branch/ubuntu/libxml2/files/head:/debian/tests/ ?
<dholbach> mitya57, ^ can you comment?
<pitti> dholbach: oooh, nevermind; I see the mapping at the bottom
<dholbach> ok cool
<dholbach> mitya57, unping
<mitya57> :)
<pitti> it's a bit confusing as grep doesn't find these
<pitti> as in the link it's foo_, and in the mapping _foo
<LocutusOfBorg1> RAOF, YOU ROCK MAN! Working!
<LocutusOfBorg1> I'll post (if you allow me) the snip of the conversation on the github issue and give you credits in debian/changelog
<pitti> dholbach, mitya57 : ok, done: https://code.launchpad.net/~pitti/ubuntu-packaging-guide/autopkgtest-updates/+merge/218265
<pitti> after this lands, how does http://packaging.ubuntu.com/html/auto-pkg-test.html get updated from that? from the branch or from the package?
<dholbach> pitti, from a daily build of the branch
<pitti> dholbach: oh, nice! so, nothing to do there except landing the branch?
<RAOF> LocutusOfBorg1: Yeah, that's fine. Go ahead!
<dholbach> pitti, yep
<pitti> dholbach: wow, thanks for the fast review!
<dholbach> no worries :)(
<dholbach> :-)
<svenx> where are the ftp master indices override files kept, in git/lp somewhere? files like http://us.archive.ubuntu.com/ubuntu/indices/override.trusty.main
<bdmurray> pitti: could you have a look at my apport merge proposal?
<directhex> hmph, whatever happened to lightdm-set-defaults
<tarpman> directhex: I was wondering that too! http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/revision/1841 apparently, no bug #
<cousteau> can the Unity global menu contain widgets such as buttons, text boxes, etc?  Or only dropdown menus?
<zyga> cousteau: it cannot, look at the dbus menu spec / wiki page for details
<cousteau> so only dropdown menus...  damn, there goes my "awesome browser interface concept"
<cousteau> I guess I could still emulate icons through Unicode symbols, though
<cousteau> zyga, can't find that spec / wiki page
<zyga> cousteau: it's tied to the HUD so you should be able to do more than the basics but that may be under development
<zyga> cousteau: https://wiki.ubuntu.com/Unity/HUD
<cousteau> hm, maybe the global menu can't do what I was thinking of
<cousteau> ...maybe if I could make my program to insert its own applet on the top bar, replacing the menu bar...
<zyga> cousteau: I don't follow desktop development that much so ask around for better hints
<zyga> cousteau: that's not going to work most likely
<cousteau> I don't do desktop development at all; I was asking hypothetically
<zyga> cousteau: that part is displayed by unity
<cousteau> my idea was to develop a web  browser in which the tab/button bar were hidden in the menu bar, so in Unity it would only display the page title until you hover it
<cousteau> http://imagebin.org/309176 - this is how it would look (without unity involved; just using its own rendering)
<cousteau> can an app draw stuff over the top bar?  because that would be another option
<cousteau> figure out where the top bar is, its size, where the area for the menus starts/ends, draw random stuff in that area
<cousteau> (and destroy that when out of focus)
<dholbach> all right my friends - I'm calling it a day - see you all tomorrow!
<arges> infinity: which queue?
<arges> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<arges> infinity: which part specifically did you need help with pending-sru or review queue?
<infinity> arges: Yes.
<infinity> arges: (I was looking at pending-sru, but if you're doing queue stuff, do that, it's more hassle :P)
<infinity> arges: I'm going through pending right now.
<arges> infinity: ok i'll keep looking at trusty queue
<jamespage> infinity, easymock->hamcrest (integration component relies on easymock only afaict)
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges, mterry
<svenx> anyone know where the ftp master indices override files are kept, in git/lp somewhere? files like http://us.archive.ubuntu.com/ubuntu/indices/override.trusty.main
<doko> infinity, according to Manoij's changelog you appear to work for gentoo ...
<infinity> doko: I do?
<infinity> Heh, not quite. ;)
<ScottK> That's barry anwya.
<ScottK> anyway
<barry> whu?
<bdmurray> Is it just me or does the ubuntu-emulator use the same mac address?
<ScottK> barry: OK, so Gentoo refugee, but almost the same thing.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<infinity> doko: Hrm, we couldn't sync make, though.  It dropped M-A:foreign.
<zyga> I wonder if the upcoming amd64+aarch64 on-a-chip boxes will force Debian and Ubuntu to redefine multiach to support executables alongside with existing libraries
<arges> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mapreri> cjwatson: do you mind uploading debootstrap to sid with the right symlink to utopic when you have a spare minute?
<dobey> adb reboot
<dobey> nope
<dobey> wrong focus, obviously
#ubuntu-devel 2014-05-06
<pitti> Good morning
<RAOF> Aloha pitti!
<pitti> hey RAOF, how are you?
<RAOF> Within acceptable parameters :)
<RAOF> Yourself?
 * RAOF has recently learnt that <fn>+1 toggles the fans on his laptop into maximum-speed mode.
<sarnold> should they do that? :)
<RAOF> It's apparently a secret firmware feature :)
<RAOF> ie: It's deliberate, and it is just turning the fans on without increasing CPU load.
<sarnold> nice! :)
<RAOF> Huh. GTK links to libcolord1 it seems.
<pitti> RAOF: I went to Taekwondo again after a 6 week break due to my wrist; I feel that everywhere now :) but quite fine, thanks
<RAOF> Oooh :)
<RAOF> Looks like it's time to prepare a libcolord transition.
<dholbach> good morning
<Mirv> slangasek: hey. it seems your Debian merge of libsdl1.2 dropped the tearing fix patch (in other words, the 1.2.15-8ubuntu2 upload) that was in utopic and is proposed for trusty too. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/libsdl1.2/utopic/revision/48
 * mpt wonders why 100% CPU is being used by âinit --userâ
<mpt> I guess killing that process would be a bad idea
<RAOF> That does seem likely.
<mardy> cjwatson: hi! Do you remember what's the state of https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674? Do you have some work already done, or is it better if I start re-implementing it on top of the latest trunk?
<pitti> xnox, slangasek: I just mailed u-devel@ wrt. moving to insserv or not; comments appreciated
<cjwatson> mardy: I have a fair amount of work done on translating it; sorry for not keeping you updated
<cjwatson> mardy: I've been doing Launchpad work lately so put it on the shelf for a while, but I think you can still safely consider it on my plate
<cjwatson> mardy: (I've basically done the translation, but I still need to sort out the handling of hook removals)
<mardy> cjwatson: cool, thanks!
<xnox> mpt: (a) it shouldn't (b) killing it should be fine, it would respawn (c) not sure how to get info as to why it's doing that.
<caribou> xnox: I got a question for you if you're familiar with ubiquity
<caribou> or to whoever else is
<xnox> caribou: sure.
<caribou> xnox: I got a reinstall issue over the weekend where the 'apt-clone' portion of the reinstall bailed out on me
<caribou> xnox: let me dig the bug I opened
<caribou> xnox: bug 1316032
<ubottu> bug 1316032 in ubiquity (Ubuntu Trusty) "ubiquity fails to complete automated upgrade with python traceback in _restore_package_selection_in_cache" [Undecided,New] https://launchpad.net/bugs/1316032
<caribou> this may not be the best room to address this though
<caribou> xnox: I am tempted to re-run the apt-clone command after rebuilding the chroot
<caribou> xnox: it might be a media problem, as this morning I was not able to reboot on the USB stick I used over the weekend
<xnox> caribou: the useful bit would be to fetch and upload apt-clone generated tarball that it is trying to restore. It should be in the target filesystem. Let me check where it should be comming from.
<caribou> xnox: I located this one
<caribou> xnox: the system is usable btw, it just doesn't have all the user environments & such
<xnox> caribou: right, please attach it to the bug report. (apt-clone-state-.*.tar.gz)
<caribou> xnox: ok. Do you think that the apt-clone could be run on the running system itself, or do I need to reboot to install media & rebuild the chroot ?
<xnox> caribou: in practice we do not recommend using ubiquity upgrade option.
<xnox> caribou: i want the one from the current system as it is right now. It should have been kept around.
<caribou> xnox: then it should be scrapped; having a documented option that is unstable is preaching for trouble IMHO
<cjwatson> I don't like the option, but it's popular
<caribou> xnox: ok, I'll let you know when I get all that done; nothing urgent
<xnox> caribou: is there no /var/ubiquity-apt-clone/*.tar.gz ?
<caribou> cjwatson: it worked for me on two other systems; which is why I'm suspecting that my USB key went bad. I just built another one
<xnox> caribou: what did you upgrade from? ~stock precise?
<caribou> xnox: yep
<xnox> caribou: i'll test that and will check what's going on.
<caribou> xnox: don't waste too much time on this
<caribou> xnox: as I said, it worked flawlessly on two systems
<xnox> pitti: i vaguely remember that we were still not using insserv & startpar on ubuntu due to shutdown not handled properly. But if that is the case, it would be RC in debian as well against upstart package. Thus we should migrate to it. slangasek might know more reasons.
<pitti> xnox: ah, thanks; OOI, how is that related to upstart?
<pitti> xnox: if e. g. the ordering in /etc/rc6.d/ was wrong, that woudl affect all sysvinit/systemd/upstart/openrc alike?
<xnox> pitti: true...
<xnox> yeah, upstart doesn't handle our shutdown, we simply leave upstart jobs running that don't have "stop on" condition and that's about it.
<cjwatson> mapreri: done
<lubko> hi
<lubko> suppose I'm running ubuntu 12.10 lts and a package I need is not available for install. What's the proper way to get the package included in Ubuntu? Add to debian and wait? Is it possible to add a package for an already released distribution?
<LocutusOfBorg1> ubuntu 12.10 is NOT lts
<LocutusOfBorg1> anyway if you add it in debian is better for sure, it will be _automatically_ imported in ubuntu aswell
<lubko> oh, then it's 12.4 maybe
<LocutusOfBorg1> but I don't think it can be backported to 12.04
<LocutusOfBorg1> anyway ask to upload on debian
<LocutusOfBorg1> ask for a sync
<LocutusOfBorg1> file a backport bug and wait for sponsors-team
<LocutusOfBorg1> hint: the commands are "backportpackage" and "requestbackport"
<LocutusOfBorg1> unless the package is useful only in ubuntu
<LocutusOfBorg1> leaving, sorry
<xnox> lubko: you can always create a PPA and make packages available from there.
<darkxst> pitti, ping
<pitti> darkxst: just ask :) (I'm busy, but I'll answer backscroll)
<pitti> dholbach: yay, http://packaging.ubuntu.com/html/auto-pkg-test.html magically updated, thanks! announcement sent
 * dholbach hugs pitti :)
<darkxst> pitti, wondering if Upower 0.99 likely to land this cycle, its pretty much a hard dependency for GNOME 3.12
<xnox> pitti: is this normal http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-libnih/5/ARCH=amd64,label=adt/artifact/results/log/*view*/ ?
<pitti> darkxst: would certainly be nice, but it's a rather large transition (lots of rdepends, a lot of them probably need to be ported from upower to logind for suspend and friends)
<xnox> pitti: that's from http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-libnih/
<pitti> xnox: the "can't parse dependency libdbus-1-dev:native (>= 1.4)
<ogra_> hmm, why do .local addresses not work anymore from my trusty laptop
<pitti> xnox: ? not sure, I never saw ":native"
 * ogra_ can reach them from all other machinnes in the network ... 
<pitti> xnox: that's using Dpkg::Deps::deps_parse, i. e. libdpkg-perl
<ogra_> and it used to work during trusty dev cycle ... is there a known bug ?
<pitti> I thought this was the official interface
<pitti> ogra_: I did that just yesterday on utopic, worked fine; hmm
<ogra_> ogra@styx:~$ ping fhem.local
<ogra_> ping: unknown host fhem.local
<ogra_> ogra@anubis:~$ ping fhem.local
<ogra_> PING fhem.local (192.168.2.75) 56(84) bytes of data.
<ogra_> anubis is a precise desktop
<ogra_> styx is my lappie
<ogra_> i wonder if it is related to wlan vs wired or some such
<darkxst> pitti, how many of the redepends actually use suspend and friends though, apart from g-s-d (already ported), u-s-d (can merge g-s-d patches), indicator-power?
<pitti> darkxst: I don't know yet; I suppose things like xfce4-power-manager, mate-power-manager, kde-runtime might well do
<pitti> darkxst: codesearch to the rescue :) (queries like http://ubuntu-codesearch.surgut.co.uk/search?q=UPower.Suspend)
<pitti> darkxst: http://ubuntu-codesearch.surgut.co.uk/search?q=up_client_suspend as well
<pitti> but it's hard to believe that this is everything, unless XFCE/KDE etc. were really good at porting :)
<pitti>     xfpm_power_sleep (power, "Suspend", FALSE);
<pitti> right, we need to catch indirect calls like that, too
<darkxst> pitti, yes hard to believe XFCE would have ported anything
<seb128> bluez5 is going to be another interesting one
<seb128> speaking of other desktops/porting and needed by new GNOME
<darkxst> http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=ae97be6f3500eea509d61c914e22c5355e7d57de
<darkxst> bluez5 is less important, we can live without that
<seb128> the Debian gnome-pkg seemed to have flagged it as an important issue to update GNOME
<seb128> but if it's not that's good
<pitti> darkxst: nice!
<ScottK> For Kubuntu, we'll have upstream support for bluez5 and are getting bugged by upstream to move forward.
<darkxst> right, it would be preferably to have bluez5, but we can ship GNOME 3.12 without it
<apw> pitti, so do we yet have any way i can detect under adt why am i being run, ie on hows behalf.  for my own upload, or an upload for another package
<pitti> hey ScottK, how are you?
<apw> s/hows/whos/
<pitti> ScottK: would you happen to know which KDE component is interfacing with upower (or perhaps logind already) to do suspend/resume/poweroff etc.?
<pitti> apw: not "under" adt (that has no idea why you call it), but we have that information in the log files on the britney host (snakefruit)
<pitti> apw: admittedly I don't have a good idea how to parse them, that's jibel's expertise mostly
<xnox> pitti: looks like when resolving build-dependencies (e.g. those that can have :any, :<arch>, :native) one needs to pass "build_dep => 1" to deps_parse. How/where should I send the patch for that?
<ScottK> pitti: Should be solid.
<pitti> ScottK: thanks
<pitti> xnox: ah; something like http://paste.ubuntu.com/7404029/ ? testing now
<darkxst> pitti, seems mate is also working on porting i.e. http://git.mate-desktop.org/mate-power-manager/commit/?id=8f734c679de61292f0ae1bd9923fc67801ab041c
<xnox> pitti: yeap.
<pitti> xnox: would that break any binary deps? (sounds not, but are you aware of anything?)
<pitti>   Removing adt-satdep:amd64 because I can't find libdbus-1-dev:native:amd64
<pitti> xnox: so, it helps a bit, but not quite sufficient yet as apt still doesn't know about those; I suppose I need to do some extra filtering somewhere
<RAOF> pitti: There's a new colord in collab-maint git (which doesn't want to be uploaded yet) that fails autopkgtest in my VM really strangely - it fails to build, but _only_ during the ADT test.
<xnox> pitti: extra filtering also works, e.g. on launchpad ":*" is simply stripped from all names.
<xnox> pitti: and since adt tests are non-multiarch and always run everything from a single arch, it's best to just do that.
<RAOF> pitti: If I keep the VM around and log in, it builds fine.
<pitti> RAOF: how does it fail?
<pitti> meh, *just* when I thought I put out the last adt-run fire two new ones come along :)
<RAOF> pitti: make fails to find a file to dist. But colord builds out-of-tree fine, I checked.
<RAOF> Sorry I don't have the exact error handy.
<pitti> xnox: hm, all that multi-arch business is actually why I'm using libdpkg-perl in the first place; I had expected reduce_arch => 1 to do that, or maybe there's yet another magic option for that?
<xnox> pitti: use_arch => 0 ?
<xnox> pitti: or maybe reduce_restrictions => 1
<pitti> xnox: no, I do want that
<pitti> adt-run1: build dependencies: architecture resolved: autopoint, dbus (>= 1.4), debhelper (>= 9), dh-autoreconf, dpkg-dev (>= 1.16.1~), libc6-dev (>= 2.15~) | libc6.1-dev (>= 2.15~), libdbus-1-dev (>= 1.4), libdbus-1-dev:native (>= 1.4), libexpat1-dev (>= 2.0.0), libexpat1-dev:native (>= 2.0.0), pkg-config (>= 0.22)
<pitti> xnox: ^ with reduce_restrictions => 1
<xnox> pitti: i guess i can remove needs-build tag and spell out the build-dependencies.
<pitti> xnox: that doesn't do the same, BTW
<pitti> xnox: so I guess s/:native// it is?
<xnox> pitti: i'm not sure how but in the case where one is not cross-compiling this simply reduces the: libdbus-1-dev libdbus-1-dev:native to libdbus-1-dev
<apw> pitti, it would be nice if we could have some kind of "RUNNING_FOR=x" sort of thing ... so we can not waste a load of time for the kernel when uploaded for itself
<pitti> apw: that sort of thing would need to be done somewhere in the britney/adt interface though
<pitti> apw: indeed; we knew about this wasted test when we came up with that simple criss-cross rebuild test
<xnox> pitti: e.g. dpkg-checkbuilddeps does the right thing -> says nothing is needed, but when i pass "-ai386" it says libdbus-1-dev needs installing (that is libdbus-1-dev:i386)
<pitti> xnox: crude, but works: http://paste.ubuntu.com/7404072/
<pitti> xnox: I'll see to come up with a test for that after lunch
<xnox> pitti: yeah, that should work.
<mardy> pitti: sorry to bother you, but I think you might be able to help me with this build failure, as it's about debhelper and python3: https://launchpadlibrarian.net/174684030/buildlog_ubuntu-utopic-i386.uoa-integration-tests_0.2%2B14.10.20140506-0ubuntu1_FAILEDTOBUILD.txt.gz
<mardy> pitti: I found that other packages in Debian had the same issue and fixed it like this: http://anonscm.debian.org/gitweb/?p=collab-maint/hitchhiker.git;a=commitdiff;h=ee7d2b40d3e66d2017498ee884a2c470b577182c
<mardy> pitti: I have to say that I don't understand what this is all about, TBH; should I just copy that fix? It seems a bit dirty...
<mardy> pitti: OK, I think that this is saying that overriding is the only solution ATM: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597105
<ubottu> Debian bug 597105 in debhelper "add support to build python3-* packages" [Wishlist,Open]
<xnox> mardy: hm, you should use pybuild which is the right way to build python3/python2 packages.
<xnox> mardy: see https://wiki.debian.org/Python/Pybuild
<Saviq> xnox, Mirv, can't cross-build unity8 under utopic, could you have a look please: http://paste.ubuntu.com/7404297/
<mardy> xnox: thanks, I'll try that!
<Saviq> hmm
<Saviq> maybe it's my fault, trying in a clean chroot
<Saviq> xnox, Mirv, unping for now
<xnox> Saviq: somehow the package you build is not the package you install build-deps for.
<Mirv> Saviq: irssi does not support 'unping', but it would be nice if it did ;)
<Saviq> xnox, I think it's the Qt5 rename
<xnox> Saviq: e.g. you removed ubuntu-settings-components and installed qtquick2.
<xnox> Saviq: but you still say that you need ubuntu-settings-components.
<xnox> Saviq: could be.
<Saviq> xnox, ok, but that's a clean chroot now: http://paste.ubuntu.com/7404308/
<Saviq> Mirv, ââ looks like this would require UITK to update its deps to the new names?
<Mirv> Saviq: well the old names are transitional packages so there shouldn't be a reason for that to make difference?
<Saviq> Mirv, maybe it's because of multi-arch though?
<Mirv> Saviq: more like that one graphical effects "|" dependency in UITK is even older transitional thing and might of course confuse some package installer
<Mirv> multi-arch sounds understandable
<Saviq> Mirv, it tries to get arch:armhf, the transitionals are only arch:all
<Mirv> Saviq: ah...
<xnox> Mirv: transitional packages must be the same, e.g. arch:any and Multiarch:same
<xnox> Mirv: if the package they point to is that.
<xnox> Saviq: ^
<Saviq> bad Mirv!
<Saviq> or whoever did the transitionals in debian ;)
<Mirv> I just synced! :)
<pitti> mardy: missing pyversions> apparently you are only building a py3 package, so you need to call py3versions (pyversions is for 2.x)
<pitti> mardy: or, if you actually build py2 versions, you indeed need to b-dep on python-all, yes
<pitti> mardy: looking at your package, it doesn't even build any python[3]-* package
<pitti> mardy: so I don't think you actually want --with python2
<pitti> ^ that's the bit which needs pyversions (but only useful for building python modules)
<pitti> xnox: btw, libnih's debian/tests/control's Depends: are entirely useless
<pitti> xnox: "Depends:\nRestrictions: build-needed" shoudl suffice entirely
<mardy> pitti: thanks, I'm now try using pybuild as suggested by xnox
<pitti> mardy, xnox: ^ except that mardy isn't trying to build python[3]-* packages :)
<pitti> so if anything, pybuild will make it more complicated
<xnox> mardy: do you or do you not build python2 or python3 packages?
<pitti> IMHO you shold drop the --with, and just do whatever you need to do (python3 setup.py install ..) in debian/rules explicitly, instead of relying on some magic which wasn't designed for this
<mardy> pitti, xnox: ATM, the package is using python just to install some data files on the system; no python files are buing handled
<pitti> mardy: right, hence my suggestion above; --with python2 or pybuild aren't really built for this, you'll run into some trouble
<pitti> so better explicitly say what you need to do
<mardy> pitti: but, there was no "--with" when that build failed. Probably debhelper was too smart and autodected that?
<pitti> mardy: I apt-get source'd the current utopic pacakge, that does have it
<mardy> pitti: oh, yes, but I removed that in the branch I'm currently building (https://code.launchpad.net/~mardy/uoa-integration-tests/python3/+merge/218283), though now I re-introduced it with the last commit
<ogra_> hmm, did pad.lv launchpad redirects stop working ? or is my new firefox broken ?
<ogra_> http://pad.lv/1308365 doesnt open for me
<ubottu> Launchpad bug 1308365 in dialer-app "press-call-twice-to-redial doesn't work" [Undecided,Confirmed]
<pitti> ogra_: yes, hangs here, too
<ogra_> k, i was about to blame FF :)
<pitti> that works just as good or bad as version 28 here :)
<pitti> it still greets me with the "OMGshoudln't have happened" page because it still doesn't know how to register to a non-archaic gnome session, but that bug is years old
<pitti> otherwise I don't really understand all the fuss about "my menus are gone", they are all still there :)
<pitti> xnox: ok, committed http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=be7814b30 (good thing I wrote a test, I was missing another spot to fix), rolled it out, and retried libnih
<pitti> xnox: crap, seems precise's libdpkg-perl is too old for this
<pitti> xnox: ok, plan B: remove them before calling deps_parse()..
<mapreri> pitti: Hi! with "you can ping the leads of these two derivatives to check" do you mean to email who seems to be the leader (admins of the lp teams?), don't you?
<marga> The bug I encountered last month is back: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605
<ubottu> Launchpad bug 1302605 in eglibc (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang" [Undecided,Confirmed]
<marga> infinity, could you please take a look? Let me know if you need any extra info
<pitti> mapreri: they should be more or less identical yes, or at least know who to ask
<mapreri> ok
<pitti> xnox: ah, so it finally greenified \o/ you and you fancy dependencies.. :)
<xnox> pitti: =))))))
<pitti> xnox: do you have an idea about the upstart failure?
<xnox> pitti: didn't look yet, will check it.
<pitti> wrong string value, expected 'init (upstart [0-9.][0-9.]*' got 'initctl: Name "com.ubuntu.Upstart" does not exist'
<pitti> missing D-BUS or whatever?
<xnox> pitti: that one is weird and has been seen intermittendly on the buildds, but does pass.
<xnox> bug #1315767
<ubottu> bug 1315767 in upstart (Ubuntu) "intermitent test failure" [Undecided,New] https://launchpad.net/bugs/1315767
<pitti> xnox: at least that's the one that seems to consistently break i qemu
<pitti> "in"
<xnox> pitti: or just slow hardware is it seems to be the trend.
<Elv1313> Hello, any idea why https://errors.ubuntu.com/problem/96becd9a35ea3f1b2a5841dd058629ecf20c5673 is failing to retrace? It has been reported again yesterday and I really like to fix this, but I can't reproduce
<pitti> superm1: uh, black screen! do we ship performant enough GL drivers for that? :-)
<superm1> pitti: :)
<mapreri> superm1: :D
<mapreri> (read a reply with a so short delay it's so pleasant!)
<pitti> mapreri: so let's wait for a reply from studio, then we can (hopefully) dramatically simplify this
<mapreri> pitti: yep. I'm deleting the rest of the old cruft...
<mapreri> pitti: maybe you can remove this mp? https://code.launchpad.net/~gilir/xscreensaver/fix-129769/+merge/18043
<pitti> mapreri: with moving the screensavers back to the debian layout, we'll need some Breaks/Replaces: until the next LTS (16.04), but otherwise it should almost get back in sync
<pitti> mapreri: I set it to "merged" according to the last comment
<mapreri> pitti: umh... you right... let me think about the correct Breaks/Replaces
<mapreri> pitti: yes, it's really merged
<arges> RAOF: hi
<bdmurray> mvo: could you have a look at bug 1309447 which failed verification?
<ubottu> bug 1309447 in apt-clone (Ubuntu Trusty) "Unicode decode error during upgrade to 14.04 if sources.list contains non-ascii characters and locale is non-US" [High,In progress] https://launchpad.net/bugs/1309447
<mvo> bdmurray: aha, thanks
<mvo> bdmurray: hrm, hrm, we probably need a .4 for this
<mpt> cyphermox, how does NetworkManager decide how many bars to give a Wi-Fi network? What are the units of measurement?
<cyphermox> IIRC <=25% one bar, >25% two bars, >50% three bars, >75% four bars
<Elv1313> Hello, there is no -dbg packages for sflphone-daemon, sflphone-gnome and sflphone-kde, is there any reason for that? What can I do to have these packages added to the repository?
<cyphermox> mpt: scratch that, I'm wrong
<mitya57> Elv1313: Can you use ddebs.ubuntu.com?
<mpt> cyphermox, I was going to say, I didnât know there was a maximum value :)
<mpt> (which percentage would imply0
<mpt> )
<cyphermox> there is
<cyphermox> well
<cyphermox> it's a function of SNR
<mitya57> Elv1313: i.e. download .ddebs for your architecture/version from http://ddebs.ubuntu.com/pool/universe/s/sflphone/, and dpkg -i them
<mpt> cyphermox, Signal to Noise Ratio?
<cyphermox> yes
<mpt> ok, thatâs all I need to know, thanks
<cyphermox> so, >5% == nm-signal-25, >30% == nm-signal-50, >55% == nm-signal-75, >80% == nm-signal-100
<Elv1313> mitya57: thanks, but I see other packages have -dbg directly in the main repository. I also have issues with errors.ubuntu.com where I have incomplete backtraces (without symbols), so there is something wrong somewhere...
<mitya57> Elv1313: Debian does not have .ddebs, so maintainers usually add debug packages manually. For sflphone it's not the case.
<mpt> cyphermox, the reason I was asking was to figure out what the accessible label should be â whether it can be a percentage, or whether it has to be just âWeakâ, âModerateâ, etc
<mitya57> Incomplete backtraces depend on whether retracer was lucky or not.
<Elv1313> mitya57: The maintainer (well, the one assigned by the sflphone developers to take care of take) happen to be myself, so what are the steps?
<cyphermox> mpt: could still be weak, moderate
<cyphermox> it's up to what you feel better conveys the message :)
<mitya57> Elv1313: No, in Debian maintainer of sflphone is not you :)
<mpt> ok
<mitya57> Elv1313: In any case, https://wiki.debian.org/DebugPackage
<Elv1313> mitya57: I know that, but I also know that its part of my job to get things done ;)
<xnox> mpt: the units are abitrary, whilst the power of the signal & noise is measured in dBm, the ratio is without units. Some devise "Arbitrary Strength Unit" but those are not consistent across GSM/3G/LTE/WiFi thus e.g. when people complained that iphone has low strength -> they released software update to "bump by one bar up" =)
<mitya57> Elv1313: In Ubuntu, you can just not care
<Elv1313> so in the end, it's still my problem to get the -dbg into the main repository
<mpt>  * The '''signal strength accessible label''' should be â(Very weak)â, â(Weak)â, â(Moderate)â, â(Strong)â, or â(Not in range)â.
<mitya57> Then that wiki page is for you
<xnox> mpt: that sounds good.
<Elv1313> mitya57: ok, thanks
 * mpt wonders how screenreaders articulate the difference between labels with and without ellipses
<cyphermox> dot dot dot
<cyphermox> I don't know :)
<slangasek> Mirv: hmm, apparently a race condition while I was preparing the merge, sorry
<slangasek> pitti: insserv is a thing we should do, but there's a lot of groundwork to do first
<slangasek> xnox: the shutdown problems with insserv are Ubuntu-specific
<xnox> slangasek: i remember you saying something like that. but i did not recall the fine details of they actually are.
<slangasek> xnox: when Scott deployed upstart, he removed init scripts in the process rather than making them upstart-aware; this means that Ubuntu is missing a lot of the init script dependency information that insserv needs
<slangasek> we obviously never removed init scripts in Debian :)
<pitti> slangasek: you mean for scripts which came back later through syncs and merges?
<xnox> slangasek: lovely. So we need to revert initscripts back into place, and modify them as needed to be apppriate for ubuntu.....
<pitti> we still remove pretty much all of rcS.d/ from initscripts, but of course there are lots more sources putting stuff there
<slangasek> pitti: sorry, I don't understand the question
<slangasek> the fact that the initscripts *are* removed is the problem
<xnox> pitti: is it normal that a get an aweful beep when i reboot with systemd?
<slangasek> insserv gets the ordering wrong without them
<pitti> slangasek: I didn't understand how you got from "we removed init.d scripts as we have upstart jobs for them" to "they are missing dep info"
<pitti> slangasek: aah
<slangasek> and it's more about rc{0,6} than rcS
<pitti> slangasek: right, now I understand
<slangasek> rcS is probably ok currently, but to get it back in sync with Debian again may introduce regressions with insserv along the way
<xnox> slangasek: so if i run my init.d/init/systemd extractor against debian and compare the output, it should be evidant what's missing, no?!
<pitti> slangasek: so upstart runs them in between or after the native and builtin jobs for shutdown, not before?
<bdmurray> xnox: slangasek said you might be able to help with bug 1316302.
<ubottu> bug 1316302 in android (Ubuntu) "ubuntu-emulator-runtime uses the same MAC address" [High,New] https://launchpad.net/bugs/1316302
<xnox> slangasek: and then sort through that as appropriate.
<pitti> slangasek: I wouldn't like to reintroduce Debian's init.d scripts for rcS/rc0/6 TBH; we won't ever support running sysvinit in Ubuntu (I think?), and we don't really need them
<pitti> xnox: beep> err, I hope not; I never heard a beep, but then again I'm not even sure if my laptop still has the equivalent of a PC speaker
<slangasek> xnox: I suppose that should work, yes
<pitti> slangasek: ok, thanks for the heads-up; so I guess for the initial merge I'll revert to our current update-rc.d and instead port the systemd script support manually?
<slangasek> pitti: there are no upstart native and builtin "shutdown" jobs; and if you want to switch to insserv you must reintroduce the rc{0,6} init scripts so that insserv doesn't pooch people's filesystems on shutdown
<slangasek> which initial merge?
<pitti> slangasek: the one which I have on my hard disk and testing currently
<xnox> slangasek: pitti is merging sysv-rc.
<pitti> (^ which is sysvinit)
<slangasek> hmm
<xnox> right yeah.
<slangasek> pitti: any chance you can post that for me to review before upload?
<pitti> slangasek: I initially pondered just doing the update-rc.d bits for systemd, but then again, we should merge it every now and then, so I got to that question about insserv
<slangasek> I am not confident in the sysvinit package in Debian
<pitti> slangasek: yes, absolutely
<xnox> bdmurray: so since it's all using qemu in the end it should be possible to override mac address.
<pitti> slangasek: I was going to put it into a PPA with a call for testing and all that
<slangasek> and I've held off merging it because things keep changing in Debian in Ubuntu-incompatible ways
<pitti> (aside from the fact that currently $world rdepends on it, and any failed autopkgtest holds it in -proposed :) )
<xnox> bdmurray: however the device that emulator uses is a funny 3g-modem-not-really one. I'll look into randomizing it's MAC address.
<bdmurray> xnox: that'd be great thanks
<pitti> slangasek: ah, you did? ok; the insserv one seemed desirable to me in the long run to avoid slowly breaking compatibility with Debian syncs, and you already committed a lot of our delta there, so it shrunk quite a bit
<pitti> slangasek: did> hold back the merge, I mean
<slangasek> yes, I do want us to get to insserv
<slangasek> we just have to sort out the init script problem first
<shadeslayer> pitti: ping
<shadeslayer> pitti: do autopkgtests get picked up automatically? i.e. if I add a test to kdelibs , https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/ will list it once it's processed?
<pitti> shadeslayer: they do, yes; but it might take an hour or two until britney gets to it (at least it needs to get built and installable on all arches)
<shadeslayer> pitti: roger
<pitti> shadeslayer: when did you upload it? i. e. has it been some inordinately long time already?
<pitti> one of these days I need to buy mvo a beer and figure out why we get these dreaded "hash sum mismatch"es on apt-get update so often :/
<pitti> (numpy and ubiquity tests restarted, FTR)
<shadeslayer> pitti: no, just uploaded it like 15-20 minutes ago
<shadeslayer> around the time I pinged you
<shadeslayer> pitti: https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu2
<pitti> shadeslayer: what is debian/tests/acc doing? just checking that the command doesn't error?
<shadeslayer> Description-en: debhelper addon to compare ABI compatibility of shared C/C++ library versions
<pitti> aah
<pitti> shadeslayer: OOI, how does "debian/rules build" know that it should test against the installed packages?
<shadeslayer> pitti: no idea, tests come from debian, so I'd ask someone on #debian-qt-kde , I'm very new to autopkgtest
<shadeslayer> still trying to understand bits and pieces
<pitti> ok
 * pitti waves good night, cu tomorrow
<shadeslayer> night :)
<xnox> pitti: i have a merge of plymouth from debian, which should enable systemd units... but this is my first time playing with systemd. So far i've caused it to unmount filesystems not-clean on shutdown, not able to boot with dirty filesystems (one needs to switch to tty1 which triggers lightdm job somehow) and systemctl reboot fails from runlevel 0
<xnox> (as in it gets stuck on a cups job)
<xnox> pitti: i think i should upload plymouth jobs/units....
<xnox> pitti: but overall it seems quite buggy at the moment =)
<slangasek> Mirv: readded your change and uploaded; have you forwarded this change upstream / to Debian already?
<xnox> slangasek: pitti: if init.d scripts are missing, is it ok to simply introduce systemd-unit and skip init.d script?
<xnox> or i guess we do want inserrv support with upstart still?!
<xnox> zz-busybox generates symlinks, yet busybox hook removes them....
<slangasek> xnox: insserv support doesn't impact leaf services; we do need to sort out init.d scripts for anything in the rc{0,6} critical path (which may mostly be sysvinit itself)
<xnox> slangasek: ack. i see a lot of packages that were not rebuild in ubuntu, that is init.d script is stipped instead of kept intact.
<slangasek> well yes, because a straight rebuild would break it given that your lsb init-functions hook hasn't landed yet
<xnox> true.
<slangasek> xnox: can you do something with your upstart-jobs branch to stop spamming upstart-devel?
<xnox> slangasek: yes.
<slangasek> thanks ;)
<xnox> done.
<xnox> bdmurray: so in android emulator it does accept shared-net-id parameter which sets the last two bytes of mac address.
<xnox> bdmurray: snprintf(nic, sizeof nic, "nic,vlan=1,macaddr=52:54:00:12:34:%02x", shared_net_id);
<xnox> bdmurray: would it be sufficient to randomize across those or do we want larger range?
<xnox> bdmurray: hm, that would also randomise the IP of the emulator.
<stokachu> xnox: you around?
<rsalveti> slangasek: these are the only remaining packages (new src pkgs) to get uploaded in order to have a working x86 emulator: https://launchpad.net/~rsalveti/+archive/touch-emulator-x86
<rsalveti> just created a build out of the archive + this ppa, and it worked fine
<rsalveti> there's still one rendering bug, but that's probably mir related
<rsalveti> as I got the same issue when I rebuilt the entire stack using the same src packages but forcing gles by default
<rsalveti> let me upload them, but will need help to get them accepted
<slangasek> rsalveti: great, happy to help with getting them accepted
<RAOF> arges: Hello! Just about to reply to your mail.
#ubuntu-devel 2014-05-07
<TheMuso`> c
<pitti> good morning
<pitti> xnox: yes, unless it affects insserv ordering (which after yesterday's discussion won't land soon anyway) there's no need to create init.d scripts which will never be used anyway
<pitti> xnox: we are only concerned about upstart and systemd, I don't think we want to start supporting sysvinit too :)
<pitti> xnox: saw the bug, thanks
<Mirv> slangasek: upstream won't develop/release libsdl 1.2 anymore but the bug report is there. I submitted the patch to Debian bug tracker yesterday now too.
<dholbach> good morning
<ion> that
<cousteau> can windows / applications draw stuff over Unity's top bar?  or is it always over the applications unless they're fullscreened?
<cousteau> because if they can, and it's also possible to get the length and position of the global menu on the screen, then applications could have their own "custom global menu" by drawing over it
<ion> cringe
<cousteau> (or one could just put that sort of stuff inside the window rather than the menu bar, but this might be a bit inconsistent with how Ubuntu looks and feels)
<xnox> pitti: so with plymouth from proposed. On boot, i get plymouth splash, then ~8 lines of systemd-fsck and then it gets stuck there. Upon switching to tty1 it realises things and instantly starts up lightdm. I'm not yet sure what's going on there. Will test out how the transitions happen in e.g. virtual machine / debian.
<pitti> xnox: thanks; sorry, I'm still stuck in putting out autopkgtest fires and now reviewing the britney fixes
<xnox> pitti: no worries. there will also be malta to listen to my lenovo PC-speaker on systemctl reboot =))))
<pitti> hehe
<pitti> xnox: do you hear any beep on printf "\a"
<pitti> xnox: or when installing and running "beep"? I don't
<pitti> PC speaker, oh the days
<xnox> nope, nothing.
 * xnox ponders if that's not, in fact, pc speaker then.
<xnox> maybe it's like a beep cod ?!
<pitti> xnox: I think that used to work, but I faintly remember that we dropped the PC speaker from the kernel some years ago; ICBW though
<xnox> code
<xnox> pitti: yeah, it's blacklisted in /etc/modprobe.d/ throughout. I pondered if systemd doesn't read that.
<pitti> xnox: so another hypothesis is that systemctl reboot pokes the bios/uefi in a different way than normal "reboot" (e. g. from upstart); could that be?
 * xnox will read systemctl reboot code
<pitti> I modprobed pcspkr, but neither \a nor beep do anything :/
<xnox> system-module-load unit fails for me =(
<pitti> xnox: yep, known; it's because of the obsolete "rtc" in /etc/modules
<pitti> it's on my TODO to file bug for this (discussed quickly on IRC last week)
<pitti> "bug against hw-detect for dropping rtc module, and kmod for removing it on upgrades"
<pitti> xnox: it's quite clear from systemctl status system-module-load, you see the failed rtc there
<xnox> pitti: do you want me to fix hw-detect ? & kmod?
<pitti> xnox: if you want to and have time, sure :) (it's mostly cosmetical at this point)
<pitti> xnox: I haven't yet checked when we dropped rtc, i. e. how careful we need to be on upgrades
<xnox> "register-module rtc on amd64 (closes: Ubuntu #1659)"
<pitti> "dropped rtc" as in "the module from the kernel"
<ubottu> Ubuntu bug 1659 in Launchpad itself "EnumCol/dbschema doesn't support DEFAULT" [Medium,Fix released] https://launchpad.net/bugs/1659
<xnox> pitti: is that bugzilla reference number?! =)
<pitti> xnox: wow, four-digit bugs, that sounds like bugzilla
<xnox> pitti: it's a delta from debian =) looks like debian never did that.
<xnox> pitti: what about "lp" module?
<pitti> xnox: too bad, it's not even on https://bugs.launchpad.net/bugs/bugtrackers/ any more
<pitti> xnox: if it helps to drop it, do it; /etc/init/cups.conf already loads it
<pitti> xnox: oh, actually it doesn't; our /etc/default/cups has LOAD_LP_MODULE=yes commented out
<pitti> xnox: nevermind, it's now in /etc/modules-load.d/cups-filters.conf
<pitti> xnox: so yes, can go
<xnox> pitti: yeah, that should make /etc/modules empty.
<shadeslayer> pitti: so kde4libs is missing from https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/
<shadeslayer> pitti: uploaded it 17 hours ago
<shadeslayer> https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu2
<pitti> shadeslayer: yes, it's missing the "XS-Testsuite: autopkgtest" header in debian/control
<shadeslayer> ahhhh
<pitti> that's how the CI machinery checks whether a package has tests
 * shadeslayer checks
<pitti> shadeslayer: but no hurry -- as far as I remember from yesterday that test wasn't that useful anyway as it just ran tests against the build tree
<shadeslayer> yeah
<shadeslayer> but might as well fix it since it should be trivial
<geser> doko_: Hi, are you working on merging python-babel? I'd like to try to fix bug #1299442 (it looks like this was already fixed in Debian) which also includes to fix it in utopic first (probably by merging with Debian)
<ubottu> bug 1299442 in python-babel (Ubuntu) "UnknownLocaleError: unknown locale 'en'" [Undecided,Confirmed] https://launchpad.net/bugs/1299442
<doko_> geser, no
<geser> so it's ok if I do it?
<doko> sure
<shadeslayer> infinity: ping, I was wondering, the eglibc homepage says that it's unmaintained, are there any plans to switch back to glibc?
<LocutusOfBorg1> shadeslayer, I wasn't aware, so sad
<LocutusOfBorg1> but is good to have only one big glibc project
<LocutusOfBorg1> rather than two
<LocutusOfBorg1> :)
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> xnox: so someone went ahead of us and filed bug 1317077 :)
<ubottu> bug 1317077 in kmod (Ubuntu) "systemd-modules-load.service fails: /etc/modules contains nonexisting module "rtc"" [Undecided,Triaged] https://launchpad.net/bugs/1317077
<pitti> xnox: so in case you are already working on it, please add the bug ref to the changelogs?
<xnox> pitti: ack, thanks.
<xnox> infinity: for above bug ^ are you happy with attached patch there https://launchpadlibrarian.net/174864006/kmod.patch ?
<pitti> xnox: LGTM (I think lt is fine, lt-nl might not suffice in weird corner cases)
<pitti> xnox: thanks!
<xnox> pitti: i'm now pondering if $2 is actually passed....
<pitti> xnox: if I may be a bit nitpicky, I'd move the LP to the next line to satisfy changelog parsers
<pitti> (dpkg-genchanges groks it, but e. g. not vim or LP)
<xnox> pitti: all changelog parsers parse it correct!
<pitti> xnox: yes, but my eye doesn't :) (but nevermind, just nitpicky)
<xnox> pitti: of vim =) emacs doesn't correct.
<xnox> pitti: fair point =)
<pitti> xnox: $2 seems fine to me
 * xnox ponders if emacs can be fixed to auto-wrap with non-breaking space.
 * ogra_ thinks $2 is to cheap 
<ogra_> :P
<cjwatson> LP should grok it fine, I think it's just vim
<xnox> pitti: nah $2 is bogus, cause it's not passed to the function, thus is empty, thus on every upgrade those modules are removed.
<infinity> shadeslayer: I'm reviewing the delta and working on moving Debian and Ubuntu over to glibc, yes.
<shadeslayer> \o/
<shadeslayer> apachelogger: ^^
<pitti> xnox: oh argh, right
<infinity> xnox: FWIW, sounds like systemd is buggy here.
<xnox> infinity: whilst true, it is also buggy to include modules that don't exist anymore. I've cleanup installer and cleaning up installed systems via kmod.
<pitti> well, we could quiesce the load-modules job, but it really failed to load "rtc"
<pitti> I think it's preferable to point that out than silently ignoring typos and other nonexisting modules
<infinity> xnox: rtc exists.
<pitti> and other than "status" yelling at you it doesn't break anything
<pitti> $ modinfo rtc
<pitti> modinfo: ERROR: Module rtc not found.
<infinity> xnox: It doesn't "exist" in our distro kernel, but it's right to try to load it when it *is* modular.
<pitti> infinity: and I think apw said it was removed many eons ago
<infinity> pitti: That bug also shows some failures to parse modutils config files in general, etc.
<pitti> asked the reporter to attach his /etc/modules (I don't get these "off" errors)
<xnox> corrected the patch to remove those modules only once upon upgrade to 2ubuntu4 https://launchpadlibrarian.net/174864473/kmod.patch
<xnox> infinity: hw-detect was only adding rtc module loading on amd64 & i386, and we do have kernels for those.
<xnox> infinity: thus if indeed rtc should be loaded always & everywhere it should be done else, e.g. be a built-in module or get udev to load it.
<pitti> xnox: only on amd64
<xnox> right, yeah, even that.
<pitti> because on i386 it gets loaded through isapnp
<pitti> (haha!)
<infinity> xnox: udev couldn't do it because it can't be detected.
<infinity> xnox: Same reason why lp has to be a manual load.
<xnox> infinity: lp is still a manual load. just via /etc/modules-load.d/cups-filters.conf
<infinity> Which assumes that the only people who want to use that device are people with cups installed.
<infinity> There's nothing wrong with trying to load it twice.
<xnox> infinity: correct.
<infinity> Look, I'm not against the installer dropping some of these options, I'm arguing that we don't need to "fix" old modules files to work around systemd being silly.
<pitti> as I said, we *can* change the job to ignore nonexisting modules
<infinity> If I don't have cups installed but use /dev/lp, you've just screwed me silently with your postinst.
<pitti> at the expense of not telling you about errors
<infinity> If I have a custom kernel with rtc built as a module, you just broke my computer.
<pitti> and I'd rather have it tell me when I did a typo and why I just broke things, than silently claiming that everything went well
<infinity> pitti: Well, modutils/modul-init-tools/kmod have never broken in this regard, I'm not fond of systemd telling me that I've been wrong for 20 years.
<pitti> but oh well, not a biggie; either way is fine
<pitti> infinity: please don't call it "broken" -- it's just as "broken" to not tell you about errors
<pitti> it's a matter of deciding how to report errros
<pitti> and if we don't want that, let's say so and we can do that
<infinity> pitti: It's "broken" in that it's a regression.  You've always been able to have non-modules in those files before, specifically to allow one file to work for multiple kernels with different configs.
<infinity> pitti: The idea being that you're saying "if this module exists, load it, cause I need it, otherwise, we assume it's built in".
<pitti> infinity: fair enough
<infinity> There could be a kmod bug here too, if it's not able to detect the built in status of rtc
<xnox> shouldn't systemd-modules-load be smart in this regard and check if a given module is built in?
<infinity> (It seems to do so for fuse)
<infinity> So, okay, the rtc thing might be a genuine bug.
<infinity> Removing lp sounds like overkill.
<pitti> xnox: that seems rather unreliable to do? for this specific case it could check /sys/class/rtc/, but that doesn't generalize
<xnox> infinity: yeah lp removal was mostly a piggy-back on top of rtc.
<pitti> yeah, that was just cleaning up duplicate loading
<infinity> pitti: Yeah, but it's not a duplicate, per se.  If a user has lp in /etc/modules, we should assume they wanted that at boot.
<infinity> pitti: cups is saying "I really want lp", but that doesn't mean someone without cups doesn't also want it.
<infinity> (I agree that it's time to drop lp from the installer, though, so few people even use the driver)
<pitti> infinity: my thinking was that for someone without cups it's much more likely that he wants to use the parport by itself rather than lp claiming it
<pitti> infinity: but, as you say, this is such an edge case these days that I really don't bother much
<pitti> it just appeared to be something which could be cleaned up along
<pitti> xnox: but ok, I don't think it's worth discussing this for long, so maybe let's put back lp?
<xnox> pitti: so do we not have rtc module at all, not even built-in?!
<infinity> The kmod builtin detection certainly fails to find rtc...
<pitti> xnox: well, there *is* no rtc module..
<infinity> rtc_generic             2711  0
<infinity> Methinks it's been renamed.
<pitti> there are things which you can build as module
<infinity> So removing that is probably not world-ending.
<pitti> whcih we build in
<pitti> those appear in /sys/modules/
<pitti> but rtc stopped being a module long ago
<pitti> hence dropping it
<xnox> debian wiki mentions genrtc module as well
<infinity> So, yeah, dropping rtc is fine.
<xnox> but keep the lp one?
<xnox> (not doing any harm what's-so-ever)
<infinity> pitti: So, assuming the kmod builtin detection actually works, I'm perhaps okay with failing on "unknown", assuming it's not also failing on "builtin" returns.
<infinity> pitti: As in, that fuse builtin thing isn't causing issues, right?
<pitti> xnox: yeah, I guess so; you could argue either way, but let's not for the 3 people in the world who still use parallel ports with Ubuntu (and can be broken either way around) :)
<infinity> People who needed to use their lp port for something else already removed it from /etc/modules.
<infinity> People who still have it there either don't care or prefer it that way.
<infinity> So, remove lp from hw-detect, but not from existing installs.
<pitti> infinity: it shouldn't; if it does, that'd be a bug in kmod or the systemd-module loader thingy (not sure which, but we can debug that if it happens)
<ghy> hi everyone, what is your opinion about https://lists.ubuntu.com/archives/technical-board/2014-March/001852.html ? I think it needs some serious planning, to speed it up. Some doker tehniques ?
<pitti> infinity: WFM
<pitti> so xnox's hw-detect upload is fine, and in kmod he'll just drop the lp bit
<infinity> pitti: kmod doesn't return an error for builtin, so it would be if systemd flips out at the output.
<pitti> infinity: right, that seems fixable; i. e. a "builtin module" is trivial to detect
<xnox> pitti: infinity: systemd-modules-load is fine with fuse, no errors.
<pitti> so, all is well then :)
<infinity> Okay, so the user removing that was overkill debugging. :P
<infinity> The "name=off" stuff is curious, I'd like to know what's up with that.
<pitti> except for that "off" error in the bug, I'll wait for the reporter's /etc/modules to see what he changed there
<infinity> Could be a systemd bug, could be a kmod-not-compatible-with-m-i-t bug, or could be a broken config on his part.
<pitti> *nod*
<infinity> We've put a lot of work into making libkmod compatible with modutils/module-init-tools, but it's certainly not 100%, so the bug could be there.
<infinity> Or he could just have had a broken config. :P
<infinity> chrisccoulson_: Weird firefox bug, on a new window, the first time I click on the (locally-integrated) menus, the tab bar drops a pixel or two.  After that click, it stays that way for the life of the window.
<xnox> pitti: are we gonna drop using plymouth on the desktop then?! =) i wonder.
<xnox> pitti: s/desktop/server/
<pitti> xnox: hm, I don't know; probably nobody would even notice on a server, but some of our scripts might expect it to be there?
<xnox> pitti: shouldn't @builddeps@ implicitly include build-essential ?
<pitti> xnox: it does
<pitti> xnox: oh wait, sorry, no; it only implies "make"
<infinity> It definitely should imply build-essential.
<infinity> Well, what it should do is exactly what dpkg does.
<infinity> (Which implies build-essential, but it would be saner to ask dpkg than to guess)
<pitti> this got introduced through debian bug 720458 which had a different use case in mind
<ubottu> Debian bug 720458 in autopkgtest "autopkgtest: allow tests to depend on Build-Depends installed" [Normal,Fixed] http://bugs.debian.org/720458
<pitti> but no objection to extending that
<pitti> (bug report s'il vous plaÃ®t?)
<infinity> pitti: Right, the only reason that worked for that bug is because perl modules happen to depend on perl and not much else from build-essential. :P
<pitti> *nod*
<infinity> pitti: But, per policy, build-deps are incomplete without Essential+Build-Essential.
<pitti> infinity: yes, I fully agree
<pitti> just explaining where it came from
 * infinity nods.
<infinity> pitti: Once mvo is done with my wishlist apt bugs, this might be simpler.
<infinity> (One of them being "apt-get build-dep source-pkg-1.23.dir/" which would parse debian/control and DTRT)
<pitti> thumbs up!
<pitti> this is a pain to implement by hand, and there are like 5 implementations out there
<infinity> Which also should let me kill pbuilder-satisfy-deps usage from a few places in the DC.
<pitti> pbuilder-satisfydepends-whatnot
<pitti> and autopkgtest has its own as slangasek didn't like the dependency :)
<infinity> So, yeah, getting him to do dir/debian/control and .dsc
<pitti> mostly kidding, it's actually useful to also enable/disable recommends, and pbuilder-s-d has a few quirks which are now gone
<infinity> Yeah, apt pretty much always gets it right, mind you.
<infinity> And has --no-install-recommends
<infinity> Etc.
<pitti> all hail apt!
<xnox> all hail mvo!
<pitti> infinity: yes, adt-run counts on that
<pitti> it builds a dummy package with the build-arch resolved dependencies, installs it, and then calls apt-get -f install
<pitti> ugly, but the best I could come up with without dragging in tens of MBs of dependencies
<pitti> (pbuilder, equivs, devscripts, etc.)
<infinity> pitti: That's more or less the "right" way to do it anyway, IMO.  Except for the "apt-get -f install" part, the best way is to actually add it to a local repo and apt-get install.
<infinity> pitti: The end result is usually the same, though.
<infinity> (This is what modern sbuild does these days)
<xnox> best bug comment ever https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/384633/comments/27 =)
<ubottu> Launchpad bug 384633 in grub-installer (Ubuntu) "Grub Installer uses device name instead of UUID, leading to unbootable system" [High,Triaged]
<pitti> infinity: yeah, but that needs another apt-get update, which is ridiculously expensive
<pitti> infinity: so maybe we can add "apt-get update for only a particular sources.list.d/ file" to mvo's list :)
<pitti> that would be really useful for add-apt-repository, autopkgtest, and presumably other cases
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> pitti: It's only expensive if the other mirrors have changed, in which case, don't you want the latest anyway?
<infinity> pitti: But for your use, "apt-get build-dep package-dir/" will solve your problem anyway.
<pitti> infinity: yes, but it just run a minute ago, for upgrading the VM
<tarpman> pitti, infinity: iirc sbuild injects a list into /var/lib/apt/lists directly instead of doing a full update
<pitti> infinity: and I need that so that apt-get source can get the right version, so I can't swap it around either
<pitti> tarpman: oh, for what? I've never seen this
<pitti> infinity: yes, apt-get build-dep package-dir/ FTW!
<tarpman> pitti: well, for exactly what you were talking about: to get a repo containing the build-depends package but not do a full expensive apt-get update
<infinity> tarpman: Indeed, yes, sbuild cheats. :)
<tarpman> I assume it wouldn't have to cheat if "update one source" existed ...
 * infinity nods.
<infinity> It could be a fun extension.
<cjwatson> You can cheat differently by creating a temporary sources.list with just the source you care about and using "apt-get --no-list-cleanup update"
<cjwatson> err with -o whatever::the::sources.list::option::is=blah
 * tarpman makes a note to try that with sbuild
<pitti> cjwatson: nice trick!
<bdmurray> mvo_: are crashs like https://errors.ubuntu.com/problem/f574669b9ee9e2de062ee26daa080c3d86b90665 useful?
<zyga> hey, I'm trying to reproduce a build failure, a package build clean in sbuild locally but I've noticed that launchpad build it in a way where various parts of debhelper get invoked with '-a' and that caused the build to fail. How can I reproduce that locally with sbuild?
<cjwatson> run sbuild without -A
<mvo_> bdmurray: I don't think so, that should be fixed in update-manager
<cjwatson> Or with --no-arch-all if you have $build_arch_all = 1; in .sbuildrc
<mvo_> bdmurray: I put it on my list, sorry that the list if currently growing and not shrinking
<zyga> cjwatson: I never pass -A, I have build_arch_all though, tried passing --no-arch-all
<cjwatson> $build_arch_all = 1; is like passing -A for every build
<bdmurray> mvo_: I'm happy to help if you could elaborate on what you mean exactly.
 * zyga tries again, though it did work (built correctly) so I cannot reproduce the failure)
<mvo_> bdmurray: sure, I think that aptdaemon/update-manager should just show a error message but not record this as a crash
<zyga> cjwatson: just confirmed that it is *not* causing -a to show up
<zyga> cjwatson: (I also removed build_arch_all from .sbuildrc to be sure)
<bdmurray> mvo_: got it
<cjwatson> zyga: would need a full transcript etc. if you want more help
<zyga> cjwatson: I'm trying to reproduce this build failure: https://launchpadlibrarian.net/174871384/buildlog_ubuntu-trusty-amd64.pyotherside_1.2.0-0.0%2Btrusty_FAILEDTOBUILD.txt.gz
<cjwatson> this isn't at all magic though
<zyga> cjwatson: note that it '-a' is passed to debhelper everywhere
<zyga> cjwatson: that failure doesn't happen otherwise
<cjwatson> zyga: where is the source?
<zyga> cjwatson: https://code.launchpad.net/~zkrynicki/+archive/experiments
<cjwatson> (for future reference, the +build URL is strictly more useful than the build log)
<zyga> cjwatson: sorry, noted
<cjwatson> so https://code.launchpad.net/~zkrynicki/+archive/experiments/+build/5986554 in this case
<zyga> yeah
<pitti> vila: bzr fails on the various stderr spam (https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-bzr/1/ARCH=i386,label=adt/console) and doesn't declare "allow-stderr"
<pitti> vila: is that stderr expected and considered "normal" (and thus we should add allow-stderr), or considered an indication of a bug?
<cjwatson> zyga: (testing here but slow network, please wait)
<zyga> cjwatson: thanks for your time! :)
<vila> pitti: hmm, you mean the stderr output needs to be declared or the test fails ? Those messages... are caused by a minor bug... with annoying ramifications. I have a fix though but I never submitted it because I thought I was the only one observing it...
<vila> pitti: it's a test-only bug for that matter
<pitti> vila: yes, by default stderr is considered a failure, mostly to catch unexpected warnings and such
<xnox> vila: i can upload allow-stderr in both debian & ubuntu if you wish.
<pitti> vila: so allow-stderr should be okay here as python's unittest will exit with non-zero on real failures
<pitti> yes, I'm happy to do the upload (not in Debian though), I just wanted to check that it's right before
<xnox> vila: and we can drop that if/when your fix to clean that output patch lands.
<xnox> pitti: i'm on debian-bzr team =))))
<pitti> xnox: ok, you earned it then :)
<xnox> pitti: ack.
<vila> xnox, pitti : sounds like allows-stderr if the easiest path then
<vila> xnox: good to know and thanks !
<vila> pitti: and to better understand, is this new ?
<pitti> vila: the stderr output is new, yes; fail-on-stderr has always been the case
<vila> pitti: ack
<xnox> vila: i did a recent upload of lp:bzr into debian and merged into ubuntu.
<pitti> yes, it's stuck in -proposed and I'm currently reviewing excuses for stuff that is "my" fault
<pitti> and fix a few easy things and report debian bugs for the non-obvious ones
<vila> xnox: really ?? That's awesome !
<xnox> vila: yeah, so debian & ubuntu are at 6595 revision at the moment.
<vila> cool, not that the latest bugs are that bad but it's good that we don't diverge too much and well, bugs are bugs so it's sad to not share the fixes ;)
 * pitti waves good night
<zyga> night?
<zyga> pitti: where are you
<pitti> zyga: well, time for Taekwondo, and I started working 12.5 hours agol..
<zyga> ouch!
<xnox> zyga: pitti is a very early riser.
<zyga> pitti: enjoy your rest then :-)
<xnox> zyga: so you can think he is based in middle east or some such =)
<zyga> heheh
<bdmurray> superm1: what is the status of bug 1290460? I ask because I'm trying to figure out if I should write something to add duplicates going forward.
<ubottu> bug 1290460 in mythbuntu-common (Ubuntu Trusty) "Mythbuntu Installer Crashes: File "/usr/lib/python3/dist-packages/mythbuntu_common/vnc.py", line 58, in create_password ValueError: Password should be passed as bytes" [High,Triaged] https://launchpad.net/bugs/1290460
<tgm4883> bdmurray: I'm actually testing if that is fixed now
<tgm4883> I think I fixed it last night
<bdmurray> tgm4883: okay, cool
<cjwatson> zyga: Sorry for the delay.  This reproduces cleanly for me.  sbuild -d trusty --arch=amd64 pyotherside_1.2.0-0.0+trusty.dsc => http://paste.ubuntu.com/7411452/
<cjwatson> zyga: My .sbuildrc: http://paste.ubuntu.com/7411456/
<cjwatson> zyga: There's a fix for this problem in click/debian/rules.  Just add this:
<cjwatson> # Sphinx documentation is architecture-independent.
<cjwatson> (with no contents for that rule)
<cjwatson> override_dh_sphinxdoc-arch:
<xnox> cjwatson: i wish sphinxdoc just do the right thing to be honest.
<xnox> cjwatson: cause a lot of packages need that fix.
<cjwatson> I agree but ran out of round tuits when I first encountered that
<xnox> ack.
<xnox> i think these days addons can declare them self indep/arch only.
<cjwatson> Well, some packages might have arch-dep sphinx docs (e.g. if they're generated in arch-dep ways)
<cjwatson> But the debhelper idiom would be to not fail if it has nothing to do
<infinity> Should just yank out the error block at the bottom and done, IMO.
<infinity> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745690
<ubottu> Debian bug 745690 in sphinx-common "sphinx-common: dh_sphinxdoc always insists on documentation" [Normal,Open]
<infinity> Already marked pending.  Curious what the pending solution is. :P
<infinity> mitya57: ^^
<infinity> mitya57: How did you plan to fix this?
<ogra_> decision pending :)
<cjwatson> infinity: http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=28648
<infinity> http://anonscm.debian.org/viewvc/python-modules/packages/sphinx/trunk/debian/dh-sphinxdoc/dh_sphinxdoc?r1=22919&r2=28648
<infinity> Hah.
<infinity> cjwatson: Yeah, I got there when I realised the pending was added by an alioth account. ;)
<infinity> Perhaps we should just cherrypick that commit right now instead of fixing any more rdeps.
<cjwatson> zyga's problem is in trusty, mind
<infinity> And cherry-pick as an SRU?
<cjwatson> (And click will probably have to keep the workaround due to backports)
<cjwatson> Or that
<infinity> I can't see how it would be harmful to do so.
<cjwatson> Yeah
<cjwatson> infinity: Did you have a chance to look at my lp-buildd MP?
<infinity> cjwatson: Not yet.  I've actually had things to do (people to argue with?) at this sprint.
<cjwatson> Ah, didn't realise you were sprinting
<infinity> Well, crashing someone else's sprint, but yes.
<ogra_> hmm, why does germinate-update-metapackage tell me my debootstrap is to old ... my trusty is up to date
 * ogra_ thought he saw that go inot -updates
<ogra_> *into
<ogra_> hmm, because germinate would like ubuntu1 instead of ubuntu0.1
<ogra_> weird
<infinity> Awesome, sphinx is FTBFS in both trusty and utopic.  Guess I need to fix that before I can SRU it.
<infinity> Grr.
<infinity> Lunch first.
<cjwatson> ogra_: it just compares against the version which was used by whoever constructed the source package last
<ogra_> ah
<ogra_> well, i grabbed the new debootstrap from LP ... all fine now
<cjwatson> You can also edit the debootstrap-version file if you know that the version decrement makes no practical difference
<ogra_> pitti, hmm, you dropped cordova from touch sdk-libs ...
 * ogra_ hopes thats fine and was coordinated with the webapps team ... 
<ogra_> (since we still support 13.10 apps in utopic)
<psusi> I'm looking at a bug report about not being able to get /etc/default/grub back after messing it up or deleting it... I would have thought that an apt-get install --reinstall grub-pc would do it, but it says it refuses to replace deleted config file.. is there a proper way to *really* reinstall, including config files, or do you just have to purge first?
<zyga> cjwatson: thanks for looking at this, neither me nor roadmr could reproduce (both utopic and trusty, also on sid), I'll dig around
<zyga> cjwatson: and thanks for the solution :-)
<zyga> roadmr: ^^ interesting how it worked (by breaking) for cjwatson
<roadmr> oh cool... reading backlog
<infinity> psusi: dpkg --force-confmiss
<superm1> bdmurray: once we fix it we will SRU, but people encountering it will keep encountering it unless they use our dailies or wait until next point release
<superm1> it's probably worthwhile to have duplicates get directed thre
<superm1> *there
<infinity> zyga: I'm SRUing sphinx as we speak so your fix/workaround can be backed out soonish.
<bdmurray> superm1: ah, that's true. okay I'll set something up.
<superm1> thanks
<infinity> zyga: And it's already fixed in utopic (as of a few minutes ago).
<xnox> pitti: i think i got that upstart test fixed now \o/
<xnox> pitti: but it's omg sad one though =)
<mdeslaur> stgraber: what images don't support capabilities? (re: iputils)
<stgraber> mdeslaur: currently our cloud images, lxc upstream images, core images, touch images are all broken
<mdeslaur> touch because of ext2? why the cloud images?
<mdeslaur> what are "core images"?
<stgraber> mdeslaur: because tar just doesn't store xattrs by default
<stgraber> mdeslaur: nor unpacks them if they are in there
<mdeslaur> hrm
<mdeslaur> ok, because this probably affects gnome-keyring too
<mdeslaur> but I guess that's not used on those
<stgraber> yeah, it does, though the keyring is mostly on desktop images which have installer hack to reset the capability
<mdeslaur> right
<mdeslaur> stgraber: ok, thanks
<stgraber> we do have a vague plan of getting fscaps working properly (discussed it here at the sprint with infinity, rbasak and smoser) but that'd involve some dpkg/debhelper changes to do right and is something we should spec and discuss with Debian first
<stgraber> so yeah, current easy fix for the issue is to go back to setuid everywhere and SRU that back to trusty
<mdeslaur> cool
<roadmr> aha, so the utopic mini.iso is trying to load files from archive.ubuntu.com/dists/trusty... this works against the internet-accessible archive but will break if trying to install from a local mirror built from a utopic iso (as I usually do)
<xnox> mdeslaur: also all wubi installation of ubuntu desktop.
<roadmr> this also happens if I pxeboot with files extracted from the full utopic iso
 * mdeslaur pretends he didn't hear wubi
<xnox> mdeslaur: installer recently gained capability to transfer capabilities.
<xnox> roadmr: correct, we didn't refresh apt-setup for utopic yet.
<roadmr> xnox: is it worth filing a bug over, is there a bug already, or is it best to wait?
<roadmr> xnox: OTOH if there's no bug and one is filed, you can point lost souls like myself to it instead of explaining every time :)
<xnox> roadmr: no need for bug-report. all d-i components need merging, that hasn't yet been done post archive opening.
<xnox> roadmr: you are first one to notice and point-out as far as can remember =)
<roadmr> xnox: I imagine few people install from a locally-hosted archive; most people wouldn't notice if they have internet access as it will just happily access the trusty archive
<roadmr> xnox: but that's good to know: I have no problem waiting and if this is not affecting other people then it's ok. That was my main concern.
<dobey> hmm, why is autoremove --purge not removing some old kernels? :(
<dobey> i still have -10, -11, -12, and -23 on trusty
<cjwatson> stgraber: I did fix the server installer to handle that too
<xnox> roadmr: fixing installer, will upload after test build. It FTBFS with make 4 as well, so had to cherry-pick patches to fix it.
<roadmr> xnox: oh thanks! much appreciated
<mterry> pitti, have you used ofono-phonesim-autostart lately on the phablet image?   Having trouble getting it to work
<mterry> pitti, well, specifically the "/usr/share/ofono/scripts/dial-number 199" call
<infinity> zyga: Are you around?
<doomlord_> anyone here familiar with compiz plugins? ... i'm curious to know how hard it would be to adapt the desktop management to do a few things..
<infinity> zyga: dh_sphinxdoc in trusty-updates is now fixed, you shouldn't need the hackish workaround in debian/rules for your package.
<SpamapS> Heh, bug 1313550 is a fun one.
<ubottu> bug 1313550 in maas (Ubuntu Trusty) "ping does not work as a normal user on trusty tarball cloud images." [High,Confirmed] https://launchpad.net/bugs/1313550
<SpamapS> Was going to verify it but looks like it is on the fast track to trusty-updates ?
<infinity> SpamapS: Already done.
<zyga> infinity: thanks, that's good to know! :)
<zyga> infinity: curiously enough trusty worked but utopic failed, I assume that sphinx is still in -proposed somewhere and waits for migration to finish
<zyga> infinity: https://code.launchpad.net/~zkrynicki/+archive/experiments/+packages
<infinity> zyga: Exactly that, yes.  It's still in utopic-proposed.
<zyga> infinity: ah, then nothing to worry about, thanks for the quick fix :)
#ubuntu-devel 2014-05-08
<infinity> pitti: adt-britney seems to be "stuck".  All the tests triggered by sphinx, for instance, have been "running" for a Very Long Time despite that being, I believe, complete BS.
<infinity> pitti: More bugs to hunt down?
<pitti> Good morning
<pitti> xnox: upstart> yay, you did it! why sad?
<pitti> ogra_: well, it was requested by dbarth and got three acks in the MP: https://code.launchpad.net/~dbarth/ubuntu-seeds/ubuntu-touch.remove-cordova-2.8/+merge/215098
<pitti> ogra_: so it seemed ok?
<pitti> infinity: probably more likely to be a networking issue; I'll have a quick look (although I'm not intimately familiar how this is plumbed together)
<infinity> pitti: Well, I was relying on you to relay to jibel if he's the one at fault. ;)
<pitti> infinity: yep :)
<pitti> infinity: btw, that adt-britney fix for ignoring results is coming along well
<pitti> https://code.launchpad.net/~jibel/britney/fix_missing_results/+merge/218467 fixes the issue, just needs some cleanup
<pitti> infinity: so this  afternoon or tomorrow morning or so we should land this
<infinity> \o/
<pitti> if jibel finishes this this morning (which I assume), I'll ask cjwatson to review; I guess he's closest to that part of britney?
<infinity> pitti: Do we also have "ignore tests that have never passed" somewhere on the wishlist stack?
<pitti> i. e. I did the first round of review, but I can't actually land it
<pitti> infinity: nope, that branch fixes those :)
<infinity> Erm, it does?
<pitti> infinity: it splits the "FAIL" state into ALWAYSFAILED (and britney will accept it) and REGRESSION (it succeeded at least once)
<infinity> Ahh, awesome.
<pitti> and everything is testcased
<infinity> This makes me very happy.
<infinity> I can probably scrap a few hints when that lands.
<infinity> pitti: This may be too much effort, so feel free to tell me to eff off, but could we also split the i386 and amd64 jobs the way armhf and ppc64el are split?  It seems like a monumental waste of resources every time I restart a failed/broken job and it rebuilds both.
<pitti> infinity: I wouldn't bother with jenkins any more TBH
<infinity> Though, I guess then they'd lose the "intuitive" linking between the two arches in the UI.
<infinity> pitti: Yes, I was hoping your response was "jenkins is going away tomorrow".
<pitti> infinity: as soon as I'm through with fixing those autopkgtest bugs, I'll continue working on https://wiki.debian.org/MartinPitt/DistributedDebCI
<pitti> infinity: well, I'd love for "tomorrow", just not quite there yet
<infinity> pitti: For large values of "tomorrow"? :)
<pitti> infinity: if everyone stops sending me fires to put out for a week or so, I can make some progress there :)
<pitti> infinity: at least I made some nice progress on the debci rearchitecture
<pitti> infinity: and I have a working prototype of the AMQP implementation
<pitti> infinity: the worker is literally just 130 lines of code or so
<infinity> pitti: I don't know what that means, but I trust it translates to "things will be more awesome".
<pitti> infinity: IOW, the entire worker/queue handling code is smaller than a single jenkins XML job config :)
<infinity> pitti: That seems like what I'd expect a worker to be, yeah.
<pitti> infinity: yes; replace jenkins with a set of AMQP queues (which are very robust, and no SPOF any more) and a distributed file system for the results
<infinity> pitti: Please share this awesome with everyone else in the company that uses jenkins as a crutch and purge them all. :P
<pitti> jenkins requires way too much maintenance, gets in the way, and becomes too much of a SPOF
<infinity> s/company/world/
<pitti> infinity: I can assure you the CI team is running full speed away from it :)
<pitti> infinity: e. g. the current CI train runs entirely without jenkins AFAIUI
<pitti> xnox: ah, my /etc/modules lost rtc! merci beaucoup :)
<infinity> pitti for President, with a campaign promise of "Jenkins-free by the next LTS"?
<pitti> infinity: next LTS? gosh, I hope "next release"..
<pitti> someone break my network for a week, and when I come back it should all be running :)
<infinity> Hah.
<infinity> We'll send doko over with scissors.
<pitti> I suppose my email server would already do
<pitti> ooh, "Jenkins Fixed - utopic-adt-libgmpada"
<pitti> does that mean the gnat/ada stack became installable now?
<infinity> doko merged gnat, I believe.
<infinity> So, it should be.
<pitti> yes, a while ago, but it made a ton of pacakges uninstasllable and thus britney unhappy
<pitti> ah, still does
<infinity> Looks like we at least need an easy hint for gnat/gnat-4.6  No idea why britney doesn't appear to be autohinting them.
<infinity> But things may well still be broken with that.
 * infinity does that now.
<pitti> infinity: well, in the recent runs it actually was uninstallable, like https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-libxmlada/6/ARCH=i386,label=adt/console
<pitti> e. g. libxmlada4.1-dev depends on gnat-4.6, while this tries to upgrade to gnat-4.9
<infinity> Ahh.
<pitti> so http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt seems quite right to me
<infinity> pitti: I wasn't implying output was wrong, just weird that it didn't autohint the two (which would still break other things)
<pitti> in the source I see
<pitti> Depends: ${misc:Depends}, ${ada:Depends}
<infinity> So, I assume anything with that dep needs a rebuild.
<infinity> Can transition in the morning if no one beats me to it.
<pitti> however, it build-depends on gnat, gnat-4.6 (why??)
<pitti> i. e. it'll need sourceful changes
<infinity> Sure, not rocket surgery.
<pitti> infinity: no, mostly checking if it still builds with 4.9 I suppose
<pitti> at least it's in debian as well, so these can be forwarded
<infinity> That particular one has an upload in Debian NEW that should fix it.
<infinity> Maybe we should just leave this alone while Debian does the transition.
<pitti> ooh, and there it is: https://ftp-master.debian.org/new/libxmlada_4.4.0puregpl-1.html
<pitti> right
 * infinity puts that transition back on ignore for a bit.
<infinity> I think I might try for an early night, so I have more time for hotel bacon in the morning.
<StevenK> infinity: Going to bed at 3am, rather than 4, you mean?
<infinity> StevenK: Shockingly, 11pm.  Though likely more like midnight when I finally sort out how to shut off my brain enough.
<infinity> (ie: when the drugs kick in)
<infinity> Toodles.
<s1aden> er, morning
* wgrant changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open, publisher stopped for maintenance | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> hallyn: I have a followup question on bug 1317179
<ubottu> bug 1317179 in systemd (Ubuntu Trusty) "lxc containers fail to start in trusty with newer kernels" [Medium,Confirmed] https://launchpad.net/bugs/1317179
<dholbach> good morning
<zyga> good morning everyone
<Wellark> hi!
<Wellark> is there a way to upgrade from trusty to utopic yet?
<Wellark> do-relese-upgrade -d says there are no new releases available
<Wellark> I could manually edit my sources.list, but that would throw away all the fail-safes do-release-upgrade provides
<RAOF> Wellark: do-release-upgrade provides no fail-safes at this stage ):
<RAOF> :)
<Wellark> well, it is able to roll back on some errors at least
<Wellark> actually I was thinking of running it with -s
<RAOF> Well, at the moment you won't get anything particularly different in utopic; it's fairly safe.
<RAOF> Although you will lose DNS resolving.
<RAOF> That might be an issue for you :)
<Wellark> I'm doing networking for touch.. maybe I could manage ;)
<Wellark> hmm.. seems we have a daily-live for utopic at least..
<mvo> Wellark: if you change your /etc/update-manager/release-upgrades from "prompt=lts" to prompt=normal do-releae-upgrade -d will work
<Wellark> mvo: I though -d explicitly overrides the config
<Wellark> will try that then
<Wellark> mvo: thanks! now it works
<mvo> Wellark: it does, but there are two channels (for lack of a better term) for upgrades, lts->lts and lts->normal and right now the upgrade is only available in the normal channel - I guess I should actually fix that and make it available in the lts->lts one as well
 * mvo makes a note
<xnox> pitti: well... we spawn user session init for some basic tests, and that was going on ahead and launching jobs from /usr/share/upstart/session... that's not good.
<pitti> xnox: ah, and that broke the upstart test?
<xnox> pitti: yeah, the test was racing the dbus user session job. thus retries on buildds, but an always loose ADT VM.
<zyga> hey, using gnome-shell (and gnome-control-center) display settings (particularly monitor arrangement) is lost after logging out and back again
<zyga> that works well with unity
<zyga> could be a missing upstart session job or something like that?
<zyga> note: changes are applied but they are not restored after logging in again
<darkxst> what should I do when a package wants to install something in "usr/lib/python3.4/site-packages/gi/overrides"
<darkxst> ^that shouldn't be hard-coded in an install file right?
<pitti> darkxst: doesn't dh_python3 take care of moving it into the right place? (or am I mixing this up with what dh_python2 used to do?)
<pitti> they need to go into /usr/lib/python3/dist-packages/gi/overrides
<pitti> infinity: oh wait, could that just be because britney didn't actually run (or finish) for several hours? excuses is from 04:13
<pitti> but I have a feeling that the publisher isn't running, so maybe britney just doesn't get triggered (it's not running at least)
<pitti> my change-override command hasn't gotten into effect for over an hour already
<Laney> pitti: the topic says it's stopped, so that sounds correct
<darkxst> pitti, nope dh_python3 doesnt move them
<pitti> Laney: ah indeed, missed the topic change
<cjwatson> pitti: Yeah, right now is probably not a good time to do proposed-migration maintenance since we won't see the results for some time :-)
<pitti> ack
* wgrant changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open, publisher stopped until ~15:00 | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> wgrant: thanks!
<mardy> pitti: hi! These autopkg tests fail apparently because some X11 dependency is missing: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/4/ARCH=amd64,label=adt/console
<mardy> pitti: am I missing something in debian/control?
<pitti> mardy: python-xlib apparently?
<pitti> oh wait, why doesn't autopilot-desktop depend on that
<pitti> it does
<pitti> mardy: ah, seems your test doesn't actually depend on autopilot-desktop :)
<pitti> mardy: you should use that instead of just python-autopilot to get the missing deps
<mardy> pitti: thanks a lot, I'll try that
<mardy> Mirv: should I add a commit to u-s-s-o-a to fix the above ^, or make a separate MP, or what?
<sil2100> pitti: hello!
<pitti> hello sil2100
<sil2100> pitti: I heard you're the best person to ask when there are mysterious autopkgtest failures going on - ubuntu-download-manager seems blocked in -proposed due to an autopkgtest failure, but it looks bogus, seems like more of some infra issue: i.e. https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-system-image/4/ARCH=amd64,label=adt/
<sil2100> pitti: do you know by any chance what's wrong and how to fix this? ;)
<pitti> sil2100: ah, it's creating the log file in the $ADT_ARTIFACTS/ directory apparently; I'm afraid 9p is really limited and you can't chown there
<pitti> sil2100: so if it's ok, I'd propose to create the log file in $ADTTMP instead, and after calling the test copying it to $ADT_ARTIFACTS
<pitti> sil2100: the alternative would be that autopkgtest would have to create the artifact dir in a VM-local dir and then always copy the thing to the shared 9p dir which introduces quite some penalty for large files
<pitti> sil2100: so in short, "qemu 9p sucks", but it's still the best of all horribly broken ways to communicate with a VM :/
<pitti> sil2100: i. e. change debian/tests/prep.py to set artifacts = os.environ['ADTTMP'], and add somethig like "cp $ADTTMP/client.log $ADT_ARTIFACTS/" to debian/tests/smoketest
<sil2100> pitti: thanks! Will do that :)
<pitti> and half of the kingdom for whoever comes up with a sane and efficient way to exchange files with a VM (which doesn't assume that the entire network stack and ssh are up, and that you have the credentials etc)
<ogra_> pitti, thanks for the answer yesterday ... i left a question on the bug already for the cordova stuff
<ogra_> (well, s/yesterday/this morning at an unholy time/)
<Mirv> mardy: you need a new landing probably
<pitti> ogra_: ack; I can also stop doing these seed changes during sponsoring, but it seems nobody else did it or updated that MP for months..
<Mirv> so, MP
<pitti> ogra_: and it looked ack'ed enough; so, sorry if that messed up something
<ogra_> pitti, well, it is probably valid (especially since it comes from dbarth)
<ogra_> as long as cordova 3.0 is fully backwards compatible we shoulld be fine ... it is just that framework changes should better be checked twice since we promise a 100% reliable framework for the ones we already released
<xnox> cjwatson: re:nvme looks good, thanks a lot.
<xnox> ogra_: framework version should be bumped, and old one still provided if new one is still compatible.
<xnox> ogra_: such that those that use 3.0 features, not present in 2.8, can set appropriate framework name.
<cjwatson> xnox: cool, I basically copied my earlier fusionio patch
<ogra_> xnox, right ... that change dropped something the old framework relied on
<ogra_> but we still support that framework
<cjwatson> xnox: it's building now, according to my laptop fans
<xnox> cjwatson: =)))))) excellent indicator.
<ogra_> xnox, thats why i was asking about it :) as long as 3.x is fully backwards compatible dropping is fine, i just dont know if anyone checked
<cjwatson> Also it vents heat at least in part through the bit where I rest my wrists - I think I shall go and have a belated breakfast rather than cooking my hands
<ogra_> winter laptop :)
<xnox> =))))) "winter laptop" that's funny. I really need a spring/summer 2014 collection laptop asap!
<basd82> What is the goog chanel to ask somting about the archive.ubuntu.com and security.ubuntu.com
<cjwatson> basd82: Not sure, would depend what the question was
<basd82> is the content security.ubuntu.com also on archive.ubuntu.com
<basd82> I made local mirror for our release party, and redirect nl.archive to local miror i prever to do the same with security du to low speed internet connection
<cjwatson> Yes.  security.ubuntu.com exists separately so that we can deliver security updates without having to wait for mirroring.
<basd82> Great so for the install party i can also redirect security to this local mirror
<cjwatson> For a local mirror you can just mirror archive.ubuntu.com; it will typically be ahead of security.ubuntu.com in sources.list and so apt will fetch packages from your mirror
<cjwatson> Even if you don't redirect security.ubuntu.com
<cjwatson> But for a short-term thing redirecting both should be fine.
<Saviq> jodh, hey, any ETA on releasing upstart with the fix for bug #1222705 ?
<ubottu> bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [Medium,Confirmed] https://launchpad.net/bugs/1222705
<cousteau> launchpad bug 932177 - could this be workarounded for 12.04 and other affected versions?  (see my comment at the end)
<ubottu> Launchpad bug 932177 in Xubuntu "XFCE (and other non-GNOME) desktops do not initialise gnome-keyring correctly / WARNING: gnome-keyring:: couldn't connect to PKCS11" [Undecided,New] https://launchpad.net/bugs/932177
<cousteau> the workaround is basically deleting the OnlyShowIn= line in the four gnome-keyring/daemon/gnome-keyring-*.desktop.in.in files
<cousteau> ubuntu 14.04 seems to have this application fixed so the annoying warning message isn't displayed, but other versions such as 12.04 are still affected
<xnox> Saviq: jodh: upstream release is not happening for a while, but we can cherry-pick that into ubuntu upload.
<Saviq> xnox, would be nice, we've been bit by it a few times
<xnox> Saviq: ack.
 * ogra_ looks around for a filesystem guru 
<ogra_> xnox, !
<ogra_> xnox, are you subscribed to the ubuntu phone ML ?
<ogra_> i'm wondering about some weird behavior of resize2fs
<ogra_> xnox, so to my knowledge resize2fs will never ever touch the underlying partition (or in the case we talk about the .img file) ... yet people seems to be able to just use resize2fs with our system.img file on the phone without dd'ing any additional space to it and the img gets resized
<ogra_> *seem
 * ogra_ wonders if resize2fs grew some secret new behavior, though the manpage still says it wont touch partitions
<xnox> Saviq: hm.... ?! that fix was released in upstream 1.12, and thus is in trusty and utopic.
<xnox> Saviq: are you sure it's the same bug? what package version did you see that bug with?
<Saviq> xnox, hmm interesting, I assumed that's that whenever I saw an init crash, will come back when I have more info
<xnox> Saviq: hm, the last line of the crash is from within libnih about to dereference a null pointer....
<xnox> Saviq: so it could be any other bug.
<pitti> cjwatson: it seems the publisher is running again; could we restart britney?
<pitti> hm, or maybe not
<pitti> LP thinks it ran (https://launchpad.net/ubuntu/+source/clustalw/+publishinghistory actually got published to universe), but rmadison disagrees
<infinity> pitti: britney will run itself.
<cjwatson> right, just leave it, it'll sort itself otu
<infinity> pitti: But the publisher is mid-run right now.
<cjwatson> *out
<cjwatson> it didn't run last time because the LP infrastructure doesn't cope well with extremely long publisher runs and the postgres connection timed out, so it never updated dists
<pitti> infinity: ah, thanks; wow, must be a hell of a run, for 5 hours already :)
<cjwatson> a number of a-f caches were absent
<infinity> pitti: We're doing Very Bad Things.
<pitti> thanks for the heads-up!
<mahmoh> mlankhorst: ping
<mlankhorst> pong
<mterry> pitti, poke about ofono test scripts.  dialer-app-autopilot seems to make the same calls the scripts do, but dialer-app-autopilot works and the scripts don't.  Do you know if there have been changed environment requirements?
<pitti> mterry: ah, I was going to reply to your question, but you weren't online; what was your problem with 199?
<pitti> mterry: if you dial that you'll get an ofono exception (that's normal with the simulator); perhaps that was what you were wondering about?
<mterry> pitti, naw, I'm used to the exception
<mterry> pitti, just nothing happens on the phone
<mterry> pitti, is it easy for you to try and sanity check my results?
<pitti> mterry: no, the scripts ought to work as well; d-a-ap just changed to doing the d-bus call manually to better handle that exception
<mterry> pitti, yeah I looked at its code, it seems to be doing the same thing indeed
<mterry> pitti, when I run the dialer-app suite, it works and I see the call (but no ring)
<pitti> mterry: what does the script do? after doing a call, do you see it in list-calls?
<mterry> pitti, when I run the script, it doesn't do anything
<pitti> so that's a recent regression then
<pitti> (in the middle of debug session with lots of brain state, so I'd prefer to try later rather than now)
<mterry> pitti, I get something from list-calls yeah
<mterry> and now it's gone
<mterry> so I think the call is happening
<mterry> pitti, OK, no worries.  I'll try to track it down.  But when you have an empty brain again, hit me up
<zyga__> looking at https://launchpad.net/ubuntu/utopic/+queue?queue_state=3&queue_text=sphinx -- when will sphinx move from proposed to main?
<cjwatson> category error: proposed is a pocket, main is a component
<zyga__> sorry, that's is correct,
<zyga__> so what is the name of the usual pocket?
<cjwatson> release
<zyga> ah, right
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sphinx lists a number of autopkgtest failures
<cjwatson> That may not be current as the publisher has been down for much of today
<pitti> https://code.launchpad.net/~jibel/britney/fix_missing_results/+merge/218467 will help with those and ignore tests which never succeeded (i. e. broken test)
<zyga> cjwatson: thanks, I'll keep that link around
<cjwatson> Right, those are all never-passed things
<pitti> I hope we can land that on Monday (or even tomorrow, although Fridays seem suboptimal for rolling out britney changes)
<cjwatson> I'm fine with landing it tomorrow morning; I'll be available if not necessary around at the weekend
<pitti> (WIP is right, jibel was working on some improvements after my initial review, but should be done tomorrow)
<pitti> apparently today is a French national holiday
<zyga> cjwatson: is there a way to force update on sphinx?
<zyga> cjwatson: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/sphinx/utopic-proposed/revision/49
<zyga> cjwatson: that's the effective delta that is currently blocked by the CI machinery
<cjwatson> It is possible, but I worry about leaving us without test cases for the (much more important) update to the machinery
<cjwatson> And any new builds in utopic happen against -proposed, so it shouldn't be urgent to push that through
<cjwatson> (You should be able to configure your PPA to build against -proposed temporarily, too)
<zyga> cjwatson: oh, is there a way to do that in a ppa as well?
<zyga> ah
<zyga> thanks, that's all I need
<cjwatson> "Edit PPA dependencies"
<zyga> right
<cjwatson> and select Proposed in the top radio group
<cjwatson> Increases the risk of transient failures in general, so it's right that it's off by default
<zyga> thanks, that should solve it for this single case
* wgrant changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Henne91> Hey everybody! I have a question concerning Unity/Debugging. Does anybody have an idea what is the best way to run unity-settings-daemon in debug mode right after boot?
<Henne91> The problem is, I am trying to debug an annoying bug but if I run "unity-settings-daemon --replace --debug" this will prevent the bug so I need to start it in debug mode right away.
<tarpman> Henne91: move/rename it and replace with a shell script wrapper? exec /usr/bin/unity-settings-daemon.real --debug "$@"
<Henne91> tarpman: sounds good, thanks ;-)
<stgraber> bdrung: hey, so with that last change you did to ifupdown we can actually start using exec ifup/ifdown again and so probably should. I rejected the upload for now, would be nice if you could re-upload with exec
<infinity> dh_install --fix-missing
<infinity> Unknown option: fix-missing
<infinity> zul: ^-- Did you mean list-missing?
<infinity> zul: Or fail-missing?
<infinity> zul: (Seen in the keystone build log, but could be in others)
<zul> fail-missing
<zul> ill fix it our bzr branch
<bdrung> stgraber: thanks for pointing it out. i will re-upload the package.
<prepangolin> any guys?
<bdrung> stgraber: can you reject the old precise and saucy ifupdown uploads?
<infinity> bdmurray: What triggers the phased update things?
<infinity> bdmurray: Cause you're running into the LP double-override bug and deleting binaries.
<stgraber> bdrung: sure
<bdmurray> infinity: its just a cronjob run every 6? hours
<infinity> bdmurray: Ugh.  Kay, so while we had the publisher offline for ~12h, every arch:all package you overrode twice disappeared from the archive.
<stgraber> bdrung: done
<infinity> bdmurray: That needs to be triggered to only run once per publisher.
<stgraber> smb: drbd8 accepted
<bdrung> stgraber: thanks
<infinity> bdmurray: I also have no idea how many binaries this affects.  I only noticed it by chance because someone mentioned python-seamicroclient in passing and I did an rmadison on it.
<infinity>  python-seamicroclient | 0.2.0-0ubuntu1 | trusty         | source, all
<infinity>  python-seamicroclient | 0.2.1-0ubuntu1 | trusty-updates | source
<infinity>  python-seamicroclient | 0.2.1-0ubuntu1 | utopic         | source, all
<infinity> bdmurray: Do you have logs or any way of knowing which packages you acted on in the last day, so we can hunt for fallout?
<bdmurray> infinity: this should help http://people.canonical.com/~ubuntu-archive/phased-updates.html
<infinity> So, anything in that list is suspect, I suppose.
<infinity> bdmurray: But I guess that doesn't list things that reached 100% in the last day?
<bdmurray> infinity: no, I can find that too
<infinity> bdmurray: That would be helpful.
<bdmurray> infinity: the last day being the last 24 hours or 05-08?
<infinity> bdmurray: The last 24h should do.
<cjwatson> bdmurray,infinity: It should be possible for the client to check for pending overrides.
<cjwatson> (Still racy in theory, but much less so in practice.)
<infinity> cjwatson: Triggering it from publisher-parts would probably be saner.
<infinity> cjwatson: trigger + timeout semaphore if you don't want it as frequent as the publisher itself.
<cjwatson> It's currently every six hours.  I don't think we want to crank it up quite that much.
<cjwatson> But I still think it should check for Pending publications, just in case somebody feels the need to run it manually.
<infinity> cjwatson: Every 6 hours with a semaphore would work fine, though.
<infinity> cjwatson: As in, I trigger you, you check if it's been >>6h since the last run, exit if not, run if so.
<infinity> (ie: the same thing we do for external mirror triggers)
<infinity> Anyhow, cleaning up the mess now.
<infinity> Enjoy the -changes spam.
<bdmurray> How do you check for publisher runs?
<infinity> bdmurray: We have hackish ways we do it now, but the better way is for the publisher to trigger you.
<infinity> Which I'm going to do for the archive reports.
<infinity> And could well do for this as well.
<infinity> Though, I suppose there's still a minor race with a real human double-overriding.
<infinity> We really need to fix that bug.
<bdmurray> infinity: so I have a list of packages that became fully phased, how I can check them for you?
<infinity> bdmurray: rmadison
<infinity> bdmurray: If there are arch:all binaries missing, life sucks.
<infinity> bdmurray: Or just give me the list, since I'm already doing it for the others.
<infinity> bdmurray: Alright, I'm done with the webpage you gave me.  How many more do you have?
<bdmurray> infinity: http://pastebin.ubuntu.com/7417678/
<cjwatson> Don't we want all phase changes, not just those to 100%?
<cjwatson> They all amount to override changes
<bdmurray> cjwatson: that was in the html report
<cjwatson> Oh right
<infinity> cjwatson: The pre-100% ones were at http://people.canonical.com/~ubuntu-archive/phased-updates.html
<cjwatson> Got it
<infinity> cjwatson: And -changes spam shows I checked those. ;)
<infinity> bdmurray: That would be much less painful by source package...
 * infinity sorts that out himself.
<infinity> Well, by source, and knowing which series...
<bdmurray> its all trusty
<infinity> Looks like gettext, clamav, marble, and kubuntu-meta, maybe.
<infinity> And kde-dev-scripts
<infinity> Alright, those are all copied.
<smb> stgraber, Your kernel is ready to be picked up
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<saiarcot895> Just to check, are we allowed to ask here if anyone is willing to sponsor an SRU?
<ari-tczew> saiarcot895: yes, you're allowed. the best is subscribe to ubuntu-sponsors @bug. is your patch already ACK'ed by SRU team?
<saiarcot895> ari-tczew: no, I thought ubuntu-sponsors had to approve it first.
<saiarcot895> For the record, the SRU/patch to review is https://bugs.launchpad.net/ubuntu/+source/checkstyle/+bug/1308794
<ubottu> Launchpad bug 1308794 in checkstyle (Ubuntu) "Checkstyle unusable on Trusty" [Undecided,In progress]
<ari-tczew> saiarcot895: https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=SRU#Procedure
<ari-tczew> step #6 says: "The ~ubuntu-sru team will review and approve then the archive admins will accept your upload."
<saiarcot895> ari-tczew: But step 5 says "Upload the fixed package to release-proposed with the patch in the bug report", and, if you can't upload, to get a sponsor
<robert_ancell> bdmurray, hey, so I'm getting emails from you (automated?) about the the nautilus SRU (bug 1286766) not rolling out further because errors.ubuntu.com is picking up new stack traces. I'm not sure that the traces are due to the patch, how do we continue from here?
<ubottu> bug 1286766 in Nautilus "Crashes on startup if shows "required directories missing" dialog" [Critical,Fix released] https://launchpad.net/bugs/1286766
<bdmurray> robert_ancell: those are from the phased-updater and are automated. if an individual crash isn't new we can override the phased updater check for that spefici crash.
<robert_ancell> bdmurray, sorry, be back in 10mins
<robert_ancell> bdmurray, sorry about that. The stack traces are new but I think they might be from the same underlying cause
<robert_ancell> so that is tricky as there might be a new stack trace every few days :/
<robert_ancell> bdmurray, is there a way of finding out if the rate of errors has increased in the users who have the SRU?
<bdmurray> robert_ancell: there is a check to see if the rate of errors for all users has increased
<bdmurray> robert_ancell: comparing rate of crashes for the previous package version to the new package version
<robert_ancell> bdmurray, but we don't know the number of users for the previous / new so we can't do a comparison right?
<robert_ancell> or is the upgraded users just a fixed percentage so we can assume?
<bdmurray> robert_ancell: if this is a critical issue as the bug seems to indicate we can manually set the phased-update percentage to 100%
<robert_ancell> bdmurray, can we get those crash rate numbers for 1:3.10.1-0ubuntu8 and 1:3.10.1-0ubuntu9 and check they have the expected ratio?
<Gladiak> hi everyone
<Gladiak> i've a little question related to mono and shell command
<Gladiak> could you help me ?
<bdmurray> robert_ancell: I've an errand to run but will look into the rate when I return
<robert_ancell> bdmurray, ok, thanks
<dobey> Gladiak: this channel is about development of ubuntu itself (mostly about the foundation), not really about development of arbitrary apps on ubuntu.
<Gladiak> ah ok sorry
<dobey> Gladiak: also, just ask your question on irc. don't ask to ask. if anyone has an answer, they'll reply with it
<Gladiak> first time for me on irc :/
<Gladiak> ok sorry again :Â°)
<Gladiak> i've a problem running this command in a gtk# mono app: sudo dpkg --set-selections < /home/$USER/pack_list
<Gladiak> i'm trying to build a "backup" program to restore a system after a format
<Gladiak> but i can't find a method to run sudo command in a terminal using mono
<dobey> you shouldn't run sudo from an app
<dobey> you should use the PolicyKit API to run commands that require elevated privileges
<Gladiak> mmm i see
<Gladiak> i'll try that, maybe it could works
<Gladiak> p.s: sorry for my english :/ i don't speak (and write) english so often
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<robert_ancell> bdmurray, I get http://paste.ubuntu.com/7418700/ as a result of that link - is that correct?
<bdmurray> robert_ancell: yes, it is
<robert_ancell> bdmurray, ok, and to confirm this is showing that there's different crashes but not an increase in the rate of crashes?
<bdmurray> robert_ancell: so the crash rate doesn't take into account the number of users and needs to be fixed
<bdmurray> robert_ancell: mostly yeah
<bdmurray> robert_ancell: here is the raw data - http://pastebin.ubuntu.com/7418714/
<robert_ancell> bdmurray, ok, then I'm confident this SRU is not causing the new crash reports. Let's set the phased release to 100%
<robert_ancell> so that says there's 10% of the crashes in the new version and I'm assuming it's rolled out to 10% of the users?
<bdmurray> robert_ancell: only update-manager respects the phased-update percentage so if people install view apt-get install or synaptic or some other packager it could be higher
<robert_ancell> right
<bdmurray> and I mean via and package manager of course
<robert_ancell> But 10% seems in the right ballpark. I wouldn't want to see the same number of crashers in the new group and the old group
<bdmurray> okay and so you think fully phasing it is a good idea?
<robert_ancell> bdmurray, yes
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<bdmurray> slangasek: can you take care of setting nautilus in trusty to a phased-update-percentage of 100?
#ubuntu-devel 2014-05-09
<xnox> zyga: barry: what's the status on pyotherside? =) I'd like to port usb-creator and ubiquity to qt5, and i think pyotherside is the way of the future =)
<xnox> zyga: barry: also that should pull in qt stuff into main ;-)
<xnox> (well pyotherside)
<slangasek> bdmurray: done
<zyga> xnox: you can play with it on a ppa
<zyga> xnox: it's still in NEW in debian
<zyga> xnox: I was playing with it on nexus 7 today, a bit slow so far
<zyga> xnox: works okay on the desktop though
<zyga> xnox: get the package and have a look at the examples
<zyga> xnox: if you need armhf packages they are built in ppa:checkbox-dev/ppa
<zyga> xnox: as for pulling into main, qt is in main already
<zyga> xnox: so is python, only pyotherside isnt
<zyga> xnox: depending on what you need to call from ubiquity and usb-creator you should have fairly easy access to anything visible from python (gi, dbus)
<zyga> xnox: keep in mind though, that you can only return simple objects (think json) across the qml/python bridge
<zyga> xnox: so you can list all partitions and keep a model in python (if needed) but you must dumb it down to a list of dicts of strings/ints/lists etc if you want to push it to qml
<zyga> xnox: I think it generally works but needs consideration on how the app will work
<ScottK> Since ubiquity and usb-creator already use PyQt, seems like a lot of work.
<zyga> ScottK: I think it depends on QML, if you want Qt5 -- fine, if you need to work in QML current bindings are a bit heavyweight and you need to rewrite the UI anyway
<ScottK> usb-creator-kde uses PyKDE4, so that'd be a tough one to support.
<zyga> ScottK: pyotherside is remarkably tiny, that is a good thing to support
<ScottK> How do you do KDE bindings with it?
<zyga> ScottK: well, it doesn't do anything related to KDE
<zyga> ScottK: I meant in comparison to python + something-qt
<ScottK> So it's not helpful for at least one of the usb-creator front ends.
<ScottK> Also, does it provide a dbus mainloop?
<ScottK> You kind of need that for these apps too.
<zyga> ScottK: from what I think so far you just use qt5 + python dbus loop (the one already packaged)
<ScottK> OK.
<zyga> ScottK: the thing with pyotherside is that you don't block the UI no matter what happens in python
<zyga> ScottK: python can be busy computing stuff/waiting for stuff and QML is not affected because all the requests are asynchronous
<zyga> ScottK: it's kind of paiful at first but seems to work better than our C++ + QML approach earlier
<xnox> ScottK: it's async gui which can receive callbacks from python, or send requests async to python.
<ScottK> Seems more interesting for new projects than porting existing stuff to Qt5.
<zyga> ScottK: yeah, I think you are right
<zyga> ScottK: if you need to jump from qt4 or gtk to QML+SDK then it makes sense IMHO
<xnox> ScottK: currently we have a lot of glue code in the backend which does "display this" "query that", which tries to be "toolkit" agnostic, but really isn't.
<zyga> xnox: :-)
<zyga> xnox: do you want it to work on the phone/tablet or just on the desktop?
<xnox> ScottK: i'd rather have "oh i'm shiny ui", "oh backend told me to display 10 usb disks in a list", "oh user made all of it's selections lets shove it into backend", "oh backend didn't like it"
<xnox> or "oh backend says we are 20% done"
<xnox> zyga: i want to have as little gui code in my backends as possible & I must send / communicate with UI in async manner.
<ScottK> I wonder when we have bindings for KF5 if this'll be easy using bits of it.
<zyga> xnox: so I think this will just work for you
<zyga> xnox: we're in the same situation with checkbox
<zyga> ScottK: KF5?
<xnox> ScottK: so far pyotherside looks like the best model-view-controller separation that i can find.
<ScottK> KDE Frameworks 5, the Qt5 based replacement for KDE libs.
<zyga> ah
<xnox> ScottK: where models are in python, yet view/controller is in qml/qt/gui
<ScottK> Instead of one big library, it's (IIRC) 61 so it doesn't have to be heavy.
<ScottK> xnox: Do you know where we are on Qt 5.3?
<ScottK> Looks like the new plasma will need 5.3.
<xnox> ScottK: does that double the number of kde* packages in the archive? or even tripple it?
<ScottK> Not even.
<xnox> ScottK: i'm not that much involved in qt packaging. Send email to ubuntu-devel?
<xnox> ScottK: well i guess you're keeping qt4 ones for now as well.
<ScottK> On my list.  I just thought you might know.
<ScottK> Yes.  For 14.10 we'll release a Qt4/KDE4 based desktop.
<xnox> ScottK: busy working on upstart/python2-removals mostly.
<ScottK> We want all of KF5 in the archive though so it's available for developers.
<ScottK> Not sure if plasma 2 will make it in the archive or not, but we'll definitely make it available somewhere so we want 5.3 if we can get it.
<robert_ancell> bdmurray, is there a way to generate the errors.ubuntu.com graph as far back as we have data?
<xnox> robert_ancell: if i remember correctly all data is not in one place. at one point cassandra fell over it's head and data was archived elsewhere, and then a new cassandra got brought up to deal with fresh data.
<robert_ancell> xnox, oh so the graph (which seems to show ~1 year of data?) is all the "new data" only?
<xnox> robert_ancell: it's highly inaccurate though. It counts total amount of users using heuristics of unique count of machines submitted any reports over a period of past X days.
<robert_ancell> xnox, I was wondering why it all converges like crazy on the left - I wonder if that is a side effect of the heuristic
<xnox> robert_ancell: and then counts a rate of errors within that pool. which clearly is bogus during a surge of machines, aka release date.
<xnox> ... or like inception of the data base =)
<robert_ancell> ha!
<xnox> i think it was also up for a couple of days, then down for a few and up again. making the beginning of the graph look crazy =)
<xnox> robert_ancell: login on the top right and look at https://errors.ubuntu.com/ops/instances/
<robert_ancell> xnox, whats the y-axis there?
<xnox> robert_ancell: it tells the tale that everyone uses LTS and upgrades to next LTS.
<xnox> robert_ancell: and !lts migrate to next release swiftly see 13.10 release date.
<xnox> robert_ancell: in my high scool that graph would get zero marks, because units are not specified.
<robert_ancell> I think any school would do that
<xnox> robert_ancell: so i guess this is calculating Ingress Mind Units per ubuntu release over time =)
<robert_ancell> I wonder if this is absolute number of reports?
<xnox> robert_ancell: or maybe unique machines making a report?
<robert_ancell> It does seem like a more useful graph than the first one
<xnox> robert_ancell: not sure which of the two is worse: only 100k of crash reports, or only 100k of users reporting.
<xnox> robert_ancell: this one is raw data, the other one applies a lot of math to answer the question "Is this release more stable than the other one"
<xnox> robert_ancell: the most useful bit however is, that we track SRU regressions via errors histograms per package/version combos. And we phase the SRU updates, thus broken SRUs get detected quickly and pulled (set phasing to zero -> update manager doesn't upgrade it)
<robert_ancell> the latter graph suggests 75% of 13.10 users have migrated in a month which is pretty impressive
<xnox> robert_ancell: well they get notification to upgrade. Average time for SRU update is ~2 weeks. (you can see drop-off in crash reports on a given bucket/bug)
<xnox> robert_ancell: so a month for a "i will need to download this for a long time" sounds awesome =)
<sarnold> I seem to recall that -updates gets suggested weekly, while -security is suggested daily; is that correct?
<robert_ancell> yeah, I'd have expected people to be a lot more conservative. I guess the 13.10ers are all developers and willing to do the upgrade
<xnox> sarnold: sounds about right.
<xnox> sarnold: oh, in that case 1w to update is near-instant =) as in when offered.
<xnox> sarnold: i wonder if we should change that to daily though.
<robert_ancell> developers or technically minded users
<sarnold> xnox: yeah, and 2w is "oh it bugged me once already I should do that"  :)
<xnox> sarnold: because only ~10% will get the update offered on day one anyway.
<sarnold> xnox: I'm mindful of the complaints I've heard about firefox/thunderbird "gee another update already??" -- but we do security updates nearly every MTWT, we're probably already giving that feeling..
<mun24> Hi all
<mun24> I compiled wu-ftpd but is not accepting connection
<sarnold> mun24: I'm headed out but three thoughts: (a) ftp is a horrible protocol, please don't use it unless you have to (b) check firewalling, iptables -L or ufw.. (c) check netstat -anp to make sure it's listening on the ports and IPs you expect
<slangasek> (d) if you're going to run an ftp server, why would you not run one that's been updated in the past decade with at least some attempt at security
<mun24> that is for minternal purpose
<mun24> internal
<mun24> I want to do high speed upload. I already wrote a windows client for it
<mun24> but experiencing some problem so want to troubleshoot
<slangasek> well, this isn't really the channel for that
<mun24> I just want to understand how to install wu-ftpd server after compiling it
<slangasek> there are plenty of ftp servers in the archive that you could install and run; if you choose not to use them and compile a different one for yourself, you're not going to find support for it on this channel
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<dholbach> good morning
<Riddell> good morning dholbach
<dholbach> hi Riddell
<pitti> cjwatson, infinity: ah, FYI, jibel is on holiday today, so the britney fix will have to wait until Monday
<didrocks> pitti: all those frenchiesâ¦
<pitti> dpm: it seems I finally managed to put out all the fires in http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/, so I'll get to your langpack mail ASAP
<dpm> awesome, thanks pitti!
<pitti> and I officially hate 9p now :)
<dpm> hi happyaron, so regarding your e-mail, would you recommend to test "Droid sans fallback" in the touch images for Simplified Chinese? Do you happen to know how to set the default font?
<happyaron> dpm: I don't know about touch, but for desktop version it's set by language-selector
<dpm> yeah, I don't know if we can use the same, we'd probably have to put the image in RW mode
<dpm> pitti, if we'd want to test different fonts for Simplified Chinese on the phone images, would you happen to know how to switch fonts? Or do you know who to best ask?
<pitti> dpm: I only have a very vague idea about how fonts are selected; I think font packages ship some fontconfig snippets whcih define a font selection priority for glyph ranges
<cjwatson> pitti: hm, ok, thanks
<pitti> dpm: so that e. g. a font optimized for Korean could mark the Korean-specific glyphs as preferred, but leave latin or math chars to other fonts
<pitti> dpm: so for switching fonts you'd have to edit those
<pitti> dpm: but I'm afraid the above already exhausts my fontconfig knowledge
<dpm> pitti, that's definitely much more than I knew, so thanks :)
<pitti> dpm: GunnarHj might have an idea
<pitti> dpm: I don't think he's an "expert" either, but at least he recently fixed a couple of bugs in that area
<dpm> ok, cool
<jamesh> mardy: not sure if you saw it or not, but I replied on https://bugs.launchpad.net/ubuntu/+source/signon-plugin-oauth2/+bug/1316021 that your signon-plugin-oauth2 fix solved the problem for me
<ubottu> Launchpad bug 1316021 in signon-plugin-oauth2 (Ubuntu) "OAuth2 Tokens from providers that don't provide an expiry date are incorrectly expired on first use" [Undecided,Confirmed]
<pitti> cjwatson: do you know why we have ubuntu-touch.utopic seeds, but the packages (e. g. unity8 or indicator-bluetooth) don't have a corresponding Task: ?
<cjwatson> pitti: We only generate tasks for a subset of seeds; the ubuntu-touch seeds are only used to generate metapackages
<cjwatson> pitti: A seed only gets a corresponding task if it has some Task-* headers
<cjwatson> Oh, ubuntu-touch does have Task-* headers, now that I look
<cjwatson> pitti: In that case it's because ubuntu-touch isn't listed in FLAVOURS in cronscripts/publishing/cron.germinate in Launchpad
<cjwatson> pitti: I'd probably only fix this if the touch people actually want tasks for some reason
<pitti> cjwatson: I was looking at that as dpm asked me about options for generating touch langpacsk
<pitti> cjwatson: so I'm looking for way to tell "is package X on touch"
<pitti> and I first looked at Tasks: and then at http://people.canonical.com/~ubuntu-archive/germinate-output/
<pitti> cjwatson: ubuntu-touch depends: helps quite a bit indeed, but doesn't get us dependencies; but I suppose langpack-o-matic could just run germinate by itself for that?
<pitti> i. e. check out lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.$RELEASE, run germinate, use the result as a package list to match against?
<ogra_> cjwatson, are the task headers not needed for proper germinate output ?
<pitti> I thought the Tasks: headers come *from* the germinate output?
<cjwatson> pitti is correct
<ogra_> ah, k
<cjwatson> pitti: So, I mean, I could if it would be useful to you, certainly
<cjwatson> I just didn't want to bother if it was only for consistency or something
<ogra_> pitti, important thing: touch uses no-install-recommends ...
<pitti> cjwatson: if it's possible that langpack-o-matic runs germinate by itself, that's fine by me (certainly much cheaper to only do that once a month or so and without adding to the size of Packages.gz)
<cjwatson> pitti: You can certainly do that if you like
<ogra_> (but the germinate output reflects that since a few weeks)
<pitti> ogra_: ah, good
<cjwatson> ogra_: A bit more than that, I thought - didn't I fix that in r136, 2013-11-21?
 * pitti RTFMs germinate to find out the invocation
<ogra_> cjwatson, only half of it ... xnox recently found that you need some "* ..." entry inside the seed file too, you added it to STRUCTURE back then
<cjwatson> Oh, it actually looks like no-follow-recommends isn't honoured in STRUCTURE at all
<xnox> cjwatson: i did add Feature: no-follow-recommends in e.g. r171
<cjwatson> xnox probably should have got me to fix germinate instead
<ogra_> PES uses the germinate file as input for their own git server (they branch all the trees of all touch packages) and that had a weird set of packages ... which made us look
<mardy> jamesh: oh, I didn't see it! I'll try to get that merged soon, then
<xnox> cjwatson: hm. I've inspected lubuntu seed (which did work as expected) and mimicked it.
<cjwatson> So the seed change is an OK fix, but I'll fix germinate to honour the way I thought it worked when I made my change
<jamesh> mardy: thanks for doing the fix.
<cjwatson> Hm, or maybe that would have bad effects on inner seeds inherited from platform
<xnox> ogra_: hm, not their own git server. they branch bzr branches, and index them for search similar to e.g. opengrok but using some other indexer. aka similar to ubuntu-codesearch.surgut.co.uk but limited in scope with history.
<cjwatson> Might need to think about that
<ogra_> xnox, oh, i thought it was a git server with a gerrit instance
<xnox> ogra_: git + gerrit is used for e.g. android code hosting like https://code-review.phablet.ubuntu.com/#/q/status:open,n,z
<ogra_> yeah i know
<xnox> ogra_: and the code search indexer will be public once it's hosted on prodstack.
<ogra_> not talking about our android trees ... i though that PES server was git too
<ogra_> thanks for clearifying :)
<pitti> cjwatson: does that look like a reasonable invocation? germinate -v --bzr --no-installer -s ubuntu-touch.utopic -d utopic -a armhf -c main,universe -m http://ports.ubuntu.com/
<pitti> cjwatson: I'm just a bit unsure how to use the result; for example, the generated "touch" file does not contain most of the indicators which are in the seeds (like indicator-bluetooth); that one is in "all", but that also has firefox and lots of stuff which we don't need
<pitti> cjwatson: so "touch" plus "sdk-libs" looks reasonable, does that sound right?
<xnox> $ seeded-in-ubuntu indicator-bluetooth -> ubuntu-touch: daily-preinstalled
<xnox> pitti: so somehow at least generators on ubuntuwire figure it out.
<xnox> pitti: firefox is in, because i think its translations debs get pulled in via langpacks chain of dependencies.
<cjwatson> pitti: Generally speaking you need to follow through the inheritance tree given in the "structure" output file
<cjwatson> pitti: I'd recommend using --no-rdepends, since that makes a noticeable performance difference; --bzr is probably mostly unnecessary these days; and -v is likely to be very boring :-)
<pitti> cjwatson: oh wow, it's really fast with --no-rdepends, thanks :)
<cjwatson> xnox: seeded-in-ubuntu isn't a very useful comparison for this, I think, because AIUI it looks at image manifests
<cjwatson> (Its name is a lie)
<cjwatson> touch: minimal sdk-libs
<cjwatson> pitti: ^- so that bit in structure tells you that the touch seed assumes that those other two seeds are already in place (and iterate)
<pitti> cjwatson: ack; so if I expand this by hand, that would be touch plus sdk-libs plus minimal; and I ignore supported and -dev
<cjwatson> Yeah, in general just ignore output files that aren't explicitly on your chain
<cjwatson> Since there'll be a ton of random stuff
<cjwatson> They're pretty much all used for *something somewhere*, but most consumers only need small bits
<pitti> cjwatson: yeah, wrt. langpacks I think we can safely ignore -dev
<cjwatson> I suspect so, yes
<pitti> I'm mostly interested in the visible part of the images that we ship
<pitti> I assume apps/clicks will continue to ship their own translations; I don't think it makes any sense to langpackify them
<cjwatson> Right
<pitti> and I'm not entirely sure yet whether and when we'll move to touch langpacks; this is mostly research for dpm and for discussion at this point
<ogra_> pitti, hopefully before release :)
<dpm> thanks pitti
<cjwatson> xnox: A few packages are dep-wait on the latest debhelper, and you're TIL; could you merge it?
<xnox>  cjwatson ack.
<xnox> also delta can become smaller, since we released lts.
<mpt> ev_, bdmurray: Is there a reference anywhere for how a developer can report a RecoverableError?
<xnox> tedg: ^ ?
<xnox> tedg wrote a few...
<xnox> slangasek: why do we _not_ call update-rc.d by default if both init.d & upstart jobs are present?
<xnox> pitti: does systemd, for sysv init units, need update-rc.d call? (and thus symlinks in rc*.d dirs?)
<pitti> xnox: yes, unless of course there's a real unit with the same name to replace it
<xnox> pitti: thanks.
<pitti> it keeps the sysvinit semantics (just starting everything would be wrong and too much)
<xnox> pitti: =) so i guess debhelper in ubuntu, should start calling udpate-rc.d then =)))))) we have that conditional if [ ! -e /etc/init/$foo.conf ]....
<pitti> xnox: ah, you mean for providing sysv fallbacks with systemd? yes, that sounds sensible
<pitti> xnox: not sure why it didn't create symlinks, perhaps just for avoiding unnecessary work?
<pitti> xnox: how does upstart run the sysv scripts, directly parsing LSB headers?
<pitti> xnox: ah no, ignore that question, that was stupid
<pitti> xnox: so yes, either extend the test to /etc/init/$foo.conf && /lib/systemd/system/$foo.service or, just call update-rc.d
<pitti> we need update-rc.d for enabling systemd units too
<xnox> pitti: i'm trying to recall, if things would break. On debian side, startpar et.al. are upstart aware and thus do not run symlinks from rx*.d directories if there is equivalent upstart job.
<xnox> pitti: i'm not sure if that was done or not.
<xnox> pitti: or depeneds on the merge of doom that didn't happen.
<xnox> pitti: i think it's safer if i go with extending the check to "...and no unit file"
<pitti> xnox: hm, I can't tell off the back of my head, but I think eventually we need to fix that anyway as names of units, jobs, and init.d scripts don't always match up
<pitti> xnox: that would be the "service" script, right?
<pitti> xnox: so our service script is already upstart aware, but not yet systemd (or openrc) aware, that's the current delta to -53
<pitti> (looking at my local merge)
<xnox> and there is no delta to startpar?
<pitti> xnox: there's quite a large one; startpar was split out into a separate package
<pitti> which is stuck in -proposed until we merge
<pitti> xnox: in our version it's a huge patch against sysvinit
<pitti> I haven't checked the "net diff" between those
<xnox> "net interdiff" i guess =)))) oh, my.
<pitti> as I thought it's fairly uninteresting to us?
<pitti> xnox: well, it's a native source package now
<xnox> it's just e.g. if a job is stuck in waiting state (waiting for some event) i don't want runlevel 2 kick in and do service foo start, disrespecting (potentially extra) "start on..." conditions and thus starting a job pre-maturely.
<xnox> i'll do this change separately rebuild at least rcS/rc0/rc6 jobs and make sure my desktop at least boots/shuts-down without problems.
<xnox> diff -r -U4 sysvinit-2.88dsf/startpar/ startpar-0.59/ | diffstat is only 11 files changed, 116 insertions(+), 41 deletions(-)
<xnox> pitti: so i wonder, if we can inspect that delta, and land split out startpar, on top of our sysvinit.
<xnox> pitti: would that make future sysvinit merge smaller?
<xnox> pitti: the two are exact equivalents, sans refactoring and new one accepting options if it needs to be executed against /etc/init.d or /etc/rcX.d etc.
<xnox> pitti: can i see your sysvinit merge somewhere?
<pitti> xnox: startpar is already in utopic-proposed, and I uploaded our Ubuntu delta there
<xnox> pitti: ah, cool.
<pitti> xnox: http://people.canonical.com/~pitti/tmp/sysvinit_2.88dsf-53ubuntu1.dsc
<pitti> xnox: NB that this currently moves to insserv, i. e. dynamic reordering of the [SK]NN levels
<pitti> xnox: I didn't have time to continue working on this since I asked slangasek and you (and devel@) about insserv
<pitti> xnox: so perhaps run it in a VM (although I've run it on my desktop for a week without any problems)
<pitti> xnox: oh, and that one has "Drop startpar dependencies, we don't need that in Ubuntu where we only support upstart." â I'm not currently sure whether that's actually true, that point was on my TODO list
<xnox> pitti: i guess in debian we do need upstart & upstart-core.
<xnox> pitti: well, first we need to land "Remove various initscripts (and an ifupdown hook) that have been replaced by upstart jobs shipped in other packages."
<xnox> as in, reinstate those init.d scripts, iff there is no systemd unit for them.
<xnox> or they are needed for insserv to work.
<pitti> xnox: mostly for the latter, yes
<pitti> xnox: quickly running through them and seeing which we are missing
<pitti> - /etc/init.d/motd
<pitti> xnox: ^ yes, that's the only one
<pitti> xnox: oh, and the ubuntu specific /etc/init.d/ondemand
<pitti> xnox: seems we don't have an upstart job for that
<xnox> funny, ha =)
<xnox> pitti: in your test machines do you have /etc/init.d/.legacy-bootordering ?
<xnox> (and new sysvinit)
<pitti> xnox: I do, but I think with that merge this is ignored as that isn't supported any more
<pitti> i. e. -53 only supports insserv now
<pitti> xnox: and I think we still have some delta for this in the merge; but I kept it for now as I wasn't sure whether we go that route
<pitti> it seems we agreed on "if we add back the important init.d scripts so that insserv gets things right, we use it", right?
<xnox> cause conversion is suppose to run.
<xnox> i'll revert that portion and thus trigger conversion to insserv with current sysvinit and check how far it would get me.
<pitti> xnox: I'm not currently sure how to tell apart "good" from "bad"
<pitti> i. e. what constitutes a broken ordering
<xnox> pitti: (a) will sysv-rc succeed to configure and migrate to insserv (b) ability to boot, reboot, shutdown, halt, use single user mode.
<xnox> the rest are bugs we would be able to sort out.
<pitti> ah, that's simple enough
<pitti> xnox: ah, warning, I don't think that merge adjusts the update-rc.d path to insserv for our changed location
<pitti> xnox: it's pretty much an "in the middle of testing and see what's wrong" state, when I had to stop and put out fires :/
<pitti> xnox: I hope I can get back to it next week though
<pitti> as with our current update-rc.d, many packages fail to upgrade/configure badly
<pitti> (when running systemd)
<xnox> i wonder what would happen if i execute all of: grep -A1 '! -e "/etc/init/' *.postinst | grep update-rc.d
<psusi> xnox: a while back you patched the reboot command in upstart to try and pass the REBOOTCOMMAND to the reboot syscall... it seems this patch introduced a bug #1174272, but I really wonder.. why did you do this? it looks like the kernel itnores the argument anyhow and sysvinit never bothered trying to pass it
<ubottu> bug 1174272 in upstart (Ubuntu) "'reboot now' reverting to maintenance mode" [Undecided,In progress] https://launchpad.net/bugs/1174272
<ogra_> psusi, the phones (which are using an android bootloader and kernel source) need an arg handed over ... i.e. to boot into recovery mode
<ogra_> sudo reboot -f recovery ... sudo reboot -f bootloader ... etc
<psusi> ahh
<ogra_> the bootloader picks it up and pre-fills bootreason= on the kernel cmdline ... the kernel then picks it up and boots to whatever is defined for a bootreason
<psusi> ok... proposing branch merge now of a one line fix to correct the regression that caused
<psusi> would have been nice to mention that in the changelog ;)
<psusi> https://code.launchpad.net/~psusi/ubuntu/utopic/upstart/fix-reboot/+merge/218997
<xnox> psusi: this is wrong.
<xnox> psusi: time option may not be passed to reboot command.
<xnox> psusi: why do you expect that?
<xnox> psusi: all of "reboot, halt, poweroff" do not take a time parameter.
<xnox> psusi: "shutdown -r now" is to perform reboot with a time parapeter, aka emmidiately now.
<psusi> xnox: I know that, but REBOOTCOMMAND is only supposed to be honored in conjunction with --force
<psusi> otherwise it should be ignored
<psusi> your patch to pass REBOOTCOMMAND with --force added a new mode enum, REBOOTFORCE, that caused the non --force path to forget to add the -r switch to the regular reboot command
<xnox> psusi: looking.
<xnox> psusi: but i have to.
<psusi> fixing it is as simple as adding the new enum to the case statement and letting it fall into the old one ;)
<xnox> psusi: -f bypasses invoking shutdown first, before doing reboot syscall.
<xnox> psusi: the rebootcommand is always passed to the syscall.
<psusi> right.. and without -f, we invoke shutdown... which should be with the -r switch, but your new REBOOTCOMMAND enum caused the -r to be dropped
<psusi> the syscall is only invoked with --force, man page even explicitly says that without --force, shutdown is run *without* REBOOTCOMMAND
<bdmurray> mpt: there is an issue with recoverable problems that needs to be addressed - bug 1316763
<ubottu> bug 1316763 in Daisy "bucketing of recoverable problems is done poorly" [Undecided,New] https://launchpad.net/bugs/1316763
<psusi> which is true, it is run without rebootcommand, but also without -r, which is wrong
<xnox> psusi: syscall is invoked, if one is in runlevel 0, 6, or --force was given.
<psusi> xnox: right.. and otherwise shutdown is run...
<xnox> psusi: remember that shutdown(8) -r eventually calls reboot.
<psusi> the error is that shutdown is being run without the -r switch because of the new enum you added... so instead of rebooting, it goes ot single user mod
<xnox> psusi: "reboot now" is not suppose to invoke "shutdown -r"
<psusi> yes, it is
<psusi> reboot is supposed to invoke shutdown -r... any argument following it is ignored
<psusi> ( again, when not using --force or in runlevel 0 or 6 )
<psusi> in other words, reboot now, or reboot foo, or reboot whatever used to all work since the argument was completely ignored... as it is supposed to be according to the man page... after your patch, it has the side effect of dropping the -r switch to shutdown so instead of a reboot, you get single user mode
<xnox> psusi: i still didn't get your argumentation.
<xnox> psusi: i understand marga's comments though.
<xnox> psusi: where she says it wouldn't be a bug if syscall with "now" arg would be executed =))))
<psusi> did you look at the actual patch yet?  it's pretty clear when you look at the code ;)
 * psusi waits to hear the sound of a facepalm
<xnox> psusi: the patch is also wrong, not future proof, against wrong branch =)
<xnox> psusi: http://paste.ubuntu.com/7421706/ ?
<psusi> against the wrong branch?
<psusi> ahh, that works too
<xnox> psusi: yes, upstart is developed in lp:upstart.
<xnox> psusi: the bug is that, we went down runlevel2 codepath. Valid modes in runlevel2 codepath are only those that it handles.
<xnox> psusi: and as per manpage, REBOOTCOMMAND mode should only be valid when force is active.
<psusi> right, that's what I've been saying... otherwise it's ignored ;)
<xnox> psusi: and slitgthly above "force" is defined as --force or runlevel 0 or runlevel 6.
<psusi> cjwatson: the grub ls command is built into the normal module and so should never need to load a module when run right?  Or did this change in the latest grub?
<psusi> this bug #1316068 is just weird...
<ubottu> bug 1316068 in grub2 (Ubuntu) "error: disk 'hd0,msdos5' not found" [Undecided,New] https://launchpad.net/bugs/1316068
<cjwatson> psusi: ls is a separate module
<seb128> who is "owning" ubottu? can we get it in #ubuntu-desktop as well? ;-)
<seb128> (we had an ubot but it went away recently)
<cjwatson> psusi: but if grub has been improperly installed then it might need to load modules to read a given filesystem; anyway you seem to be on the right track with the info you're asking for there
<cjwatson> psusi: could be a partition table parsing bug or something, hard to say as yet
<xnox> https://bugs.launchpad.net/reminders-app/+bug/1317977
<ubottu> Launchpad bug 1317977 in Ubuntu Reminders app "GPLv3 license terms violation" [High,Confirmed]
<ogra_> xnox, should have posted that in #ubuntu-app-dev ... thats where the devs are
<ogra_> err
<ogra_> #ubuntu-app-devel
<ogra_> mhall119, ^^^
<xnox> ogra_: i'm actually not sure if that app is shipped.
<xnox> ogra_: it's in ppa only? can't find it pre-installed, nor in the ubuntu archive.
<xnox> ogra_: is it in the store?
<ogra_> xnox, it is pending, we are waiting for it to be switched to the actual server from the test server
<ogra_> was discussed over the last days in #ubuntu-touch
<ogra_> it is supposed to be preinstalled afaik
<ogra_> once it points to the right server so you dont need to use fake accounts
<ogra_> good catch btw
<popey> xnox: its in a ppa and in the click store
<popey> thanks xnox
<dpm> xnox, if you tell us what we need to do to fix it, we can do it straight away
<infinity> dpm: Adding an exception to your license is the quickest fix, and he copy-pastaed some boilerplate in the bug.
<dpm> infinity, xnox, argh, sorry, I misread the bullet points
<dpm> ok, will do that
<psusi> cjwatson: ok, I thoguht it was part of the normal module... but here's what is so weird... if the normal module loaded, then it obviously managed to find /boot/grub... so now when it tries to load the ls module, how can it claim that it can't find the /boot partition?
<cjwatson> Could be various reasons.  Maybe it's not actually trying to find /boot, but /.
<cjwatson> Or maybe the signed EFI image is in use in which case normal is built into the core image
<cjwatson> Don't know really without that debugging output you asked for
<psusi> since he's using an msdos partition table, that should preclude EFI as a possibility...
<cjwatson> Probably, but you never know :)
<cjwatson> Anyway, not enough information to say, but there are various possibilities
<dpm> infinity, xnox, so essentially doing this for all source files should be enough? -> https://code.launchpad.net/~dpm/reminders-app/fix-1317977-openssl-exception/+merge/219037
<dpm> hi tedg, so following up on the e-mail, can you help me setting up the translations exports for indicator-network? If you're happy with it, I'd like to wrap it up for the weekend and start testing the translations next week
<dpm> tedg, It's just about going to https://translations.launchpad.net/indicator-network/14.04/+link-translations-branch and setting:
<dpm> ~indicator-applet-developers/indicator-network/trunk.14.04
<tedg> dpm, That's probably not a good idea.
<tedg> dpm, Indicator-network will be changing all it's translations shortly.
<tedg> dpm, We should wait for the rewrite to land.
<tedg> dpm, It's got a silo, but I don't think it's landed yet. There were some ppc64 issues.
<dpm> tedg, can we set up LP at least, so that's already done? I can hide the translations if necessary, so that translators do not do any unnecessary work
<tedg> dpm, Hmm, the new one doesn't have any translation files setup :-/
<dpm> ok, I think I'll call it a week then, we can follow up on Monday. For now, I'll disable translations in Launchpad
<tedg> dpm, Yeah, I'll ping folks on that. Sorry :-/
<dpm> np, we'll follow up next week
<mali_> hello there. Not sure if this is the right place to ask.. but I am an arch user (I left when unity came about.. guess you know those kind of stories ,p) but.. I see serge and graber? have dome great progress on the LXC part. Now, our kernel doesn't have user name spaces enabled but I have re-compiled that. We also have the nsexec bazaar version we can pull. But regarding newuidmap and the patched shadow, package.. I was wondering if someone here cou
<mali_> ld point out what I might need ot do to have the right patches for this? we use systemd and you have upstart or sysv still, right? Any tips or perhaps a repo I can find the patches I would need to work with ?
<martsbradley> Few days ago with some difficulty was able to download nautilus via bzr, and make a silly change to the code (duplicated the forward button for test) and got it running in my machine via dpkg -i
<martsbradley> To do so I had to make a patch via quilt for the change I made.
<martsbradley> The build tools seemed to mandate the patch.
<martsbradley> Is there a very simple way to make changes to the source code, build them to a .deb and install and avoid the need for the patch.     (This is only for my own use after all)
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<bdmurray> slangasek: I've seen two sponsorship requests for SRUs for package description typos. Is there some reason to SRU those?
<slangasek> bdmurray: I ... would not think so
<bdmurray> I wasn't sure if I missed some memo
<slangasek> bdmurray: if the packages were being SRUed for some other reason, that seems ok to include, but certainly doesn't justify an update per se
<bdmurray> that was my thought too
<dobey> can i get someone to approve the ubuntuone-client and ubuntuone-storage-protocol packages in the proposed queues for saucy and precise please?
<dobey> slangasek: ^^ pretty please? :)
<slangasek> dobey: you mean the ubuntuone-storage-protocol upload for bug #1307549, which has an unanswered question from me asking for a proper test case?
<ubottu> bug 1307549 in ubuntuone-storage-protocol (Ubuntu Saucy) "Should load all available CA Certificates and not just the u1 bundled/shipped ones" [Critical,In progress] https://launchpad.net/bugs/1307549
<cjwatson> infinity: Do you have any objection in principle (I haven't tested it yet, won't for a day or two) to http://paste.ubuntu.com/7425787/ in livecd-rootfs and http://paste.ubuntu.com/7425798/ in launchpad-buildd?  It'd be awfully convenient to be able to pass arbitrary extra arguments to "lb config", particularly --apt-http-proxy.
<cjwatson> (For local testing, in the case of that example)
<infinity> cjwatson: Nope, no arguments conceptually, though it could mean we need some strict input validation if we intend to pass that all the way back to the API.
<cjwatson> Do we, since the LP master basically owns buildds?
<infinity> cjwatson: I guess it depends on who has the rights to make the API calls.
<infinity> cjwatson: If that's a strict and trusted subset anyway, then I guess we can throw whatever garbage we want at it and get to keep both pieces.
<cjwatson> ~launchpad-livefs-builders gets to create new LiveFS rows; the owner of a given LiveFS gets to edit it.
<cjwatson> And vaguely similarly for builds of a given LiveFS.
<cjwatson> I think, though, that code is actually reasonably safe to the extent that it doesn't let you append random shell metacharacters and such
<infinity> cjwatson: I could forsee this being problematic in a future where PPA owners could set up custom builds, maybe.  Though, I guess they can also upload a livecd-rootfs that does Stupid Things too, so maybe I'm overthinking it, and the potential for explosion is already there.
<cjwatson> Right, anyone who can do this can already own a build chroot in a myriad other ways.
<infinity> And so long as we don't let the Stupid escape the chroots and clean up sanely afterward, then meh.
<infinity> I think I was thinking from the POV of current livefs builders, where the chroot isn't ephemeral, so you can break the next build easily by breaking how you call live-build.
<infinity> Not really an issue in the one-chroot-per-build scenario on LP.
<cjwatson> Oh, right, indeed, the new style doesn't work that way
<infinity> So, yeah, no objections here.
<infinity> Just had to think through it and convince myself I was silly.
<cjwatson> Great.  I'll see about getting that tested at some point soon
<cjwatson> <cjwatson@amber ~/src/ubuntu/cdimage/cdimage>$ dogfood-lp env ARCHES=i386 DEBUG=1 bin/for-project ubuntu-touch bin/cron.daily-preinstalled --live
<cjwatson> ===== Building live filesystems =====
<cjwatson> Fri May  9 23:04:55 UTC 2014
<cjwatson> Making progress ...
<cjwatson> ubuntu-touch-i386 on launchpad:name16/ubuntu-touch starting at 2014-05-10 00:04:55
<infinity> cjwatson: Does pgraner know you named your computer after his wife?
<cjwatson> Only if she's named after the Roger Zelazny books. :-P
<infinity> I suppose it's possible.
<cjwatson> Hmm.  Maybe I need the ability to set arbitrary environment variables too.
<cjwatson> It would be nice to be able to override click_uri in ./live-build/ubuntu-touch/hooks/60-install-click.chroot without having to add specialised launchpad-buildd code just for that
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> There's config/environment et al; maybe I can do something with that
#ubuntu-devel 2014-05-10
<BenC> I realize this is likely not the proper place and most people are out for the weekend, but for anyone in the Dallas/Fort Worth area looking for a job working on Ubuntu systems with a company that builds servers and solutions based on those servers, please email bcollins@ubuntu.com
<BenC> Even if youâre not DAL/FTW, if youâre a top notch programmer (firmware/kernel/low-level app), looking telecommute, email me as well. We may consider remote for the right person/people
<psusi> infinity, it seems another week has slipped by ( and Ted Tso has poked again )... have you made any headway on util-linux?
<dobey> slangasek: oh sorry. i hadn't seen that
<darkxst> arm builds of gnome-control-center failed, but there are not even buildlogs...
 * Laney retries them
<Laney> looking good now, hopefully
<darkxst> Laney, thanks!
<debfx> ScottK: could you please set up https://launchpad.net/trusty-backports
<hjd> Hi all. :)
<hjd> freefem++ is listed as ftbfs in Utopic with an error message about unmet dependencies (https://launchpadlibrarian.net/173942186/buildlog_ubuntu-utopic-i386.freefem%2B%2B_3.30-1_FAILEDTOBUILD.txt.gz). It built successful for me locally though (only tried i386). Could someone please schedule this package for a rebuild?
<darkxst> hjd, "E: Unable to correct problems, you have held broken packages." are one of those stuck in -proposed queue maybe?
<hjd> darkxst: I don't think so. Did you get that now or from the report?
<darkxst> hjd, just guessing based on your log!
<hjd> Aha, that's the report from http://qa.ubuntuwire.com/ftbfs/. :) However, when I built it locally yesterday it worked fine without any problems. So it might have been some package stuck in -proposed or something else. It seems to have been resolved now though.
<debfx> hjd: done
<debfx> fwiw the builders have -proposed enabled
<hjd> Oh, I didn't know that.
<ScottK> debfx: Done.
<ScottK> Did utopic too, while I was thinking about it.
<debfx> ScottK: thanks
<galgalesh> I submitted a merge request for the software center, but I'm not sure if I implemented it the right way. Is there a way to get feedback about it, or do I just wait until it gets approved/denied?
<galgalesh> https://code.launchpad.net/~merlijn-sebrechts/software-center/software-center/+merge/219099
<galgalesh> *it's a bugfix for https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/968974
<ubottu> Launchpad bug 968974 in unity-lens-applications (Ubuntu) "Some free applications looks like paid applications with price 0.00 and with buy button" [High,Triaged]
<Wanglethrop> Herro?
#ubuntu-devel 2014-05-11
<kongda_> Hello, I'd like to write an application to recognize three finger touch pad gesture on Ubuntu. Could anyone point me in the right direction?
<mitya57> Hi, can anybody please retry qt4-x11 on arm64? It got "g++: internal compiler error: Segmentation fault (program cc1plus)".
<debfx> mitya57: the build failed again
<cjwatson> mitya57: FWIW these days if gcc doesn't explicitly flag the ICE as unreproducible (the compiler driver tries the backend compile twice to see if it acts differently the second time) then a retry probably won't help
<hjd> I'm looking at http://qa.ubuntuwire.com/ftbfs/ where the package mozo failed because it is waiting for libmatemenu-dev. That is a virtual package (https://packages.debian.org/sid/libmatemenu-dev). I can't find this with the package search in Ubuntu (http://packages.ubuntu.com/search?keywords=libmatemenu-dev&searchon=names&suite=utopic&section=all) but when I try to install it on my Utopic system, it correctly installs libmate-menu-dev which
<hjd> provides the virtual package.
<hjd> So I'm not sure why the virtual package is not found by the search, but it seems like a rebuild of mozo would work.
<cjwatson> hjd: Build-deps on virtual packages aren't automatically retried when they become available; it probably just wasn't available at the time of the initial build
<cjwatson> hjd: I've kicked a retry
<hjd> cjwatson: thanks :)
<mitya57> cjwatson: so can I do anything to fix that failure?
<mitya57> The file in question (qsharedpointer.cpp) didn't change since last upload
<mapreri> pitti: do you think I have to send a friendly ping to the ubuntu studio people (wrt xscreensaver)?
<siretart> I've just uploaded libav10 to debian/unstable. When would be the best time to start this transition in utopic?
<siretart> hint: it might get a bit messy, and will require some manual removals, but OTOH, it is "only" in universe.
<semitones> Hi! I used system settings to switch to the nouveau driver, and while it says I'm using nouveau now, It actually left some blacklists in modprobe.d, and I'm really using VESA. Is that a bug I can report somewhere?
<s1aden> semitones: it would be good to record it somewhere
<semitones> alright, here it is: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1318406
<ubottu> Launchpad bug 1318406 in xorg (Ubuntu) "SystemSettings doesn't enable nouveau but says it does" [Undecided,New]
<cjwatson> mitya57: I haven't actually looked at it, but perhaps /usr/share/doc/gcc-4.8/README.Bugs will come in handy
<cjwatson> it> the failure
<psusi> cjwatson, do you think you might get around to reviewing those d-i patches to remove the parted dependencies soonish?
#ubuntu-devel 2015-05-04
<pitti> Good morning
<dholbach> good morning
<LocutusOfBorg1> good morning developers
<highvolt1ge> morning LocutusOfBorg1, I am 3 of 5
<LocutusOfBorg1> you are then already assimilated.
<LocutusOfBorg1> :)
<seb128> bdmurray, hey, is that normal that e.u.c doesn't have a graph for vivid?
<seb128> RAOF, hey, bug #1351286 is high ranked on e.u.c, not sure if you noticed/can have a look to the issue?
<ubottu> bug 1351286 in sane-backends (Ubuntu) "colord-sane assert failure: colord-sane: simple-watch.c:454: avahi_simple_poll_prepare: Assertion `s->state == STATE_INIT || s->state == STATE_DISPATCHED || s->state == STATE_FAILURE' failed." [Medium,Confirmed] https://launchpad.net/bugs/1351286
 * LocutusOfBorg1 wonders when warty warthog will open for development :p
<LocutusOfBorg1> mapreri, ^^^ ;)
<Riddell> a decade ago :)
<LocutusOfBorg1> it would be funny to call it in the same way and see how many bugs are discovered due to the same name
<lifeless> s/funny/tragic
<LocutusOfBorg1> I'm wondering if launchpad will screw up
<LocutusOfBorg1> and also apt
 * highvoltage sits in a corner and chants warty-final-ubuntu.png
<tseliot> pitti: can you push ubuntu-drivers-common (1:0.4.5) to the git repository, please?
<pitti> tseliot: whoops, sorry, forgot to push; done now
<tseliot> pitti: thanks!
<mapreri> heh, i had completely forgotten the warty-final-ubuntu.png jpg ^^
<mapreri> wow, #296538 got fixed only the last year
<tsdgeos> hmmm
<tsdgeos> ignore hmmm
<tedg> When will the wily archive be open?
 * tedg hides
<pitti> tedg: time to start polling https://launchpad.net/ubuntu/w-series :)
<tedg> pitti, Link changed ;-) https://launchpad.net/ubuntu/wily
<didrocks> pitti: you are so outdated! :)
<pitti> and now the name is updated :)
<chrisccoulson> "Wily" is far too close to "willy" for my liking
<barry> werewolves are kind of like coyotes, right?
<caribou> Is there a way to be sure that an upstart job completes before *runlevel* is emitted ?
<caribou> I need kdump-tools to terminate before the runlevel jobs kick in
<shadeslayer> mhall119: got a moment?
<mhall119> shadeslayer: yes
<shadeslayer> mhall119: is there a ubuntu community council irc channel of sorts?
<shadeslayer> mhall119: need to chat a bit more informally about something
<mhall119> shadeslayer: there is, let me see if the others are available now
<shadeslayer> ok
<mhall119> shadeslayer: invite sent
<mhall119> or not...hang on
<mhall119> shadeslayer: you should have gotten an invite from cproffit
<smoser> hey
<smoser> where would i get the dsc for the 2.26.2-2 version of util-linux from debian ?
<smoser> its in new queue there per https://packages.qa.debian.org/u/util-linux.html
<smoser> but can't find a way to get the code.
<zumbi_> smoser: I do not think you can get that code, as it still needs to be eyed for licensing and distributable details
<cjwatson> smoser: Yeah, Debian doesn't publish files in its NEW queue, though I expect you can get that one from git
<cjwatson> smoser: try http://tracker.debian.org/util-linux as a starting point
<teward> has the development timeline for Wily been created/published yet?  (Just curious, hence asking)
<infinity> teward: I'll get it posted later today, working on opening wily first.
<teward> infinity: ack
<teward> infinity: i assume wily is just going to start out as a 'copy' of vivid until the autosyncs happen and what not?
<cjwatson> That's how it always goes.
<teward> cool
<teward> just wanted to make sure :)
<cjwatson> infinity: Oh, before I forget, we should arrange to blacklist haskell-* temporarily.  Autosyncing them all with the switch to GHC 7.8 isn't going to go well.
<cjwatson> infinity: Let me see if I can hack that into auto-sync on snakefruit.
<infinity> cjwatson: Thanks.  I guess we need to find a sucker to care about haskell transitions now that it's not you.  Unless you feel like keeping that one.
<cjwatson> (done)
<cjwatson> I can keep on caring about them, they're low-effort.
<cjwatson> I mean, now that I've taken the hit of understanding how they work.
<infinity> cjwatson: I think I understand how haskell transitions work, and the bizarre way the dependencies happen, what I don't understand is haskell itself, which makes massaging anything other than mindless no-change rebuilds a bit problematic.
<cjwatson> Right.  I'm not even slightly an expert but can occasionally manage non-mindless things.
<infinity> cjwatson: The part of my brain that understands every language ever, at least well enough to debug, seems to balk at haskell. :)
<infinity> Some day, I should probably fix this.  But I've yet to run across a need.
<rbasak> infinity: I might be able to do the other half. Knowing some haskell, but no idea about transitions or dependencies or how library packages work.
 * rbasak isn't particularly volunteering though
<Unit193> LocutusOfBorg1: Heard anything back from pkg-virtualbox? :)
<RAOF> Urgh sane plugin.
#ubuntu-devel 2015-05-05
<pitti> Good morning
<infinity> pitti: Just the man I've been waiting for.
<pitti> hey infinity
<infinity> pitti: We need adt-britney love for wily.
<pitti> infinity: yep, jibel will set up the wily jobs this morning
<pitti> I'll create VMs in the meantime (with the usual dist-upgrade hackery until we have daily cloud images)
<pitti> wgrant, infinity: is the ddeb magic turned on in LP now?
<pitti>  pkg-create-dbgsym | 0.65        | wily             | source, all
<pitti> oops!
 * pitti copies from vivid-updates
<infinity> pitti: I'm not sure what the state of the magic is.
<pitti> https://launchpad.net/ubuntu/+source/dfc/3.0.5-0.1/+build/7385174
<pitti> that's a recent build
<pitti> apparently it's on \o/
<Unit193> You're going to want to talk to Debian about ddebs soon, I believe.
<pitti> infinity: all the old stuff in vivid-proposed is going to be moved to wily, right? so that enabling -proposed stops being a potential disaster
<pitti> wily-proposed, I mean
<infinity> pitti: It's all moved as of about now.
<infinity> pitti: Plus a publisher cycle.
<pitti> yay, thanks
<RAOF> Now's probably a reasonable time for some AA training...
<infinity> RAOF: A few hours ago before I copied all of thise stuff by hand would have been a better time.
<RAOF> infinity: Hah!
<infinity> pitti: I *think* britney is ready to go, but hard to tell since it explodes with "OMG ADT NO WORKIE, POOF".
<infinity> pitti: But, I'm working on the theory that once that's fixed, it'll Just Work.
<wgrant> pitti: ddebs are enabled on most archives that matter, but I haven't done a recheck that I caught all of them.
<wgrant> Will do so now.
<pitti> wgrant: at least looks good for wily builds
<pitti> wgrant: I copied the latest mangler now
<infinity> Something's actually built in wily that created ddebs?
<pitti> infinity: yes, e. g. https://launchpad.net/ubuntu/+source/dfc/3.0.5-0.1/+build/7385174
<wgrant> pitti: Yeah, the primary archive, security PPAs and silos have all been enabled since Thur/Fri.
<pitti> wgrant: I'll walk through https://launchpad.net/ubuntu/+source/dfc/3.0.5-0.1/+build/7385174 and see if any of the failures were due to the old mangler
<pitti> wgrant: sorry, through https://launchpad.net/ubuntu/wily/+builds?build_text=&build_state=failed&arch_tag=all
<infinity> Oh wow, that magically started building.  Huh.
<infinity> Must have missed a mass give-back right before release. :/
<infinity> Oh well.
<wgrant> infinity: Copied to proposed.
<wgrant> Oh, right, that's what you mean.
<pitti> wgrant: ok, all the FTBFSes are not due to the old mangler, so all good
<pitti> wily testbed VMs created in CI
<pitti> infinity: https://launchpad.net/ubuntu/+source/jemalloc/3.6.0-3 looks like a leftover, ok to remove that from vivid-proposed?
<pitti> or was that on purpose by any chance? (I suppose you moved over with a script, so odd that this one got stuck halfway)
<infinity> pitti: Script.  Hah.  No, it was by hand, I just missed deleting that one.
<pitti> infinity: well, script == for p in <packages>; do copy-package; remove-package; done
<infinity> pitti: I should script it, but it needs to be smarter than "copy to x, delete from y" because LP treats with and without binaries differently depending on if there are completed builds or not.
<infinity> pitti: Anyhow, deleting.
<pitti> ah, ouch
<pitti> infinity: ah, for built ones we need to copy the binaries, I see
<infinity> pitti: We do, and you can't say "copy with binaries" for all of them, cause LP tosses a fit if there are no binaries. :P
<infinity> Still, not that hard to script, just do the binary check first, I'm just allergic to the LP API, and doing it by hand gives me a chance to examine what's in proposed.
<pitti> jibel, infinity: I'm not sure if the snakefruit setup is complete -- http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still points to adt-vivid-* jobs, not adt-wily-* ?
<infinity> pitti: It's not running, because it crashes when your end doesn't work. :P
<infinity> pitti: Lemme try one by hand.
<pitti> infinity: right, jibel is setting that up right now; he just wondered who set up britney, and I wondered if it needs more changes
<infinity> pitti: I did, but it might not be completely right.  No idea.
<pitti> infinity: nah, don't bother yet
<jibel> pitti, infinity the CI infra doesn't know about wily yet, and I am not allowed to update the code on jenkins master
<pitti> meh - CI vanguard o'clock?
<jibel> someone's on it
<LocutusOfBorg1> sil2100, was it ok to review? I don't remember
<LocutusOfBorg1> oops s/ sil2100 / Unit193
<sil2100> !
<pete-woods> pitti: just nagging you about this MR again https://github.com/martinpitt/python-dbusmock/pull/9/files
<pitti> pete-woods: ack, nag taken :)
<pete-woods> :)
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Break Time | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur, arges, Laney
<Laney> mdeslaur / arges: â lies?
<infinity> pitti: When the autopkgtest stuff is all working, can you let cjwatson know?  I'm handing off to him, since it's 3:30am here.
<pitti> infinity: ack, will do
<pitti> infinity: sleep well!
<pitti> infinity: looks mostly ok now, just the queue is awfully long
<Laney> jamespage: hiya, could you take a peek at bug #1374999 - nothing to sponsor currently, right? could unsubscribe ubuntu-sponsors then.
<ubottu> bug 1374999 in OpenStack Compute (nova) "iSCSI volume detach does not correctly remove the multipath device descriptors" [Low,In progress] https://launchpad.net/bugs/1374999
<jamespage> Laney, agreed - I'll get tinoco to ping me directly once he has something ready - I need to coordinate that with other openstack updates anyway
<jamespage> Laney, unsubbed sponsors
<Laney> thanks!
 * Laney is Purging Old Stuff
<jamespage> Laney, nice one
<LocutusOfBorg1> is the wily import started?
<LocutusOfBorg1> I see something has been built for vivid
<LocutusOfBorg1> s/vivid/wily
<cjwatson> only sort of
<cjwatson> please stop asking for the time being, we'll tell people when it starts
<LocutusOfBorg1> thanks, sorry if I'm bothering, I asked many syncs from experimental, I would like to see if they are now sync'd from unstable again
<pitti> LocutusOfBorg1: they will be
<LocutusOfBorg1> thanks!
<pitti> cjwatson, infinity: ah, distro-info bug fixed, and the queue is catching up -- first wily test results! http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/
<pitti> aptdaemon failure seems genuine, I figure some distro-info/python-apt/whatever needing an update for wily
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Break Time | 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: arges, Laney
<mdeslaur> Laney: thanks, forgot to check out apparently
<tinoco> jamespage: hello james, freyes has taken this case. i remember my fix did not fix it entirely (at least for all cases, emc backend did work though)
<tinoco> freyes: pls update james regarding the iscsi volume detach issue whenever you have something
<tinoco> jamespage: thank you!
<cjwatson> pitti: So I'm a little confused, do you know why http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html thinks aptdaemon passed?
<cjwatson> oh, maybe that just needs to be rerun
<pitti> jibel: ^ could it be that vivid's results.history was copied after that ran?
<pitti> cjwatson: me too
<cjwatson> I'll try rerunning p-m
<cjwatson> 2015-05-05 12:52:54,113 DEBUG cmd: ['rsync', '-a', '--remove-source-files', 'rsync://tachash.ubuntu-ci/boottest/wily/out/', '/home/ubuntu-archive/proposed-migration/boottest/data/boottest/wily-proposed/krillin/work']
<cjwatson> rsync: change_dir "/wily/out" (in boottest) failed: No such file or directory (2)
<cjwatson> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [Receiver=3.0.9]
<cjwatson> pitti,jibel: ^- noticed by chance in p-m logs
<pitti> oh, I specifically didn't change RELEASE= for boottest
<jibel> psivaa, fginther ^
<pitti> in lp:a-p-t
<pitti> AFAIUI we do *not* want to move the phone to wily
<pitti> but keep vivid, or vivid+PPA, or a vivid-based RTM release or something
<pitti> so boottest should not run on wily, at least not right now
<cjwatson> we don't want to move the phone to wily yet, but we also don't want to let the quality of wily drift
<pitti> psivaa, fginther ^
<cjwatson> (per slangasek)
<pitti> ah, so will we have a channel for wily touch builds, but don't advertise it?
<cjwatson> that was my understanding
<cjwatson> ICBW
<jibel> pitti, cjwatson a possible explanation is that aptdaemon/policykit passed in vivid, and the result is still valid in wily because policykit didn't retrigger a test of aptdaemon in wily ie policykit in wily didn't break aptdaemon.
<pitti> ok; so I guess CI needs to create these dirs
<fginther> pitti, jibel, I've created the rsync dirs on tachash for boottest. Will take a closer look at what boottest should really be testing in a moment
<dholbach> slangasek, can you join #ubuntu-uds and #ubuntu-uds-core-1?
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Break Time | 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: arges
 * dholbach hugs Laney and arges
<arges> oops I forgot to pilot out : )
<arges> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Break Time | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * Laney hugs dholbach back
<cjwatson> jibel: I guess that makes sense, but why did aptdaemon run in wily at all then?
<slangasek> dholbach: done
<dholbach> great
<Orphis> Hey, does anybody know what's the progress of apt "by-hash" update status?
<rbasak> "chdist create" for wily, when running on vivid, didn't seem to create or populate .chdist/.../etc/apt/trusted.gpg.d/ I get gpgv failure warnings. Is this a bug?
<jibel> cjwatson, I don't know yet, 8 package tests have been triggered because packages were considered newer in wily, but the version is the same in vivid, and there is no new upload in wily
<Orphis> And is there any plan on using it in future Ubuntu release?
<rbasak> Orphis: I think support in apt will get synced this cycle. Then it needs to be enabled in the archive, and we need to switch to InRelease. I'm not sure about the status of those two parts. I think we're still planning on switching to it. mvo may know more but I don't see him online right now.
<Orphis> rbasak: Do you know if apt-ftparchive supports generating repositories for this format?
<rbasak> I don't think it does right now.
<rbasak> I did have a script that takes a regular archive and adds the by-hash information.
<rbasak> Not sure what happened to it.
<Orphis> That's "easy" to add on top of existing index generation scripts though
<rbasak> Right. The by-hash design allows for the extra stuff to be added to downstream mirrors even without upstream support.
<cjwatson> We'd certainly want to support it in Launchpad, rather than messing about on mirrors.
<Orphis> Is Launchpad the main ubuntu repository?
<rbasak> Sure - it's easier to test by decoupling that though.
<cjwatson> Orphis: Yes.
<rbasak> (eg. on a local mirror)
<cjwatson> Rather, Launchpad is the software that (among other things) publishes the repository.
<Orphis> Mirrors will probably have to be smarter when mirroring, like handle packages first, then by-hash, then (In)Release(.gpg)
<rbasak> "cp -a ~/.chdist/{vivid,wily}/etc/apt/trusted.gpg.d" fixed my chdist issue. Not sure if it's a bug in chdist or not.
<cjwatson> Orphis: Mirrors already have to mirror pool then dists.
<Orphis> Right, but they should still do a smart dists mirroring not to break everything :)
<ev> can you statically link LGPL v2 code in a GPLv3 codebase?
<cjwatson> I think they already have to do that too.
<Orphis> Great
<rbasak> Orphis: or, simplify the smarts to say "sync new files first, then modified files, then deleted files". Pool then dists would also work but best to sync deleted files last in that case.
<Orphis> Do you know what software they're using?
<rbasak> Oh, and InRelease last after everything else in dists.
<Orphis> rbasak: That's a smarter way to do it too, yes
<Orphis> Indeed
 * zyga wonders what generates https://ftp-master.debian.org/new.html
<zyga> and if there's an API for it
<cjwatson> software> varies but we recommend https://wiki.ubuntu.com/Mirrors/Scripts
<cjwatson> deletion isn't a big issue due to the stay of execution
<Orphis> To serve the internal repository at my company, I have some software that is smart enough to keep a session based on the IP address of the client and keeps multiple versions of the index. When an update session starts (through Release.gpg or InRelease download), it tracks which index it should serve and avoids all issues. And on the other side, the index is updated automically using a smart symbolic link
<cjwatson> yeah nobody wants to do that on public Ubuntu mirrors though :)
<Orphis> It works great even for frequent updates of the repository and serves the right index, provided no 2 machines with the same IP are updating at the same time during an update
<Orphis> Indeed
<cjwatson> and anyway NAT
<Orphis> I'm just looking for a solution that would work for my infrastructure to mirror your packages properly in different sites
<Orphis> Yes, it's good for a private infra, not so much for external people, although that would reduce errors for people and shouldn't add more
<Orphis> It's not 100% fail-safe and is transparent to old clients
<Orphis> When it works, it works, when it doesn't, there would have been an error anyway without it
<Orphis> How often is the ubuntu index regenerated? And how long does it usually take?
<cjwatson> usually multiple times per hour
<cjwatson> how long> depends exactly what you mean by that question ...
<Orphis> How much time is spent between the moment you ask for the index to be built and it's actually done?
<cjwatson> ev: yes, http://www.erisian.com.au/wordpress/2007/07/06/gplv3-and-debian has a summary
<cjwatson> Orphis: (a) nobody asks for it explicitly (b) varies quite a bit depending on how much work it has to do; typical would be around 5-15 minutes
<cjwatson> Orphis: that isn't relevant to mirrors though ...
<cjwatson> I mean, frequency can be, but publisher runtime isn't
<Orphis> No, but it's interesting to compare infrastructures of big repositories :)
<cjwatson> right
<Orphis> We have continuous deployment for some software, so we publish it in our repository and we block on the indexing. Having a fast indexing is always nice then
<smoser> hey. bug 1446767
<ubottu> bug 1446767 in isc-dhcp (Ubuntu Wily) "dhclient can fail if other nics are renamed" [High,Triaged] https://launchpad.net/bugs/1446767
<smoser> is in vivid-proposed.
<smoser> is it acceptable to sign and upload 4.3.1-5ubuntu2.1  ? to wily ?
<smoser> or.. how should that be done.
<smoser> binary copy?
<cjwatson> just copy with binaries to wily-proposed, if it isn't there already.
<cjwatson> Orphis: small repositories there isn't really a good excuse for taking more than a small number of seconds :)
<Orphis> cjwatson: Well, I have a big one!
<Orphis> With multiple copies of some packages for gradual rollouts and stuff
<Orphis> cjwatson: While you're around, something a bit related I couldn't get an answer for. Is trusty-updates a superset of trusty-security?
<smoser> cjwatson, i don't do this very often.. can you confirm http://paste.ubuntu.com/10990160/ is right?
<smoser> er.. do i coyp to wily-proposed
<cjwatson> smoser: You should copy to wily-proposed, indeed.
<cjwatson> smoser: Otherwise it's fine.
<smoser> thanks
<cjwatson> Orphis: More or less.  All updates to -security are automatically copied into -updates provided that they don't clash.
<doko_> xnox, barry: isn't the python session now ongoing?
<cjwatson> Orphis: There's a slight delay on that, and in any case -security still exists separately in part because that means we can point users' sources.list files at security.ubuntu.com for that suite, so that they get security updates quickly regardless of the vagaries of mirroring.
<Orphis> cjwatson: So one should be safe enough to use only updates and not security, provided the updates repository is properly mirrored
<cjwatson> Orphis: I can't recommend it, but I've explained the behaviour.
<Orphis> Thank you
<Orphis> Updates aren't applied automatically, so the slight delay is probably not relevant in that case
<Orphis> Well, in *my* case
<cjwatson> Probably not.
<barry> doko: in 90m i think
<xnox> doko: UTC time is 14:27
<dholbach> doko, http://summit.ubuntu.com/uos-1505/2015-05-05/ - as barry said
<doko> argh, won't be there then
<xnox> doko: that's alright, it's not like we've been planning python3-only for a few years now....
<ev> cjwatson: thanks!
<barry> doko: darn.  can you pvtmsg me any links you want to share?  e.g. py3 work needing done?
<xnox> where can i get recent go for 14.04 ?
<doko> xnox, apt-get install gccgo
<xnox> doko: what version of go does that translate to on 14.04?
<doko> ahh, 14.04, the ubuntu-toolchain-r/test PPA
<doko> 1.4.2
<xnox> well i need at least 1.3 i think
<xnox> hm i wonder if there is environment variable to do -compiler gccgo
<doko> barry, xnox: for python3.5 in 15.10, somebody would need to sit down and see, if we have the resources to do 3.5 as supported version, or if it's too early (will be beta status at this time)
<doko> xnox, GCCGO
<cjwatson> pitti: do you know of any reason not to open at this point?  there's the lack of boottests, but I think we can live with that in the short term
<pitti> cjwatson: fine from my POV;  if the toolchain (gcc 5?) is set?
<cjwatson> apparently set, gcc 5 not default yet
<cjwatson> (and not for opening)
<cjwatson> I just want to get branch-distro sorted
<pitti> cjwatson: do we have a newer distro-info and debootstrap already?
<pitti> quite some stuff will fail without that, I figure
<cjwatson> pitti: no, but be my guest
<cjwatson> pitti: well, we do have a newer distro-info-data
<pitti> cjwatson: ok; I have two UOS sessions now, noted for tomorrow morning
<pitti> cjwatson: yes, that's what I meant
<cjwatson> debootstrap isn't opening-critical
<pitti> right, I locally added the symlink to the CI machines
<pitti> they have wily containers now
* cjwatson changed the topic of #ubuntu-devel to: Archive: wily 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:
<rbasak> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.vivid/rdepends/python2.7/ works but http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.vivid/rdepends/python2.7 redirects to http://people.canonical.com/germinate-output/ubuntu.vivid/rdepends/python2.7/ which then 404s (dropped off ~ubuntu-archive)
<cjwatson> we'll start up auto-syncs soon
<cjwatson> rbasak: sounds like a bug in the IS-managed proxy on lillypilly
<rbasak> cjwatson: I'll file an RT then I guess? Thanks.
<cjwatson> I think
<cjwatson> it probably needs to rewrite the redirect or something
<dholbach> woohooo!
<pitti> cjwatson: \o/
<pitti> cjwatson: https://launchpad.net/ubuntu/wily/+builds?build_text=&build_state=built&arch_tag=amd64 doesn't have builds with ddebs that are more than 30 mins old yes, but I'll check tomorrow that the ddeb import worked
<pitti> cjwatson: at least they are being produced and published in LP now, so we won't lose them \o/
<bdmurray> barry: where are we with the python-pip SRU?
<smoser> anyone have thoughts on http://paste.ubuntu.com/10990807/
<cjwatson> smoser: I'd strongly suggest talking with the Debian vim maintainers
<cjwatson> they may have past experience
<smoser> essentially replace python with python3 in vim. it doesn't actually build (a python3 test fails), but wonder if its the  right thing to do to replace Provides.
<cjwatson> and Debian is targeting a pretty widespread switch to python3 for stretch so there's no good reason for this to be Ubuntu-specific
<cjwatson> also, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729924
<ubottu> Debian bug 729924 in vim "vim: Add Python 3 support" [Wishlist,Open]
<cjwatson> past history there you're skating over :)
<smoser> cjwatson, thanks.
<pitti> stgraber: lxc/wily failed because of debootstrap missing wily, I'll upload that
<stgraber> pitti: yeah, I assumed it'd be something like that so I didn't even bother checking
<stgraber> pitti: I usually start worrying about adt around a week after the series opened :)
<pitti> cjwatson: uploaded debootstrap FTR
<pitti> oh, Laney beat me to it
<pitti> meh @ pull-lp-source not working yet
<Laney> pow pow pow
<zyga> barry: do you know, perhaps, what generates the debian NEW index? https://ftp-master.debian.org/new.html
<zyga> barry: I wanted to write an app that loads the same data and presents it in a QML app
<Laney> zyga: you could parse https://ftp-master.debian.org/new.822
<zyga> Laney: fantastic, that's excactly what I wanted!
<Noskcaj> How can i see what packages i have upload rights for?
<bdmurray> seb128: In case you didn't notice the vivid line is fixed now.
<seb128> bdmurray, did notice; thanks
<utlemming> pitti, stgraber: which package provides the preseed files on the cdrom?
#ubuntu-devel 2015-05-06
<teward> anyone know how I can make my local sbuild on 14.04 recognize 'wily' as a distro for mk-sbuild ?
<TheMuso> teward: Do you have a wily chroot set up and defined in schroot.conf?
<TheMuso> teward: Oh wait, you mean the mksbuild command from ubuntu-dev-tools.
<TheMuso> teward: debootstrap needs to be updated to know about wily.
<TheMuso> apt-cache policy libgtk3.0-0
<TheMuso> whoops
<pitti> Good morning
<sarnold> morning pitti
<pitti> utlemming: sorry, I don't know; question for infinity or cjwatson perhaps?
<Unit193> Howdy, sarnold.
<sarnold> hey Unit193
<sarnold> pitti: I got to wondering, how many packages did you guys wind up systemdifying before the vivid release? I suspect I'm not the only one who'd be interested in a breakdown of main / universe, how many needed systemd service files, sysv-init files, how many were sent up to debian, etc..
<pitti> sarnold: for some rough numbers we can compare http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-13.txt to http://people.canonical.com/~jhunt/systemd/packages-to-convert/2015-04-20.txt
<pitti> the script changed a bit in between
<pitti> ah, so let's start with http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-20.txt
<sarnold> pitti: is that really 191-5 == 186 packages from main and 962-6 == 956 packages from universe???
<pitti> sarnold: so, ~ 46 packages from main, ~63 from universe
<sarnold> aha :)
<sarnold> pitti: still, that's amazing.
<pitti> sarnold: I'd say I personally fixed maybe 10 universe packages, most of them came through debian I think
<sarnold> that's a lot of packages, hehe
<pitti> sarnold: main was mostly on our table though, as we had a lot of upstart-only packages there
<pitti> sarnold: heh yes, I've been busy :) and thanks again to didrocks, he also helped with this
<sarnold> pitti: impressive :) thanks for humouring my curiosity :)
<pitti> sarnold: note, that's not accurate for any statistics (we started with the conversion way before), but the magnitude sounds about right
<sarnold> pitti: makes sense :)
<pitti> # apt-get install tzdata-java
<pitti>  tzdata-java : Depends: tzdata (= 2015c-1) but 2015d-0ubuntu0.15.04 is to be installed
<pitti> hmm
<pitti> that causes quite some uninstallability
<pitti> but tzdata and t-java are both built by tzdata
<pitti> ah, that's not even just in -proposed, but in wily release too
<pitti> infinity: ^ any idea how that made it past britney's installabilty checks?
 * pitti syncs 2015d-1 into wily
<pitti> ok, fixed now
<infinity> pitti: Err, wat?
<pitti> infinity: nevermind, all sorted out
<pitti> infinity: tzdata was pre-installed in the VMs from vivid-updates, but vivid had a newer version than wily
<pitti> so tzdata-java was only available for an older version
<infinity> pitti: Ah-ha.  Yeah, I know the archive wasn't broken. :P
<pragomer> how can I have UDF v. 2.6 support in ubuntu?
<infinity> pitti: But this reminds me that it's probably time to turn on auto-sync.
<pitti> infinity: yeah, let's get some new fun! wily is outright boring right now
<infinity> pitti: Fun incoming.
<pitti> infinity: britney etc. seems to work fine, I had quite some argument with her this morning
<infinity> pitti: (Mostly, the reminder was you syncing one of my uploads :P)
<pitti> infinity: yeah, that was to get four green dots back ;)
<pitti> (libreoffice, cantor, poxml, and chromium-browser, which failed due to that uninstallability)
<infinity> I don't know why it annoys me when people sync my Debian uploads to Ubuntu for me, but for some weird reason, it does.
<infinity> Must some control freak issue.
<infinity> pitti: auto-sync on.  Let's see how that goes.
<pitti> <dholbach mode> yee-haw!
<infinity> Oh, next run isn't until 11:00 UTC, so a bit of an anti-climax there.
<infinity> pitti: Going back to your tzdata oops, why do your VMs have updates installed in the base at all?
<pitti> infinity: because we have to cheat and dist-upgrade a vivid VM
<pitti> infinity: until we get proper wily image builds (cloud images in particular)
<infinity> pitti: Sure, I meant why do the vivid ones have updates installed.
<pitti> why wouldn't they?
<infinity> pitti: I guess since we only use them for SRUs, it makes sense.
<pitti> dist-upgrade to -proposed would take ages otherwise
<infinity> pitti: I live in a world where -security is a thing, so none of my chroots have updates in the base.
<pitti> by pre-dist-upgrading to -updates we save the majority of per-test dist-upgrade time/work
<infinity> pitti: Yeah, it makes perfect sense until we end up trying to use this machinery for -security, which we've never discussed, and probably don't want to do.  So, carry on.
<infinity> I'm also less and less convinced that there  are people who run with -security-only, and I think we should revisit that some day.
<pitti> infinity: don't we fold -updates into the next -security upload anyway?
<infinity> The part where I didn't copy tzdata to -security until starting sometime last year but never had a single bug report about broken timezones for security-only, for instance, is a suspicious data-non-point.
<pitti> I don't think we maintain two branches for security updates (one with pure -security, one with -updates+-security)
<infinity> pitti: We do, but it still builds only against security and release.
<infinity> pitti: So, for instance, a library with new symbols in -updates might have binaries in -updates that depend on it, but not in -security.
<infinity> pitti: Anyhow, I think the separation (especially given the "base security uploads on the last SRU" policy) is probably pointless, and worth talking with Jamie's team about why we do it that way, and if we should keep doing it.
<infinity> Hard to get good metrics about it, though.
<infinity> The only two I have are non-data.  tzdata and linux-firmware, which are now included in security, but didn't used to be.
<infinity> The former leading to broken timezones, the latter to completely nonfunctional kernel drivers.
<pitti> infinity: yeah; over the years I shifted my mind to "security.u.c. is just a faster mirror" mostly
<infinity> And no bugs about either.
<pitti> I still remember the long debates that we had about whether or not to keep -security as a totally separate branch, and effectively applying security patches twice
<infinity> pitti: See, if there really is a "completely stable only-security" use-case, we should have done that.
<infinity> pitti: But we didn't.
<infinity> pitti: And the current policy is just a bit odd.
<infinity> It's also not uncommon for random universe packages to get security updates via SRU instead of being done through the security team.
<infinity> Which is "wrong" in the split model, but wouldn't matter if everyone's running -updates anyway.
<lifeless> isn't that the only way random universe packages can get security updates?
<infinity> lifeless: No, the security team encourages people to submit MOTU security fixes to them to pass through the PPA to -security.
<infinity> lifeless: But not everyone gets the memo, and sometimes people do micro-release SRUs that just happen to also fix 27 CVEs, etc.
<lifeless> heh
<lifeless> thanks
<infinity> pitti: I think what I'd be happier with is if -security became more of an "urgent -proposed".  People have it on by default (as now), we implicitly trust the uploaders (as now), but it builds against -updates, and is just a faster way through SRU that doesn't need the usual baking period.
<infinity> pitti: I might have a discussion with jdstrand and friends about this when they wake up.
<tjaalton> anyone know what's different between starting suspend from the menu or hitting the hotkey? (or xdotool key XF86Sleep)
<tjaalton> because there's a bug in trusty that only happens with the hotkey
<mgedmin> hotkey is handled by gnome-settings-daemon; menu is handled by ... uh ... probably not gnome-shell if you use unity, but anyway
<pitti> indicator-session ^
<tjaalton> ok
<pitti> they should both eventaully go through logind to actually do the suspend request, though
<pitti> the lock screen behaviour is a bit different, though
<seb128> the indicator locks the screen before suspending, not sure about u-s-d
<tjaalton> it's a i915 bug, probably just a pageflip less with the menu
<pitti> seb128: it's supposed to do the same
<pitti> it should set a delay suspend inhibitor, lock the screen, and release the inhibit after locking
<pitti> perhaps tjaalton can tell us what the bug actually is :)
<seb128> yeah, that would be easier ;-)
<tjaalton> total system hang
<tjaalton> so, the usual deal
<tjaalton> on haswell
<tjaalton> it's fixed in 3.19 at least
<tjaalton> just need a ton of bisecting..
<pitti> tjaalton: ah, so at least you can run trusty with the lts-vivid backported kernel?
<pitti> (do we actually have that already?)
<seb128> bah, neeed torestart, 90% of the chars got missing fromÃ¹ my screen
<pitti> so you put in some extra chars as compensation :)
<tjaalton> pitti: yes, but it's an oem bug
<tjaalton> needs to be fixed in trusty kernel
<tjaalton> lts-vivid is in proposed at least
<tjaalton> the kernel
<tjaalton> rest to follow once infinity allows ;)
<seb128> http://people.canonical.com/~seb128/xchat.png
<tjaalton> intel?
<seb128> tjaalton, ^ do you know if that's a video issue?
<seb128> yes, i5
<tjaalton> more specific
<tjaalton> every gen has i3/i5/i7 :)
<pitti> seb128: I sometimes get something similar, but usually ctrl+L helps
<seb128> tjaalton, ironlake gen5 from xorg log
<tjaalton> so gen5
<tjaalton> uh
<tjaalton> you said that
<seb128> pitti, ctrl-L where? when it starts doing that it's on all applications, not one
<pitti> seb128: yes, I know, here too; I just press it (I'm usually in gnome-terminal), it helps here
<seb128> last time I noticed it seemed font specific though, if I change the text size it's fine, if I go back to the old value it's the same issue
<seb128> text does get redraw on focus changes sometime though
<tjaalton> this on vivid?
<seb128> tjaalton, yes
<pitti> yes
<tjaalton> check dmesg if you don't have a gpu hang
<tjaalton> or does X restart cure it?
<pitti> at least here it never hangs, it just disrupts the screen all of a sudden; I can work on, and redrawing screen helps
<seb128> tjaalton, session restart fixes it
<seb128> I just did a logout/login cycle to fix it
<tjaalton> k
<tjaalton> if you can build -intel from git that would be something to try
<seb128> tjaalton, well, it's not like the issue was easy to reproduce
<seb128> it's also not new from vivid, I have it happening sometimes for some cycles
<tjaalton> ok
<seb128> but would that be a video driver issue?
<seb128> not sure how font rendering works exactly
<tjaalton> it's sna acceleration bug I think
<tjaalton> you can switch to uxa in xorg.conf too
<tjaalton> to see if it ever happens again
<seb128> tjaalton, looks similar to https://bugs.freedesktop.org/show_bug.cgi?id=88584
<ubottu> Freedesktop bug 88584 in Driver/intel "[ilk] Font and screen corruption in GTK+ applications" [Major,New]
<tjaalton> yeah
<seb128> pitti, ^
<pitti> ah, thanks
<LocutusOfBorg1> hi doko_ are you sure you fixed the kfreebsd-amd64 build failure? I see 5.1.1-4 still failing... thanks
<rbasak> $ pull-lp-source -d hello wily
<rbasak> pull-lp-source: Downloading hello version wily
<rbasak> pull-lp-source: Error: Failed to download: https://launchpad.net/ubuntu/+archive/primary/+files/hello_wily.dsc: 404 Not Found
<rbasak> Is that expected?
<rbasak> I haven't updated distro-info-data or anything so it is out of date.
<rbasak> But I still expected an explicit "wily" to work. "vivid" does.
<cjwatson> Noskcaj: edit-acl -p noskcaj query (from bzr lp:ubuntu-archive-tools)
<cjwatson> utlemming: they're in lp:~ubuntu-cdimage/debian-cd/ubuntu
<cjwatson> rbasak: Yes, it looks like pull-lp-source decides whether the argument is a series name or a version number by checking whether it's present in distro-info-data
<rbasak> cjwatson: ah, that makes sense, thanks. I'll update distro-info-data.
<Laney> rbasak: tumbleweed said he was going to do it
<cjwatson> rbasak: it's already done somewhere
<rbasak> Oh. I meant locally. I assumed it was already updated in the archive.
<cjwatson> Right
<Laney> Don't see it in unapproved at any rate
<LocutusOfBorg1> 45 minutes to the sync? :)
<cjwatson> LocutusOfBorg1: Takes it a while to think about it before it starts copying
<doko> LocutusOfBorg1, why is kfreebsd relevant here?
<LocutusOfBorg1> I don't see you in the debian-devel channel :)
<jpds> stgraber: Can you take a look at https://bugs.launchpad.net/ifupdown/+bug/1452238 ?
<ubottu> Launchpad bug 1452238 in ifupdown (Ubuntu) "Failed to upgrade system from 14.04" [Undecided,Confirmed]
<ricotz> doko, hi, is there an official backport of gcc for precise planned to deal with applications dropping support for gcc < 4.7
<rbasak> jpds: that looks likely to be an issue with sysvinit, not ifupdown. Why was initscripts not configured on your system? Had it previously failed to configure?
<jpds> rbasak: It was a brand new box.
<rbasak> jpds: how was it installed?
<jpds> rbasak: I'd literally never touched it before.
<jpds> rbasak: Came per-installed.
<rbasak> jpds: I'm interested to know whether "apt-get -f install" complains about anything before attempting the upgrade.
<jpds> rbasak: It doesn't, it fixes the issue.
<rbasak> jpds: it doesn't complain? Or it does and fixes the issue? And this is all before update/upgrade, right?
<jpds> rbasak: Put the output in the bug.
<rbasak> jpds: OK, but did you run this after or before the upgrade attempt?
<jpds> rbasak: After.
<jpds> rbasak: Then it does its thing, and one can dist-upgrade again.
<rbasak> jpds: what does "dpkg -l initscripts" give you, please?
<jpds> rbasak: Don't have access to my machine right now.
<jpds> rbasak: http://cdimage.ubuntu.com/ubuntu/releases/14.04/release/ubuntu-14.04-server-amd64+mac.list
<rbasak> jpds: I wanted to know configuration status of that package before and after the upgrade failure.
<rbasak> jpds: the full log of the upgrade would be helpful too. I wonder if it's a dependency loop. It needs a deeper dive than I have time for right now, sorry. Maybe stgraber will know faster. Some kind of dependency loop maybe?
<pragomer> hi. I have no dns in my remastered live-iso (that works perfect except of dns). as I see via google this is not only my problem. but I could not find a solution. could you help me?
<cjwatson> auto-sync properly underway now
<LocutusOfBorg1> cjwatson, I see ghc building on wily right now, didn't you mention a blacklist for haskell?
<cjwatson> LocutusOfBorg1: most of the rest is blacklisted until ghc itself builds
<cjwatson> LocutusOfBorg1: blacklisting ghc would not help that cause :-)
<LocutusOfBorg1> I though the blacklisting was until the debian transition was done :)
<cjwatson> No
<LocutusOfBorg1> I mean, you were waiting for the haskell stuff to migrate to testing ;)
<cjwatson> It's because I don't want us to have to build haskell-* out of order only to have to build it all again in order
<cjwatson> No, that would take ages
<cjwatson> This is purely a let's-get-the-ordering-right thing
<cjwatson> (auto-sync has copied everything now)
<seb128> jibel, pitti, hum
<seb128> "wily-adt-samba - Build # 1 - Failure:
<seb128> Public Jenkins URL:  https://jenkins.qa.ubuntu.com/job/wily-adt-samba/1 to view the results."
<seb128> but that url is a 404?
<pitti> it ran here: http://d-jenkins.ubuntu-ci:8080/job/wily-adt-samba/?
<seb128> need vpn access to see that one
<pitti> seb128: jibel sent an RT to create the /Wily view on public jenkins; no idea whether that also needs action to copy the actual jobs
<jibel> seb128, given the number of job running the publisher is probably late
<pitti> hm, some do exist: https://jenkins.qa.ubuntu.com/search/?q=wily-adt
<seb128> jibel, shouldn't the emails be sent after the publishing when the log has there?
<jibel> seb128, this job finished less than 10 minutes ago
<pitti> so I guess it just takes time to catch up
<seb128> has->is
<pitti> seb128: maybe, but we don't control the public jenkins
<jibel> seb128, no that's completely differnet
<seb128> bah, and why can't I access d-jenkins even if with the vpn
<pitti> well, what we "should" do is to get rid of jenkins :)
<seb128> oh, works now
<seb128> go figure
<jibel> seb128, the sync to the public instance can take several minutes up to several *long* minutes if there are big attachments
<seb128> jibel, pitti, thanks
<seb128> seems like  python-samba is not installable
<seb128> shrug, and of course activating the vpn makes everything else timeout/stop working, I had forgotten about that
<pitti> seb128: how do you mean?
<pitti> seb128: I have the VPN on all the time (auto-started for me on boot)
<pitti> it's not supposed to hang anything else
<pitti> s/boot/connecting to my home network/, but all the same
<seb128> pitti, dunno if I misconfigured the vpn in nm-connection-editor, but when I activate it from there the non-vpn web stops working for me
<pitti> seb128: does your default route go via VPN now? that would explain it
<pitti> $ ip route|grep default
<jibel> seb128, don't use the vpn as your default route
<pitti> seb128: in NM, select the VPN -> Ipv4 settings -> Routes... [X] Only use for resources of this network
<pitti> seb128: it should be on by default; switching it off will use it for default route, which doesn't work for me either
<seb128> pitti, thanks, that's checked
<seb128> in fact this time it didn't make the interweb stop working
<seb128> but some IRC networks and thunderbird timeout
<pitti> seb128: ok; default route points to your normal router, not VPN?
<seb128> so it's like it was making something that open connections don't like
<seb128> pitti, correct
<pitti> seb128: ah, the internal irc probably?
<seb128> yes
<seb128> and the canonical imap
<pitti> seb128: ok, that sounds plausible
<seb128> so maybe just canonical machines
<Saviq> mhall119, mzanetti, elopio_, just watching "Unity8 User Documentation", not sure if you got to that conclusion, but I totally agree with the goal of automating that
<Saviq> the documentation text itself should totally live next to the test itself
<mhall119> Saviq: the conclusion was that we should build a prototype covering one specific thing, and see how it goes
<mzanetti> Saviq, yeah, mhall119 will come up with a prototype
<mzanetti> Saviq, so you met elopio's bird :D
<Saviq> one thing I wanted to mention is: if any of the full-stack test fails, it needs to be looked at anyway
<Saviq> it's either that the test is not stable, wrong, or something really needs to change
<mzanetti> yeah. it definitely sounds like it could work out
<Saviq> mhall119, long-term we could think of a way for the doc team to get a set of diffs (text and visual) between published and current state to go through and ack/nack
<mhall119> Saviq: diffs to the docs?
<Saviq> mhall119, yes
<Saviq> the docs could be generated daily/per-image, depending on how often the full-stack testing runs
<mhall119> Saviq: I was hoping the docs team would help you guys update them directly
<mhall119> in the bzr branch
<Saviq> mhall119, sure, but then, before publishing them
<Saviq> mhall119, you likely want a sanity pass
<Saviq> over the changes
<Saviq> mhall119, then, a few times in a cycle, we could generate them for different locales, and even for different devices...
<mhall119> Saviq: true
<Saviq> elopio_, mhall119, FWIW I don't think we need that many screenshots (11 for unity7 were mentioned? ;)), it's probably whoever writes the initial doc should leave a hint in the text where a screenshot is needed
<mhall119> Saviq: for Unity, yes, but if this works we can have it over individual apps too
<elopio_>  Saviq, mzanetti, mhall119: it's also worth thinking about videos.
<Saviq> mhall119, totally
<Saviq> elopio_, and yeah, totally
<Saviq> elopio_, it'd likely be useful to also be able to only take a screenshot of a certain region (launcher.screenshot())
<Saviq> but yeah, one step at a time :)
<mhall119> elopio_: for videos, having touch-event overlays would really be useful
<mhall119> touch/mouse
<Riddell> uos question: how do I get the hangout url for a session I'm running?
<seb128> Riddell, copy paste from your url bar
<seb128> ctrl-L + ctrl-C + ctrl-V in most browser
<Laney> https://wiki.ubuntu.com/UDS/Sessions shows how to do all the mangling
<Riddell> ah that's the URL I want thanks Laney, the summit site only links to some out of date docs
<mitya57> ScottK: does it make sense to copy qscintilla2 from vivid-proposed to wily, or you are going to fix it via Debian soon?
<ScottK> I think it will get auto-copied, but in any case I plan an upload in Debian soonish, so I think it's not worth expending effort on.
<mitya57> Ok
<xnox> doko: will you be at the GCC5 update session?
<xnox> doko: in one hour
<doko> maybe ;)
<xnox> doko: hehe
<tumbleweed> Laney: yeah, sorry. Couldn't do it at the time, beacues it wasn't open yet. And couldn't later because I didn't have key material with me. Then it fell off my stack
<hjd> Anyone know when http://qa.ubuntuwire.com/ftbfs/ will switch to show status for wily?
<tumbleweed> hjd: wgrant runs that
<smoser> arges, https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1272414
<ubottu> Launchpad bug 1272414 in sudo (Ubuntu Precise) "extremely slow sudo with many network interfaces due to slow getifaddrs() syscall perf" [Undecided,New]
<smoser> the fix there...
<smoser> do you have to configure sudo somehow to get it ?
<arges> smoser: what do you jmean?
<smoser> the upstream discussion talkss about a sudo config iption
<smoser> option
<smoser> er... maybe it doesnt
<smoser> oh. the bug summary does
<arges> smoser: you have to add a special flag
<smoser> it says "the ability to disable th echecking the network intefaces with a runtime option"
<arges> --probe-interfaces
<smoser> so its fast *unless* you run sudo with that ?
<arges> err the config is 'Set probe_interfaces false' (sorry its been a while since I looked at this)
<arges> smoser: http://www.sudo.ws/repos/sudo/rev/e9dc28c7db60  seach for the man page description
<arges> so in systems with lots of virtual interfaces (neutron routers for example) sudo is really slow since its scanning all those veth pairs
<smoser> arges, yeah. thats what i'm seeing.
<bdmurray> mdeslaur: Are the upstart tasks in bug 1391296 still necessary?
<ubottu> bug 1391296 in upstart (Ubuntu Vivid) "14.10: NFS drives in fstab not mounted automatically" [High,Confirmed] https://launchpad.net/bugs/1391296
<mdeslaur> bdmurray: no
<mdeslaur> uh, wait a sec
<mdeslaur> bdmurray: no, closing them now
<bdmurray> mdeslaur: thanks
#ubuntu-devel 2015-05-07
<dodeluser> I create a remastered ubuntu iso with this genisoimage syntax:  http://pastebin.com/WR8kJxbN             but the iso is not "hybrid" as I cannot write it to usb with "dd" and boot (does not boot) . what am I doing wrong?
<pitti> arges: hey! would you mind looking at systemd in unapproved? https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1437375/comments/19 has the explanations
<ubottu> Launchpad bug 1437375 in systemd (Ubuntu Vivid) "[udev] Adding "Austin" adapter to Ubuntu partition take over system network interface" [High,Fix committed]
<pitti> arges: what was uploaded yesterday was not meant to go into -proposed, I uploaded a newer version now
<pitti> infinity, RAOF ^ or someone else in ~ubuntu-sru
<RAOF> pitti: Certainly, sir!
<infinity> pitti: Nope, but RAOF will!
<pitti> RAOF: cool, thanks!
<RAOF> pitti: Want to add the various SRU headers to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1448259 ?
<ubottu> Launchpad bug 1448259 in systemd (Ubuntu Vivid) "Systemd does not send SIGTERM first on shutdown" [High,Triaged]
<RAOF> pitti: Particularly test-case (although I expect that you'll be aggressively following up anyway)
<pitti> RAOF: ah, can do; there are several reporters who will test this anyway (and already did so in the PPA)
<pitti> RAOF: I'll add it
<pitti> I thought the description was already sufficiently clear
<RAOF> pitti: It is pretty clear, but it's nice to have a simpleminded test case to run through :).
<pitti> RAOF: added
<RAOF> pitti: Also - what's the regression potential for it? The comment in the revert is all âwaiting for this is unreliable and breaks stuffâ.
<pitti> RAOF: typing
 * RAOF holds his finger over the âacceptâ button...
<RAOF> ...oh! Tea's ready!
<RAOF> :)
<pitti> RAOF: added
<RAOF> Ah, ok. So the worst failure mode is âshutdown is delayed by some number of 90s timeoutsâ? Rad.
<pitti> RAOF: reportedly in nspawn
<pitti> RAOF: so it could also be in LXC
<pitti> RAOF: but I've never seen that, so I can't really tell how often it happens
<pitti> RAOF: it's ceratinly not a real fix, just a compromise to let stuff actually shut down cleanly (bash, mosh, probably other programs too)
<pitti> now: session gets immediately SIGKILLed
<pitti> with patch: session gets SIGTERMed, cgroup for the session is being watched for becoming empty, then it gets removed
<RAOF> Yeah, seems reasonable.
<RAOF> Accepted.
<pitti> and it will eventually get SIGKILLed if something is hanging
<pitti> RAOF: cheers
<cjwatson> wgrant: "reverse-depends: Error: Unknown release" is that something you can fix?
<cjwatson> ajmitch: ^- or you?
<wgrant> tumbleweed: ^^
<pitti> who has the power to modify the description on http://summit.ubuntu.com/uos-1505/meeting/22514/systemd-and-ubuntu-to-1604/ ?
<seb128> pitti, I can
<pitti> slangasek and balloons are probably already asleep -- dholbach?
<seb128> what do you need changed?
<pitti> seb128: ah -- let me think
<pitti> seb128: how about this: http://paste.ubuntu.com/11005549/
<seb128> pitti, done
<pitti> seb128: merci beaucoup !
<seb128> de rien !
 * mgedmin is amazed that his laptop takes more than 20 minutes to reboot (gave up waiting for shutdown staring at a black screen, used alt-sysrq-s,u,b)
<pitti> mgedmin: something is clearly hanging; can you have a look at /usr/share/doc/systemd/README.Debian for debugging shutdown hangs?
<mgedmin> thanks for that hint!
<tjaalton> why would installing xserver-xorg-lts-utopic on trusty cause this http://pastebin.com/S3Zy0FQB ?
<tjaalton> the x bits haven't changed
<tjaalton> proposed is enabled, though it didn't change without
<tjaalton> ok libegl1-mesa-drivers-lts-utopic needs to be installed manually
<tjaalton> which is weird
<pitti> mvo_: mind if I steal your util-linux merge?
<mvo_> pitti: go for it
<Laney> tumbleweed: is it on your stack again or should someone else take over?
<doko> pitti, bzr ftbfs
<zyga> mdeslaur: ping
<zyga> mdeslaur: I watched the gsettings vieo
<zyga> video*
<zyga> mdeslaur: I have one observation that you may find interestinog
<zyga> interesting*
<zyga> mdeslaur: windows went through a similar approach
<zyga> mdeslaur: windows has a layer where some writes are translated
<zyga> mdeslaur: and writes to legacy paths are redirected to per-user location
<zyga> mdeslaur: this works for filesystem and the registry
<zyga> mdeslaur: I can give you pointers after a meeting I'm in
<pitti> doko: ah, just saw the mail, yes
<Laney> ev: can we maybe delete https://launchpad.net/libtimezonemap ?
<Laney> afaik https://launchpad.net/timezonemap is the real thing
<ev> Laney, wgrant: any idea how I'd do that?
<wgrant> Laney, ev: YOu can't, since it's linked to the libtimezonemap source. You need to unlink it first.
<ev> can the UI say that?
<wgrant> Well, a mortal also can't delete a project themselves anyway, mostly for historical reasons.
<wgrant> But even I can't until it's unlinked.
<ev> its unlinked now
<wgrant> Yep
<Laney> Cheers chaps
<wgrant> It's also gone now.
<slangasek> barry: your dmesg output has some strange delays in it.  But it also shows the drm module loading 15s after boot, and completing initialization within 2s... so I don't think that explains the gpu-manager delays you're seeing.  It also looks like this all happens in the initramfs and your rootfs is only mounted 17s after boot, which is odd
<slangasek> barry: anyway, your 8s delay in the initramfs can't be blamed on systemd ;)
<barry> slangasek: ok.  i reboot this machine so infrequently i just haven't been annoyed enough to dig into it.  it's basically been upgraded since lucid at least, so it could be fairly crufty
<bdmurray> mpt: Do you have a color suggest for wily for errors.u.c?
<smoser> hey... anyone have an idea on how to determine if a drive is bootable ?
<smoser> i'm guessing that mr watson has an idea, or that grub can somehow figure it out.
<smoser> cjwatson, ^ didnt want to bother you, but if you're there .
<tumbleweed> Laney: on it
<Laney> cool
<Laney> noticed that reverse-depends is broken for wily because of it
<tumbleweed> yeah, that's a thing
<cjwatson> smoser: grub won't be able to; if I were you I would look up the spec for whatever firmware is in use and implement the algorithm prescribed there
<cjwatson> (in the case of BIOS, look up the congealed wisdom of the internet rather than the spec, but there's still an algorithm that the firmware implements)
<strikov> smoser: I know nothing about gpt but in case of mbr arbitrary code can be stored inside the mbr boot recoder. It means that the only thing you can check is 0x55AA signature at the end of this code.
<strikov> anything else (partition to boot for example) depends on the code which makes decision i.e. you can't understand what's on its mind without running it
<smoser> strikov, wellk i need to figure out which device the bios would look at for that data.
<smoser> ie, i need the bios search order. or even more simplistically, "would the bios boot from this drive".
<cjwatson> there's no way to discover the real bios search order from the os.
<smoser> thats what i thought..
<smoser> but that sucks.
<strikov> smoser: iirc, in case of mbr disks bios chooses first with correct 0x55AA (or AA55 don't remember) signature at the end of boot record
<cjwatson> some bioses also implement a bit more than just 55aa too - they check things about the partition type
<cjwatson> *partition table
<smoser> right.
<cjwatson> I expect it's possible to find a sample algorithm somewhere
<smoser> well, my google foo fails me.
<smoser> just now, i have 2 systems... one of them is ocnfiugred in the bios to boot from cciss/c0d0, one is not.
<smoser> i have no way to know, and thus fail to boot on one and work on the other.
<smoser> really dont want the user to have to tell me.
<cjwatson> this is why my advice for a long time was to install the boot loader to the master boot record of all installed non-removable disks.
<smoser> yeah
<cjwatson> feel free to try to come up with something better, but I tried for years and failed.
<smoser> cjwatson, the othe rthought was to do so, and somehow fingerprint which it came from
<strikov> smoser: hm, bios settings are stored inside a separate chip which is powered via the battery on the motherboard
<cjwatson> pretty sure I've been down all these paths before you :)
<smoser> cjwatson, yes.. .that is why i bother you.
<cjwatson> ... and found that it was impossible.
<cjwatson> anyway, have to go for dinner, sorry
<pitti> elmo, apw: in case you are interested in the "move from ifupdown to networkd" session: https://plus.google.com/hangouts/_/hoaevent/AP36tYdEA6lEvNPGjxR0J_YbKeXK6hLl5joZb9ERTmNXMVN3Fd8Pqg
<bdmurray> pitti: If want to create the wily branch of apport I'd just take ~/ubuntu-core-dev/ubuntu/vivid/apport/ubuntu and then push to s/vivid/wily/ right?
<leszek> hi does anybody have a clue on what might be wrong when add-apt-repository is adding ppas but with wrong codename (wily instead of vivid) even though /etc/lsb-release is set up correctly and in python aptsources.distro.get_distro().codename shows vivid correctly ? Where does the add-apt-repository script grab the codename from ?
<leszek> even SoftwareProperties.distro.codename() shows the correct one vivid
<leszek> but in the end it adds wily to the sources
<leszek> when I try to add a ppa
<Unit193> codename = get_current_series_from_lp(self._info["distribution"])  is what I'm seeing.
<leszek> Unit193: thats means ? It only gets the current version of the ppa or what exactly ?
<leszek> anyhow it should always add the ppa for the distro I am currently using and not for the one that is default set on ppa (or whatever)
<leszek> and best of all the ppa (kubuntu backports) that I want to add does not even have a wily repo xD
<leszek> ah ok now I found a clue. Distro Name changing to somethign else then Ubuntu causes the issue. WTF
<leszek> in /etc/lsb-release
<leszek> I am still not getting why that is though or even should be
<pitti> bdmurray: sorry, was in UOS sessions; yes, we need to do that anyway, before we change apport in wily
<pitti> bdmurray: thanks for setting up the wily branch! (please update Vcs-* in debian/control too)
<hallyn> slangasek: if you have time, would you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.37-1.dsc into sid?  Also, would you be willing to sponsr me for Debian DM?
<highvoltage> :)
<arges> infinity: added bug 1452877, going to patch it. any objections ?
<ubottu> bug 1452877 in debootstrap (Ubuntu) "Add wily support to debootstrap" [Undecided,New] https://launchpad.net/bugs/1452877
<infinity> arges: Already fixed in vivid (task updated), but go nuts on the SRUs, sure.
<arges> infinity: cool
<infinity> Err, s/vivid/wily/
 * infinity updates properly.
<infinity> My poor brain won't shift codenames for another week or two.
<infinity> Despite how many times I've typed "wily" this week.
<arges> i keep typing willy
<dobey> wascwy wabbit
<Unit193> robert_ancell: Now that it is wily time, care to look at lp 1295207?  Been using the patch for a couple months now.
<ubottu> Launchpad bug 1295207 in pidgin (Ubuntu) "Migrate to farsight 0.2* / gstreamer 1.0" [Undecided,Confirmed] https://launchpad.net/bugs/1295207
<robert_ancell> Unit193, yeah, I guess that makes sense
<Unit193> Looks like it may be fixed once .12 is released as well.
#ubuntu-devel 2015-05-08
<pitti> Good morning
<Unit193> Howdy.
<pitti> wgrant: hm, seeing all the -dbgsyms in https://launchpad.net/ubuntu/wily/+queue?queue_state=0 is moderately confusing
<wgrant> pitti: Hm, indeed. +queue has its own special way of determining what is new, and it clearly doesn't work properly here.
<wgrant> (but the calculation for when things should be held in new is correct)
<wgrant> Can you file a bug?
<pitti> wgrant: yep, will do
<Snow-Man> mwahahahaha
<Snow-Man> spread the good news- PostgreSQL now has UPSERT.
<pitti> Snow-Man: that sounds like someone was interrupted by a phone call when writing SQL..
<Snow-Man> hahaha
<pitti> wgrant: filed bug 1452996 (should be "low" importance I guess, mostly just a visual distraction)
<ubottu> bug 1452996 in Launchpad itself "NEW queue shows -dbgsym packages" [Undecided,New] https://launchpad.net/bugs/1452996
<wgrant> pitti: Thanks.
<dholbach> good morning
<ts> morning bach
<pitti> hey dholbach
<dholbach> hey pitti
<seb128> hey dholbach & pitti
<dholbach> hey seb128 :)
 * mgedmin wonders if pitti'll be interested in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1453011
<ubottu> Launchpad bug 1453011 in apport (Ubuntu) "SegvAnalysis: Failure: invalid literal for int() with base 16: '='" [Undecided,New]
<LocutusOfBorg1> hi folks, now that the builders are somewhat idle, can anybody please retry this build? https://launchpad.net/ubuntu/+source/hedgewars/0.9.21.1-5
<LocutusOfBorg1> seems that locally it is building correctly now
<LocutusOfBorg1> (at least the haskell stuff seems to be fine on amd64)
<infinity> LocutusOfBorg1: amd64 still seems full of sadness.
<LocutusOfBorg1> can you please explain me why in my local wily pbuilder-dist environment it doesn't behave like that? I'm lost
<geser> LocutusOfBorg1: did you try building with wily-proposed enabled in your local builder?
<infinity> LocutusOfBorg1: What he said.
<LocutusOfBorg1> I tought proposed was enabled by default
<LocutusOfBorg1> bad me, I didn't check
<LocutusOfBorg1> how can I enable them in pbuilder-dist?
<LocutusOfBorg1> I see from the man page they should be enabled by default
<infinity> No idea, don't use pbuilder.
<LocutusOfBorg1> anyway, I'll sort it out, sorry for the noise
<LocutusOfBorg1> thanks
<LocutusOfBorg1> anyway, seems that there is a bug in pbuilder, I see them
<LocutusOfBorg1> http://paste.ubuntu.com/11022144/
<geser> LocutusOfBorg1: not sure if there is an easier way, but login into your pbuilder (don't forget to add --save-after-login), edit /etc/apt/sources.list, logout (your changes will get preserved)
<LocutusOfBorg1> (bad css is bad)
<LocutusOfBorg1> geser, this is what I usually do, wondering if there is a better way :)
<LocutusOfBorg1> infinity, I use proposed, but my apt seems to be smarter and discarding them
<LocutusOfBorg1> http://paste.ubuntu.com/11022226/
<LocutusOfBorg1> this is funny enough
<cjwatson> LocutusOfBorg1: I've only got up to about the third layer of <lots> of Haskell
<cjwatson> Snow-Man: yay, maybe http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/17402 can be less messy at some point
<geser> LocutusOfBorg1: http://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html , hedgewars is at level 6
<LocutusOfBorg1> cjwatson, the question is, why pbuilder-dist just discards the new haskell stuff and picks the release one?
<cjwatson> LocutusOfBorg1: don't know, don't care :)
<infinity> LocutusOfBorg1: Because pbuilder is erring on the side of "always make it build" instead of "do the right thing". :P
<cjwatson> geser: and it's more complicated than that, because the transition order we actually want to follow is Debian's
<cjwatson> which makes it hard enough to keep track without people jumping in and randomly retrying builds in the middle of it :)
<LocutusOfBorg1> yeah, I think so, I should make it behave more correctly
<infinity> LocutusOfBorg1: And that's aptitude, not apt.  The aptitude resolver is particularly silly in some cases.
<infinity> (Granted that silliness is probably exactly what a "normal user" wants, but it's the exact opposite of what a buildd wants)
<LocutusOfBorg1> yes, it is!
<LocutusOfBorg1> pbuilder-dist should use apt then, not aptitude.
<LocutusOfBorg1> I don't see any benefit in building something in the wrong way (at least in a developer tool)
<cjwatson> LocutusOfBorg1: you could use sbuild then
<infinity> ^
<cjwatson> if you don't see any benefit in doing things wrong :)
<geser> LocutusOfBorg1: check your pbuilderrc what is configured as build-dependency resolver
<LocutusOfBorg1> I just never learned sbuild
<LocutusOfBorg1> when a tool works flawlessly I don't see a need to change, but a bad resolver might be a good reason
<LocutusOfBorg1> geser, yes, I need to check that too
<pitti> seb128: hi! do you happen to be on the samba merge already? it currently causes a lot of uninstallability
<pitti> (samba-libs in particular, needs to build against current libldb1)
<seb128> pitti, hey, no I'm not, do I own that? I just did a bugfix upload, I was expecting zul or one of the usual samba maintainers to do that
<seb128> technically you are the one who owns the merge due your upload from yesterday :p
<pitti> seb128: right now, yes (TIL); I can look into it too, but indeed I've earned way too many merges due to doing archive fixes :)
<seb128> pitti, I can have a look if you want
<pitti> seb128: (no-change upload this morning, but it does feel like yesterday :) )
<seb128> pitti, the TIL doesn't make much sense on complexe packages which have an usual maintainer and where somebody else do a tiny change upload
<pitti> seb128: yeah, I know; I just don't think that samba has a "maintainer"
<pitti> seb128: either way, just didn't want to step on your toes
<seb128> I didn't start on it
<seb128> I can have a look if you want though
<pitti> seb128: doesn't look too hard; ok, I'll merge it
<seb128> pitti, thanks
<pitti> bdmurray: FYI, I committed http://bazaar.launchpad.net/~ubuntu-archive/apport/lp-retracer-config/revision/22 and rolled out to the LP retracers; we need the same for daisy
<pitti> cjwatson, wgrant: I did some spot checks, and ddebs.u.c./ seems to get all the dbgsyms for wily \o/
<cjwatson> pitti: excellent
<wgrant> pitti: Great.
<dodeluser> Got a question about editing "initrd.lz". According to this tutorial http://pastebin.com/qSkAXJdX   I made some changes successfully and repacked the file initrd.lz
<dodeluser> But when copying it to /remasteredisofolder/capsper/  it has no effect...... something that I am doing wrong?
<pitti> doko_: hm, the new version of python2.7/i386 consistently fails, this looks like a real regression?
<pitti> doko_: (http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-python2.7/4/ARCH=i386,label=adt/console)
<mvo> pitti: silly question but what sets ADT_REBOOT_MARK in the snappy-selftes? is that outside of the selftest? I was looking into some simple upgrade test fakeing
<pitti> mvo: adt sets it in the tests' environment, yes
<mvo> pitti: cool, thanks
<pitti> mvo: is the test losing it somehow? perhaps calling something through sudo which prunes the env?
<pitti> mvo: (see https://lists.ubuntu.com/archives/snappy-devel/2015-January/000057.html for how to run them with autopkgtest, BTW)
<mvo> pitti: no, all good, I was just curious how it works as I want to extend it
 * LocutusOfBorg1 wonders how many packages can be syncd from unstable now that xorg is transitioning
 * LocutusOfBorg1 looks at https://release.debian.org/transitions/html/xserver1.17.html
<mitya57> Mirv: do you know if someone is working on qtcreator update to 3.2 / 3.3 / 3.4?
<mitya57> The current old qtcreator has conflicting files with QBS, while a newer one can be built against our packaged QBS.
<Mirv> mitya57: zbenjamin has probably the best estimate. he has been working on upstreaming a lot of the Ubuntu SDK modified parts like the whole CMake stuff, and the update relies on getting to some sort of state where eg. 3.4 or 3.5 is such that it makes sense to update the rest of the patches to it while dropping the upstreamed parts
<mitya57> Mirv: ok. 3.4 was just released so maybe it's a good time to port the patches.
<doko> pitti: can you retry?
<pitti> doko: I can, but it didn't look flaky
<doko> I don't see it upstream on the build bots
<doko> http://buildbot.python.org/all/waterfall?category=2.7.stable
<pitti> doko: running again (4th try)
<pitti> amd64 is okay, i386 broken
<pitti> (consistently)
<zbenjamin> Mirv: i have a branch compiling against the current QtC master branch .
<doko> ahh, i386 only?
<zbenjamin> Mirv: so i would like to use that one
<mitya57> zbenjamin: master is 3.5?
<zbenjamin> mitya57: i think so
<zbenjamin> mitya57: it has all our patches we need
<mitya57> zbenjamin: Should be fine then. Can you include a change from Debian that makes it build against packaged qbs?
<zbenjamin> mitya57: is that patch already done for QtCreator in the archive?
<mitya57> Only in experimental.
<mitya57> http://anonscm.debian.org/cgit/pkg-kde/qt/qtcreator.git/commit/?id=e885d186c540cc12a875640ca3d719d88d6ff1aa
<zbenjamin> mitya57: not sure , can we Mirv?
<Mirv> zbenjamin: yes please we can take preferably as much as possible from Debian's qtcreator packaging :)
<Mirv> zbenjamin: we're pretty far out of sync unlike with Qt itself, but we don't necessarily need to yet to fully sync up
<Mirv> zbenjamin: so your thought is to package 3.5 git snapshot to wily?
<zbenjamin> Mirv: what is the release schedule for QtC?
<zbenjamin> i hoped we get 3.5 in this cycle
<Mirv> zbenjamin: it seems only in August https://wiki.qt.io/Qt_Creator_Releases
<Mirv> so yes this cycle but it'd mean we're stuck with 3.1 until then
<zbenjamin> Mirv: until then i'm fine with a snapshot i guess
<zbenjamin> Mirv: important part is that we get a release before we do one :D
<Mirv> zbenjamin: well wily is a development version so yes it'd be possible. as long as it like, you know, actually works :)
<zbenjamin> Mirv: well it seems they will feature freeze in june
<Mirv> zbenjamin: if we have that sprint we could hack on it together
<zbenjamin> Mirv: +10000
<mvo> pitti: is there a way to see the qemu terminal while adt runs? when it tries to ssh connect (I simulate a boot failure right now and would love to get some more info what is going on)
<pitti> mvo: you mean the output during boot? yes, adt-run --- qemu --show-boot myvm.img
<pitti> mvo: ah sorry, snappy runner, right?
<pitti> mvo: hm, /usr/share/autopkgtest/ssh-setup/snappy calls -serial none
<pitti> mvo: you could copy the script somewhere, change -serial none to e. g. -serial unix:/tmp//ttyS0,server,nowait
<mvo> pitti: yeah, the snappy runner
<mvo> pitti: aha, nice, let me try that
<pitti> mvo: and then nc -U /tmp/ttyS0 while you run
<pitti> mvo: that sounds like an useful option to add to the snappy setup script anyway, so bug report appreciated
<mvo> pitti: can I haz this by default? maybe not with a predictable name, but as a option or something?
<mvo> pitti: thanks :)
<pitti> mvo: yeah, probably just to stdout?
<mvo> +1
<pitti> mvo: i. e. a --show-boot option?
<pitti> (like qemu)
<mvo> yes
<mvo> pitti: added bug #1453154
<ubottu> bug 1453154 in autopkgtest (Ubuntu) "please support --show-boot option in snappy runner" [Undecided,New] https://launchpad.net/bugs/1453154
<pitti> mvo: ah, thanks
<aitiba> hi
<aitiba> Â¿can I ask here about lxc - linux containers?
<strikov> aitiba: #ubuntu-server might be the better place I think
<aitiba> doing a "lxc exec d1 -- /bin/bash" I get "websocket: bad handshake" error Â¿any ideas?
<aitiba> sorry
#ubuntu-devel 2015-05-09
<Logan> so DDE is dead, which means that pull-lp-source and pull-debian-source can't find the source package name from the binary package name
<Logan> is it too risky/janky to have the script query UDD's public mirror directly?
<Logan> (using Postgres)
<cjwatson> Logan: It's possible to do that lookup with LP now; I've been meaning to send a patch
<cjwatson> Will try to get that done soon
<Unit193> LP 1453330
<ubottu> Launchpad bug 1453330 in ubuntu-dev-tools (Ubuntu) "pull-{lp,debian}-source not getting source for binary because DDE is dead" [Undecided,New] https://launchpad.net/bugs/1453330
<gammax> Hi everyone :)
<gammax> i've got some questions related to ubuntu bugs
<gammax> Hi everyone :)
<gammax> i've got some questions related to ubuntu bugs
<gammax> Are there someone?
<cjwatson> gammax: not that I'm going to be able to answer as I'm about to go out, but you should always, always simply ask your question rather than asking whether you can ask.
<ari-tczew> how can I create pbuilder-dist for wily? I'm getting an error: Warning: Unknown distribution "wily".
<Logan> cjwatson: cheers
<psusi> mediatomb.service fails to start during boot saying it can't find eth0... my first thought was that it isn't depending on the network, but /lib/systemd/system/mediatomb.service does say After=NetworkManager-wait-online.service network.target, so what could it be?
<psusi> it seems that systemd is now what really handles system logging using its journal facility, yet passes things on to rsyslog which then dumps the backlog to syslog all with the same ( late ) timestamp.. why are we still using rsyslog?
<psusi> why doesn't systemd provides: system-log-daemon?  it is actually what handles /dev/log right?  so why do we still need rsyslogd?
#ubuntu-devel 2015-05-10
<slangasek> because in our default configuration the persistent logging is via rsyslogd, and this is intentional
<slangasek> so having systemd satisfy the dependency and throw away the logs on reboot wouldn't be very satisfactory
<slangasek> it would be possible to create a package which provides: system-log-daemon and just ships /var/log/journal, perhaps
<psusi> ahh, the journal is entirely in memory?  doesn't that chew up a lot of ram?
<psusi> so mediatomb.service fails to start at boot because the network is not yet up... it seems that network-online.target isn't waiting for NetworkManager managed interfaces to come up.. any idea how to get it to or where to file the bug?
<Unit193> infinity: Howdy.  So did a quick bzr log check of livecd-rootfs and ubuntu-cdimage for where you switched from using tasks to metas, was wondering how you did that.  Is it in another repo?
<cjwatson> Unit193: it's in livecd-rootfs but in the branches for various stable releases.  you should be able to find it from https://code.launchpad.net/ubuntu/+source/livecd-rootfs
<Unit193> cjwatson: Ah, thanks very much.
<cjwatson> Unit193: actually, sorry, make that https://code.launchpad.net/livecd-rootfs/
<cjwatson> {precise,trusty}-proposed
<Unit193> Right, found it.  Thanks again.
#ubuntu-devel 2016-05-09
<stub> Is the update-manager indicator on wily supposed to be informing people abount Xenial now?
<pitti> Good morning
<pitti> hallyn: indeed, that seems fairly new; can you please file one (debian or LP, doesn't matter) with how you got there, so that we can write a test case?
<infinity> stub: Yes.
<infinity> stub: wily upgrades were enabled pretty much right after release, it's only LTS->LTS upgrades where we delay until the point release.
<stub> ok, that was my confusion. I thought all recommended upgrades were delated until point release.
<stub> I like that word. I'm keeping it.
<infinity> stub: Nah, the justification is threefold: 1) wily->xenial is what most people were testing through the xenial cycle, so we're pretty sure it mostly works, while trusty->xenial has some bugs to iron out, 2) LTS users expect higher quality, so that 3 months of polish gets them a less crap release, and 3) we get to use the fasttrack EVERY SIX MONTHS IS A NEW UBUNTU, FUCK YEAH users as post-release beta testers for the LTS people.
<infinity> stub: That said, for technical Canonical employees, we recommend you upgrade way before release.  Slacker.
<infinity> (unless this was your mom's machine)
<ginggs> morning! would someone help me understand why bliss is not migrating please? if i am reading update_output correctly, then polymake is involved somehow.
<infinity> ginggs: That output is telling you that upgrading bliss will make polymake uninstallable.
<infinity> ginggs: Because polymake needs a rebuild for the libbliss1d->libbliss2 soname bump.
<ginggs> infinity: aha thanks!
<infinity> ginggs: Do you have upload rights for the rebuild, or shall I lob it at the archive for you?
<ginggs> infinity: no need to worry, i can do it
<infinity> ginggs: Enjoy.
<infinity> (dch -R)
<ginggs> infinity: for future reference, how did you get from 'will make polymake uninstallable' to 'needs a rebuild'?
<infinity> ginggs: I checked if any package names changed.  Saw the sover bump.  Checked rdepends of libbliss1d, which happens to just be libbliss* and polymake, extrapolated.
<ginggs> infinity: ok, manually then
<infinity> ginggs: One could also try installing in a chroot while explicitly excluding all the old packages (apt-get install polymake libbliss1d- libbliss1d-dbg-) and watch it whine, if it's to complex to understand at first glance.
<infinity> The second one is a better option if you see no immediate connection between your upload and the breakage britney is telling you about.
<infinity> Cause be an interim dep needs fixing, or a dependency is versioned in a way that breaks things, etc.
<jamespage> mwhudson, hey still awake? do you know if we're planning to adopt the shared linking stuff in go in any way just yet?
<jamespage> mwhudson, openstack has its first go based work it wants to include and they are struggling with approach so wanted to chime in with what we've done in Ubuntu for LXD and Juju...
<Skuggen> slangasek: Did you have time to review some sedition for making MySQL upgrades more robust?
<Skuggen> slangasek: https://github.com/ltangvald/mysql-5.7/commit/f57b068c956d0792bb35cec72fee8d66b0f513c7
<xnox> marga, W: http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg: Signature by key 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 uses weak digest algorithm (SHA1) ....
<xnox> =)
<juliank> xnox: that's in progress already AFAICT (the file already has a 4096R signature as well last time I checked)
<juliank> pub   rsa4096/0x7721F63BD38B4796 2016-04-12 [SC]
<juliank> It's now just a matter of the packages shipping a new key
<xnox> juliank, right. but the bug is not in the key, but in the parameters passed to gpg as to which digest algo to use =)
<juliank> xnox: No, no.
<xnox> hm?!
 * xnox thought it's about gpg --digest-algo SHA256
<juliank> You get the warning from a DSA1 key
<juliank> s/key/signature/
<juliank> that uses SHA1
<xnox> *sigh*
<juliank> xnox: On the other hand, the RSA signature seems to use SHA1 as well
<juliank> (But that's not the cause of the error yet)
<juliank> So while you are practically right in the end, this surprisingly does not follow from the error
<juliank> :)
 * juliank had to run gpgv manually to check
<juliank> xnox: If you want to track state, https://bugs.chromium.org/p/chromium/issues/detail?id=596074
<juliank> There's also the fancy https://bugs.chromium.org/p/chromium/issues/detail?id=440870 where we ask to install into trusted.gpg.d instead of using apt-key...
<seb128> juliank, hey, looking at bug #1562733 ... is APT::Update::Post-Invoke supposed to work in case of "E:" like "E: Some index files failed to download. They have been ignored, or old ones used instead."?
<ubottu> bug 1562733 in apt (Ubuntu) "apt signature requierements prevent updates from some repositories" [High,In progress] https://launchpad.net/bugs/1562733
<juliank> seb128: I forgot to update this. It currently doesn't.
<juliank> We'd have to swap some lines around
<seb128> k, so not a solution to the appstream issue :-/
<juliank> seb128: I think it should start working soon, we talked about this yesterday in #debian-apt
<seb128> juliank, is that swap something you consider doing/a fix or would it be a behaviour change you don't want for some reason?
<juliank> seb128: DonKult had some concerns because it was always like this; but I don't think the current state makes sense. What we want to do is make -Success run if not all sources failed. But it's slightly unclear yet how much work that is.
<seb128> juliank, would that be SRU material for 16.04?
<juliank> seb128: I'd hope so. 1.2.11 in yakkety is also SRU material, BTW.
<seb128> I guess it just requires somebody taking on doing the SRU then
<seb128> juliank, thanks!
<juliank> seb128: I can continue 1.2 releases for some time upstream (until 1.3 hits unstable), and they could be SRUed, as that's a sort-of-stable-series-intended-for-xenial
<seb128> juliank, that sounds good ... then I guess it would be up to mvo or infinity to handle xenial SRUs? or do you plan to handle those as well?
<juliank> Well, I don't have any upload permissions...
<juliank> Which means it does not really matter that much, it's just a question of who writes the SRU bug
<juliank> because if I do, someone has to sponsor-ACK it
<seb128> right
<pitti> slangasek, cyphermox: FYI, I did some research about packages integrating with resolvconf, and I think it's simpler better to do the DNS resolution part first/separately; I adjusted https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver accordingly
<pitti> i. e. this will continue to use resolvconf for the time being, and just replace dnsmasq on the desktop and introduce it on the server
<pitti> if we want to move from resolvconf to resolved for managing resolv.conf, that's doable, but rather independent, and should then become a separate BP; but this is much more work, and there is not much visible benefit
<rbasak> flexiondotorg: just to be clear, those packages are things you consider part of MATE, and should be included in part of any MATE packageset, right? As opposed to any special only-you upload thing.
<pitti> slangasek: I set it to "review" and proposed for yakkety (I can't accept any more); this is now all actually tested, too :)
<caribou> xnox: With LP: #1564475 you raised crashkernel to 196M, then LP: #1570775 talks to add cio_ignore output to the kexec kernel
<ubottu> Launchpad bug 1564475 in Ubuntu on IBM z Systems "128M is not enough for kdump on s390 LPARs" [Critical,Fix released] https://launchpad.net/bugs/1564475
<ubottu> Launchpad bug 1570775 in makedumpfile (Ubuntu) "makekdump should re-exec with cio_ignore on s390x" [Medium,Confirmed] https://launchpad.net/bugs/1570775
<caribou> xnox: what is the final decision on this one ? use cio_ignore + 128M or cio_ignore with 196M ?
<flexiondotorg> rbasak, Yes, those packages are part of the MATE package set.
<caribou> xnox: I'm preparing a version of kdump-tools that will set the value different if it sees an LPAR but I need to know if this is still relevant
<rbasak> flexiondotorg: OK. Just checking I didn't understand something. Thank you :)
<flexiondotorg> rbasak, No probs. Thanks.
<rbasak> Uh, misunderstand something I meant :)
<nacc> anyone else having wiki.ubuntu.com problems? https://wiki.ubuntu.com/NishanthAravamudan/YourDeveloperApplication says (while logged in) that "Immutable Page" for myself...
<pitti> nacc: log out and back in, SSO sometimes gets confused
<nacc> pitti: tried that 2x now, will try again
<nacc> pitti: ack that
<pitti> it's not immuatable for me, but the page is rendered tiiiiiiny!
<nacc> pitti: that's probably what is going on, if i had to guess, though
<nacc> pitti: weird :)
<pitti> nacc: I tried logging out and back in, and it's now hanging after SSO auth
<pitti> so, definitively something up here
<nacc> pitti: yeah, login takes a long time for me, but i wonder if it's the spam prevention stuff
<pitti> nacc: finished, can edit again, hmm
<nacc> pitti: still immutable for me :/
<nacc> pitti: heh, restarted chrome and now i get a 500 from the login :)
<nacc> pitti: second attempt, got logged in again, but immutable still
<seb128> bdmurray, hey, do you think you could look at https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1566201 ? it's the most reported e.u.c issue on the weekly summary
<ubottu> Launchpad bug 1566201 in apturl (Ubuntu) "/usr/bin/apturl-gtk:AttributeError:/usr/bin/apturl-gtk@47:main:enableChannel:doEnableChannel" [Undecided,New]
<seb128> bdmurray, and any idea why https://errors.ubuntu.com/problem/25cc76910cc3cfeaf1369ca3f208f5c3710046d3 fails to get a stacktrace?
<seb128> or https://errors.ubuntu.com/problem/d4cb05c46d65d26239b285df4c0162e393f4972a
<Michal_amateur> Hello, can somebody help me? I have game, I have backgroud image size 150x150 and I want multiple this picture to size for example 2000x2000.
<lathiat> Hi Michal_amateur, the channel for support is #ubuntu you should try there
<Michal_amateur> I see thanks, I will try
<bdmurray> seb128: both of those nm-applet crashes which failed to retrace have some "?? ()" in StacktraceTop in the first 4 parts.  I'll try and force a retrace of them though.
<seb128> bdmurray, do they have symbols after the ??
<seb128> or just those?
<bdmurray> seb128: http://pastebin.ubuntu.com/16321012/
<Umeaboy> Hi!
<Umeaboy> Any plans of getting an update for the package repo?
<sarnold> Umeaboy: can you rephrase your question?
<Umeaboy> May I please get an update of the repo package into 15.10?
<nacc> Umeaboy: existing release's versions need to follow the SRU policy at https://wiki.ubuntu.com/StableReleaseUpdates; usually new releses don't qualify in and of themselves
<Umeaboy> nacc: Right, but can't the upgrade notice at least be hidden by default?
<nacc> Umeaboy: what "upgrade notice"?
<Umeaboy> When you run repo init you see a message that there is a newer repo and that an update is suggested to install.
<nacc> Umeaboy: that's presumably something in the repo source itself? it's unmodified from Debian, so my guess is this is just how the packaged `repo` behaves
<nacc> Umeaboy: if you want, file a bug, I guess
<Umeaboy> OK.
<Umeaboy> I'll do that.
<Umeaboy> Thanks.
<Umeaboy> Have to go......take care!
<mwhudson> jamespage: yeah, should start using go shared libs in y
<hallyn> pitti: for that deb-systemd-helper error, I filed bug 1579922
<ubottu> bug 1579922 in init-system-helpers (Ubuntu) "dh_systemd_enable fails due to 'preset' when service file is renamed" [Undecided,New] https://launchpad.net/bugs/1579922
<hallyn> (may well be my fault, but if so then  Ineed gentle prodding and corretion :)
<hallyn> thx
<TJ-> is there any unmentioned dependency of dput that would cause it to stall whilst uploading to a PPA? According to iftop only about 871 bytes are sent - dput is showing "lubuntu-artwork_0.62.dsc: " and nothing else happens and the TCP connection eventually is dropped but dput continues sitting there until Ctrl+C
<sladen> TJ-: can you try 'strace'ing it?
<sladen> TJ-: you're probably found a parsing bug
<TJ-> sladen: I'm using python -m trace ... and it appears to be getting stuck at the sftp client
<sladen> TJ-: wireshark might be the next top
<sladen> TJ-: or ssh -v  and see how much setup is managed
<TJ-> solved it - somehow the id_rsa* from 15.10 had been replaced by a fresh generated key on the 16.04 PC; all the other keys (i have 1 key per service/server used) were the same. After doing that there was a "sign_and_send_pubkey: signing failed: agent refused operation" error, which required "ssh-add" to let the agent know about the keys
<sarnold> it might still be worth a bug report, good error messages are always nice :)
<TJ-> spoke too soon. It uploaded the .dsc then failed next with "lubuntu-artwork_0.62.tar.xz: Connection to ppa.launchpad.net closed by remote host."
<TJ-> this time it's continuing, showing a steady 1Mb/sec for the tar.xz file
<TJ-> I think that problem was the entire ISP connection dropping - just noticed the IRC client reconnected with IPv4 instead of IPv6
<TJ-> I've never known an LTS with so many issues as 16.04. I seem to spend most of my days tracking them down
<sladen> TJ-: please can you turn them into bug reports.  This immediately starts to help other people Googling with the same error messages, and in the medium term allows a starting point for getting them fixed
<TJ-> OK, got it again "lubuntu-artwork_0.62.tar.xz: Connection to ppa.launchpad.net closed by remote host." ... but iftop shows a steady 1Mb/sec upload still going on
<TJ-> sladen: they are all bug repports
<sladen> TJ-: excellent
<TJ-> sladen: along with patches in most cases
<sladen> TJ-: doubleplusgood!
<TJ-> But it would be nice if someone learned what 'regression tests' means :)
<cjwatson> some of us have 25000 of them ;-)
<sarnold> you could add dep-8 tests for the things you found so they'd show up on http://ci.ubuntu.com/ if they break in the future :)
<cjwatson> (upload problems to ppa.launchpad.net sound like connectivity issues, honestly - I agree with trying wireshark, you'll probably find some evidence in there)
<sarnold> hmm maybe not that, that looks ancien.t
<TJ-> this is nice "Successfully uploaded packages." ... despite the connection closed message... now to see if I get an Accepted email!
<TJ-> cjwatson: Yes, you're the guy I want! a bug in grub2 I had to chase with a client today actually. do you recall if you were responsible for the patches/sleep_shift.patch (adds Shift keys to GRUB_TERM_ESC in sleep --interruptable) ?
<TJ-> because on 16.04 Shifts no longer work, and the alternative Esc is causing issues because it is also the key that accesses the firmware's setup
<TJ-> cjwatson: I shall be filing a bug report on it shortly, now I've got the plymouth-theme-lubuntu-logo bug-fix uploaded, but wondered if sleep was one of yours?
<cjwatson> TJ-: I wrote that patch eons ago and it's known that it doesn't work on UEFI
<cjwatson> TJ-: but it's not my responsibility any more, you want cyphermox
<cjwatson> (well, not in Ubuntu anyway)
<TJ-> cjwatson: right, so there's a bug report... I couldn't find one earlier but maybe I didn't search well enough
<cjwatson> I don't know if there's a bug report but I knew about the issues when I wrote the patch
<cjwatson> UEFI doesn't (or at least didn't at the time) permit checking the status of keyboard modifiers with zero delay
<cjwatson> and I was instructed to make it zero delay
<cjwatson> so meh
<TJ-> ahhh bug 1028126
<ubottu> bug 1028126 in grub2 (Ubuntu) "grub hidden timeout does not react to shift" [Undecided,Confirmed] https://launchpad.net/bugs/1028126
<TJ-> cjwatson: thank-you :) I'll do some work on it then, see if I can come up with a fix
<cjwatson> I have a vague recollection that I might have tried to add a delay only on UEFI, but I don't remember if that's true or if so where
<cjwatson> certainly dig through the current spec version and see if you can work out a way to do zero-delay modifier checks
<TJ-> cjwatson: I'm working on cryptodisk patches to add keyfile support, and detached headers, which are going upstream, but not dabbled in the GRUB term code so far, still find it easy to get lost in the modules and abstraction at times
<TJ-> cjwatson: did you understand that to be a problem with UEFI itself, or GRUB's use of UEFI ?
<cjwatson> UEFI itself
<cjwatson> I haven't read the relevant bits of the spec for a while but at the time it was not possible to implement the getkeystatus method in grub-core/term/efi/console.c (as opposed to e.g. grub-core/term/i386/pc/console.c)
<TJ-> the "zero delay" being for the HIDDEN option of GRUB2?
<cjwatson> sounds right
<TJ-> ahhhh... OK, I think I can tackle it now... I wasted a few hours today searching fruitless in the source-code for the shift modifier... only to realise I was in the upstream repo, not the Ubuntu patched one!
<cjwatson> https://anonscm.debian.org/git/pkg-grub/grub.git will be close enough
<cjwatson> debian/patches/quick_boot.patch is the bit that relies on getkeystatus
<cjwatson> and that also has an attempted fallback
<TJ-> thank-you, that's really helpful.
<cjwatson> the Escape bit is in grub-core/commands/sleep.c:grub_check_keyboard
<cjwatson> so if that were made to check some other reasonable key as well as GRUB_TERM_ESC it would probably be a reasonable workaround for your client
<cjwatson> backspace or something
<TJ-> is the delay required for something in GRUB to settle... in other words, maybe "priming the pump" as soon as grub starts might help
<TJ-> Yes, that's one thing he asked, but trying to avoid having to maintain patches that won't ever make it into upstream or Debian/Ubuntu. He ships a *lot* of laptops with Ubuntu pre-installed
<ogra_> slangasek: i think your last livecd-rootfs change is missing bits in live-build/auto/build
<cjwatson> TJ-: no "settling".  the reason a delay was needed when I last checked the UEFI spec is that it could only detect transitions in modifier keys, not the current state
<cjwatson> TJ-: so that only works if there's enough time for a user to press a key in the relevant window
<cjwatson> TJ-: I haven't been involved upstream in a while, but I think adding some other reasonable alternative key to interrupt the sleep command could go upstream
<cjwatson> TJ-: it wouldn't really conflict with much else
<slangasek> ogra_: what bits?
<TJ-> OK, thanks for the background, it is making a lot of sense now
<cjwatson> np
<TJ-> that's a real foobar on the side of UEFI if it doesn't treat the modifiers as they were always intended
<ogra_> slangasek: there are other mentions of "ubuntu-core:system-image"
<cjwatson> eh, things are always fairly raw at the level of the firmware
<cjwatson> pretty much by definition
<slangasek> ogra_: yes; the ones I dropped were the only ones that were nested conditionals
<cjwatson> and I think you're reaching with "always intended".  modifiers were intended to modify other keys, originally; testing their state in isolation is a bit of an extension really
<cjwatson> obviously it would be nice if we could
<ogra_> slangasek: ah, so the $PROJECT:$SUBPROJECT construct still exists ? fine then ... ignore me :)
<TJ-> cjwatson: but the original IBM PC/AT hardware defined it at the I/O register level, so the bit flags represent the current state, not a transition
<slangasek> ogra_: it does still exist for the moment, yes... we can eventually simplify but that's a bit more of a refactor, since there are other projects with support for builds that key on SUBPROJECT=system-image
<slangasek> (whether they should or not is another question)
<cjwatson> TJ-: I think it may be possible now though; looking at the current-ish spec, the EFI_KEY_STATE_EXPOSED flag to EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.ReadKeyStrokeEx looks relevant
<ogra_> yeah, stuff for the athens sprint i guess :)
<ogra_> as long as stuff still builds allll is fine i guess
<ogra_> -ll
<TJ-> cjwatson: stop already, it's not your problem :p
<TJ-> cjwatson: but thanks for saving me a few hours already :D
<ogra_> (though it is yakkkety anyway .... nothing we currently focus on)
<cjwatson> TJ-: looks like this may have been added in UEFI 2.4, which postdated my original work.  I'll leave figuring out whether it actually works to you
#ubuntu-devel 2016-05-10
<bdmurray> pitti: Could you have a look at bug 1579949? (fwiw I can't assign apport project bugs to you)
<ubottu> bug 1579949 in Apport "add_gdb_info hides OSErrors when running gdb" [Undecided,New] https://launchpad.net/bugs/1579949
<TJ-> cjwatson: thank-you, I'll do that :)
<cjwatson> (there's a SetState method that you want to look at too)
<mwhudson> has something changed in the last week or so in the area of autopkgtest infra and proxies?
<rlaager> cjwatson: Are you saying you no longer maintain GRUB in Ubuntu and cyphermox does?
<Unit193> Likely part of his stepping back, and moving to LP things.
<cjwatson> rlaager: I still maintain the Debian package, but as Unit193 says I now spend most of my time on Launchpad development, so things I don't have time for include spending lots of time tracking down GRUB bugs in Ubuntu.
<rlaager> I'm just trying to figure out who might be able to accept: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1527727/comments/31
<ubottu> Launchpad bug 1527727 in grub2 (Ubuntu) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,In progress]
<rlaager> I know we missed Xenial on that, and I'm not necessarily even intending to propose an SRU, but it'd be nice to get into yakkety, so we have the correct fix, rather than the current workaround.
<Unit193> cjwatson: Oh, any update on being able to re-generate PPA gpg signing keys?
<cjwatson> Unit193: As opposed to just re-signing with current digests?  No, we haven't done any work on that, sorry.
<Unit193> OK, thanks.  Sorry for buggin'
<cyphermox> rlaager: hello
<rlaager> cyphermox: Hi! I'm someone interested in ZFS in Ubuntu, and I'm trying to help out with packaging work to that end.
<sarnold> s/trying to help/helping/  :)
<cyphermox> rlaager: ah, that's where I remember your name from then
<cyphermox> rlaager: I'm not in the right frame of mind to do grub changes now (and I have to fill in the Canada census), but I can look at the grub bugs for ZFS and shepherd things along tomorrow morning
<rlaager> I want two things: 1) To get changes into Ubuntu. 2) To know what I'm doing wrong or could do better to accomplish #1. :) So I'm still trying to learn the procedures here.
<cyphermox> rlaager: my morning would be in some 8-9 hours, would you still be around then or should I just comment on the bugs?
<sarnold> canadians really take this census seriously :) you're the fourth or fifth person I've heard talk about it :)
<cyphermox> sarnold: it's either that or multiple hours of community service, or potentially other punitive methods.
<sarnold> cyphermox: yikes
<cyphermox> I'm really stretching it given that the deadline is in about 1 hour 5 minutes in theory ;)
<sarnold> eek
<sarnold> is that "local midnight" or a specific midnight? :)
<cyphermox> local midnight
<cyphermox> TBH I have no idea
<cyphermox> usually "by May 10" should parse as before; but for government it may actually mean on May 10 at the latest
<rlaager> cyphermox: I'm in US/Central. This week, I'm at a work (telecom) conference followed by a Rotary conference in a different city. So my availability on IRC will be limited. So commenting on the bugs is probably best.
<cyphermox> and then I guess the TZ for that might be Ottawa's, but who knows ;)
<cyphermox> rlaager: will do
<sarnold> long form or short form? :)
<cyphermox> rlaager: I kind of also wanted to know how cjwatson felt about some of these, so we could get Ubuntu and Debian back in sync (which means I need to apply some other changes in the Debian vcs too
<cyphermox> sarnold: I don't know; I think it might be long form? we haven't had a census in a while
<cyphermox> I don't remember ever filling one
<sarnold> other friends who got the short form lamented they couldn't put 'jedi' in an official govt document. heh.
<cyphermox> sarnold: yeah, neither can you identify as anything but male or female.
<sarnold> maybe next decade..
<cyphermox> well they have the concept of marriage down ok, it seems
<cyphermox> and apparently, copyright attribution of census data!?
<sarnold> no kidding? :)
<cyphermox> no kidding.
<cyphermox> "do you accept that the census data from 2016 be accessible in 2108? (92 years after the census)"
<sarnold> <3
<rlaager> Is that even a question? You can't actually say "no" can you?
<cyphermox> you can actually say not
<cyphermox> *no
<cyphermox> I have no idea what that would change.
<rlaager> hmm. Everything's better in Canada I guess.
<cyphermox> I'm mildly curious, would look up census data from 92 years ago, if only my curiosity was higher than my laziness.
<cyphermox> sarnold: I suppose it had to be the short form, there weren't many questions
<sarnold> done with 53 minutes to spare? :) go-getter!
<cyphermox> rraaaahh!
<sarnold> the last .us census I did, I was selected for in-person interviews too, with another ~45 minutes of questions. The only question I remember now is how lop-sided their view of marijuana is: "Everyone should try marijuana" "strongly disagree", "disagree", "neutral", "agree". They left off "strongly agree" from that one... wonder why.
<cyphermox> fifth? :)
<cyphermox> or whatever amendment to not incriminate yourself
<Unit193> That does not sound fun.
<Unit193> Fifth.
<cyphermox> Unit193: I don't know, aside from having to go somewhere, it might be fun
<sarnold> funny enough there's some rules about how the results of census can't be used against you in court.
<sarnold> they came to the house!
<cyphermox> for example, how badly can you mess up the data while giving truthful answers.
<sarnold> hehe
<mwhudson> pitti: http://people.canonical.com/~pitti/scripts/britney-indexes-ppa needs updating for bz2 -> xz :-)
<mwhudson> sigh http://paste.ubuntu.com/16336342/
<sarnold> ouch
<sarnold> kind of hard to tell what error needs fixing..
<sarnold> can you reach your amqp server from that machine?
<mwhudson> i don't have an amqp server
<mwhudson> oh i see that's actually required
<mwhudson> i mis-read https://wiki.ubuntu.com/ProposedMigration/LocalSetup
<mwhudson> sarnold: "I: [Tue May 10 15:50:39 2016] - data/yakkety-proposed/autopkgtest/results.cache does not exist, re-downloading all results from swift" is also a pretty implausible line
<sarnold> mwhudson: hopefully that means your local swift :)
<sarnold> otherwise..
<Unit193> So 1562358 is "fixed" then, but not in the LTS...
<sarnold> it's got a 'xenial' 'new' task -- did you just add that?
<Unit193> I have no superpowers, may have missed that.
<sarnold> I can't recall seeing it hte first time I viewed the bug but it was there after I viewed the main lpsrc page. it's either poor memory or someone added the task in the middle. :)
<Unit193> I didn't get an email.
<cpaelzer> good morning
<doko> nacc, Trying easy from autohinter: php-zend-stdlib/3.0.1-1 php-zend-hydrator/2.2.1-1
<doko>     * amd64: php-zend-search
<doko> FAILED
<doko> Depends: php-zend-stdlib (>= 2.3.4-2~), php-common, php-zend-stdlib (<< 3~~)
<mwhudson> now britney is segfaulting for me
<ginggs> hi, How can I get dolfin into xenial as an SRU?  It was removed along with python-scientific (LP: #1542928). The lastest upload of dolfin drops the dependency on python-scientific.
<ubottu> Launchpad bug 1542928 in python-scientific (Ubuntu) "python-scientific should be removed" [Medium,Fix released] https://launchpad.net/bugs/1542928
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<sidi> Is there a document somewhere that describes the security checks done on packages in the Ubuntu repositories? And specifically, is there any difference in how main and community packages are checked/validated?
<shadeslayer> chrisccoulson: poke
<shadeslayer> chrisccoulson: I wanted to talk to you about firefox/thunderbird
<shadeslayer> chrisccoulson: for some reason dpkg-buildpackage on my CI on the ff package makes it always error out on the configure step
<chrisccoulson> shadeslayer, I don't really do anything with firefox or thunderbird these days, other than the minimum of work to provide updates
<chrisccoulson> I'm pretty busy with other stuff
<shadeslayer> Oh .. ok ...
<shadeslayer> guess I'll need to try and figure it out by myself
<shadeslayer> ( it's weird because it builds fine in sbuild , but apparently not with docker )
<bigon> hi I posted that on #ubuntu-server, not sure it was the correct place so I'm trying here again
<bigon> 13:29 < bigon> are there any objections if I'm hijacking the "selinux" package name in debian?
<bigon> 13:29 < bigon> ATM we have a selinux-basics package in debian an I was thinking about renaming it
<bigon> 13:30 < bigon> in ubuntu I see that there are some upstart scripts there
<bigon> 13:30 < bigon> do you actually care?
<bigon> 13:31 < bigon> last upload of that package is 2012, so...
<mdeslaur> bigon: I don't think anyone cares, I doubt selinux is in a working state in Ubuntu right now. Go ahead.
<mdeslaur> bigon: thanks for asking
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur, Laney
<Laney> 94 :(
<mdeslaur> Laney: I'm currently doing openldap, so don't take that one :P
<Laney> k
<Laney> probably wouldn't have been my first choice :-)
<mdeslaur> hehe
 * dholbach hugs Laney and mdeslaur 
 * mdeslaur hugs dholbach
<rbasak> infinity: with mvo out, could you take a look at bug 1571174 please?
<ubottu> bug 1571174 in squid3 (Ubuntu) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Triaged] https://launchpad.net/bugs/1571174
<rbasak> I'm not sure if this is an apt bug, or maybe fallout from the dpkg conffile renaming hacking going on in there.
<jamespage> slangasek, good morning
<jamespage> slangasek, I have net-tools on my merge list which we deferred from Xenial due to the large amount of changes the new snapshot from debian makes to output
<jamespage> slangasek, I last touched to unblock a sru that was causing some openstack-y issues
<jamespage> slangasek, would your team like to steal that from me?
<barry> pitti: ping
<smoser> barry, https://bugs.launchpad.net/ubuntu/+source/pyflakes/+bug/1580214 is kind of painful.
<ubottu> Launchpad bug 1560134 in pyflakes (Ubuntu) "duplicate for #1580214 TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'" [Critical,Confirmed]
<smoser> err.. https://bugs.launchpad.net/pyflakes/+bug/1560134
<ubottu> Launchpad bug 1560134 in pyflakes (Ubuntu) "TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'" [Critical,Confirmed]
<barry> smoser: i saw the emails ;(
<smoser> ok. its enough for me to know you're on it.  i noticed when curtin FTBFS now.
<barry> smoser: yep.  i'll take a look asap
<caribou> Could someone from the backport team help out with LP: #1335068 pls ?
<ubottu> Launchpad bug 1335068 in trusty-backports "Please backport apache2 2.4.10-1ubuntu1 (main) from Utopic" [Undecided,In progress] https://launchpad.net/bugs/1335068
<Laney> caribou: yep, I'll look in 2 minutes
<Laney> thanks!
<caribou> Laney: thanks to you ! This is the one we discussed previously
 * Laney remembers
<nacc> doko: will look
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<infinity> rbasak: It's not your fault (not apt's), it's ufw's.  Or, more annoyingly, it's that we need to sort out how to upgrade ufw early.
<jdstrand> infinity: is this related to that trigger change you made?
<infinity> jdstrand: Well, the trigger change was to get around it, but yes.
<infinity> jdstrand: The trigger change was correct, but it doesn't entirely fix the world unless ufw upgrades before things that trigger it.
<jdstrand> interesting
<jdstrand> infinity: fyi, I'm working with kees to get that change into Debian
<infinity> I'll give it some thought.
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> rbasak: Fixing this specific case could be done by having squid Breaks << the new ufw, but that's a lie.  If the upgrades are happening in the right order, I can do the Breaks from dpkg, but that might not help wily->xenial.  I'll ponder a fix that will more globally be correct.
<rbasak> infinity: thanks
<hallyn> pitti: hey - i assume you're busy sprinting and can't, but it would be awesome if you could take a look at bug 1579922
<ubottu> bug 1579922 in init-system-helpers (Ubuntu) "dh_systemd_enable fails due to 'preset' when service file is renamed" [Undecided,New] https://launchpad.net/bugs/1579922
<jderose> cyphermox: FYI, "Download updates while installing" has no effect with the 16.04 ISOs - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1580232
<ubottu> Launchpad bug 1580232 in ubiquity (Ubuntu) ""Download updates while installing" does not download updates" [Undecided,New]
<infinity> kees, mdeslaur, slangasek, stgraber: TB meeting?
<slangasek> jamespage: we can probably swing that
<jamespage> slangasek, awesome
<infinity> slangasek: Are you SRUing for https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1578006 as well?
<ubottu> Launchpad bug 1578006 in plymouth (Ubuntu) "Xenial minimal install: "W: plymouth: The plugin label.so is missing, the selected theme might not work as expected."" [Undecided,Fix released]
<infinity> slangasek: Seems like the sort of cosmetic cleanup we'd want in an LTS.
<slangasek> infinity: it's on my "list"
 * infinity adds a series task.
<infinity> slangasek: Kay.  I'm just reading through my apt-listchanges on my yakkety upgrade today and going "oh, that looks like it should be in xenial, ..." over and over again.
<infinity> slangasek: The other one that jumped out was the Debian maintainer of bsd-mailx reverting the removal of -b (BCC), thinking "hey, that's something spammers^Wsysadmins probably expect to work".
<bigon> is there a way of doing mass bug closing in lp?
<mitya57> There is an API :P
<bigon> but there is no std tool for that?
<mitya57> Not that I know of.
<bigon> :/
 * bigon says something about the mail interface of the debian bts
<cjwatson> bigon: LP has a mail interface too.
<cjwatson> You just have to sign mails that involve status changes.
<bigon> oh
<cjwatson> The normal API tends to be easier to use.
<cjwatson> https://help.launchpad.net/API/launchpadlib
<bigon> thx
<juliank> Laney: seb128: Is just running AppStream even on (partial) apt update failure OK for you guys? This should fix the gnome-software issue mentioned in #1562733
<juliank> infinity: What does it take for us to get apt 1.2.11 SRUed to xenial, and 1.2.12 once it's released and tested (changes for that being https://github.com/Debian/apt/compare/1.2.y...julian-klode:1.2.y?expand=1) - those are upstream micro releases with extensive test suite.
<juliank> 1.2.11 diff for the curious: https://github.com/Debian/apt/compare/1.2.10...1.2.11?expand=1
<juliank> I picked a commit that removes the annoying "There is no public key available for the following key ID" for 1.2.12, as that's really annoying now for the repos migrating from DSA to RSA (it only shows if one of the keys used to sign the repo is unknown, but the other sigs are valid)
 * juliank is trying to have an upstream 1.2 LTS series (for merging into xenial)
<juliank> Not all future 1.2 releases would be in Debian, but they  be tagged, and run their test suite using APT's usual CI tools
<juliank> Opinions welcome
<juliank> :D
<sarnold> any chance this gets rid of the "can't install package, package already installed" errors from dpkg? :)
<smoser> infinity, i've tested bug d-i kernels at bug 1568918 on i386, amd64 and ppc64el. what else would you want done before promotion to trusty-updates ?
<ubottu> bug 1568918 in maas-images "Add support for lts-xenial kernel flavours in trusty " [Medium,Confirmed] https://launchpad.net/bugs/1568918
<infinity> smoser: Test a xenial daily ISO too (any arch, don't care) and see if that's doing the right thing.
<infinity> smoser: Otherwise, I think we should be good.
<infinity> smoser: (d-i bits are used on the ISO, hence the connection)
<smoser> infinity, where do i get that ?
<smoser> xenial daily ?
<smoser> or trusty daily
<infinity> smoser: Err, trusty.  That one. :P
<smoser> http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20160510/
<smoser> right ?
<infinity> smoser: Yep.
<infinity> juliank: If the 1.2 branch is bugfix only and all changes have extensive test coverage, that should fit our new and improved micro-release SRU process, so I'd be more than happy to let 'em in.
<juliank> infinity: I did not run coverage checks (but the test suite is huge!), most commits even add coverage, as they include regression tests. There are some exceptions that cannot really be tested like https://github.com/Debian/apt/commit/57f16d51f4158dce1a49f6d5f5f05f057125b871 (but this one includes error messages for unwanted failure cases!)
<infinity> juliank: Sure, sometimes a single commit just isn't feasibly testable, but in general, every change in a microrelease should be regression tested to the best of upstream's ability to fit the new policy, that's all.
<infinity> juliank: I think we're on the same page there.
<juliank> That's the plan for all APT bug fixes in general.
<infinity> juliank: And if this won't be going to unstable (because you're moving on to 1.3.x), an apt-maintainers PPA that you use for pre-release CI would be a good idea, so we can have a better look at the state of 1.2.x on xenial before accepting an upload.
<juliank> infinity: That's quite useful, yes. We also run CI on all pushes using travis
<infinity> juliank: But, yeah, I don't see any fundamental issues with a 1.2.x branch for the LTS.
<juliank> travis runs on trusty IIRC
<juliank> (JFTR)
<infinity> juliank: The upshot of the PPA is we can get it building/testing on all arches with fairly minimal effort.
<infinity> juliank: Anyhow, we can hammer out details, but I'm happy to put a +2 (+1 from SRU team, +1 from TechBoard) on the idea.
<juliank> That's fine. I'd also like an recipe-built PPA like for master, but I don't think that's possible yet.
<infinity> juliank: git recipes are possible.
<juliank> Oh
<juliank> Maybe I should try playing with that
<infinity> juliank: I don't think we have automagic imports yet, though, so you'd have to run a local job to mirror git.d.o to git.lp.n
<infinity> But that's not too onerous.
<fo0bar_> infinity: https://wiki.ubuntu.com/ARM/RaspberryPi/RaspberryPi3#Bugs_filed updated with experimental -> yakkety merge request, and I've addressed your comment in MP: #293959 (and filed a corresponding bug for good measure).  that *should* be everything needed to get a working raspi3 target on yakkety
<infinity> fo0bar: Ta.
<infinity> smoser: d-i     passwd/user-password-crypted    password $6$.1eHH0iY$ArGzKX2YeQ3G6U.mlOO3A.NaL22Ewgz8Fi4qqz.Ns7EMKjEJRIW2Pm/TikDptZpuu7I92frytmk5YeL.9fRY4.
<infinity> smoser: ^-- Is that sha512 for "ubuntu"? :)
<smoser> you cracked my secret password
<infinity> smoser: I used to have a des crypt() NULL password string memorized (what a useless skill THAT is), but sha512 is a bit rougher.
<infinity> smoser: Do you still have that daily ISO sitting on your hard drive?
<smoser> well, on *a* hard drive
<infinity> smoser: I meant locally, so I can get you to do one more quick test (if not, I'll do it).
<smoser> sure
<infinity> smoser: Just wanted you to boot into the installer, hit a shell, and verify the booted installer kernel is also 4.4.0
<smoser> i have it booted to my install but i can do another isntall
<smoser> ah. yeah, i forgot.
<infinity> smoser: Which it should be.
<smoser> infinity, posted in bug
<infinity> smoser: Danke.  Will release to updates and fix up cdimage/netboot etc this afternoon.
<smoser> k. i'm out now.
<doko> ginggs, next gdal transition? omg
#ubuntu-devel 2016-05-11
<pitti> Good morning
<sarnold> what's the deal with http://archive.ubuntu.com/ubuntu/pool/main/b/blam/ ?
<sarnold> it's an empty directory, that seems odd.. but blam lives in universe, not main
<infinity> sarnold: Empty directories shouldn't stick around long.
<infinity> Oh, huh.  But that's been at the same version -- and in universe -- for years.
<sarnold> drwxr-xr-x 2 mirror mirror 2 Sep 12  2013 pool/main/b/blam
 * infinity scratches his head.
<infinity> Aaand, it's not empty on ftpmaster, that's why.
<infinity> Probably will empty out when we reap some old releases.
<sarnold> heh, was blam in main N releases ago?
<infinity> Dunno.
<sarnold> $ find /srv/mirror/ubuntu/ -type d -empty | wc -l
<sarnold> 9000
<sarnold> heh
<infinity> Hrm, this one actually looks like an ancient LP bug.
<infinity> http://paste.ubuntu.com/16356171/
<infinity> wgrant,cjwatson: ^-- whee, fun.
<infinity> (Granted, that version should be reaped anyway, but the orig/dsc split there across directories looks very busted)
<sarnold> blamblam? looks like a paste went awry
<infinity> Err, yeah.  Bad paste.
<infinity> http://paste.ubuntu.com/16356180/ <- Gooder paste.
<wgrant> infinity, sarnold: https://bugs.launchpad.net/launchpad/+bug/117780
<ubottu> Launchpad bug 117780 in Launchpad itself "packages unnecessarily symlinked to other components in primary archive" [High,Triaged]
<infinity> wgrant: There are no symlinks there.
<infinity> wgrant: orig is in main, dsc/diff are in universe.
<wgrant> infinity: Surely the orig is symlinked into universe.
<infinity> wgrant: http://paste.ubuntu.com/16356180/ is a complete ls. :P
<infinity> wgrant: Also, did we not kill hardy debs yet?
<infinity> s/debs/packages/
<infinity> Oh, we probably did.  I see no deb there.  But I bet the broken orig/dsc thing there prevented the source package from dying.
<infinity> So it's just left behind cruft.
<infinity> Curious how much of that sort of thing might be hanging around.
<infinity> Maybe we should reverse-magicmirror ourselves. :P
<wgrant> It thinks it's gone.
<wgrant> I wrote a script once to compare the pool to the DB, but never actually ran it.
<sarnold> :)
<infinity> wgrant: Well, the next time we go reaping a release, maybe we should run it.
<infinity> wgrant: And see how many GB of oops we have.
<infinity> For now, I think it's bed time.
<sarnold> night
<wgrant> Quite.
<wgrant> Oh we're in the same tz for once.
<infinity> wgrant: Well, off by an hour, but close enough.
<wgrant> Oh yeah.
<pitti> doko: OOI, does Debian's amd64 gcc also default to PIE now? i. e. should a patch for https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/g/gprbuild/20160510_073641@/log.gz go to Debian too?
<pitti> actually, I'm not sure if that's a bug in gprbuild or in gfortran
<Laney> juliank: do you mean the patch attached to the bug?
<Laney> if it's okay with ximion then fine by me
<juliank> Laney: Yeah, I applied it in git now. I'm not closing that bug as the SHA1 error still exists, but the issue with appstream and friends goes away.
<infinity> pitti: Debian's compiler doesn't default to -fPIE -pie, but it also doesn't hurt to apply -fno-pie -no-pie unrestricted in both Debian and Ubuntu when appropriate.
<pitti> infinity: ok, thanks; that still leaves the question of whether this should be done in gfortran or gprbuild, but I'll look at that later
<infinity> pitti: The only caveat of doing it unrestricted is that it makes the package unbackportable (the -no-pie args were only accepted as of xenial timeframe).
<infinity> But, meh.  Backporters are never my top priority.
<mwhudson> yes, i wish someone could  have had a crystal ball in 2012 and added it to gcc then
<rbasak> cyphermox: are you aware of bug 1576588 and bug 1576588? They seem to be rising in heat.
<ubottu> bug 1576588 in openvpn (Ubuntu) "google-authenticator with openvpn fails on 16.04" [High,Confirmed] https://launchpad.net/bugs/1576588
<doko> pitti, no
<rbasak> cyphermox: the other was bug 1211110
<ubottu> bug 1211110 in openvpn (Ubuntu) "network manager openvpn dns push data not updating system DNS addresses" [High,Confirmed] https://launchpad.net/bugs/1211110
<Laney> barry: did you see that the libpeas split got past NEW in Debian?
<Laney> what are your plans regarding syncing back up with that?
<mwhudson> jamespage: hi
<jamespage> mwhudson, hello
<mwhudson> jamespage: did my response about openstack help at all?
<jamespage> mwhudson, it did thanks - have that on my list to respond today
<mwhudson> jamespage: ok
<jamespage> mwhudson, there is alot of contention about whether openstack projects should be anything other than python...
<mwhudson> jamespage: i'll be working tomorrow night so we could have a chat about this in about 22 hours or so if that would be useful
<mwhudson> (it's a bit late now!)
<jamespage> mwhudson, that would be great
<mwhudson> jamespage: drop something in my calendar?
<jamespage> mwhudson, +1 will do
<mwhudson> cool
<jamespage> mwhudson, that would be first thing my time right?
<mwhudson> jamespage: i am 11 hours ahead of you currently
<mwhudson> so your 9am is 8pm for me etc
<jamespage> mwhudson, okies
<mwhudson> before 10pm my time would be appreciated :-)
<davmor2> mwhudson: wow you have your own timezone
<mwhudson> davmor2: there are a few other people here
<mwhudson> but not very many, indeed
<mwhudson> comared to, say, https://en.wikipedia.org/wiki/UTC%2B12:45
<barry> Laney: i did see it.  i had talked w/the debian maintainer and their approach was different but workable.  after i get a few other things done, i plan to resync for yakkety
<rbasak> infinity: any news on bug 1571174 please?
<ubottu> bug 1571174 in squid3 (Ubuntu) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Triaged] https://launchpad.net/bugs/1571174
<Laney> barry: nice
<Laney> barry: if there's some C/B/R needed we can probably upload those into debian
<Laney> to sync it
<barry> Laney: C/B/R?
<Laney> haha
<barry> ah
<barry> i get it now :)
<Laney> you probably need to deal with libpeas-1.0-0-python3loader
<Laney> but I would imagine we can accommodate that in debian
<barry> Laney: ack
<cpaelzer> infinity: I'll bring up STT_GNU_IFUNC on the dpdk mailing list next week as a joint request by Ubuntu/Debian/Cisco/Brocade for a long term solution
<cpaelzer> infinity: do you WANT to be part of that discussion (on CC) or should I keep you out of it (the default)
<infinity> cpaelzer: I don't need to be part of it.
<nacc> is it a known thing that the amd64 kernel builds are failing at http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/ ?
<nacc> true of http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/BUILD.LOG.amd64 as well
<fidencio> cjwatson: hey/ping
<fidencio> cjwatson: not sure if you're the right person to ask, but I hope you can at least point me to the right person
<fidencio> cjwatson: so, I'Äºl be working on adding support to express installation (preseed) for ubuntu on libosinfo (and consequently on gnome-boxes)
<fidencio> cjwatson: all the released ISOs support the preseed installation or just the "server" ones?
<cjwatson> fidencio: -> cyphermox in general for this kind of thing
<fidencio> cjwatson: thanks, let's wait for him then.
<mterry> pilot in
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<cholcombe> question for you systemd guys.  when you start a service with systemd does it wait for it to come up or just return immediately? i'm trying to track down a bug that only surfaces in xenial
<rbasak> cholcombe: I think it's supposed to wait, assuming that the service definition means that it can know
<rbasak> I'm not sure though.
<cholcombe> rbasak, hmm ok
<cholcombe> yeah i'm not sure either
<cholcombe> my guess is that it would wait but i don't know for sure
<rbasak> The real question is: in your case, how would it know?
<cholcombe> rbasak, good question.  I'll check gluster's systemd file and see what they're doing in there
<rbasak> cholcombe: BTW, it's fairly common for daemons to "daemonize" before they're ready and thus lead to a race condition. I've seen it in a few cases.
<cholcombe> i believe that's what is going on.  My code depends on systemd bringing up gluster correctly and it works fine in trusty.  Testing in xenial shows some kinda weird race condition where my code tries to do things before gluster is finished coming up
<cyphermox> fidencio: all installs support preseeding.
<fidencio> cyphermox: okay, all installers, even the live medias, support preseeding
<cyphermox> yes
<fidencio> cyphermox: super, thanks!
<cyphermox> fidencio: on the "live" setups, you want to boot with 'only-ubiquity automatic-ubiquity' on the kernel command-line probably, that turns on the bare-bones just-do-preseed UI
<cyphermox> it will still pause to ask any questions that you haven't preseeded, but should otherwise run unattended
<fidencio> cyphermox: hmm. interesting. and do you know whether I can face some issues passing 'only-ubiquity automatic-ubiquity' on the kernel cmd line on "non live" setups?
<cyphermox> fidencio: it should be safe, if you don't start ubiquity it won't matter
<fidencio> cyphermox: right. I'll try to come up with something. Hope you don't mind with me coming back asking for help :-)
<cyphermox> not at all. #ubuntu-installer is also a good place for general installer-related questions
<fidencio> cyphermox: super, I'll join the channel
<fidencio> cyphermox: thanks a lot for your help
<cking> mterry, mind you can peek at the ZFS MIR again? bug 1532198
<ubottu> bug 1532198 in zfs-linux (Ubuntu) "[MIR] zfs-linux" [High,Incomplete] https://launchpad.net/bugs/1532198
<cking> bah, programming in x86 has messed up my head, I meant to say "do you mind peeking at.."
<mterry> cking, sure
<mterry> cking, looks good to me
<cking> mterry, thanks, I can get one of the kt to upload it into -propsed for me and let it go through the SRU process then
<mterry> cking, not yakkety?  :)
<cking> that to..
<mterry> MIR bugs don't care about SRUs  :)
<cking> mterry, ah, i forgot that, I don't do MIRs that often
<mterry> cking, I mean, *I* personally like SRUs, but yeah, once a release is out, we can't promote anything in old releases
<mterry> but cool!  With the promise of an upload I'll go ahead and mark the bug fix committed
<mterry> cking, ^
<mterry> cking, on that note actually, you mention SRUing your dep8 patch for spl-linux, but yakkety would be sufficient.   Less paperwork
<cking> mterry, ack, OK
<cking> mterry, for the spl, the SRU for the dep8 would be useful to catch any regressions if we make subsequent fixes to SPL over the next 5 years
<mterry> fair.  dep8s are great  :)
<cking> yeah, I love catching bugs before they get passed -propsed ;-)
<doko> pitti, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71072
<ubottu> gcc.gnu.org bug 71072 in ada "[6/7] gnat doesn't respect --enable-default-pie" [Normal,Unconfirmed]
<coreycb> arges, bdmurray: hello, just a friendly alert to let you know we have a brand new mitaka stable point release for neutron* in the xenial queue
<arges> coreycb: ok i'll take a look
<coreycb> arges, thanks
<arges> coreycb: why is the bug invalid 1580674
<arges> bug 1580674
<ubottu> bug 1580674 in neutron-vpnaas (Ubuntu) "[SRU] mitaka point releases" [Undecided,Invalid] https://launchpad.net/bugs/1580674
<coreycb> arges, I just fixed that up
<arges> coreycb: why is it invalid in yakkety
<arges> coreycb: we can't upload a newer version in xenial than yakkety
<coreycb> arges, gah
<coreycb> arges, let me get this into yakkety first
<coreycb> arges, we'll fix that up and let you know once it's done.  I forgot we're in a weird point in the release where yakkety is basically mitaka for now.
<pitti> doko: gnat upstream bug> thanks
<doko> pitti, yes, but we need a proper test case
<doko> anyway, th gnat transition is still blocked, but doesn't block anything else
<mterry> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> smoser: you should see a fix for LP: #1560134 show up in yakkety after the normal sausage making
<ubottu> Launchpad bug 1560134 in pyflakes (Ubuntu) "TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'" [Critical,In progress] https://launchpad.net/bugs/1560134
#ubuntu-devel 2016-05-12
<Unit193> Richard Wilbur still active?
<sarnold> looks like it https://bugs.launchpad.net/bzr/+bug/1572314
<ubottu> Launchpad bug 1572314 in Bazaar "--profile-imports crashes with relative imports in plugin" [Undecided,Incomplete]
<Unit193> Guess he's just not active where I was looking nor on IRC anymore, meh.  Thanks.
<Unit193> FWIW, I've poked berry a couple time about bzr-fastimport fixes, poked the Debian maintainer, and understandably they want it fixed upstream/are pending on his review, which was done a year ago.
<pitti> Good morning
<infinity> pitti: Is the init-system-helpers upload in the xenial queue still relevant?  The yakkety changelog makes it seem like perhaps it isn't?
<pitti> infinity: it is, and it is still applied to yakkety too
<infinity> pitti: Ahh, the xenial upload is the combination of all the yakkity uploads, then?
<pitti> infinity: the thing we introduced and reverted in yakkety was a check for `runlevel` failing, but that was something else (and I never intended to SRU that)
<pitti> infinity: yakkety had two fixes, one of which got reverted again in y, and the other (the important one) stayed and got SRUed
<infinity> pitti: *nod*
<seb128> pitti, can you maybe review/approve the gstreamer-vaapi update? you approved the rest of the gst stack but they need to go together or things get uninstallable (like currently vaapi needs to be removed if you want to try the 1.8.1 update)
<pitti> infinity: are you doing SRUs? thanks (cloud folks are waiting for this fix)
<pitti> seb128: ack, will do
<seb128> danke
<infinity> pitti: Minor nitpick.  Given that the default RL in Debian (under sysv) has always been 2, it would seem that would be the better RL to "fake" there, not 5.  Especially if it's later used to validate/call rc?.d/Sblah, where a local admin may have only bothered to add an rc2.d link.
<pitti> infinity: hm, it's been 5 since vivid
<infinity> pitti: Note I said "under sysv".
<infinity> pitti: Yes, it's been 5 since the systemd switch. :)
<pitti> infinity: but this check isn't actually used to determine whether a service is enabled, it just checks whether the corresponding symlink is broken
<pitti> so it really doesn't matter that much
 * infinity shrugs.
<pitti> I can change it to 2 if you prefer
<infinity> Don't really care deeply.  I think this affected Debian more than Ubuntu, and would have mattered more if this was happening during the jessie release.
<pitti> at some point I'll throw out that entire `runlevel` parsing thing under !sysv, it's completely irrelevant
<infinity> By now, people are sort of upgraded to the new world order already.
<alkisg> Hi! $ grep ID_FOR_SEAT /lib/udev/rules.d/71-seat.rules
<alkisg> TAG=="seat", ENV{ID_FOR_SEAT}=="", ENV{ID_PATH_TAG}!="", ENV{ID_FOR_SEAT}="$env{SUBSYSTEM}-$env{ID_PATH_TAG}"
<alkisg> This rule makes my second GPU get ID_FOR_SEAT=drm-pci-0000_01_00_0, while the fbdev for the same GPU gets a different ID_FOR_SEAT=graphics-pci-0000_01_00_0
<alkisg> I.e. drm belongs to a different seat than fbdev! Is that a bug that I should file against udev, or did I understand something wrong?
<pitti> alkisg: I'm not familiar with that rule really; it would be great if you could file this at https://github.com/systemd/systemd/issues so that we can discuss it there with upstream?
<alkisg> pitti: thanks, I'll check if it originates from upstream and file it there
<pitti> alkisg: it does
<pitti> seb128: done
<seb128> pitti, danke
<seb128> could somebody on SRU shift look at network-manager?
<seb128> there is a 7 days verified version in xenial-proposed
<seb128> and a new cherry pick bugfix on top of that in the queue
<seb128> that fixes wifi reconnect not working for quite some users and it's flagged by the oem team as something they need to see resolved
<seb128> so would be nice to get it in proposed today if possible
<seb128> either by copying the previous to update/accepting the new one
<seb128> or just accepting it in top of the current one
<infinity> happyaron: That network-manager patch needs to go to xenial too, I assume.
<willcooke> yes please!
<infinity> happyaron: Err, yakkety.  I just accepted it in xenial, but it needs to go to yakkety. :P
<pitti> infinity: I commented on the openstack SRU diff, please don't accept it for now
<infinity> happyaron: Pretty please.
<pitti> (commented in the bug)
<happyaron> infinity: will do, :)
<infinity> pitti: I'm not really processing the full queue, just cherry-picking here and there cause I can't sleep.  Openstack wasn't on the list. ;)
<pitti> infinity: heh, ok; I guess I can't talk you into reviewing systemd, as I can't review that myself? :-)
<infinity> pitti: I just opened the diff to decide if I care.
<infinity> +  * Revert "enable TasksMax= for all services by default, and set it to 512".
<infinity> pitti: Was that an upstream commit, or a Debian local thing?
<infinity> pitti: FWIW, I agree wholeheartedly with reverting it.  A system with only systemd-init and no fancy session management (ie: libpam-systemd) should, IMO, default to no limits.
<pitti> infinity: it was committed upstream in version 228, and reverted downstream
<pitti> infinity: upstream discussion is still ongoing, but people run into this with xenial so I'd like to SRU it now-ish
<infinity> pitti: Right, we tried to "fix" it with making sure libpam-systemd is everywhere, but...
<infinity> pitti: Wide open just feels like the right default, in the absense of fanciness.
<pitti> infinity: that's one aspect, but things like mysql seem to run a gazillion threads even on moderate workloads, so 512 is not enough for them
<pitti> arguably these shoudl specify their own resource limit over time, but not for 16.04
<infinity> pitti: They should specify a limit, sure, but the system limit still shouldn't be crap.
<pitti> infinity: yes, agreed
<pitti> infinity: I meant that it's still beneficial to add resource limits to units one by one, and then doing it properly
<pitti> like also adding some file system protection, removing capabilities, and similar
<infinity> pitti: Accepted.
<pitti> cheers
<Saviq> pitti, hey, you being the resident systemd expert, I've a similar bug to #1438612 (and there are actually others reporting it in there as well) - I've nfsroot on one machine and network gets torn down too early, making anything trying to access rootfs hang - any pointers on what to collect to debug?
<seb128> infinity, thanks for the nm review
<Saviq> bug #1438612
<ubottu> bug 1438612 in dbus (Ubuntu) "remote file systems hang on shutdown, D-BUS stops too early" [High,Fix released] https://launchpad.net/bugs/1438612
<Saviq> pitti, I've debug shell enabled, but by the time this issue happens I can't do anything since any access to / results in a hang
<infinity> seb128: NP.  Just make sure happyaron gets the same patch in yakkety too. :P
<pitti> Saviq: nfs-root does not sound related to dbus stopping too early, this is almost surely a different bug
<Saviq> pitti, yeah I'm quite certain it has nothing to do with dbus, but the symptoms are similar
<pitti> Saviq: things that are useful is your /etc/network/interfaces*, /etc/fstab, and a jouranl output which includes the shutdown bits
<Saviq> I suppose network is just taken down too early (with nfs-root, is it ever *not* too early)?
<pitti> Saviq: which I realize is a bit tricky as the journal lives on NFS (or do you have a local /var?)
<pitti> Saviq: right, network should not get stopped at all with root on NFS
<pitti> Saviq: the initrd brings it up, and ifupdown should not touch it at all then
<pitti> Saviq: does your /e/n/i refer to the net interface that NFS is on?
<alkisg> pitti: thanks, I filed it under https://github.com/systemd/systemd/issues/3243, hopefully it's a real issue and not some misunderstanding of mine
<Saviq> pitti, yeah, I do have dhcp on it, otherwise resolvconf and NM are messing with things - should I just drop NM and resolvconf and pop it from /e/n/i ?
<infinity> pitti: Wow.  I shouldn't have read that bug log.  "I'm not sure if root on nfs was ever supported".  And now I have more people to be grumpy with. :P
<pitti> Saviq: err yes, you can't have ifupdown mess with the interface that NFS is on
<pitti> Saviq: otherwise ifupdown will shut down the interface during shutdown if it's anything but "manual"
<infinity> You should list it as manual to avoid NM touching it, probably.
<pitti> Saviq: something like "iface eth0 manual" should hide it from NM?
<infinity> Jinx.
<Saviq> pitti, right, it does mean a bit more manual config (resolv.conf) than I'd like, but oh well
<pitti> Saviq: well, that's the bit where I said "you need half an OS in initrd"
<pitti> which effectively makes the initrd your root fs :)
<pitti> infinity: I'm *still* not sure whether we ever officially supported root on NFS :)
<infinity> pitti: Well, Linux clearly does.  Debian does.  Ubuntu might? :P
<pitti> our installer doesn't offer it, so my inclination was and would be "no"
<pitti> and we don't have a test plan for it either, otherwise things like the above would have popped up much earlier
<pitti> so it's well in the "you break it, you get to keep both halves" territory
<pitti> infinity: same for Debian really
<infinity> pitti: I wouldn't mind testing it more, only because it's a good test of boot/shutdown being otherwise sane.
<pitti> people have a gazillion different configs, but that doesn't mean that it's reasonable to support the combinatorial explosion of them
<infinity> pitti: The DHCP handoff bit seems to have bitrotted, though.  I vaguely recall this working better.
<pitti> i. e. we get bug reports here and there and fix some of them, but without putting some efforts into installer and CI this will just keep breaking
<infinity> But, instead of poring over that, I think I'll go back to bed.
<pitti> (don't get me wrong, I don't object to fixing things of course -- just that this has bitrotted more than once)
<pitti> and without installer support, everyone will configure it differently wrong
<infinity> pitti: Sure.  That quote was from the upstream bug report, not from you.  My complaint was people saying "well, Linux can't do that, because I'm 12 and I forget that people have been using computers in a certain way for the last two decades". :P
<infinity> s/forget/don't know/
<infinity> Basically, I'm just a grumpy old man.
<pitti> infinity: I think it actually was from me
<infinity> pitti: Oh.  In that case, nevermind.  If the "we" in the sentence was "Ubuntu", I agree (except in the ltsp case, but I suspect it hasn't been tested thoroughly since the systemd switch).
<infinity> Especially given Edubuntu not releasing this cycle.
<alkisg> infinity: nfs rw root has been working fine for ages, with "manual" in ifupdown
<alkisg> ltsp supported it until overlayfs broke nfs submounts
<infinity> I *think* ltsp was the only place where we ever claimed to "support" nfs-root, any other attempt was best-effort.
<pitti> right, I think ltsp sets up a "manual" stanza
<pitti> and that's correct
<pitti> it STFUs ifupdown and NM
<infinity> alkisg: Yeah, manual should DTRT indeed.
<infinity> Well, it'll do a thing.
<infinity> I question if it's right.
<infinity> But it sort of works. ;)
<infinity> The right thing is more complicated, and maybe I never wrote it.
<infinity> I thought I did, but I can find no evidence.
 * infinity shrugs.
<pitti> Saviq: so, if it still hangs with "manual", please let me know and file a bug with the journal, fstab, and /e/n/i
<alkisg> (Details: LTSP doesn't support rw NFS, only ro + aufs or overlayfs, it still works fine with systemd and aufs, but not with overlayfs. Unrelated to LTSP, NFS rw still works fine afaik)
<infinity> pitti: When you and stgraber decide to tear out our network stack and jam a new one in, remind me that I sort of care about nfsroot, and maybe I can make it a bit more Just Works)
<infinity> pitti: initramfs-tools is entirely missing the code I wrote in my head a few years ago, which implies that it stayed in my head, cause I'm a tool. :P
<pitti> infinity: NM will stay as it is, so we'll have to keep hiding it from it (but we can move that blacklisting into some NM config)
<pitti> infinity: networkd does not touch interfaces that are not explicitly configured, but neither does ifupdown, so that's the same
<alkisg> Dracut also supports nfs4 for nfs root afaik
<pitti> i. e. we mostly need to teach people and installers to *not* create a network config for the thing that NFS is on
<infinity> pitti: Right, NM needs blacklisting, but that's not the real concern, the real concern is that we should be transferring control from initrd to userspace (or, alternately, forwarding more config info), so manual configuration of any sort isn't needed.
<infinity> We've been doing this wrong for ages, and it kinda works, but is fiddly.
 * infinity shrugs.
<pitti> yeah
<alkisg> infinity: my idea in some related bug report is that the boot interface is marked and saved somewhere in /run, and all the tools respect that automatically and never bring it down...
<pitti> Saviq: how did that /e/n/i config for the ethernet interface get into your system anyway? did you add that manually?
<pitti> Saviq: or was that some installer thing?
<Saviq> pitti, no, my doing
<Saviq> pitti, I added it so that resolvconf gets the DNS, but you're right I probably shouldn't have - not sure if resolvconf has a way to get it from when initrd asked dhcp
<pitti> Saviq: no, you really shouldn't re-run dhclient on that interface, you might get a different IP and break NFS again
<Saviq> pitti, right, of course (well, it's a static lease in my case but you're still right) :)
<pitti> Saviq: so I guess one takeaway from this is that the initrd's dhclient should haul the DNS/NTP information into userspace/resolvconf
<pitti> I think that would make a fine request/bug report
<pitti> and it shouldn't actually be that difficult, the initrd just needs to drop a file into /run/resolvconf/ ideally
<Saviq> pitti, ack - will file one
<pitti> Saviq: against resolvconf or initramfs-tools, but I think the former
<pitti> i-t should not really know about resolvconf, but then again its NFS hook might not be sufficiently extensible
<pitti> well, we can reassign
<alkisg> initrd has `ipconfig`, not dhclient, by default
<Saviq> ack
<alkisg> It doesn't have the concept of leases
<juliank> So, APT 1.2.12 is in yakkety now. If someone can lead me through what is needed to get that into xenial as a new upstream microrelease (I suppose it's appending some ~ubuntu something changelog entry), or wants to do it themselves (I can't upload anyway!), please do.
<juliank> We should also upgrade yakkety to apt 1.3~exp1 from experimental
<juliank> (probably)
<infinity> juliank: If we'd done the latter, we wouldn't have to do the former. ;)
<infinity> (ie: we could just sync 1.2.12 from unstable to xenial)
<infinity> But, too late.
<juliank> infinity: Yeah, next time. Both releases were uploaded the same time, and the auto sync catched the 1.2.12 release early on. I set up a PPA for future 1.2 releases at https://launchpad.net/~deity/+archive/ubuntu/apt-1.2 which will then see 1.2.13 and so on.
<infinity> juliank: Anyhow, ideally what we want is a bug filed against apt/xenial with a changelog dump of changes between xenial and 1.2.12, a short explanation of why this is all sane and happy, and then a changelog entry for 1.2.12~ubuntu16.04.1 with "Backport 1.2.12 to xenial (LP: #1234)"
<ubottu> Launchpad bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234
<infinity> Ish.
<infinity> ubottu: Oh, shut it.
<ubottu> infinity: I am only a bot, please don't think I'm intelligent :)
<infinity> juliank: If future 1.2.x releases will be xenial-only, the LP: closure should just be in the upstream changelog, so we don't have to bother with the "backport" entry.
<infinity> Well, I suppose even if they're not xenial-only.  I do a lot of LP closures in Debian uploads too.
<rbasak> infinity: poke on bug 1571174 (please!)
<ubottu> bug 1571174 in squid3 (Ubuntu) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Triaged] https://launchpad.net/bugs/1571174
<pitti> sil2100, robru, infinity: how do we review https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=libhybris ?
<infinity> rbasak: If you want a quick workaround, just SRU squid to Breaks: ufw (<< 0.35-0ubuntu2)
<pitti> it was a sync from a landing PPA which already got repurposed and does not have the package any more
<infinity> rbasak: I'm sitll pondering a more sane global solution.
<pitti> so we don't have a .changes, a .diff, nor links to SRU bugs etc.
<juliank> infinity: OK, I'll go and write a bug
<infinity> pitti: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-029/+packages?field.name_filter=libhybris&field.status_filter=&field.series_filter=
<pitti> infinity: ah, thanks; so no SRU bugs, you lose ?
<pitti> or do we accept touch things without the SRU process?
<infinity> pitti: I'd reject.
<infinity> pitti: Both because of the lack of bugs, *and* the deleting the silo before it landed (which they're not meant to do).  Both those things kinda imply they don't actually care about that SRU (or maybe it was unintentional).
<pitti> not sure if we even build touch products out of xenial, or how that triple landing is supposed to work, but it doesn't seem to get along well with our normal stable process
<pitti> infinity: ack
<pitti> rejected
<infinity> pitti: Touch is meant to move to Xenial any day now, but landing to xenial would follow the same SRU rules as anyone else, they don't get to be special.
<infinity> pitti: Unfortunately, rejects from silos end up in an email blackhole, so you might want to poke Simon directly and tell him about it, though. :P
<rbasak> infinity: squid3/ufw> thanks, I'll go ahead and do that.
<rbasak> infinity: I assume we want an upload to Yakkety with the same Breaks first?
<infinity> rbasak: No.
<infinity> rbasak: It's unnecessary in yakkety, since we don't support upgrading to yakkety from << xenial.
<rbasak> Oh, because all upgrade paths togo through Xenial?
<rbasak> OK.
 * rbasak ponders how to test this
<pitti> morphis: hey! I rejected libhybris from the xenial SRU queue; the silo is already gone and the upload did not refer to any LP bugs (which we need for SRUs)
<rbasak> Can one get do-release-upgrader to use a PPA?
<rbasak> I guess I could just use dist-upgrade if it reproduces.
<infinity> rbasak: Yeah, reproduces here.
<infinity> apt-get install ufw squid && sed -i -e 's/wily/xenial/g' /etc/apt/sources.list && apt-get update && apt-get dist-upgrade
<infinity> Obviously, starting with a clean wily schroot.
<rbasak> Yeah, trying it now.
 * rbasak is using lxd
<infinity> Potayto potahto.
<rbasak> schroot could do with a lxd backend incidentally. That's be nice.
<rbasak> And it exploded. Great!
<juliank> infinity: Does this look sensible for the first part (without the Ubuntu changelog entry for now, this has yet to be generated...): https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1580952
<ubottu> Launchpad bug 1580952 in apt (Ubuntu) "[SRU] Update apt/xenial to 1.2.12" [Undecided,New]
<infinity> I'll pop a Breaks in dpkg too (which is actually where it belongs, but upgrade order isn't guaranteed here).
<morphis> pitti: why was it pushed into the SRU queue? I thought all xenial uploads are going to the overlay ppa
<morphis> sil2100: ^^
<infinity> morphis: We can't answer the why.
<infinity> morphis: (Well, pitti and I can't)
<pitti> morphis: ah, so it was misdirected after all; no idea why
<morphis> pitti: yeah
<morphis> was never meant to be SRU'ed
<infinity> juliank: Looks quite sensible to me.
<pitti> Mirv: ^ on that note, was https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=qtbase meant to be an SRU, or an overlay PPA upload?
<infinity> morphis: So, on the one hand, I'm glad that was just a misfire we rejected.  On the other hand, there was meant to be a point in time where the phone played more nicely with the distro and the overlay PPA stopgap could be used less and less (and eventually die).
<infinity> morphis: That upload looked like it *could* have been suitable for an SRU, had a bug been attached to it.
<Mirv> pitti: it's meant for SRU, it has several xcb fixes
<juliank> infinity: I should really request upload permissions for APT at some point... Needs some endorsements on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU2 first (the 2 is there because of a wiki bug), though
<Mirv> (that are already in yakkety)
<pitti> Mirv: thanks
<xnox> doko, could you review for sanity? https://launchpadlibrarian.net/259134650/gcc-5.debdiff
<xnox> did a test build in ppa:xnox/nonvirt, builds everywhere.
<infinity> juliank: Uploaded.
<infinity> pitti: If you're feeling reviewy, apt/xenial could use some love.  Diff against yakkety is more obvious than diff against xenial, though both are useful.
<pitti> infinity: ack
 * infinity goes back to bed.
<juliank> bdmurray: I'd like to join bug control so I can set importance and stuff on APT bugs (and other packages I maintain in Debian or develop) - I'd consider that the "If you are an upstream developer or bug triager for an upstream project contact Brian Murray" part of the wiki :D
<doko> xnox, looks good
<juliank> I don't have a particular short list of bugs, though...
<xnox> doko, ok. I want to upload that into security ppa, then publish into -proposed, then eventually migrate to -updates&-security
<infinity> pitti: dpkg/xenial too, while you're at it, s'il vous plait.   And now really bed.
<pitti> infinity, juliank: bug 1562733 and bug 1562733 need an SRU test case; I figure the former is mostly to do some dist-upgrades and package installs, but some formal procedure is needed to verify this
<ubottu> bug 1562733 in apt (Ubuntu) "apt signature requierements prevent updates from some repositories" [High,In progress] https://launchpad.net/bugs/1562733
<infinity> pitti: That was the same paste twice. ;)
<juliank> pitti: I don't really see that as closing 1562733, but just a comment in there that affects appstream
<juliank> Otherwise I'd have closed the bug itself in the changelog
<pitti> err, bug 1580952
<ubottu> bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Undecided,In progress] https://launchpad.net/bugs/1580952
<pitti> 1562733 is actually pretty clear
<pitti> adding google talkplugin source already does that
<infinity> pitti: 1580952 needs a test case?  It's an MRE upload.  The test case is "upload it and check the testsuite".
<juliank> pitti: 1562733 is  really more about allowing to fetch from such repositories, which I did not do; I just changed the hooks to also run if some repositories failed, but that's not really the main point of the bug.
<infinity> And 1562733 isn't closed by this upload, unless I'm blind...
<juliank> pitti: FWIW, there's a regression test case in the upload that runs on autopkgtest.
<pitti> ah, good
<juliank> Test case would be: Have a repository that you cannot fetch from due to errors -> Post-Invoke-Success scripts still run
<pitti> hmm, why did sru-review open that bug then
<juliank> AKA https://anonscm.debian.org/cgit/apt/apt.git/tree/test/integration/test-apt-update-hooks?id=35664152e47a1d4d712fd52e0f0a2dc8ed359d32
<infinity> pitti: Anyhow, I'll let you and juliank sort out if his bug is short on info.  I think I'm finally tired enough to sleep.
<juliank> infinity: You could syncpackage apt 1.3~exp1 to yakkety before you go to sleep
<infinity> pitti: I guess I should update that squid/ufw bug with a test case too, so you don't reject my dpkg. :P
<pitti> I didn't reject apt, I accepted it, but for testing it we still need to know *what* to test :)
<infinity> pitti: Bug updated, bedifying.
<pitti> infinity: sleep well!
<rbasak> infinity, pitti: "Should succeed if either squid or dpkg have been updated for the Breaks.
<rbasak> " - so do I still want the squid SRU?
<rbasak> I'm getting an even bigger explosion in testing the squid SRU Breaks BTW.
<infinity> rbasak: I think probably.  It's hard to guarantee that dpkg will be upgraded first.  And, oh?
<rbasak> infinity: http://paste.ubuntu.com/16374154/ - haven't really looked at it yet.
<rbasak> This is with my proposed squid SRU, and without xenial-proposed I think.
<infinity> rbasak: Gross.  But not related to what you're doing, at least.
<rbasak> Oddly I wasn't getting this before though.
<infinity> Well, you wouldn't have gotten that far before.
<rbasak> Hmm, OK.
<juliank> I think I have a problem getting sponsor endorsments on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU - almost everything I do is synced automatically, only sometimes do I have to manually request a sync.
<infinity> juliank: I'm happy to endorse.  Ask me again tomorrow when I'm not pretending to sleep, though.
<pitti> so much for "really sleep" :)
<rbasak> infinity: looks like a lxd/systemd interaction. The service is failed on a xenial instance, too.
<infinity> pitti: I'M SLEEPING SO HARD.
<infinity> ZZZZZZ
 * rbasak tests harder, as infinity would say.
<seb128> chrisccoulson, hey, do you know how firefox determine what handler to use to open files?
<seb128> I'm trying to figure out why it tries to open launchpad .tar.xz with gedit
<seb128> the dialog sttes that it's of type "archive XZ" so it seems to get that right?
<seb128> I don't see a Content-Type info if I capture packets using wireshark
<seb128> though I wonder if that could be bug #645924
<ubottu> bug 645924 in Launchpad itself ".tar.xz files are served with text/plain content-type by launchpadlibrarian" [Low,Triaged] https://launchpad.net/bugs/645924
<seb128> but the firefox dialog states the type is "archive XZ" so it somewhat knows the type
<infinity> rbasak: Confirmed that the dpkg fix worked for me.  But I can't guarantee that dpkg will always configure before squid3, so fixing both won't hurt.
<rbasak> infinity: ack
<Mirv> cyphermox: cjwatson: do you think there's a solution possible at some point in the future for bug #1530530 ? comment #13 has the useful information of SeaBIOS reusing existing framebuffer. removing gfxboot from Ubuntu image makes it possible to boot & install Ubuntu.
<ubottu> bug 1530530 in gfxboot-theme-ubuntu (Ubuntu) "Installer doesn't show up on some Chromebook" [Medium,Confirmed] https://launchpad.net/bugs/1530530
<cjwatson> Mirv: sorry, not me
<Mirv> cjwatson: no problem
<tkamppeter> infinity, hi
<Mirv> not sure if anyone is familiar with gfxboot initialization code
<cyphermox> Mirv: pretty sure that system should be booting EFI, not BIOS.
<Mirv> cyphermox: I think by design it's not possible to boot other than via the SeaBIOS payload currently. there's no EFI, only coreboot.
<cyphermox> I thought all chromes enforced and used EFI
<cyphermox> anyway, it's definitely possible to look through the gallium gfxboot code and see if there's anything we can steal from it
<Mirv> well where it's possible to choose the boot option, that's before EFI. and there one can select the legacy boot option where it's possible to install SeaBIOS. other parts of the flash are more proteced. but I'm no expert.
<Mirv> oh, if galliumos is using gfxboot, they'd definitely have some trick probably then
<cyphermox> but I can't exactly say I know very well how it all works. gfxboot is the kind of thing you want to tiptoe around very carefully
<Mirv> cyphermox: do you know if it's easy to what unetbootin used to do, ie remove gfxboot from existing image and add dummy boot option instead? I could write a wiki page about modifying ubuntu image to boot without gfxboot.
<cyphermox> I have no idea what it does
<Mirv> ok. it has a text menu that works, it's just unetbootin has bitrotted enough not to handle newer images.
<cyphermox> I would usually recommend people don't modify the images, that's easy to get wrong too especially if you're playing in the syslinux code. I guess it just runs syslinux with fewer options maybe?
<Mirv> it sounds like according to bug #1530530 that gallium uses grub instead
<ubottu> bug 1530530 in gfxboot-theme-ubuntu (Ubuntu) "Installer doesn't show up on some Chromebook" [Medium,Confirmed] https://launchpad.net/bugs/1530530
<rbasak> pitti: I just uploaded the squid3 half of the SRU in bug 1571174 if you don't mind reviewing please.
<ubottu> bug 1571174 in squid3 (Ubuntu Xenial) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,In progress] https://launchpad.net/bugs/1571174
<cyphermox> Mirv: ok
<muktupavels> trevinho: do you have time to look at my new compiz merge proposals?
<cyphermox> Mirv: I don't know if we have gfxboot just for the prettiness or if it's because it works better on some systems. If it's just for the prettiness, we can maybe look into using grub everywhere, I have been playing with the grub graphical menu a few weeks ago
<Trevinho> muktupavels: ok
<Mirv> cyphermox: I agree it's a change that's hard to validate to be bullet proof, although great that we've just done an LTS... grub everywhere could make sense but only if the graphical mode does not bring problems that can't be fixed with some fallback
<cyphermox> cjwatson: do you recall if there is another immediate impact of replacing gfxboot with grub, or if it's just that gfxboot is shiny and was there first?
<cyphermox> not that I'd really want to change this just for the sake of change
<cjwatson> cyphermox: it's just that we never worked out how to replace the interface
<cyphermox> ok, thanks
<cjwatson> it was always something we wanted to do, just hard work
<cyphermox> Mirv: ah, indeed this would mean no keyboard/language selection at boot
<cyphermox> yeah
<Mirv> cyphermox: right, similar to how we don't have that selection in EFI mode already
<Mirv> cyphermox: ubiquity does have language selection on bootup if one doesn't enter the gfxboot menu to select it. EFI/grub mode doesn't currently have a default that would boot into that graphical language selection / live-or-install.
<Mirv> it could all use some more coherence, like always booting to the ubiquity language / mode selection menu.
<Mirv> now bios gfxboot vs efi grub boot experiences are quite far from each other
<happyaron> question, should we still disable dns caching in dnsmasq by default (for NetworkManager)?
<mdeslaur> happyaron: the privacy issue on multiuser systems remains, so yes
<MrBIOS> hi folks, anyone here around? Iâve discovered that some non-upstream (Ubuntu/debian-specific)patches to Xorg cause it to segfault on start-up on Book-E PowerPC64 (big endian) machines. Simply commenting out most of the patches that do not apply to non-x86_64 machines seems to resolve the problem.
<MrBIOS> Iâd like to know how to file this ticket such that it gets fixed in the next point release of Xenial
<mdeslaur> MrBIOS: https://help.ubuntu.com/community/ReportingBugs
<MrBIOS> yes, I know *how* to file bugs
<MrBIOS> but not how to get them actually acted on by someone within the Ubuntu Xorg server team, who actually gives a shit
<teward> MrBIOS: beyond filing the bug, there's no way to expedite it in rapid motion
<happyaron> mdeslaur: so the only way for enabling dns caching is to have something like per-user dnsmasq?
<mdeslaur> MrBIOS: as teward said. Once you've filed the bug, you can paste it in #ubuntu-x and see if someone bites.
<mdeslaur> happyaron: per-user dnsmasq, or dnsmasq gains per-user caching, yes
<happyaron> ic
<teward> MrBIOS: but in supplement to what mdeslaur said, there's no guarantee someone'll bite and rapid-expedite it to the top of the list of things needing fixed by point release
<mdeslaur> happyaron: I believe there's a plan underway to replace dnsmasq with systemd
<mdeslaur> happyaron: but I don't know the details
<happyaron> ok
<juliank> bdmurray: Thanks!
<MrBIOS> well, if âXorg crashes, and I know how to fix itâ isnât something yâall care about, good luck with your distro :)0
<mdeslaur> MrBIOS: if you have a fix, you can subscribe ubuntu-sponsors to your bug and get it sponsored
<robru> pitti: yes if there's a train item in the upload queue but the silo has been deleted, please just reject with extreme prejudice. 99% of the time the silo was misconfigured as an SRU, published, reconfigured to point at overlay PPA and republished / merged / deleted.
<MrBIOS> mdeslaur: the âfixâ is to simply not apply some patches that are N/A to PowerPC, when xorg-server is built.
<bdmurray> juliank: no problem
<cyphermox> happyaron: I don't know that you should waste too much time on NM+dnsmasq, we might want to instead revisit whether we still want to use dnsmasq as the local caching server, and it's quite possible that we don't; and quite possible that we'd want to use systemd-resolved instead
<happyaron> cyphermox: yeah I've refreshed the patch and continued the merge, ty!
<cyphermox> what merge?
<cyphermox> AFAIK NM is at 1.2 for both xenial-proposed and yakkety, that should be good for now
<juliank> bdmurray: Do you happen to remember enough interactions from last year (python-apt IIRC) to add something nice to https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU?
<cjwatson> tjaalton: ^- perhaps you could sort MrBIOS's issue out?
<happyaron> cyphermox: 1.2.2 for yakkety, a trival one
<MrBIOS> cjwatson: tjaalton, I just filed https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1581076
<ubottu> Launchpad bug 1581076 in xorg (Ubuntu) "Xorg segfaults on start-up on Big Endian PPC hardware" [Undecided,New]
<MrBIOS> ah, there we go, thanks bot
<happyaron> cyphermox: but need some time for me as there are background/historical issues I need to read through
<cjwatson> MrBIOS: so I know nothing much about X myself, but it strikes me that you have an obvious target for bisection here if you wanted to make it quicker for the relevant developer
<MrBIOS> cjwatson: yeah, I have it narrowed down to one of ~19 small, non-upstreamed patches
<cjwatson> right, so that would be at worst five builds to determine exactly which one
<cjwatson> at which point I think you're a lot more likely to get somebody to bite
<cjwatson> it's not clear why e.g. "190_cache-xkbcomp_output_for_fast_start_up.patch" shouldn't apply to powerpc for instance, so this isn't just a pile of obviously x86-specific patches
<MrBIOS> yes, some of them can likely be safely applied
<tjaalton> 190 is disabled because it broke
<tjaalton> MrBIOS: you need to narrow it down to whatever breaks it for you
<MrBIOS> heh, I love how 227_null_ptr_midispcur.patch has been âwaiting for review from upstreamâ since 2009
<MrBIOS> yeah
<MrBIOS> last comment on https://bugs.freedesktop.org/show_bug.cgi?id=24181 was over three years ago
<ubottu> Freedesktop bug 24181 in Server/General "Reproducible segfault in miPointerUpdateSprite()" [Major,New]
<tjaalton> MrBIOS: maybe try without just 188
<MrBIOS> tjaalton: building
<teward> The next nginx upload which is a merge from Debian is going to be introducing 9 additional binary packages, which are dynamically-built modules and are not static-compiled into the nginx flavors.  nginx-core, a binary we created to include in Main, includes 5 of the 9 binaries as dependencies, in order to provide those modules as part of the core feature set (none of those are third party modules).
<MrBIOS> also, for things like 08_xfree86_fix_ia64_inx_outx.diff, why should that even be applied at all?
<teward> Where my confusion now is, is Main / Universe for those 9 new binaries
<MrBIOS> there is no IA64 Ubuntu flavor, is there?
<cjwatson> there used to be
<rbasak> teward: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.xenial/view/head:/supported-misc-servers
<teward> as a result of the 5 being install-depends for nginx-core, do those 5 dynamic module binary packages need to be in Main?
<rbasak> teward: nginx is in there
<teward> rbasak: ack
<tjaalton> MrBIOS: it's not applied as you can see from the series file..
<rbasak> teward: the 5 will appear in component mismatches if nginx-core depends on them I think.
<MrBIOS> yep just realized that, it actually fails to apply if you try to apply it, probably should just be removed completely.
<teward> rbasak: that's what I thought, then those 5 would then need Main inclusion I presume?
<rbasak> (assuming nginx depends on nginx-core).
<tjaalton> MrBIOS: it comes from debian
<MrBIOS> sufficient codebase drift since it was written
<MrBIOS> tjaalton: yes I understand
<rbasak> teward: right. Assuming the existing approved nginx MIR still applies, an archive admin should just move them over.
<MrBIOS> it can come from Debian and still be totally broken, those two things are not mutually exclusive :P
<teward> rbasak: nginx metapackage depends on the following in this order: nginx-core OR nginx-full OR nginx-light OR nginx-extras
<teward> rbasak: which has been the case since the initial MIR which put nginx-core in Main
<teward> rbasak: the rest of the flavors are in Universe
<rbasak> teward: OK, that should be fine then.
<teward> rbasak: that's what I thought, I'm still finishing up getting a Yakkety system in place to test upgrading, installation, etc.
<teward> so nothing's been uploaded yet
<tjaalton> MrBIOS: dropped it from git
<superm1> bdmurray: i got an email that fwupd upload might have caused regressions but I can't access anything about what happened.  do these get turned into launchpad bugs?
<superm1> given the nature of the upload that was made i highly doubt they were bugs caused by that upload, but likely existing issues that were just uncovered as people updated
<bdmurray> superm1: Oh, you don't have access to crashes at the Error Tracker? that might be useful.  Regardless those crashes are not regressions, I'll get it sorted out.
<superm1> i used to have access a long time ago, but it looks a lot different now than when i remember accessing it last
<superm1> so things have probably changed
<superm1> bdmurray: thanks for adding me.  could those crash reports be accessed somehow?  will the retracer run on them?  i'm guessing this is related to some USB device plugged into the system crashing the DFU provider but the crash reports appear to not be showing up.
<bdmurray> superm1: they were just package install failures, not crashes per se
<superm1> bdmurray: oh but i saw .crash files listed in their crash reports list
<superm1> but i guess that's what these were?
<bdmurray> superm1: everything has a .crash extension ProblemType distinguishes the type of crash / error
<superm1> bdmurray: oh.  so https://errors.ubuntu.com/oops/d55f4d9c-1868-11e6-b85f-fa163e8d4bab having 3 files really doesn't tell me anything than those 3 were being configured when there was a failure
<bdmurray> superm1: the Error Tracker isn't really well suited for package install failures yet
<superm1> ah darn
<superm1> it looks like this is probably a firefox postinst problem, but would be nice to know for usre
<bdmurray> package install failures like this still go to Launchpad even for stable releases
<sarnold> "is already installed and configured" has a long sad history :(
<sarnold> superm1: I did see in an apt-get update yesterday this message: AppStream cache update completed, but some metadata was ignored due to errors.
<superm1> sarnold: yeah that's what the fwupd fix in proposed was supposed to fix
<sarnold> superm1: ah! :D
<superm1> some local appstream data that fwupd shipped for some gaming mouse was causing it
<sarnold> nice to know it's known, sorry I can't be useful, heh
#ubuntu-devel 2016-05-13
<bigon> what was the process again to ask for the pkg removal from ubuntu?
<bigon> tyhicks: I see that you fix the build of https://launchpad.net/ubuntu/+source/refpolicy-ubuntu/ shouldn't the package be removed instead?
 * tyhicks scratches his head
<tyhicks> ha, that's why I don't remember fixing that
<tyhicks> Wed, 18 Apr 2012
<mwhudson> bigon: file a bug on the package asking for it's removal and subscribe ~ubuntu-archive
<mwhudson> *its
<bigon> thebwt: oh I saw 2016, but that when the archive for Yakkety Yak has been open I guess
<bigon> thx
<tyhicks> bigon: if we remove that, what is the replacement? selinux-policy-default?
<bigon> probably
<bigon> I'm pretty sure that the -ubuntu selinux policy is broken (no systemd support)
<bigon> but it is probably broken for other stuffs too in the previous version
<bigon> not sure that the current policy in debian is in better shape
<tyhicks> bigon: yeah, I also expect it to be pretty broken
<bigon> the one in debian is more or less my fault :p
<psusi> pitti, have you spoken with Lenart at all lately?  it seems that libatasmart has not been updated upstream in 2 years and this patch has been waiting to be applied there for 3 years... is the upstream dead? https://bugs.freedesktop.org/show_bug.cgi?id=61998
<ubottu> Freedesktop bug 61998 in library "Fails to read status from WD raptors" [Normal,New]
<tjaalton> I have DEB_BUILD_OPTIONS='parallel=8 noddebs' but sbuild still builds dbgsym packages, what's wrong?
<pitti> Good morning
<pitti> psivaa: I speak to Lennart a lot, but not about libatasmart -- this project is indeed unmaintained
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<seb128> pitti \o/
<cpaelzer> good morning
<cpaelzer> I guess the answer is no, but I might miss something. Does Launchpad on top of git also have some sort of integrated patch-review like gerrit/patchwork ?
<cpaelzer> hmm, for bzr that is eventually on the merge step, let me see if there is a git merge ...
<sarnold> there's this.. https://answers.launchpad.net/launchpad/+question/267929
<cpaelzer> sarnold: thansk, reading through it
<TJ-> is there a way to build a package using dh_auto_build that can have it use two Makefile targets, one after the other?
<pitti> juliank: now that we have apt finally in sync, could you rather apply the patch in bug 1573547 straight at the Debian side? (looks good enough to me)
<ubottu> bug 1573547 in apt (Ubuntu) "Apt's bash completion is incomplete" [Low,Triaged] https://launchpad.net/bugs/1573547
<ricotz> hello, did dpkg-source 1.18.7 got stricter about appearing binary files (e.g. *.pyc) while creating a source-package? 1.18.4 worked/works
<juliank> pitti: I have a pull request in github pending for that sort of thing (https://github.com/Debian/apt/pull/13/files), and it and the attached patch are both somewhat wrong
<juliank> That is, build-dep can also take source package names, and takes folders, not .deb files
<juliank> I think I'm going to do it myself, as the PR/patch submitters RTT gets a bit too high otherwise
<juliank> pitti: It's also still missing options like -t/--target-release but I'm not really sure where to apply them
<pitti> juliank: ah, thanks; so I won't apply this for now either
<juliank> pitti: Should I add a apt moo completion ;)
<pitti> juliank: what? that doesn't exist yet???
 * pitti files an RC bug
<pitti> "no apt is complete without completion for moo"
<sil2100> cjwatson: hey! Frequently in the last few days certain touch builds are failing on cdimage due to 503 errors while fetching files from livefs - do you know anything about it?
<sil2100> In the last two days it happened over three times now
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<juliank> pitti: This one seems really complete now: https://github.com/julian-klode/apt/commit/3dacc9806f1d51e0b963e2bca2be4d8f66e586df
<juliank> pitti: Would be nice if you could take a quick look, maybe I made a silly mistake somewhere
<juliank> typo, for example
<pitti> moo!
<juliank> pitti: I should count the number of moos to not suggest more moos than apt supports
<pitti> juliank: around line 35, this uses $GENERIC_APT_GET_OPTIONS" but repeats a lot of the options again; this looks a bit weird?
<pitti> same in line 144 (--target-release at least)
<pitti> I suppose duplicates don't hurt, but I wonder whether these commands really support all options and thus should actually include GENERIC_A_G_O
<juliank> pitti: Yeah, well, we do want to move them to more specific commands at some point anyway, I just added the entire list of options (for all apt-get style commands) there to catch them all
<pitti> juliank: ack; looks good to me otherwise, many thanks!
<juliank> pitti: The variable contains all the options our apt-get parser supports for all commands. This might not mean they are actually useable in there, but we have not really checked yet, I suppose (the parser code contains: // FIXME: move to the correct command(s))
<pitti> juliank: that seems fine; there's only so much logic one should repeat in the completion :)
<juliank> What I'd love to have is offer suggestions for --target-release, but I have not yet found a way to do so
<juliank> So -t <TAB> gives you xenial,xenial-something,etc.
<juliank> same for -t<TAB>
<pitti> juliank: i. e. collect the series from /e/a/sources.list{,.d/*}?
<pitti> that involves quite a bit of parsing indeed
<juliank> Or from apt-cache policy output the a= and n= fields, although it's not that parseable in case they contain a comma (but why would they)
<pitti> I wrote some parsing for sources.list with awk; it's not trivial because of the [] options, so it's not a fixed field
<pitti> (bbl)
<juliank> $(apt-cache policy | egrep -o 'a=[^,]*|n=[^,]*' | cut -f2 -d= | sort -u )
<juliank> Should suffice
<juliank> The question is more how to integrate that into the bash completion so both -t<TAB> and -t <TAB> are completed
<juliank> I think I've got it working
<LocutusOfBorg> thanks pitti for cmake
<juliank> pitti: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=5aba189
<juliank> oh build-dep misses directory support (directory containing a debian/control file)
<juliank> Hmm, I wish we could also have completion for pkg=version and pkg/distribution
<juliank> But that probably gets insane
<pitti> juliank: \o/
<juliank> pitti: Long term it would be nice to have a complete helper inside the apt binaries that generates possible input. That would get rid of a lot of duplication
<juliank> pitti: Do we also want that in xenial? If so, I'd cherry-pick that over into the 1.2.y branch
<pitti> juliank: harmless enough I guess
<juliank> The next 1.3~exp release is coming soonish, as I want to fix a bug WRT public key pinning (Signed-By in Release files)
<Laney> caribou: you shall go to the ball!
<Laney> and you can take apache 2.4.10 as your date
<cjwatson> sil2100: do you have a sample build?
<cjwatson> cpaelzer: right, you can just use merge proposals for git pretty much the same way that you do with bzr.  there are one or two missing features, but there are projects actively using git-based MPs.
<sil2100> cjwatson: yeah, some example logs:
<sil2100> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/vivid/daily-preinstalled-20160512.2.log
<sil2100> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/xenial/daily-preinstalled-20160513.log
<cjwatson> sil2100: I don't know of a specific cause, but 503s could just be transient load issues.  Somebody should probably try to get cdimage to backoff/retry in that case.
<caribou> Laney: I can think of a better one but thanks ! :-D
<nacc> slangasek: request for mind-refresh: drupal in debian/unstable is now indicating php7 support (although there's a bug in the dependencies and i've let the debian maintainer know). To sync that version down into Xenial, should I just file a new FFe/SRU bug? Trivial in the sense that our version now doesn't install and we released with this in mind?
<slangasek> nacc: yes, new SRU bug, referencing the previous discussion in the rationale
<hallyn> pitti: hi, libvirtd.service has "Alias=libvirt-bin.service", but it doesn't seem to work:
<hallyn> pitti: http://paste.ubuntu.com/16390766/
<rbasak> slangasek: would you mind reviewing the upgrade path seddery in https://github.com/ltangvald/mysql-5.7/commit/f57b068c956d0792bb35cec72fee8d66b0f513c7 please? Eg. version number check, leaving a backup file behind, and the quality/coverage of the regexp.
<nacc> slangasek: thanks!
<slangasek> rbasak: hi, great, I'll put that in my queue to take a look at; don't know that I'll get to it today
<rbasak> slangasek: np, thanks.
<hallyn> coreycb: pitti: hm, maybe it's a container issue.  or an upgrade issue.  when i cleanly install libvirt 1.3.4 in a vm, 'systemctl status libvirt-bin' does work
<coreycb> hallyn, interesting
<hallyn> coreycb: actually i htink it's an upgrade issue.  might be something i'm doing in the postinst in upgrade case
<hallyn> but i'd really prefer that we update all userspace to use libvirtd whe nneeded so that at 18.04 we dont' have this issue again :)
<coreycb> hallyn, I agree.  I'll sync with james on Mon.  but for now it sounds like I can upload nova with the original group fix only.
<drab> hi any ubiquity developers around? trying to track down a possible bug with dhcp hostname setup
<hallyn> coreycb: awesome, please do.
<hallyn> coreycb: uh, do you want to show me the fix you have real quick? :)
<hallyn> pastebin debdiff?
<coreycb> hallyn, sure, that wouldn't be a bad idea :)
<drab> if I install the sever version with the text installer the hostname is correctly set to what dhcp sends, but the same preseed file for a desktop version sets the hostname to "computer", which is what I have for d-i netcfg/get_hostname
<drab> it seems to me that ought to depend on ubiquity, but not 100% sure, still, no desktop is getting its hostname right
<coreycb> hallyn, http://paste.ubuntu.com/16392244/
<hallyn> coreycb: uh.  hm.  is that test what you really want?
<hallyn> or do you want '[ -n "$libvirt_group" ]' or something like that?
<hallyn> hm, suppose it works
<hallyn> ignore me
<coreycb> hallyn, good news is I just installed the package on yakkety and it installs fine
<coreycb> hallyn, ok ignoring and uploading then :)
<hallyn> thanks :)  ttyl
<BrAsS_mOnKeY> hello ;)
<xnox> infinity, slangasek - no change rebuild of d-i failed on i386/amd64 with mcopy talking about cylinders, sectors and tracks (no idea what any of those things are, is it related to floppy drives?!)
<xnox> mcopy -i./tmp/hd-media/boot.img ./tmp/hd-media/vmlinuz ::linux
<xnox> Total number of sectors (1603584) not a multiple of sectors per track (63)!
<xnox> Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
<xnox> not sure what to do about that. bump sizes somewhere and/or trump/ignore the error?
<infinity> xnox: Looking.
<infinity> xnox: It's going to be the new dosfstools, but I'll sort out what needs fixing.
<drab> any hint of what sets the hostname in an ubiquity autmatic installation? I'm looking at the code but can't find it
<drab> there's a d-i/source/netcfg that i'm looking at, but its purpose does not seem to set the hostname for the install
<drab> just to get the instance up and running
<infinity> xnox: Fix committed/uploaded.
<xnox> infinity, thank you! you are a star =)
<infinity> xnox: Well, in this case, it had already been argued about and worked around in Debian. ;)
<infinity> (But I tested locally to make sure it fixed it for us too, before uploading)
<drab> actually nm, it's there, in netcfg_activate_dhcp(...), can't figure out why it's failing tho
<xnox> drab, one moment.
<xnox> drab, netcfg/get_hostname=myhostname on the kernel command line should do the trick
<xnox> or d-i netcfg/get_hostname string myhostname in the pressed file as usual.
<drab> sure, I've got all the moments, I need to figure this one out cuz I need to deploy a large fleet of desktops and bad hostname is breaking the rest
<drab> xnox: I already have that and it's using it, but that's not what it's supposed to do
<drab> per comment in the seed file itself, DHCP hsotname is supposed to take precedence
<drab> and the dhcp server is sending that
<drab> I see that in casper.log
<drab> so the client is getting it, no questions about that
<drab> and ubuntu server is doing the right thing and setting /etc/hostname to it
<drab> but ubuntu dekstop xenial is not, even tho ubiquity installer is supposed to do anothing about netcfg (per wiki page)
<drab> so I'm lost why the same version of d-i would work on server version but not desktop version to set the hostname from dhcp correctly
<infinity> Because ubiquity is only sort of d-i.
<infinity> And doesn't quite follow all the same codepaths.  Annoyingly.
<drab> right, but isn't it supposed to be using d-i? it's in the repo and the wiki says "we leave d-i alone for a bunch of stuff, including netcfg"
<drab> maybe I misunderstood the meaning of that
<infinity> If I were setting up a d-i netboot infra for a mixed desktop/server environment, I wouldn't use the ISOs at all, I'd just netboot and change the task selection based on the target type.
<drab> the only thing I can think of is that NetworkManager is getting in the way
<drab> infinity: I was considering that and may just do that after all, I have the mini iso setup in pxe already
<infinity> drab: Wouldn't even use the mini.  If you're PXEing, I'd just use the netboot kernel/initrd and a preseed.
<infinity> drab: But whatever works for you.
<drab> infinity: ok, will try that out, thank you
<infinity> drab: The tasks you want are: "minimal" "standard", and "ubuntu{-server,-desktop}" (depending on target).
<infinity> drab: Or if you're doing it based on packages instead of tasks, ubuntu-minimal, ubuntu-standard, and ubuntu-{desktop,server}.
<drab> infinity: what if I want to setup something like lubuntu? I've seen metapackages for those, like lubuntu-desktop, would the netboot still work with that?
<drab> I ahve some old machines I need to use lubuntu for
<infinity> drab: Yup!
<drab> cool, ok
<drab> thank you very much
<infinity> drab: minimal, standard, and lubuntu-desktop
<infinity> drab: You can probably see a pattern here. ;)
<drab> :)
<infinity> drab: By all means, don't let me talk you out of submitting bugs/patches for ubiquity preseeding, but it'll always be annoyingly a bit different from a pure d-i environment.
<infinity> drab: So, in your case, if you're deploying server, desktop (and other desktops), you'll probably lose less hair by using the same installer for everything and just tweaking the one task selection line in your preseeds.
<infinity> (Note: it will be slower, though, since d-i netboot uses debootstrap for the inital rootfs, rather than blatting out a squashfs like the ISOs do).
<drab> infinity: yeah, that was one of my worries, I was actually thinking of baking my own isos with a whole bunch of stuff we wanna ship
<drab> I might just abandon the whole quest to get the hostname right at install time and just patch it up with ansible after the fact
<drab> that may be faster overall
<drab> but will test
<drab> thanks again
<Unit193> 1. Is there any reason Contents-foo.xz files aren't in the component sections like in Debian/all other repos?  2. It should function to use 'devel' in the changelog, but is that actually acceptable for an upload?
<cjwatson> Unit193: 1. https://bugs.launchpad.net/launchpad/+bug/1579372  2. yes
<ubottu> Launchpad bug 1579372 in Launchpad itself "Update location of the Contents files on the mirrors" [Undecided,New]
<drab> also any chance people around here have thoughts on https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1370707 ?
<ubottu> Launchpad bug 1370707 in plymouth (Ubuntu) "Plymouth does not display the graphical boot splash" [Medium,Confirmed]
<drab> most of the people I'm setting up these labs for are windows users at home (small non profit) and they are freaking out at the initial blank screen, thinking the computer is broken
<Unit193> cjwatson: Well dang, I didn't see that.  I'm sorry.  Thanks very much.  And wow, that's awesome!
<drab> I've tried the framebuffer=y thing, but all I get is a blue screen (testing lubuntu) and no progress dots etc
<cjwatson> Unit193: np, we should sort it out but it will probably take a while
<Unit193> Very understandable, you're changing the archive structure (however little it may be.)  I'd expect that.
<Unit193> That also helps, shows me I should change how my Contents files are generated. >_>
<stgraber> pitti: hey, I've got about 300 systems reporting a critical package error (nagios) because you removed a package from trusty-updates (libnl3). That's something I'd expect for broken -proposed packages, but not for -updates.
<stgraber> I now manually downgraded all those systems to the previous version, but it may have been better to upload the old source with a higher version number directly to -updates rather than just removing the package.
<stgraber> (my monitoring system detected that case but I'm guessing most of our users aren't so lucky and will just end up with the broken version installed on their system not knowing that they should downgrade)
<infinity> stgraber: Erk, we're never supposed to just remove things from updates.  Where did this happen?
<ogra_> also, wouldnt you get a y/n question during dist-upgrade for that even if it happened ?
<ogra_> (better dont have your scripts blindly apply -y .... )
<infinity> stgraber: Okay, after looking at history, I'm going to upload a -1ubuntu1.1 that's a rever of -1ubuntu1, promote it immediately, and then a -1ubuntu2 that's -1ubuntu1 with a Breaks on network-manager.
<infinity> stgraber: Concur that that's a sane path?
<infinity> s/rever/revert/
<stgraber> sounds reasonable I think, yeah
<infinity> stgraber: Will be landing both in the queue shortly, if you want to review.
<stgraber> at least the uploading a revert as ubuntu1.1 part, I'm not sure what the change actually was, I just know it got removed :)
<stgraber> infinity: ok, I'll at least look at the revert one, should be easy enough to confirm it's sane :)
<infinity> stgraber: Ahh, so, the gist is that -1ubuntu1 broke network-manager, but there was also an n-m SRU to fix that.  But with the joy of phased updates, people are getting libnl and not n-m.
<infinity> stgraber: Hence, kaboom.
<nacc> ack, there's an askubuntu topic on it getting a lot of activity and a lot of complaints in #ubuntu today
<sarnold> phasing is applied per package on an individual system?
<stgraber> infinity: oh, fun, ok, so yeah a versioned breaks sounds good
<infinity> stgraber: Okay, revert hitting the queue now.  We can push that through ASAP.
<infinity> stgraber: Versioned breaks one following shortly.
<infinity> stgraber: And versioned Breaks version uploaded too, for after we promote the revert.
<infinity> Unconvinced that the revert is strictly necessary, and maybe we should just go with promoting the Breaks version in a hurry, but doing it this way won't hurt either.
<infinity> New NM and old libnl should be fine.  I think.
<infinity> (old, as in reverted)
<infinity> sarnold: Phasing is per-package, yes, but it won't allow you to do an impossible upgrade either, so a Versioned Breaks will force either both or neither to upgrade.
<stgraber> infinity: ok, let me check. Didn't feel like uploading to -updates directly? :)
<infinity> stgraber: Sort of forgot I can do that.
<infinity> stgraber: Since I haven't included a pocket in my uploads for years.
 * infinity shrugs.
<infinity> Not a big deal to do it this way.
<stgraber> nah, easy enough
<infinity> stgraber: I'll do the -ubuntu2 accept and promotion after I promote 1.1, if you pre-review the Breaks to make sure I can type.
<sarnold> infinity: ah, that's better than I feared, but I figured if wer're annoying a user to install updates, we might as well reduce the number of times we annoy the user..
<stgraber> I never bother putting the pocket in my uploads except for backports, but something like this, I'd have uploaded to ubuntu/xenial-updates or whatever the magic dput path is
<stgraber> infinity: yeah, just waiting for LP to give me diffs
<infinity> sarnold: Annoying them less and phasing are sort of opposing concepts, unless you want to take some randomness out of it and just say "these 7 people are always our canaries, totally sucks to be them".
<infinity> sarnold: Which is both unfriendly to those 7 people and also gets us crappier testing, as we're only testing the same machines over and over.
<stgraber> hmm, wtf, pull-lp-source isn't happy either (trying to fetch 3.2.21-1), do we have some kind of librarian slow down
<infinity> stgraber: Dunno.  pull-lp-souce worked for me.
<infinity> For both versions.
<stgraber> oh, pull-lp-source is happy now
<sarnold> infinity: I figured it was done per upgrade thing.. "oh today's my day in the 10%", and just download all the updates available at that moment
<stgraber> infinity: looks fine, except for your english skills :)
<infinity> stgraber: I didn't english gud?
 * infinity looks.
<stgraber> infinity: kinda missed a t in there :)
<infinity> Oh.  Lolz.
<infinity> Can reupload with the T.
<infinity> Or not, since we'll be overriding it shortly anyway.
<stgraber> yeah, not worth the trouble
<rlaager> stgraber! Are you going to file this upstream: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1567557
<ubottu> Launchpad bug 1567557 in zfs-linux (Ubuntu) "Performance degradation of "zfs clone" when under load" [Undecided,New]
<rlaager> I can copy-and-paste it, but it seems like it would be better if you filed it (since you've filed upstream before) so you can participate there.
<infinity> stgraber: Pre-review -2ubuntu2 for me too, and you can walk away from this.  I'll babysit it from here.
<stgraber> rlaager: possibly, I'd kinda like to get a better idea of what's going on first. As an upstream myself, I hate it when people say "performance isn't good" but can't show me more.
<stgraber> infinity: I did a straight accept on 1.1 as sru-review is confused when you have more than one of the same source in the queue, not like we care anyway since we'll bypass the rest of the SRU process anyway
<infinity> stgraber: Yeah, I didn't put bugs in the changelogs anyway, so sru-review isn't all that helpful. :P
<sarnold> stgraber: probably this is good enough already, it's got numbers!
<stgraber> infinity: that's nitpicking but wouldn't you want << 0.9.8.8-0ubuntu7.3~ in theory just in case people do random backports of that stuff?
<infinity> stgraber: Probably, but if people are backporting libnl/n-m to << trusty, I'm not sure I'm full of sympathy for their cause.
<infinity> stgraber: I also have time to reupload though, if you want to be picky. :)
<stgraber> infinity: nah, indeed seems unlikely anyone would be backporting all that stuff (would be more likely if it was xenial) and if they are, they'll likely need to make other changes anyway
<stgraber> infinity: so LGTM, feel free to self-accept once the other one has been moved to -updates
<infinity> stgraber: Too late.  I uploaded.
<stgraber> infinity: ok, well, let me diff that one too then :)
<stgraber> infinity: LGTM
<infinity> stgraber: Kay, reject the one you like least, and I'll work with the other.
<stgraber> rejected
<infinity> stgraber: Ta.
<teward> how hyper concerned should I be when mk-sbuild fails to create an schroot with these errors...?  http://paste.ubuntu.com/16397041/
<teward> (trying to make a Yakkety build environment in my sbuild)
<teward> does anyone know whether there's issues getting Yakkety to have schroots made via sbuild debootstrap at all?
<tumbleweed> worked just fine for me (on debian)
<teward> tumbleweed: got these odd errors on Trusty sbuild making the schroot (these don't happen on Xenial schroots): http://paste.ubuntu.com/16397041/
<tumbleweed> is that key in the keyring?
<infinity> teward: That's a change in apt.  The error message is pretty clear about what needs fixing.
<teward> infinity: okay, so where do I file the bugs, or whom do I stab with a stick to fix it?
<teward> or is there already a bug on this?
<infinity> I might fix it right now.
<teward> infinity: ah, okay.  let me know, because it's blocking Yakkety test builds of the horribly-evil nginx merge
<teward> (evil in that i basically had to start 'fresh' from Debian and readd the delta >.<)
<infinity> teward: Fix uploaded.
<fo0bar> http://pastebin.ubuntu.com/16394359/ <-- infinity
<fo0bar> and the whole thing is currently way too immature to get into ubuntu proper so far, since that's going to be your next question :)
<fo0bar> but if the kernel team wants to start working on a raspi3 arm64 defconfig, that's a good first start
 * fo0bar is currently using Some Dude's Kernel
<infinity> fo0bar: Good ol' Some Dude.
<fo0bar> anyway, much faster than my previous qemu arm64 486-speed env
<fo0bar> well, maybe pentium 2
<sarnold> "BogoMIPS	: 38.40
<sarnold> reminds me of my old pentium :)
<teward> infinity: I don't see the fix anywhere, did it land, or is it stuck?
<nacc> teward: i think some folks have been reporting the fix is in trusty-updates
 * teward checks
<teward> nacc: either the mirrors haven't updated or that's a lie
<nacc> teward: presuming we are talking about the same nm/libnl fix?
<teward> nacc: ah, no, actually, apt fixes
<nacc> teward: ah sorry!
<sarnold> nacc: http://paste.ubuntu.com/16397041/
<teward> [2016-05-13 16:42:09] <teward> tumbleweed: got these odd errors on Trusty sbuild making the [Yakkety] schroot (these don't happen on Xenial schroots): http://paste.ubuntu.com/16397041/
<teward> [2016-05-13 16:55:50] <infinity> teward: That's a change in apt.  The error message is pretty clear about what needs fixing.
<teward> nacc: though, i've pulled in those fixes now ;)
<nacc> sarnold: thanks
<nacc> interesting
<infinity> teward: The fix was in ubuntu-keyring.  I assume you realized that eventually?
<teward> infinity: just ran mk-sbuild, same breakage
<teward> hence the original question
<teward> but yes i realized, ubuntu-keyring
<infinity> teward: Yeah, it's just publishing to the release pocket now.
<infinity> teward: Patience.
<teward> ack
#ubuntu-devel 2016-05-14
 * teward turns his attention back to diagnosing his postfix install
<infinity> teward: debootstrap should be working now.
<teward> infinity: checking
<infinity> Man, I hate it when that happens.
<infinity> I just asked "who's the idiot who made nova-compute-kvm depend on qemu-system?"
<infinity> Checked the changelog.
<infinity> The idiot was me.
<teward> infinity: heh
<teward> infinity: looks like it works now
<teward> thanks
<infinity> rharper: Oh, so you did prep a version with Breaks, but never got it uploaded?  Fun.
<Bluefoxicy> any reason linux-signed-image doesn't provide linux-image ?
<Bluefoxicy> if you remove linux-image-4.4.0-22-generic when you have linux-signed-image-4.4.0-22-generic, apt wants to remove linux-image-generic-4.4.0-22-extras and all other stuff that requires linux-image-4.4.0-22-generic
<Bluefoxicy> (for that matter, why have unsigned images at all?)
<dobey> Bluefoxicy: do you not have "linux-signed-generic" installed?
<infinity> Bluefoxicy: linux-signed-image-4.4.0-22-generic only contains the signed image, none of the modules.
<infinity> Bluefoxicy: (In fact, it really only contains the signature)
<infinity> Bluefoxicy: Which is why signed depends on image.
<infinity> Bluefoxicy: dpkg -L linux-image-4.4.0-22-generic versus dpkg -L linux-signed-image-4.4.0-22-generic would probably have answered your question.
<Bluefoxicy> ah
<Bluefoxicy> infinity:  I was just looking in boot, re
<Bluefoxicy> -rw------- 1 root root 6.7M May  5 15:03 vmlinuz-4.4.0-22-generic
<Bluefoxicy> -rw------- 1 root root 6.7M May 14 14:08 vmlinuz-4.4.0-22-generic.efi.signed
<infinity> Bluefoxicy: Yeah, vmlinuz-4.4.0-22-generic.efi.signed is the combination of vmlinuz-4.4.0-22-generic and the detached signature shipped by -signed.
<Bluefoxicy> I'm guessing grub just automatically uses the signed image if present?  Doesn't seem to get its own menu entry.
<infinity> Bluefoxicy: update-grub goes looking for it and prefers it.  I have no boot entries for unsigned.
<Bluefoxicy> 'grep signed /boot/grub/grub.cfg' returns nothing after update-grub
<Bluefoxicy> (aside:  optionally selecting a signed kernel doesn't seem to provide any security if your rootkit can just tell grub to boot an unsigned kernel)
<infinity> Bluefoxicy: Are you booting on an efi system?
<infinity> (base)root@nosferatu:/etc/grub.d# grep signed *
<infinity> 10_linux:  if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then
<infinity> 10_linux:	linux	${rel_dirname}/${basename}.efi.signed root=${linux_root_device_thisversion} ro ${args}
<infinity> 10_linux:    *.efi.signed)
<Bluefoxicy> looks like I'm not
<infinity> That's the logic.  It should Just Work if you're EFI.  If you're not, the signed kernel is useless.
<Bluefoxicy> ah
<Bluefoxicy> I can probably convert this system to efi.  LAst time I did that it took black magic.
<Bluefoxicy> thanks for the info
#ubuntu-devel 2016-05-15
<ipatrol> I was musing over some stuff, and I thought, "Well gee, we have gnome-disks, but it's not quite the "graphical fstab editor" that people have been asking for at least as far back as 2006
<ipatrol> "
<jair> hello, what does that mean (linux-image low latency? version?
<dobey> jair: linux-lowlatency is the metapackage for the low latency kernel. linux-image-lowlatency is the metapackage for just the low latency kernel image
<ptrz> hi guys. Does anyone know where I can find the code for the nologin(8) ubuntu uses?
<ptrz> seems like it's different from redhat's
<cjwatson> $ dpkg -S bin/nologin
<cjwatson> login: /usr/sbin/nologin
<cjwatson> $ apt-cache showsrc login | grep ^Package:
<cjwatson> Package: shadow
<cjwatson> therefore, apt-get source shadow
<ptrz> cjwatson: thanks
<infinity> cjwatson: I had a dream this morning that the process for turning off my alarm clock involved running germinate.  I'm trying to figure out how to blame you for this.
<cjwatson> infinity: Blaming Scott is more fun.
<infinity> cjwatson: I shall send doko to tell him all about it in a changeroom.
<tsimonq2> huh, germinate, I learned something new today XD
#ubuntu-devel 2017-05-08
<mwhudson> what the heck is going on here? https://launchpadlibrarian.net/318753835/buildlog_ubuntu-artful-amd64.paste_1.7.5.1-6ubuntu3_BUILDING.txt.gz
<mwhudson> dpkg-genbuildinfo: error: cannot fstat file ../python-paste_1.7.5.1-6ubuntu3_all.deb: No such file or directory
<cjwatson> mwhudson: read up slightly above that - need to stop using -Z bzip2 (default is now xz which is generally better)
<mwhudson> cjwatson: ah ok
<mwhudson> wgrant: do you (or anyone else) know stuff about python packaging?
<mwhudson> the story is that the current jinja2 package doesn't install some files that have syntax that python 3.5 doesn't accept
<mwhudson> but without them, jinja2 doesn't install under python 3.6
<mwhudson> er doesn't import
<mwhudson> so i changed the package to include them but now it doesn't install properly because errors get spat out by python3.5 during install
<mwhudson> oh wait, man dh_python3 explains this
<mwhudson> no, that doesn't work
<Skuggen> Is there some way to get dput (for uploading to a launchpad ppa) working behind a proxy?
<infinity> Skuggen: If it's a proxy that forwards active FTP but fails miserably at passive you could try twiddling passive_ftp to 0 in /etc/dput.cf
<infinity> Skuggen: Alternately, sftp might work better, see https://help.launchpad.net/Packaging/PPA/Uploading#Uploading_with_SFTP
<Skuggen> infinity: Thanks, I'll give it a try :)
<Skuggen> I tried changing a ~/.dput.cf before, but according to the debug output it was still using passive, but can try with the file in /etc instead
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<nacc> gsilvapt: i'm around now
<nacc> tjaalton: do you know if the dogtag trac moved somewhere else with fedorahosted reitrement (re: LP: #1662654)
<ubottu> Launchpad bug 1662654 in tomcat8 (Ubuntu) "Please remove resteasy (3.1.0) from zesty-proposed" [Undecided,Fix released] https://launchpad.net/bugs/1662654
<nacc> the link goes to the retirement page
<nacc> tjaalton: and do you have the link to the resteasy bug
<sarnold> gsilvapt: now that the update is pushed, you can go through the pull-ubuntu-source, patch, build, test, iterations
<gsilvapt> ah. okay. I can try to do that now. Thanks, sarnold
<gsilvapt> I need help solving a community issue. Can someone forward me to the right place?
<wxl> what's up gsilvapt ? also hey :)
<gsilvapt> hey wxl, long time no see
<nacc> gsilvapt: what community issue?
<gsilvapt> There's this guy that I'm not sure what the hell is his goal. He started my suggesting an edit that had swastikas in the page and thought it was okay and now he removed content from Wiki pages that were useful and he didn't ask anyone before doing any changes
<nacc> gsilvapt: spammer?
<gsilvapt> Of course we can revert that back but it's getting extremely ridiculous at this point
<nacc> gsilvapt: on the wiki?
<gsilvapt> I have no idea. I once emailed him suggesting to keep his cool, get to know the people around, ask & suggest stuff in the *proper* way and not spam/do stuff right-of-the-box because nobody would listen to him
<wxl> links may be helpful
<gsilvapt> He said he had been contributing for 9 years and he would be fine. lol
<gsilvapt> s/page/wiki
<cjwatson> swastikas in pages are just a matter of banning, IMO.  the Ubuntu code of conduct does not require you to negotiate with Nazis
<nacc> heh
<nacc> sad that it's even a thing
<wxl> what if it's the more eastern persuastion of swastika?
<cjwatson> (OK, unless it's explicitly in one of the relevant Asian religious contexts, but I can't see why that would be on-topic in the Ubuntu wiki either)
<wxl> that
<wxl> i guess someone could use them for bulletpoints
<cjwatson> ... but shouldn't
<gsilvapt> link to page where he deleted content, according to Brian Murray: https://lists.ubuntu.com/archives/ubuntu-quality/2017-May/006887.html
<wxl> i don't see it as RELEVANT, but that doesn't mean someone wouldn't use them
<cjwatson> I don't think it's interesting playing the what-if game on this.  If it was actually a relevant non-Nazi use then I assume gsilvapt would have said
<cjwatson> don't be played by trolls
<gsilvapt> And this all started here: https://lists.ubuntu.com/archives/ubuntu-quality/2017-April/006847.html
<gsilvapt> He later removed the images of swastikas, FYI
<cjwatson> where was the swastika thing?
<jbicha> I think original was https://commons.wikimedia.org/wiki/File:Blueprint_of_Victory._Avoid_the_Black_Widow_of_war_production_-_NARA_-_534556.jpg
<jbicha> tweaked to https://wiki.ubuntu.com/es20490446e/Reporting%20bugs?action=AttachFile&do=view&target=Blueprint.jpg
<tjaalton> nacc: oh right, I'll update that
<nacc> tjaalton: thanks!
<wxl> um, equating windows (?) to nazis?
<cjwatson> ok, I guess that's super bad taste rather than Nazi advocacy
<wxl> where did you find that btw, jbicha ?
<jbicha> wxl: by digging through https://wiki.ubuntu.com/es20490446e/Reporting%20bugs?action=info
<cjwatson> though I would not defend it and perhaps the poster needs a cooling-off period
<nacc> also, i think there is a general issue with es20490446e on bugs :)
<wxl> yeah i hadn't seen it when i searched through there
<wxl> XD
<nacc> gsilvapt: so it's not like you are unique here :)
<wxl> nacc: that is a WHOLE different story XD
<nacc> wxl: :)
<gsilvapt> Look, I stopped reading his stuff a long ago. I feel he is trying to troll us. He sends youtube videos as replies to emails on the mailing list
<wxl> um
<gsilvapt> Today I got another email from someone complaining he removed parts he considered important in the Wiki
<wxl> so Alberto is the one who did that?
<gsilvapt> Yes, wxl
<nacc> wxl: it appears so (the original image)
 * wxl sighs
<cjwatson> see also https://bugs.launchpad.net/launchpad/+bug/1686518
<ubottu> Launchpad bug 1686518 in Launchpad itself "The reporting guidelines aren't well fitted" [Undecided,New]
<cjwatson> the "just a joke" defence he used for the swastika bit is unacceptable
<jbicha> https://help.ubuntu.com/community/ReportingBugs
<jbicha> https://help.ubuntu.com/community/ReportingBugs?action=recall&rev=299
<gsilvapt> And I thought this had to stop. I have no clue if I'm just being too naggy or if this is actually crossing the line of reason and thus asked for help for some to check this
<gsilvapt> I emailed the council once, I don't want to email again if they did nothing on this before
<gsilvapt> (before being the Swastika and his "just a joke" comment)
<cjwatson> this certainly seems like a matter for the CC, anyway
<wxl> he's a very avid contributor, it seems, at least in terms of the frequency of contributions
<wxl> quality of contributions may be open for discussion..
<nacc> SNR is low, in my experience
<nacc> not that they are not making ubuntu better, admittedly
<wxl> and i've found him entirely convinced of his own opinion and unwilling to listen otherwise
<wxl> this has come up more than once
<wxl> i'm sure the cc looks at the former point as trumping the latter ones, though
<cjwatson> they may do, but they should actually respond
<cjwatson> rather than leaving people to guess
<nacc> yep
<gsilvapt> yea wxl, I was surprised to see his LP karma page. He might have been around for 9 years after all but it seems most of his contributions are more setbacks rather than progress. What he is doing is not aligned with anything other than his opinions
<wxl> karma is of no real value :)
<gsilvapt> Sure but it says if a person is active or not
<wxl> right
<nacc> seb128: will you be merging/fixing gnome-menus this cycle? just tracking stuff in merges i'm associated with :)
<nacc> slangasek: are you doing an lvm2 merge? rbalint's fix for LP: #1576341 will add to the delta and i wonder if we should just send it to Debian?
<ubottu> Launchpad bug 1576341 in systemd (Ubuntu) "systemd in degraded state on startup in LXD containers" [High,Confirmed] https://launchpad.net/bugs/1576341
<wxl> what i would suggest is contacting them again with https://bugs.launchpad.net/launchpad/+bug/1686518 being a really concrete example of the problems he causes. you might want to check out #ubuntu-community-team as some cc members hang out there
<ubottu> Launchpad bug 1686518 in Launchpad itself "The reporting guidelines aren't well fitted" [Undecided,New]
<wxl> gsilvapt: ^^
<wxl> with popey, mhall119 being the most active
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/1686518 is an "annoys Colin" kind of thing, not a "should be banned" kind of thing; I think it's at most illustrative
<wxl> cjwatson: well, i'm not suggesting the cc ban him. but suggesting better behavior might be appropriate.
<cjwatson> I think the terrible stuff around the proposed wiki edit is a much better example, but it's probably worth accumulating things
<wxl> he may think he can just bully people around, but i doubt he would be so inclined with the cc.
<gsilvapt> Okay, I can try to get in touch with them again and bring this example to the table
<wxl> also, colin, you really eloquently reflect my feelings about video. the post that drove me crazy was https://lists.ubuntu.com/archives/ubuntu-quality/2017-May/006888.html
<cjwatson> (I've encountered this user a few times, but before seeing the stuff gsilvapt posted here I only considered them annoying rather than anything more)
<wxl> gsilvapt: feel free to cc me in further emails. i certainly agree with your concerns and would be willing to support you
<jbicha> he also annoyed GNOME recently, https://bugzilla.gnome.org/782002
<ubottu> Gnome bug 782002 in general "Making GNOME really pleasant to use" [Normal,Resolved: incomplete]
<gsilvapt> cjwatson, yep, that's my problem. I stopped reading his stuff a while back, when he posted a private video entitled "I feel Ubuntu is facing doom". From thereon, I just ignored his stuff. Then some answers started getting my attention. First the swastika, now the user complaining he deleted important parts of the wiki page. Men... Trolls are trolls, this is something else
<gsilvapt> Thank you wxl, I think I'll reply to my own email to add this another example and keep the previous message
<infinity> I kinda feel like he's using Ubuntu mailing lists to get impressions on his youtube channel. :P
<gsilvapt> Who knows....
<wxl> cjwatson: my concern is that even annoying can be severely problematic. what's annoying to us might be infuriating to others. maybe even causing them to give up contributions and/or assume the community consists of and supports people with similar attitudes
<slangasek> nacc: am I doing an lvm2 merge> grep-merges tells me that you TIL; I don't particularly care who does it, it's been a pretty trivial merge up to now
<nacc> infinity: heh
<nacc> slangasek: ack, i was just going to remerge it now and pull in rbalint's fix at the same time
<wxl> "I know this project doesn't like reports in video, but I think this is the exception rather than the rule:"
<nacc> slangasek: if it wasn't on your plate, you had just done the last merge
 * wxl facepalms
<slangasek> nacc: yeah, go for it :)
<nacc> slangasek: thanks
<cjwatson> wxl: yes
<slangasek> gsilvapt, wxl: uh... what's this about swastikas and wiki page deletions?
<slangasek> fwiw bdmurray has a lot of context on this particular contributor
<wxl> gsilvapt: if you read the CoC, i think there are some points where there is clear violation. i'd be willing to reply to your initial email with further elaboration on that.
<wxl> slangasek: i didn't know about it, but jbicha summarized the relevant links above. tl;dr ReportingBugs wiki :(
<cjwatson> feels like a more or less well-intentioned contributor whose idea of being constructive is at right-angles to everyone else's and isn't listening to feedback, which is one of the most difficult cases to deal with
<nacc> rbalint: are you ok with me pulling your fix for the above bug into the merge?
<rbalint> nacc: perfectly, thanks :-)
<nacc> rbalint: might do the same for open-iscsi if that's ok with you
<nacc> rbalint: also, thank you very much for the bug feedback!
<slangasek> cjwatson: not counting that one time when he tried to troll debian-devel into fighting with the Ubuntu community for him
<cjwatson> slangasek: I don't remember that one
<rbalint> nacc: sure, please update open-iscsi
<nacc> rbalint: thanks!
<rbalint> nacc: i'm building the systemd, but some tests are failing
<nacc> rbalint: fun :)
<infinity> cjwatson: Well-intentioned or not, I've just wasted several minutes of my life on more than one video response of his from that thread that amount to "sorry, not sorry", and "people will always be angry about something, so you should let me publish swastikas in the wiki, you fascists".
<bdmurray> I was hoping the video re "ubuntu is facing down" would lead to a walking away.
<cjwatson> infinity: yeah, quite
<cjwatson> slangasek: was that https://lists.debian.org/debian-user/2013/11/msg00410.html ?
<slangasek> cjwatson: yeah
<slangasek> wait
<slangasek> cjwatson: no
<cjwatson> (my "more or less well-intentioned" comment is not intended as a defence BTW; regardless of intention this person is currently wasting people's time and IMO needs to shape up or ship out)
<slangasek> cjwatson: https://lists.debian.org/debian-devel/2014/04/msg00319.html
<nacc> the most annoying thing to me, is he sets the priority of bugs (which results in an e-mail) without ever (afaict) actually fixing anything. And the priority hover text claims to be about when bugs will get fixed
<nacc> so it ends up lying to users about when to expect a fix
<cjwatson> slangasek: whee
<gsilvapt> I can't stand his name or email address anymore, oh lord
<gsilvapt> It's decided, I'll gather these links and send them to the CC, wxl
<gsilvapt> When running dpkg-buildpackage -S -nc -d it returns clearsign failed: "No secret key"
<gsilvapt> Any help?
<nacc> gsilvapt: did you insert a changelog entry?
<nacc> gsilvapt: you can't sign a package with a changelog entry for a different user -- you can pass -us -uc to not sign the .dsc and .changes files
<gsilvapt> Hum, I thought it was because of that. I didn't write anything because the log is not changed since 2016. Not sure if I should or not write something
<nacc> gsilvapt: are you making a change?
<gsilvapt> editing the man pages to remove the hyphens
<nacc> gsilvapt: then you need to add a changelog entry :)
<nacc> gsilvapt: dch -i
<gsilvapt> Okay, I'm in the changelog file. Lets see if I don't mess this one up
<nacc> gsilvapt: i would recommend using dch
<nacc> gsilvapt: as inserting by hand can be error-prone
<gsilvapt> yes, I used that command
<gsilvapt> I had it before in the step-by-step guide you sent over
<nacc> gsilvapt: ack, ok
<gsilvapt> Now, I'm afraid I have no clue about the software version, lol
<nacc> gsilvapt: `dch -i` should have done the right thing already
<gsilvapt> The LP is confusing, the github page is only upstream
<nacc> gsilvapt: what is the prior version in the srcpkg?
<gsilvapt> is there a command to check that? I have no clue where/how to find it
<nacc> gsilvapt: just look in the changelog?
<nacc> gsilvapt: it will be the one just below what you're entering
<gsilvapt> 1:4.2-3.2Ubuntu1 yakkety
<gsilvapt> Right, I froze there because there are no entries since september
<nacc> gsilvapt: what release are you trying to work on?
<gsilvapt> Viviv
<nacc> gsilvapt: vivid??
<nacc> gsilvapt: vivid is eol
<nacc> sarnold: ping -- i just saw your shadow update went out for y and z but not a (per rmadison)?
<nacc> sarnold: so a is behind z now
<gsilvapt> Wait, not vivid. Should be artful
<nacc> sarnold: is that a latency thing?
<sarnold> nacc: two pronged -- (a) I don't have upload privs to -devel, only released releases (b) since they're fixed in debian, a merge from debian would handle that well
<nacc> sarnold: sure, just wasn't sure if it's what was expected
<nacc> sarnold: and  means gsilvapt's artful upload is missing context that will be dropped on the next update
<nacc> sarnold: but it's ok
<sarnold> nacc: :(
<nacc> sarnold: and (a), understood, makes sense
<nacc> gsilvapt: ok, so for artful, since it's in development
<nacc> gsilvapt: your version will be 1:4.2-3.2ubuntu2. But note that it is probably better to wait for a merge
<nacc> gsilvapt: as i think the merge will pick up the thing you want to backport anyways, right? (bumps upstream version to 4.4)
<gsilvapt> When they merge with upstream, the man pages will be fixed. So yes, I believe the answer is yes
<nacc> gsilvapt: to be clear, not just upstream, but specfically 4.4
<gsilvapt> Only upstream has this fix, as far as I could see
<nacc> gsilvapt: in a released version?
<gsilvapt> Nor Ubuntu or Debian had this fix yet but it was fixed in November last year upstream
<gsilvapt> Not sure if it is in a released version, apparently not, nacc.
<nacc> gsilvapt: how have you checked?
<nacc> gsilvapt: oh i see 4.4 is from september, but the fix was in november?
<nacc> gsilvapt: ok so it won't be fixed by the merge, got it
<nacc> gsilvapt: merge is not with upstream, but with debian
<nacc> gsilvapt: and debian is at 4.4
<gsilvapt> Wait, you're way over my head :D
<nacc> gsilvapt: i'll start over
<gsilvapt> Lets recap: I've recreated the bug in my system and it confirmed. I download all source deos from Debian and Ubuntu and neither have the fix. The upstream source has the fix, made in November last year.
<nacc> gsilvapt: what i'm trying to understand is if this particular change you've found from upstream is present in the version packaged in Debian right now
<nacc> gsilvapt: and an ubuntu merge is merging with debian, not with upstream
<gsilvapt> s/deos/packages
<nacc> gsilvapt: so, back to your srcpkg
<nacc> your veresion will be what i said before
<nacc> and insert an appropriate chagnelog entry
<nacc> target it for artful
<nacc> then dpkg-buildpackage should work, it will try to sign it with gpg
<gsilvapt> But shouldn't I wait for a merge? Or because it is not in a debian release there is no use in that?
<nacc> gsilvapt: right, unless debian is also planning on bumping it's version, a merge doesn't help
<nacc> gsilvapt: but that's gated by an upstream release anyways
<nacc> gsilvapt: we can do multiple merges too
<gsilvapt> Okay, I think I understood. Thanks! I'll give it a try to, at least, finish the first fix I made
<nacc> gsilvapt: sounds good, feel free to ping if you want a review
<gsilvapt> I have to do dpkg-buildpackage before doing that, right, nacc?
<gsilvapt> Ahum... Invalid user id :D
 * gsilvapt faceplam
<gsilvapt> Did the entry, forgot to add details for gpg
<gsilvapt> I think I've broken the changelog... Oh dear me
<gsilvapt> nacc, how do I ask for review?
<gsilvapt> Post it anyways in LP bug report or is there another way?
<nacc> gsilvapt: from me or generally?
<gsilvapt> I understood you were going to do it but if you're too busy I can request a general review. After all, that's the right process, isn't it?
<nacc> gsilvapt: yeah, so upload a debdiff to the bug and subscribe ubuntu-sponsors
<gsilvapt> Okay, thanks, nacc
<gsilvapt> I think I've done it right: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1427807
<ubottu> Launchpad bug 1427807 in shadow (Ubuntu) "usermod's man refers to --*-sub-uids but accepts only --*-subuids" [Medium,Fix committed]
<nacc> gsilvapt: i don't think 'fix committed' is right
<nacc> gsilvapt: notyour  fault
<nacc> gsilvapt: ok, few things i see with https://launchpadlibrarian.net/318864267/remove-extra-hyphens-as-LP427807-suggests%2A
<nacc> gsilvapt: lots of trailing newlines in the changelog entry
<nacc> gsilvapt: it's not targetting a release (UNRELEASED rather than artful)
<nacc> gsilvapt: you made it 1:4.2-3.2ubuntu3 rather than ubuntu2
<nacc> gsilvapt: and you changed an unrelated chagnelog entry
<nacc> gsilvapt: finally there is no content to debdiff, that's just the changelog changes :)
<rbasak> slashd: thanks for the ping. Sorry, it keeps being bumped by things :-/
<rbasak> slashd: it's been long enough now I'll add it to my list of immediate highlighted todos.
<rbasak> It had almost fell off the page :-/
<slashd> rbasak, no problem thanks for looking at it
<slangasek> gsilvapt, wxl, jbicha: when all is said and done, is someone reverting the changes on https://help.ubuntu.com/community/ReportingBugs, or...?
<wxl> slangasek: bdmurray asked that same question on the mailing list, so i take it he's leading the charge
<slangasek> wxl: I bet he, like I, was trying to get somebody else to do it ;)
<bdmurray> Honestly, I'm not happy with either version but sorting it out isn't a high priority yet.
<jbicha> I defer to bdmurray :)
<gsilvapt> oh, so I need to work a lot on those. The UNRELEASED entry is not mine, or is it?
<gsilvapt> nacc, first and foremost, thank you for the time reviewing this. Loads of lessons are being learned thanks to you!
<gsilvapt> is there a way to cancel that commit so that I can start over? It somehow feels more adequate, considering I did changes to unrelated entries that I didn't even realize :|
<infinity> gsilvapt: rm -r shadow-4.2 ; dpkg-source -x shadow_4.2-3.2ubuntu1.dsc
<infinity> ginggs: And try again from there.
<infinity> gsilvapt: ^
<infinity> ginggs: Tab completion fail, ignore me.
<gsilvapt> will give that a try. Thanks, infinity
<infinity> gsilvapt: Also, "Do the stuff bug #foo requests" isn't a useful changelog entry.
<infinity> gsilvapt: You want something more like "foo.xml: Correct type in --switch-thing docs (LP: #12356)"
<ubottu> Launchpad bug 8012 in linux-source-2.6.15 (Ubuntu) "duplicate for #12356 other devices (sound, wireless?) fail to work when lp/parport modules are loaded due to IRQ conflict" [High,Fix released] https://launchpad.net/bugs/8012
<Unit193> type â typo
<infinity> gsilvapt: Changelogs should document the changes done, not just document that "some change" was done. ;)
<infinity> Unit193: That's the one problem you had with that? ;)
<gsilvapt> Hum, it makes sense. Thanks!
<Unit193> infinity: Well that's the issue that jumped out at me enough to fix! :P
<gsilvapt> I'll try to do it again
<infinity> ;)
<infinity> gsilvapt: If you're ever use Windows and been frustrated by the fact that literally every Windows Update changelog entry is "Update Product: see KB123456", you'll understand why some people prefer changelogs to actually have useful information.
<gsilvapt> Yes, I understand. Was in a hurry at the time and did a poor job :)
<gsilvapt> Sorry. I'm starting over now
<gsilvapt> Creating the changelog entry is actually really difficult
<gsilvapt> I think I know how/why I deleted/changed an entry without even realizing it
<gsilvapt> when doing dpkg-source --commit and after entering the patch name, it opens a menu with some info to fill in. Can/Should you remove anything in that file aside from those you have to actually edit?
<gsilvapt> infinity ^ (I keep forgetting to reference the people I'm calling out :D )
<infinity> gsilvapt: Creating the changelog entry should be a simple matter of calling "dch -i"
<infinity> gsilvapt: As for the patch headers, you should keep the relevant ones and delete the ones that don't make sense for your patch, yes.
<nacc> gsilvapt: i'm around again
<nacc> gsilvapt: yes, by default `dch -i` inserts an UNRELEASED entry
<nacc> i believe i said earlier, you need to mark it for artful
<nacc> rbalint: did you see my comment in the systemd bug? as to whether or not it's correct to never allow systemd-remount-fs.service to run in containers?
<nacc> rbalint: as i think there are advanced container configurations that use real disks
<nacc> rbalint: where we do want to remount them to match fstab
<rbalint> nacc: yes, but one can easily override the stock .service file
<rbalint> nacc: i see no clean solution here :-(
<nacc> rbalint: yeah, neither do I, but we'd need to document that in the 17.04 release notes, i think, as it's a change in behavior
<nacc> rbalint: if we decided to go that route, i mean
<rbalint> nacc: one other not too clean option is diverting /lib/systemd/systemd-remount-fs in image generation to check "mount -f /" before actually doing the remount and reporting success when  "mount -f /"  fails
<rbalint> nacc: quite ugly, but if there is a working / in fstab it gets remounted
<nacc> rbalint: yeah -- nothing is great. I was just reading `man systemd-remount-fs` and it indicates more than just / is handled by it (all kernel virtual fs, e.g.)
<nacc> rbalint: and specifically /usr for some reason
<nacc> cpaelzer: just to be sure, your lvm2 upload to zesty of 2.02.167-1ubuntu5, that was because ubuntu4 was accidentally uploaded?
<rbalint> nacc: those mount points are typically set up properly in containers
<infinity> nacc: Why do people have containers with bogus info in /etc/fstab to begin with?
<nacc> infinity: cloud-image generation
<nacc> rbalint: i agree, they should be -- i just don't want to break anyone :))
<nacc> rbalint: if you're confident in the change, i'm cool with it, tbh
<infinity> nacc: fstab(5) isn't a random dumping ground for garbage, it's a list of filesystems that the system *can* mount successfully, and the onus is on the sysadmin to make sure it's accurate (or on the image creator, if you're creating bogus ones out of the gate).
<rbalint> infinity: some ubuntu container images are preset with fstab containing LABEL=cloudimg-rootfs : LP: #1576341
<ubottu> Launchpad bug 1576341 in open-iscsi (Ubuntu) "systemd in degraded state on startup in LXD containers" [High,In progress] https://launchpad.net/bugs/1576341
<nacc> infinity: CPC image generation that is :)
<nacc> infinity: it's hardcoded in the CPC code
<infinity> Code can change. :P
<nacc> infinity: yeah, i have a note in there to figure that out
<nacc> infinity: i think it's needed for VMs, possibly
<nacc> infinity: but in containers it doesnt make sense
<infinity> I'm just saying systemd isn't buggy here.  Perhaps a bit overzealous, but it's not a bug to assume entries in fstab should be mountable.
<nacc> infinity: agree, and i wasn't suggesting to fix systemd in my original request
<nacc> more that we needed to understand the issue and figure out the 'right fix'
<nacc> Odd_Bloke: rcj: --^ you may have input on the above too
<rbalint> infinity: if  generating separate container and vm images for cloud would be an option then we could go that way
<rbalint> nacc: maybe adding the diversion to only remount working / would be better, let's collect some feedback on the various options
<nacc> rbalint: ack, i'd like to hear from CPC too
<infinity> rbalint: Is it really "the same image"?
<infinity> rbalint: On cloud-images dailies, I see a -lxd.tar.gz, which would imply otherwise.
<infinity> Oh, that's also only 848 bytes. :P
<rbalint> infinity: definitely different :-)
<infinity> Well.  That appears to be metadata about mangling/overwriting files.
<infinity> So, if could also whack fstab.
<nacc> infinity: oh that's a good point
<nacc> so maybe stgraber *is* the one to ask :)
<infinity> nacc: If official lxd images are our only concern, I think that's the right place to fix it.  If we want people to download our generic cloud images and run them in "any container" without that metadata mangling, a first-boot job that accomplishes the same thing would also be sane.
<infinity> nacc: Which would need to run early enough that it gets there before systemd-remount-fs, obviously.
<rbalint> infinity: the image i got with the lxc command seems to be built with livecd-rootfs:
<rbalint> root@unified-ox:~# cat /etc/init/ttyS0.conf  | grep Cloud
<rbalint> # CLOUD_IMG: This file was created/modified by the Cloud Image build process
<rbalint> infinity: but yes, probably it was post-processed
<rbalint> infinity: how do you feel about the local diversion?
<rbalint> infinity: "fstab(5) : stab is only read by programs, and not written;" :-)
#ubuntu-devel 2017-05-09
<infinity> rbalint: A diversion that attempts to remount / to see if we can remount /?  Seems pretty gross.
<infinity> rbalint: And a disgusting workaround for "we're shipping bogus cruft in a config file".
<nacc> infinity: yeah, i think we need to decide on the intention of the images
<nacc> infinity: i'll take it as a todo to converse with CPC on it, at least
<nacc> rbalint: yeah i think i pasted in the bug the bit from the CPC livecd-rootfs hook that adds the fstab entry unconditionally
<infinity> nacc: So, there's absolutely value in having a single image to rule them all, from an 'easier to QA' perspective, if nothing else.  But fstab still shouldn't be bogus (and then worked around on every boot!), so either the lxd metadata trick, or a first-boot one-shot that checks the state of the world and whacks fstab, both seem vaguely acceptable to me.
<infinity> Not sure how early cloud-init gets its tendrils into things, but I suppose maybe it could be involved in that.
<nacc> infinity: ack, they do seem clean (and if nothing else, easy to document why we do it)
<rbalint> infinity: the idea was just make -f /, to see if remounting would work
<rbalint> infinity: but if there is a cleaner solution, that would be better
<rbalint> infinity: s/make -f/mount -f/
<infinity> rbalint: Sure.  The problem there is that (a) you'd want to do that for all the possible filesystems in /etc/fstab, and (b), if remounting stuff in fstab fails for reasons other than "this is a container and we think we shouldn't", that service SHOULD fail. :P
<infinity> So, again, I'm sticking with "fstab shouldn't be bogus".
<infinity> If a sysadmin wants to make it bogus after first-boot, they're welcome to keep the failing systemd service that comes with it.
<rbalint> infinity: yes, it should not be
<nacc> yeah, and in this particular case, we are shipping a known-bogus fstab, so i think cleaning it up, somehow, is the most reasonable approach
<infinity> nacc: Well, cleaning it up, or having an earnest discussion with CPC about why they think they need an fstab at all.
<nacc> infinity: yeah, true
<infinity> nacc: It's not needed to boot (root= on the kernel cmdline handles that), and a modern linux system is entirely functional with an empty fstab.
<nacc> infinity: that's a good point, i don't know why it would be needed in any default cloud image
<infinity> nacc: So, the path of least resistance here might be deleting it, or making it comment-only.
<infinity> (I prefer comment-only, but that's just cause my old UNIX beard shrivels slightly at the file literally not existing)
<infinity> (Both should work)
<rbalint> ok, i'm leaving now, maybe tomorrow will bring a nice solution :-)
<nacc> looking in `bzr log` ... it seems like it might have been added originally for "Minimal setup required for systemd to provide a r/w FS"
<nacc> but that was a slightly different hook
<infinity> nacc: So, it's also possible that systemd is braindead, and needs / in fstab to get a r/w / ... But that's easy enough to test. :)
<nacc> infinity: yep, on my todo now
<mwhudson> lol lol lol jinja2 build depends on itself
<nacc> mwhudson: it does? i don't see it in b-d in debian (synced currenty i think)?
<mwhudson> nacc: via sphinx i think
<nacc> ah python3-sphinx -> python3-jinja :)
<nacc> fun!
<nacc> sounds like you need to bootstrap build it?
<mwhudson> well i'm trying to make it work with python3 but i created a broken package instead (in a ppa)
<nacc> heh
<mwhudson> *python3.6
<mwhudson> so i can't just upload a fixed version, i have to delete the bad one from the ppa first
<rbalint> #550059
<mwhudson> no disaster but it's another bit of the yak to shave
<rbalint> sad to see such old circular dependencies :-(
<gsilvapt> well, I repeated the process and I think I did it right this time. Hopefully, all this is done now :)
<gsilvapt> oh crap, the scroll got locked above this conversation. infinity, I meant the entire entry that is in the file it creates. It seems the last entry in the changelog
<infinity> gsilvapt: Yes, you should run dch -i before dpkg-source --commit if you want it to fill in useful info. ;)
<infinity> (I always do it in the wrong order too)
<gsilvapt> okay then apparently I did it right this time. I kept the "additional fields" down below just for reference but I guess that's okay
<infinity> nacc: Hah, systemd may well be braindead enough to require / in fstab.
<infinity> nacc: In fact, I think I ran into this when upgrading some fstab-less machines from upstart to systemd, but I *thought* someone fixed it. :P
<nacc> infinity: heh :)
<infinity> Evidently not.
<infinity> pitti: Hey.  Hey you.  Upstream guy.  Why does systemd still require an fstab just to remount / rw?
<infinity> pitti: plzfix, kthx.
<infinity> That should sort it.
<infinity> pitti: PS: Even upstart/mountall got this right.
 * gsilvapt off for tonight. See you guys later o/
<pitti> infinity: well, somewhere you need to say how you want fstab and other fses mounted -- why not use the canonical file that has been there for years :)
<cpaelzer> nacc: on your lvm2 question ubuntu[34] were timeouts on proposed verification
<pitti> infinity: who says that you want the root fs mounted r/o? that's not the case in many container or embedded use cases, and there's been a lot of work towards making systems work with a r/o root
<cpaelzer> nacc: therefore they were removed on the following upload of ubuntu5 which "in itself" was to fix the bug mentioned in the changelog
<pitti> infinity: so, this behaviour can't be changed willy-nilly, but of course it can be discussed whether there could be a kernel boot option instead
<infinity> pitti: I assume you mean r/w
<pitti> err, yes
<infinity> pitti: Of course, from an Ubuntu perspective, this did change "willy-nilly" already. :P
<infinity> pitti: And I'd argue that if you wanted an (abnormal) r/o root, that overriding it in fstab would be your best bet.
<infinity> pitti: But it's also just irritating that root is the only fs that doesn't have a set of 99%-correct defaults (which it did with mountall), allowing the joy and wonder of an empty /etc in a systemd world.
<infinity> pitti: Sort of ironic, given that's one of systemd's goals.
<infinity> pitti: But I'll find a bucket of hats and eat them if you can prove that r/o root is the "usual" systemd use-case. ;)
<pitti> with GPT partitions of the proper type and no fstab, systemd-gpt-auto-generator will generate some .mount units where the root fs  is r/w, but that doesn't help with the classic MBR case, of course
<infinity> (The system should have expected and sane defaults, and /etc should be for overrides is the mantra, is it not?)
<pitti> infinity: I'm not saying it's the "usual" case, I'm saying that this is the kind of behaviour that can't just be changed
<infinity> pitti: Irksome that it wasn't yelled about earlier, when it could be?
<infinity> pitti: For Ubuntu, though, I'd still argue you're wrong that it can't be. ;)
<infinity> As upstart behaved in this way for years.
<infinity> And, indeed, it also would have done so in RHEL.
<infinity> Which muddies the waters a bit.
<sarnold> infinity: "stockholm syndrome", at some point those who would yell about it instead start to identify with the 'new features'
<infinity> pitti: In neither Ubuntu nor RHEL, could one argue that the behaviour with a lack of fstab has been reliably unchanged.
<infinity> pitti: Which could lead to the conclusion that almost no one cares one way or the other, and it's a moot point if changing it "breaks" anything, then we're back to philosophical arguments over "useful defaults" and "rare overrides". ;)
<pitti> heh :)
<mwhudson> doko, slangasek: for the python 3.6 transition when we can get 3.6 compatibility by importing a new upstream, i guess we should tend that way?
<mwhudson> we're not getting upstream updates much from debian currently because freeze
<doko> mwhudson: yes, there's no freeze, and maybe Debian will be still frozen...  you could ask here mitya57, jtaylor, maybe Tumbleweed (currently not here)
<mwhudson> we're going to end up with a stack of delta to get this done
<mwhudson> no way around that i guess, we'll just have to try to unwind it as much as we can when we can
<mwhudson> bah https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1679831
<ubottu> Launchpad bug 1679831 in pygobject (Ubuntu) "pygobject FTBFS on all arches during zesty test rebuild" [Undecided,New]
<mitya57> doko, mwhudson, Debian is frozen but it is possible to upload to experimental. I would be happy to commit/sponsor any fixes for DPMT maintained packages.
<mwhudson> mitya57: noted
<doko> mwhudson: about pygobject: maybe there is some DEPRECATED flag in glib2.0 ... or just avoid -Werror, or new pygobject upstream? Laney or seb128 could help
<mwhudson> yeah, avoiding -Werror would probably do the trick
<doko> mwhudson: http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html
<Laney> https://git.gnome.org/browse/pygobject/commit/?id=d005df9645fd5fb2f19bd09384355f45591f1e58
<mwhudson> Laney: awesome
<Laney> mwhudson: feel free to upload that if you want
<Laney> I'll probs put the new version in exp at some point and sync it
<mwhudson> Laney: i've just shoved it into my ppa for now, too late in the day for me to be putting things in the archive :-)
<Laney> okey pokey
<sil2100> fossfreedom: hello!
<sil2100> fossfreedom: could you fix up the bug description of LP: #1661159? I wanted to review the SRU but this one bug isn't ready formally-wise
<ubottu> Launchpad bug 1661159 in budgie-desktop (Ubuntu) "Budgie Menu Jumps Around In Latest Daily Build" [Undecided,Fix released] https://launchpad.net/bugs/1661159
<sil2100> Ah
<sil2100> I see what just happened there
<sil2100> fossfreedom: so I see you did one 'master-bug' for all the changes that are included in the SRU, right?
<sil2100> fossfreedom: I generally prefer if each bugfix has a separate bug with the impact, test case and regression potential fields
<sil2100> fossfreedom: but seeing that his one bug is rather well documented and issues are rather related, I'll review it as is
<sil2100> fossfreedom: I'll have to re-upload it before release with a modified changelog since we don't want this additional bug to be 'marked'
<sil2100> fossfreedom: but for the future SRUs - please include one bug per fix, each one mentioned in the changelog and each one with the SRU template prepared, ok?
<Odd_Bloke> rbalint: nacc: infinity: So do I need to dig in to your conversation about container fstabs yesterday, or have you resolved it?
<rbalint> Odd_Bloke: the plan seems to be generating non-broken fstab for lxc images
<tombombadil> hello ubuntu
<nacc> Odd_Bloke: i would read it (or the bug) for context
<kees> infinity, slangasek: meeting?
<zyga> pitti: no snap install cockpit? :)
<nacc> infinity: if i understood your convo with pitti / your feedback yesterday, it's not so simple as having an empty fstab on lxd images, right?
<jbicha> tjaalton: do you know why https://launchpadlibrarian.net/186043623/mesa_10.3.0-0ubuntu1_10.3.0-0ubuntu2.diff.gz wasn't pushed into Debian?
<tjaalton> jbicha: no idea, but the dependency should be more strict now?
<jbicha> tjaalton: it's still just a recommends in Debian so a dh_auto_test that works in Ubuntu needs to explicitly Build-Depend on libgl1-mesa-dri for the test to work in Debian
<tjaalton> maybe ask on #debian-x
<tjaalton> I don't know why it's just a recommends
<tjaalton> probably could be fixed there too
<infinity> nacc: Empty fstab for lxc/lxd is fine because / is mounted externally.
<infinity> nacc: But it's not so simple as removing fstab from *all* cloud images, because ones that need to remount-rw on boot won't because systemd hates your freedom.
<nacc> infinity: ok, thanks
<nacc> cyphermox: it would appear open-iscsi has grown a b-d/dep on libisns-dev/libisns0 (both in universe). Would you recommend trying to undo that dependency (unclear as it's a feature and i'd probably have to undo some documentation changes) or file a MIR?
<nacc> given that open-iscsi and open-isns seem to be basically co-maintained, it seems like a MIR makes sense
<cyphermox> nacc: +1 on MIR
<nacc> cyphermox: ack, thanks, will file it tmrw
<cyphermox> for that kind of stuff, I'd normally mostly do just a quick look if something can be ripped out, unless it's something very very ugly we'd really prefer not to have in main
<cyphermox> nacc: ack. I'll review the MIR as soon as I see it ;)
<nacc> cyphermox: yep, makes sense. Thanks!
<cyphermox> nacc: fwiw, I trust your judgement, do not feel like you must run everything by me for open-iscsi :)
<nacc> cyphermox: sure, i was just checking on your opinion for this case :)
<cyphermox> yup
<nacc> cyphermox: arguably generic from open-iscsi, but since you had touched it recently :)
<cyphermox> really just a drive-by that went wrong
<nacc> heh
<cyphermox> :)
<nacc> yeah, that was the longest merge i've had to do in some time :)
<cyphermox> ah?
#ubuntu-devel 2017-05-10
<nacc> cyphermox: yeah, we were up to ubuntu17 in zesty :)
<nacc> luckily just back and forth on the tests mostly
<cyphermox> I thought it was mostly tests and initramfs, yeah
<nacc> yep it was an easy merge, in the end
<cyphermox> oh ok
<LocutusOfBorg> hello mwhudson golang-pty sync, right?
<mwhudson> LocutusOfBorg: um
<mwhudson> we have delta for that?
<LocutusOfBorg> yes sir, and some ppc stuff
<mwhudson> apparently we do
<mwhudson> ah, ppc, everyone's favourite platform when it comes to ioctl numbers
<mwhudson> oh no, this is ppc as in powerpc as in who cares any more
<LocutusOfBorg> soooo will you sync it?
<mwhudson> yes
<LocutusOfBorg> thanks!
<mwhudson> ah yes the war on built-using
<mwhudson> LocutusOfBorg: done
<LocutusOfBorg> Logan, sorry but I think qbzr still needs that delta :(
<LocutusOfBorg> I'm readding it
<sil2100> Laney: hey! Do you know if when I re-run an autopkgtest for a github PR, will it be automatically picked up by the PR itself?
<sil2100> Laney: I got some failures caused by 'API rate limit exceeded for 91.189.89.216.' in tests that actually poll github through the API
<smoser> so i did apt-get install ubuntu-gnome-desktop. select gdm3 at the dpkg prompt. log out, back in. it seems like all i have changes is the system theme. i still have unity panel on the left and the top. and changing background doesn't work.
<smoser> is that known/expected ?
<ogra_> smoser, why wouldnt it ... if you didnt select another s4ession you will end up in unity again
<smoser> yeah, htat makes sense. but i was confused by the theme change.
<ogra_> (if you expect to end up in gnome you need to pick gnome)
<smoser> yeah.
 * smoser logs out. thanks
<smoser> ogra_, so, chose 'gnome'. background now is solid black. still unity launcher and panel.
<smoser> what am i supposed to pick ?
<ogra_> hmm, gnome should have brought you a gnome desktop
<ogra_> without unity panel and all
<smoser> other options were: gnome classic, gnome on wayland
<smoser> and 'ubuntu'
<ogra_> right, ubuntu should be unity ... gnome -> plain gnmome
<smoser> xerros shows:
<smoser> dbus-update-activation-environment: setting GDMSESSION=ubuntu
<smoser> dbus-update-activation-environment: setting XDG_CURRENT_DESKTOP=Unity:Unity7
<ogra_> what release is that btw ... it works fine for me (without changing to gdm btw) on my 16.04 laptop .... i installed gnome-desktop and just seletced it on lightdm
<smoser> Orphis, it is/was Artful.
<smoser> i think the issue was that i must selected the session, then typed the password wrong, then typed it right. i think it lost it in between.
<smoser> ogra_, (sorry Orphis )
<Orphis> Aaaaah
<jbicha> smoser: what are you trying to test?
<jbicha> if you just want the current state of Ubuntu Artful with GNOME, I think it might be better to just add gnome-shell to your Ubuntu install
<jbicha> ubuntu-gnome-desktop will change more settings and install more apps but not all of that will end up being in the default Ubuntu 17.10
<smoser> jbicha, well, i'm there now.
<smoser> so, "all in"
<jbicha> and currently, I think we're leaning towards lightdm instead of gdm but that's still TBD
<smoser> jbicha, thanks/
<jbicha> lightdm would end up *looking* more like gdm though
<Laney> sil2100: Pretty sure it should be.
<Laney> If you're hitting a rate limit, slow the test down?
<gsilvapt> hello everyone
<bdmurray> jbicha: Have you seen my comment on bug 1689093?
<ubottu> bug 1689093 in apport (Ubuntu) "Drop ubuntu-gnome hook for trusty, xenial" [Low,Triaged] https://launchpad.net/bugs/1689093
<jbicha> bdmurray: yes, could we set the hook to unreportable just for certain releases so that the hook can be synced with the current development release too?
<bdmurray> jbicha: Sure whatever is in the report e.g. DistroRelease, Package, ...
<jbicha> bdmurray: how much in a hurry are you? I'm not very familiar with apport's code so it will take more time for me to do that
<bdmurray> jbicha: Enough that'd I do it for you if you could pastebin me some criteria.
<rbasak> tjaalton: for bug 1676845, wouldn't it be appropriate to check that vlc still actually works?
<ubottu> bug 1676845 in vlc (Ubuntu Yakkety) "libgles1-mesa is being removed, don't depend on it" [Undecided,Fix committed] https://launchpad.net/bugs/1676845
<rbasak> Similarly opentk.
<rbasak> arges, bdmurray: ^
<rbasak> I do feel that this is something missing from SRUs currently.
<rbasak> A more explicit test plan so we actually check that the result isn't broken during SRU verification. Even just a quick smoke. It seems inappropriate to me to land an SRU if not one single person is known to have looked to see.
<tjaalton> rbasak: it works
<rbasak> But that's not in our current process.
<rbasak> tjaalton: thanks! I'll release Xenial now then.
<bdmurray> rbasak: yes, that makes sense me. What cases do you think would require a quick smoke check?
<jbicha> bdmurray: how about something like https://paste.debian.net/931810/ ?
<rbasak> bdmurray: any situation where checking the bug isn't fixed doesn't implicitly include a smoke check.
<rbasak> This vlc bug is an example - it should be verified just by checking dependencies, without actually running vlc.
<bdmurray> it could be verified, but we should do more - agreed
<rbasak> OTOH, a hypothetical "help button appears in wrong place" bug wouldn't need it because one cannot check that the help button is in the right place without running the app, and that constitutes a smoke test.
<bdmurray> jbicha: what about gnome3-next?
<jbicha> bdmurray: that's empty right now, but feel free to use the same template there if you want, https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-next
<rbasak> I'd suggest a [Test Plan] section, but I agree about not wanting to require additional paperwork. So how about making it an ~ubuntu-sru thing? Not required, optional for uploaders, but we'll add one if we feel it is needed, or if there isn't one, we feel it is needed but it isn't clear what it would be, only then would we ask and defer accept until the test plan is agreed.
<jbicha> rbasak: just rename Test Case to Test Plan?
<rbasak> Test Case is for the specific bug being fixed though.
<rbasak> Test Plan is wider (but does of course include Test Case)
<bdmurray> rbasak: I think the suggestion seems reasonable and depending on how well it works we could then make it a requirement.
<rbasak> "Here's what I plan to do to ensure that I haven't regressed the package in some other way" vs. "Here's what I plan to do to ensure that the bug I'm fixing is actually fixed".
<rbasak> bdmurray: thanks. Shall I propose this on ubuntu-devel@?
<bdmurray> rbasak: That'd be great.
<bdmurray> jbicha: and the ubuntu-gnome hook could be dropped in artful correct?
<rbasak> ack
<jbicha> bdmurray: no, the GNOME3 PPAs are still being used, at least for now
<bdmurray> jbicha: okay, got it
<justanotherbody> can anyone tell me where i could find the recipies used to compile the binaries for e.g., libstdc++ ?
<nacc> justanotherbody: the src package the generates the binary packge
<justanotherbody> can you by chance tell me where to find the source package on http://mirrors.mit.edu/ubuntu/ ? i can only seem to locate the .deb files
<nacc> justanotherbody: i don't know if they mirror them or not
<nacc> justanotherbody: but you can just use `pull-lp-source <srcpkg>`
<justanotherbody> if i didn't have admin privileges to install `pull-lp-source` could you suggest another command?
<justanotherbody> (i dont, and it is apparently not installed)
<sarnold> apt-get source will download to a current working directory
<nacc> sarnold: thanks
<sarnold> that mirror doesn't look like it has any sources -- only debs
<sarnold> oh that's because the gcc dir has way too many debs
<sarnold> never mind
<justanotherbody> ?
<sarnold> note e.g. http://mirrors.mit.edu/ubuntu/pool/main/g/gcc-6/gcc-6_6.3.0-17ubuntu1.dsc
<sarnold> that file describes the other sources used to build the gcc-6 source package and all its binary packages
<justanotherbody> so i looked at once of these
<justanotherbody> but i didn't understand how i could use it to locate the build script
<justanotherbody> so im specifically after the actual build script
<justanotherbody> my underlying problem is i need to locally compile a newer version of libstdc++
<justanotherbody> for reasons relating to the fact i'm running ubuntu 14.04 (not by choice) and need a version newer than security updates allow for
<justanotherbody> and adding a PPO or alternative apt installation mechanism isn't supported by anyone with superuser access
<justanotherbody> so i figure i download the library adn compile from source - something ive done before
<nacc> building your own libstdc++ is a recipe for pain, it feels like
<justanotherbody> but i want to mirror the make arguments and e.g., CFLAGS env variables as closely as possible
<justanotherbody> im not disagreeing
<nacc> seems highly likely to break stuff :)
<nacc> justanotherbody: use `apt-get source` and then see debian/rules in the srcpkg
<justanotherbody> which is *exactly why* i'm trying to locate teh build script
<nacc> justanotherbody: i mean by version
<nacc> justanotherbody: the chagne in version, without rebuilding stuff that depends on it, is likely to break things taht try to load it
<justanotherbody> i agree
<justanotherbody> my hope is to isolate the lib such taht hte fewest possible things try and load it
<nacc> justanotherbody: but in any case, `apt-get source...` and then see what d/rules does
<sarnold> you may need to also use newer gcc to compile your tools
<nacc> yeah
<sarnold> abi changes happen :(
<justanotherbody> sarnold: interesting, new gcc is provided
<justanotherbody> *interestingly
<justanotherbody> by my infrastructure team
<sarnold> justanotherbody: if you're going for slightly-hacky you might have some success just unpacking newer debs manually
<sarnold> justanotherbody: that'd be a thousand times faster than building your own and it might work well enough
<sarnold> justanotherbody: download the .deb file, use ar x to extract it into a data.tar.gz and control.tar.gz files, tar xf the data.tar.gz fiile, and grab the library out of it that way
<sarnold> and if it doesn't work for some reason, well, you'll have only spent ten minutes on it anyway
<justanotherbody> nacc, sarnold: you have been very helpful. thank you much!
<nacc> justanotherbody: yw
<infinity> sarnold: What you're looking for is "dpkg-deb -x foo.deb path/" ... ar and tar is pretty unfriendly. :P
<sarnold> good luck justanotherbody :)
<sarnold> infinity: I can do ar x tar xf blindfolded in my sleep. it takes me ten minutes to find the right manpage to read if I want to skip those.
<infinity> :P
<infinity> sarnold: dpkg-deb -x unpacks data.  dpkg-deb -R unpacks data and control.  The latter being useful if you want to dpkg --build again after you tweak it.
<infinity> sarnold: I mean, keep aring and taring all you want, but the above is probably more user-friendly to tell others. ;)
<sarnold> infinity: don't even get me started on apt-cache rdepends, apt-rdepends, and reverse-depends....
<sarnold> infinity: but I have to know them myself before I can tel others about them, heh
<nacc> cyphermox: fyi,, filed LP: #1689963
<ubottu> Launchpad bug 1689963 in open-isns (Ubuntu) "[MIR] open-isns" [Undecided,New] https://launchpad.net/bugs/1689963
<rbasak> jbicha: fyi, I got the same es translation notice from Launchpad for gnome-calendar in Zesty. Not a problem from my perspective - just letting you know.
<jbicha> ok, I'll fix that up
#ubuntu-devel 2017-05-11
<cjwatson> jbicha: Can https://bugs.launchpad.net/ubuntu-gnome/+bug/1575621 be made public?  See https://answers.launchpad.net/launchpad/+question/627738
<ubottu> Error: launchpad bug 1575621 not found
<infinity> cjwatson: I like that he's all irate about the "so-called LTS", but the software crashing is all from a PPA.
<jbicha> that PPA is now no longer supported for 16.04 LTS
<jbicha> I'll follow up on the question
<cjwatson> thanks
<juliank> xnox: I just released apt 1.4.3 fixing a bug where the timers get restarted/stopped in postinst/rm scripts of all packages. Nothing on the "runs to soon after" resume side, yet.
<juliank> I guess we really want some restart handling of the service, with 15 min delay or so
<juliank> (and limit that sensibly)
<juliank> But I fear this might be too much, I can't really see what issues could arise from that; and if the service even fails at all (update might exit with 0 if network is not up yet)
<juliank> Or imagine some hosts failing all the time
<juliank> can't run update all the time
<juliank> Yep, resolve failure is transient, that would not cause the unit to fail. A 404 (missing repository) would cause it to fail, we would not want to retry that all the time
<juliank> Well, maybe once an hour or so
<juliank> Leaves us with sleeping a minute or so in a service which we specify Before=apt-daily, After=suspend, WantedBy=suspend. Fairly hacky.
<xnox> juliank, ack, can we do sru of these, without addressing resume.
<nacc> bdmurray: slangasek: re LP: #1646739 is it actually fix released? seems to have been spam from someone to change a bunch of state?
<ubottu> Launchpad bug 1646739 in samba (Ubuntu) ""Use of uninitialized value" in debconf via update-manager" [Critical,Confirmed] https://launchpad.net/bugs/1646739
<juliank> xnox: I'll do some new SRUs matching 1.4.3 later today or tomorrow. I guess I might just write a helper that deals with http and https repositories and calls connect() for each of them in order for a minute, and put that in execstartpre or something.
<bdmurray> nacc: No, I thought I fixed it yesterday
<juliank> Let the helper exit with a special exit code and set some restart handling for that.
<juliank> (well, maybe no restart if I can't figure out implications)
<juliank> If I can figure this out early tomorrow, I might just do 1.4.4 and SRU a more complete fix :)
<nacc> bdmurray: thanks
<cjwatson> LP no longer requires buildinfo files to be signed in source uploads.
<jbicha> thanks!
<nacc> rbasak: around?
<rbasak> nacc: o/
<nacc> rbasak: do you have a moment to talk snaps for the importer?
<rbasak> Sure. HO?
<rbasak> or IRC?
<nacc> HO would be great
<rbasak> OK. Send a link and I'll be two minutes
<nacc> rbasak: did we agree/decided on the ubuntu/debian remote change?
<nacc> rbasak: and if not, what should the spec be for the fetch of the default remote
<nacc> rbasak: 'origin' for now?
<rbasak> nacc: I don't follow the question
<rbasak> Which is the default remote?
<nacc> rbasak: for `git ubuntu clone`
<nacc> rbasak: right now the remote is called 'lpusip'
<rbasak> I think that should set up both a debian remote and an ubuntu remote, and fetch both
<nacc> rbasak: ok, i just wasn't sure if we had agreed on the 'debian', 'ubuntu' remote idea or not :)
<nacc> rbasak: ack, will do
<rbasak> nacc: if you're not happy, further discussion welcome.
<nacc> rbasak: no, i just didn't see it int he spec
<nacc> rbasak: as it says 'crazy idea' still :)
<rbasak> nacc: lines 48-55 in the pad?
<rbasak> Oh :)
<rbasak> I think it turned out less crazy
<nacc> rbasak: ack
<rbasak> Since we have cleared defined specific refspecs, there shouldn't be any confusing overlap
<nacc> yep
<nacc> rbasak: do we not want to add any push url at all by default?
<nacc> rbasak: i know we don't want any push refspec, but not having a push url means that the importer needs to include a bit more knowledge (or push() does)
<rbasak> nacc: not sure. I think a push url is probably fine if it's inconvenient otherwise, as ACLs should prevent accidents in the end anyway
<rbasak> nacc: OTOH, perhaps for our safety the importer should require the push URL explicitly?
<nacc> rbasak: right, i think i will do it piecewise
<nacc> rbasak: as right now we do add pushurls
<rbasak> We could always change that later
<nacc> rbasak: so i'll keep it in the namespace cleanup and have a followon commit that doesn't have the push url
<rbasak> Sounds good
<nacc> rbasak: hrm, also, our fetch refspec won't see import tags or orphan tags
<nacc> rbasak: i can't remember if that was intentional?
<robert_ancell> bdmurray, now you rejected gnome-software (3.20.1+git20170509.0.8292905-0ubuntu1) can I re-upload with the same version with a corrected version number?
<robert_ancell> It was an annoying copy-paste error in the changelog, not sure the best way to correct that.
<robert_ancell> that should have read "corrected changelog entry"
<nacc> robert_ancell: yes, you can if it never got published (rejected from queue)
<rbasak> nacc: not intentional.
<nacc> rbasak: if you have the time, cna you update the specs? not sure how you want that to look, as they (import, orphan tags) are not namespaced on the remote
<mwhudson> robert_ancell: pretty sure you can, lp will tell you pretty quickly if not :)
<infinity> mwhudson: Actually, LP wouldn't tell him for the same reason that he can indeed reuse the same number.  Versions in the queue don't "exist", and it's not checked until it's accepted.
<mwhudson> right, that's what i thought
<mwhudson> time to break the archive by adding python3.6 as a supported version i think
<robert_ancell> infinity, awesome, I hoped that was the case
<robert_ancell> I wish there was an easy way to pull sometime from the queue you've uploaded
<infinity> robert_ancell: queue -Q unapproved -s zesty-proposed fetch $source
<mwhudson> robert_ancell: isn't that what the 'queue' tool in ubuntu-dev-tools does?
<robert_ancell> Do I have permissions for that?
<infinity> The queue is public.
<infinity> So, yes, you should be able to.
<infinity> I think.
<robert_ancell> I don't see any queue command in ubuntu-dev-tools...
<infinity> It's in ubuntu-archive-tools
<rbasak> nacc: ah. import tags aren't specific to Ubuntu or Debian, are they? IIRC, it's whatever the importer saw first, so often Debian but not when there's an Ubuntu delta?
<infinity> lp:ubuntu-archive-tools
<mwhudson> oh right, i bungled the name
<nacc> rbasak: right, they are just first-seen
<nacc> rbasak: it's the first time any version is ever seen
<rbasak> Perhaps we could pull them into refs/tags/import/* locally. At least they're still separated from the user's own tags.
 * rbasak forgets what orphan tags are
<rbasak> When a parent could not be found?
<nacc> rbasak: orphan tags exist if we cant' find any parents
<nacc> fairly rare, but they exist for some old imports
<robert_ancell> I get a "401: Unauthorized" if I try and reject my last upload
<rbasak> Oh yeah, the "must not fail" thing. I remember now :)
<robert_ancell> Do I need to add permissions somewhere?
<rbasak> I think it'd be OK to pull them into refs/tags/orphan/* as well.
<nacc> robert_ancell: oh queue manipulation is different than looking at the queue
<rbasak> The refspec would have to be a little odd - perhaps in the ubuntu remote but not the debian one?
<nacc> rbasak: right, because it's technically "in" both remotes (since they are the same underlying repo)
<mwhudson> robert_ancell: oh, i think i misinterpreted how you used the word 'pull' :-)
<rbasak> Yeah. A little ugly :-/
<robert_ancell> mwhudson, ah, ok
<robert_ancell> So not possible?
<nacc> robert_ancell: you meant remove something from the queue?
<mwhudson> robert_ancell: you meant "remove"?
<nacc> robert_ancell: you need someone with permissions to do that for you, as you did above (i think)
<mwhudson> i don't think that's possible no
<robert_ancell> nacc, yeah, if I make a mistake in an upload, it would be really nice to cancel it an do it again.
<nacc> robert_ancell: right, it depends on the series
<nacc> robert_ancell: for instance, the devel series, not possible, as it's getting auto-accepted
<nacc> robert_ancell: sru, the sru team can reject
<rbasak> nacc: added to the spec
<nacc> rbasak: thanks, and then our acl on the backend for the push will be what prevents users from pushing their import/orphan tags (or changing them or whatever)
<nacc> in case they do try to push, that is
<rbasak> Yeah
<rbasak> That's exactly the same issue as pushing the branch pointers, right?
<nacc> yeah i think so
<bdmurray> robert_ancell: yes, you'll just need to use '-f' with dput
<nacc> rbasak: and we're not fetching any tags from a user's git repository?
<nacc> rbasak: also, `usd clone` currently creates a tracking branch for lpusip/ubuntu/devel and checks it out. Do we want to just checkout ubuntu/devel (remote branch)? As a local tracking branch? with what name?
<doko> mwhudson: did you already start doing no-change uploads for stage1 http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html ?
<nacc> speaking of transitions ... is there a way tot specify that http://people.canonical.com/~ubuntu-archive/transitions/html/postgresql-9.6.html e.g.'s "bad" shoudl not include things that are also good?
<nacc> both those entries appear to be |'d already with 9.6 deps
<doko> mwhudson: now promoted the python3.6 packages
<nacc> rbasak: oh and i recall a primary reason for a lot of our non-pygit2 calls -- they didnt' support working-directory at all
<nacc> rbasak: i believe they fixed that, i need to check
<nacc> rbasak: ok, last point, i think we should iether drop support for --lp-owner to `usd import` or we need to rethink the refspec a bit
<nacc> rbasak: actually, maybe this fixes it :)
<nacc> rbasak: ok, i think i'm nearly there -- need some assistance on ll. 87-92 in the spec, if you have time tmrw
<nacc> cyphermox: fyi, i think i got the open-isns tests to run during the build, will update the MIR
<nacc> rbasak: http://paste.ubuntu.com/24557476/
#ubuntu-devel 2017-05-12
<mwhudson> doko: yes
<cyphermox> nacc: cool, ta
<mwhudson> doko: also does https://launchpadlibrarian.net/318956988/buildlog_ubuntu-artful-amd64.gpgme1.0_1.8.0-3ubuntu2_BUILDING.txt.gz mean anything to you?
<mwhudson> it fails in the archive the same way, some bizarro interaction between pie/pic things
<mwhudson> the rules file says
<mwhudson> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie,+pic
<mwhudson> which seems a bit crazy
<jbicha> mwhudson: could you check if we can remove the ",-pie,+pic" diff from Debian there now that we have a newer dpkg, etc.?
<mwhudson> oh is that delta?
<mwhudson> that would explain a lot :)
<nacc> rbasak: i think the above paste has git-clone matching the spec (and I guess we'll want another option to git-clone like --add-remote or something for adding a colleague's remote?)
<mwhudson> does the ben output at https://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html come in any other formats?
<mwhudson> AssertionError: "year is out of range" does not match "year 0 is out of range"
<mwhudson> yay
<arune_> hello, regarding https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641203/comments/14
<ubottu> Launchpad bug 1641203 in sssd (Ubuntu Xenial) "SSSD can't process GPO from Active Directory when it contains lines with no equal sign" [Medium,Triaged]
<arune_> I need sssd 1.13.5 to test ding-libs from proposed
<arune_> are sssd 1.13.5 also in proposed? (where can I see that?)
<infinity> arune_: sssd hasn't been uploaded yet, no.
<arune_> infinity, ok, thanks
<Unit193> Though sssssssd might have. >_>
<mwhudson> doko: some of the bad things on https://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html have been rebuilt now
<mwhudson> doko: i guess that means the packaging screws up depends?
<mwhudson> or possibly the packaging fails to build for all supported python versions somehow
<arune_> infinity, where can I watch if new version of sssd gets uploaded?
<infinity> arune_: The bug you referred to will get a comment when the sssd that references it is uploaded.
<arune_> infinity, thanks
<sil2100> bdmurray: hey! Once you're up: I wanted to review your apport SRUs just now but none of the bugs comply to the SRU procedures
<sil2100> bdmurray: the changes themselves look good and I guess me as a reviewer understands all the implications, but I don't know if I can legally accept this without any of the formalities fullfilled
<sil2100> bdmurray: I guess I could get it in if you'll be the one doing the verification
<sil2100> bdmurray: anyway, I'll leave it for now until you pop up
<brainwash> systemd 233 was built with +IMA, but there is no /etc/ima/ima-policy or /etc/default/ima-policy
<brainwash> bug?
<brainwash> >Unable to open file: /etc/ima/ima-policy (-2)
<brainwash> >IMA: policy update failed
<infinity> brainwash: It's not a bug that we don't ship a policy, no.
<infinity> brainwash: It might be a minor upstream cosmetic bug that systemd is whiny about it when the file isn't there.
<brainwash> infinity: alright. thanks
<bdmurray> sil2100: You shouldn't just accept it, that'd be a double standard on our part! I'll add the stuff today.
<sil2100> bdmurray: thanks! Give me a quick poke once done, I'll re-review them then
<nacc> rbasak: i'm around now, if  you want to discuss  my laundry list from yesterday :)
<rbasak> Sure. Give me ten minutes?
<doko> mwhudson: looks like you got some help from somebody ...
<nacc> rbasak: yep
<doko> mwhudson: looking at libxml2 ... this should be worth a bug report, or a fix.
<doko> xnox: boost1.62 and .64 still in artful?
<doko> .64
<doko> .63 even
<xnox> yeah....
<doko> mwhudson: did you already file debian bugs for the 3.6 transition? If not, please could you use user tagging, python3.6 / debian-python@lists.debian.org?
<infinity> doko: libxml2 is a mess.  That debian/rules made my eyes bleed.
<infinity> doko: I feel like the right fix will be someone submitting a whole new version of the debian/ directory. :P
<doko> well, happyaron packaging ;p
<infinity> doko: FWIW, if you feel the urge to look, it actually *does* build for all python versions.  Then installs them all over each other, and the default wins.
<infinity> (derp)
<doko> yes, there is a prename call in between, which is now deprecated. thanks for the dpkg maintainer to break things ...
<doko> I really love this behaviour
<infinity> How is that the dpkg maintainer's fault? :P
<infinity> But also, the prename is just for the -dbg stuff, it looks like.
<infinity> There's no way that rule file would have ever worked right for multiple versions of python3.
<infinity> (Which makes sense, as it was introduced with py3.5, and never tested with multiple)
<doko> not for 3.4?
<infinity>   * add python3 support (Closes: #737774)
<infinity>  -- Aron Xu <aron@debian.org>  Mon, 12 Sep 2016 02:57:02 +0800
<doko> looks like some of the rebuilds were done before the new python3-defaults was published. at least the protobuf package now fails in the tests instead of the build
<doko> happyaron: ^^^
<happyaron> doko: I took the package from mike miller IIRC
<happyaron> when he doesn't have enough time to make security updates
<infinity> python-traits is hung up because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846771
<ubottu> Debian bug 846771 in src:python-traits "python-traits: FTBFS randomly (failing tests)" [Important,Open]
<infinity> I've retried it repeatedly, no luck.
<infinity> Might just want to carry a delta to ignore those two tests for the short term. :/
<happyaron> infinity: so what's the problem you have with libxml2?
<infinity> happyaron: The attempt to build for multiple python3 versions doesn't work.
<infinity> happyaron: Unless you wanted a larger review of debian/rules than that, but I'm tired. :P
<happyaron> I had a hard time understanding the d/rules when I took the package, :D
<happyaron> mind to send a bug report? I'll give it a poke.
<infinity> happyaron: I'm about to go to bed.  If this verbal bug report isn't enough, I can follow up later.
<happyaron> good night, please do drop something to the bug tracker so that it's easier to track...
<doko> mwhudson: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.6;users=debian-python@lists.debian.org
<doko> xnox: boost doesn't like to build for multiple python versions?
<xnox> doko, it does not
<doko> xnox: b-d: python-3-all-dev
<doko> maybe change to python3-dev, python-dev
<doko> but it builds for 3.6 ...
<xnox> doko, ok.
<xnox> but everything links against boost_python3.so or what not.
<xnox> thus things rebuild against the boost-python will still be using only the default python3.
<doko> so you are just lucky that it builds 3.5 after 3.6 and overriding the 3.6 binaries ...
<bdmurray> sil2100: apport X and Y SRUs are all set
<sil2100> \o/
<sil2100> bdmurray: on it
<bdmurray> sil2100: Actually I meant Y and Z - X is still coming.
<bdmurray> sil2100: I also just uploaded whoopsie to the yakkety queue
<tsimonq2> Is there a reason why pull-ubuntu-source is not symlinked to pull-lp-source in ubuntu-dev-tools?
<tsimonq2> It would make sense, in my opinion.
<infinity> tsimonq2: Because lp is shorter to type? :P
<infinity> tsimonq2: Alternate answer "because it's not".  I don't think there's a conspiracy afoot, just no one thought/cared to do so.  Which probably indicates how often we're asked (never), which probably means you could just alias it locally and be happy.
<tsimonq2> infinity: Fair. :)
<sil2100> bdmurray: accepted, I'll also accept whoopsie for xenial even without the apport part as it doesn't hurt anyone
<nacc> slangasek: are you available for a quick question? (beyond this one :)
<slangasek> nacc: yah
<nacc> slangasek: rbasak and i were discussing earlier today about what you'd expect the default behavior of `git clone lp:...` to be. Would you want us to checkout to the patches-applied ubuntu/devel branch? The reason *not* to do that is there is no .pc directory. So things like `dpkg-buildpackage` and `dpkg-source --commit` don't work without .pc. But the lack of .pc is for dgit compatibility.
<nacc> slangasek: vs. what we currently do, which is put you in the patches-unapplied ubuntu/devel
<nacc> slangasek: just trying to capture different use-cases/expectations, at least at first
<slangasek> nacc: fwiw I'm pretty sure dpkg-buildpackage does work with patches-applied and without .pc
<slangasek> nacc: but I figured I'd leave it up to you guys what the default branch checkout should be :)
<nacc> slangasek: oh i wonder if it might, because i think it might do a parallel extraction to see if there are local cahgnes?
<nacc> slangasek: if dpkg-bp does 'just work', then maybe it's less of a concern. The `dpkg-source --commit` problem is why dgit (afaict) has this quilt-fixup mode
<slangasek> nacc: MoM for example always gives you a patches-applied, no-.pc tree
<nacc> slangasek: sorry, you're right, dpkg-bp probably does work
<nacc> slangasek: the issue is how to make changes to that tree that are capture-able in the src package
<nacc> it feels like dgit's model is you use dgit and only dgit :)
<nacc> slangasek: but that's good feedback, i'll make some notes
<nacc> slangasek: totally unrelated question (now that I remember it). I'm trying to add the open-isns self-tests at build-time (for its MIR). Is there a typical way to specify to use the package build directory as LD_LIBRARY_PATH (or maybe some subdir of the build directory)? As the tests need to load the library built by the package during the tests.
<slangasek> nacc: I don't think there's any way of doing this that's more typical than just constructing and exporting LD_LIBRARY_PATH yourself
<slangasek> if upstream were using libtool, there would be wrappers galore
<nacc> slangasek: ok, i wasn't sure, thanks!
<nacc> slangasek: yeah they're not :)
<nacc> slangasek: does debhelper provide a variable containing the build_dir? Or is it safe to use '.' in d/rules?
<slangasek> nacc: I don't think there's a variable for build dir, no
<gsilvapt> Hello everyone
<gsilvapt> I need help updating a Debian repository with a newer release version from upstream, using gbp
<gsilvapt> Can someone guide me through the process? I'm not 100% how that works from the docs because the covered processed seems to be the opposite
<nacc> gsilvapt: do you need to use gbp?
<gsilvapt> I'd like to because the upstream is a Git repo
<nacc> gsilvapt: but you're using an upstream release, right? not from an arbitrary git commit?
<nacc> gsilvapt: just use `uscan` and `uupdate`
<gsilvapt> no, it's an upstream release
<gsilvapt> But how do I take care of things? Get both sources and use those commands to update the Debian package?
<nacc> gsilvapt: i don't know what you mean
<nacc> gsilvapt: `uscan` will download new upstream releases based upon debian/watch
<nacc> gsilvapt: `uupdate` will take the existing debian/ and use the provided orig tarball you obtained via `uscan`
<gsilvapt> So I do pull-debian-source and then do those commands?
<nacc> gsilvapt: you want to update a debian version's release?
<nacc> gsilvapt: that is typically a task for the debian maintainer
<gsilvapt> I can still propose him, right?
<gsilvapt> or ask him for sponsorship on that
<nacc> gsilvapt: i guess so, not very typical IME
<gsilvapt> after uupdate, what is next?
<nacc> gsilvapt: this seems contradictory to what you suggested was your goal -- to learn development/fix bugs, etc
<gsilvapt> Also included maintaining packages
<nacc> it seems way more useful to learn the first ones first then work on maintaining packages
<nacc> but your choice, of course
<nacc> gsilvapt: have you run `uupdate`?
<nacc> gsilvapt: with an appropriate path to a tarball
<nacc> gsilvapt: it tells you what to do, it will create a ../<srcpkg>-<newversion> directory with the srcpkg contents
<nacc> you'll need to update d/changelog, make sure the d/patches apply/need refreshing etc, check that everything is building as expected and test it
<gsilvapt> This was a suggestion from the mentor I talked about. He mentioned I should use gbp specifically but I'm kind of stuck because the only material I found has the reverse process (debian to upstream and not upstream to debian). Didn't want to mess that up.
<gsilvapt> Not sure if he wants to actually submit that but it can still work as a project to learn how things work
<gsilvapt> I'm guessing messing around with local repositories will not damage the original ones
<gsilvapt> No, I haven't done a thing
<gsilvapt> Still trying to figure out the process in my head before doing stuff
<nacc> gsilvapt: presumably you will need to use `gbp-import-orig` if you want to use gbp
<nacc> i don't personally use gbp, so i can't help more with that
<nacc> gsilvapt: it feels like you should just ask your mentor
<gsilvapt> Okay, thanks anyway! I'll keep trying to look out for gbp docs
<nacc> gsilvapt: the manpages are pretty complete iirc
<gsilvapt> Alright, thanks!
<rbasak> slangasek: nacc: http://people.canonical.com/~cjwatson/dpkg-quilt-setup
<rbasak> MoM does break dpkg-buildpackage, at least some of the time.
<rbasak> That script (IIRC, it may be some other script) fixes it up
<rbasak> I don't like this general approach though. There's more scope that an edge case will not put you exactly back.
<slangasek> you can have an MoM tree for which the patches don't actually unapply cleanly; but that's separate from .pc being absent
<rbasak> Ah, I see.
<rbasak> Even so, can we perhaps consider what would happen if we did keep .pc in our trees, and if that breaks dgit, if we can make dgit cope with that situation?
<slangasek> (and, to be clear, really annoying to manually unwind when it happens :)
<rbasak> Then we both get what we want, I think. All tooling, including quilt, will all work at any step.
<slangasek> hmm but storing .pc means lots of extra delta in the history
<rbasak> The history is fake anyway.
<rbasak> If you want real history, look at the patches unapplied branch and the quilt patches, since that's what's really there.
<slangasek> anyway, I'm not fussed about lp:ubuntu/$pkg pointing to patches-unapplied
<rbasak> I am. I appreciate Ian's "drive by contributor" use case.
<Unit193> Why would one want .pc applied?
<rbasak> Unit193: so that "quilt pop -a" still works.
<rbasak> It's just a matter of deciding what the patches-applied commits should look like exactly.
<rbasak> But I think I've become convinced that it's the patches-unapplied that really matters to Ubuntu. That's what we'll be uploading. Until one day everyone's using git-dpm or something similar.
<rbasak> Just adding commits onto patches-applied means that we'll be losing sight of our delta.
<rbasak> I want a rich patchset, as well as a rich history.
<sladen> yup
<nacc> quilt pop -a and `dpkg-source --commit`
<nacc> i think the latter is most relevant for our drive-by case
<sladen> if one wants this illusion of reality, by all means write a wrapper
<gsilvapt> nacc, could you give me a hand using uupdate?
<nacc> gsilvapt: sure, what's up?
<gsilvapt> so, I ran uscan and it found the tarballs for a new version.
<gsilvapt> now running uupdate isn't that straightforward x)
<nacc> gsilvapt: uscan, without args, i think runs uupdate itself
<nacc> gsilvapt: what src package?
<gsilvapt> it says no archive given
<gsilvapt> it says no archive given if I run uupdate*
<nacc> gsilvapt: well you didn't give it an archive
<nacc> gsilvapt: as i said earlier, you need to pass it the new upstream tarball
<nacc> gsilvapt: did you read `man uupdate`?
<gsilvapt> yes, I have it opened but still can't run the commands
<nacc> gsilvapt: what src package?
<gsilvapt> what do you mean? The name of the program?
<nacc> gsilvapt: what source package are you trying to update? very basic question
<gsilvapt> pandas
<viju> Hi, if I rebuild the package from sources, will it replace the original package installed before?
<nacc> viju: rebuilding a package just builds a pacakge
<nacc> viju: it doesn't install it
<viju> I mean if I make install it.
<nacc> gsilvapt: http://paste.ubuntu.com/24563342/
<nacc> viju: if you build from source, you're not using a package
<gsilvapt> I was using the wrong command to show where the file was. Sorry and thanks for the help!
<nacc> viju: so i'm not sure what you mean
<viju> nacc: I am trying to tinker with some application, just change something and build-install it to see how it works, so that next time I can add small feature for my own use. However I am a beginner when it comes to building anything on Ubuntu.
<tsimonq2> I want to work on (release a new version) a package that's in Main. Is there anything special for finding out who to check with if that's OK? Isn't that a bit different from getting things in Universe?
<nacc> viju: if it's an application, you probably dont' actually need to build install it
<nacc> tsimonq2: is it sync'd currently?
<nacc> tsimonq2: and/or which pkg?
<nacc> viju: that is just build it locally and then run the local binary
<tsimonq2> nacc: I was looking at libreoffice
<tsimonq2> nacc: No, it's not synced
<nacc> heh
<nacc> there's a snap now! :)
<tsimonq2> Bah
<tsimonq2> :P
<nacc> tsimonq2: i'd probably check in with the last uploader
<tsimonq2> nacc: Ah ok, so just like in Universe?
<nacc> tsimonq2: yeah, i mean, (IMO) packages in main/universe is a support statement (security and canonical), less deterministic about how the package is maintained
<nacc> others may disagree
<nacc> but i've not treated them differently in that regard so far
<viju> nacc: so if I place it in /opt/gcalculator, I can run it from the same location, right?
<tsimonq2> nacc: Which is why I want to be very careful that I don't duplicate work if I want something in Main because there's likely a Canonical person working on it, iirc.
<nacc> tsimonq2: yeah, i see what you mean -- i'd contact the last uploader still
<tsimonq2> nacc: Ok, thanks. :)
<nacc> viju: i mean, why put it in /opt? just build it from somewhere and run it from there?
<nacc> s/from somewhere/somewhere/
<spencerb> with unity 8 officially abandoned, are the dconf bindings for qt still being developed?
<tsimonq2> Hmmmm, good question...
<tsimonq2> mitya57: ^
<nacc> rbasak: ok, i have pushed up the rename to git-ubuntu, and will give you a MP for the namespace changes as they are now
#ubuntu-devel 2017-05-13
<tsimonq2> jbicha: Now that I'm digging through lxqt-l10n, I just want to say thanks for your attention to detail re: bug 1635701 :)
<ubottu> bug 1635701 in lxqt-session (Ubuntu) "Merge 0.11.0-3 from Debian Sid" [Undecided,Fix released] https://launchpad.net/bugs/1635701
<tsimonq2> jbicha: bug 1690489
<ubottu> bug 1690489 in lxqt-l10n (Ubuntu) "Force sync 0.11.2-1 from Debian Sid" [Undecided,New] https://launchpad.net/bugs/1690489
<viral_mutant> I am creating a DEB package, which marks âConflictsâ flag with another package provided by Ubuntu repo. The âdpkg -iâ reports conflicts while installing my package, which is what I expect
<viral_mutant> But, using apt-get install, that proposes to Remove the already installed package and install my package
<viral_mutant> Is there a way to make apt-get behave the dpkg way of failing with error ?
<sladen> vila: apt install --no-remove
<sladen> vila: (see   'man apt'  for more options)
<mitya57> spencerb, tsimonq2: I am not the best person to ask about dconf-qt, but I believe it will be abandoned.
<jbicha> mitya57: are you going to be handling the Qt update for artful later?
<mitya57> jbicha, yes, we decided to skip 5.8 and ship 5.9 later
<mitya57> and with Mirv no longer working for Canonical, this will be complicated
<jbicha> mitya57: unity8 is being removed from artful so hopefully that helps
<mitya57> if other packages like ubuntu-ui-toolkit, or the just mentioned dconf-qt get removed too, that will help
<mitya57> jbicha, btw https://launchpad.net/ubuntu/+source/sphinx/1.5.5-1ubuntu1 is for you
<mitya57> Will upload to Debian on Monday together with 1.5.6 upstream release
<jbicha> mitya57: thank you!
<mitya57> jbicha, I will make sure that the autopkgtest now actually passes on the server, and after that upload the SRUs
<mitya57> (anyway not having more time today)
<jbicha> xnox: do you know about ubuntu-ui-tookit and dconf-qt yet?
<mitya57> and qtubuntu (aka Qt MIR support), it is also a tricky package
<jbicha> bdmurray: unattended-upgrades ran automatically when I booted today's Ubuntu artful image :(
<jbicha> I guess the surprising part for me is that no one reported this during the zesty cycle
<jbicha> so I guess we can either fix LP: #1649709 or workaround the issue in casper
<ubottu> Launchpad bug 1649709 in unattended-upgrades (Ubuntu) "unatttended-upgrades 0.92ubuntu3 installs all updates but update-manager is set to only install security automatically" [Undecided,Confirmed] https://launchpad.net/bugs/1649709
#ubuntu-devel 2017-05-14
<mapreri> jbicha: I'm looking at the lxqt-session and I can't find a reason on why we wouldn't want lxqt-common as a dependency.
<mapreri> can you explain me why you did that?  Was because of some temporary situation that is not gone?
<jbicha> mapreri: please talk to gilir, the Lubuntu lead who made that change originally
<jbicha> mapreri: I think it wouldn't hurt to keep that transitional pkg until after 18.04 LTS
#ubuntu-devel 2018-05-07
<Unit193> Are backports going to be a thing for Bionic?
<RAOF> Unit193: Vs, say, snaps?
<Unit193> Not really a 'vs' unless you mean 'vs ignoring the backports queue'
<Unit193> RAOF: In the past few releases, there haven't been many people reviewing the queue, so very few things got into backports.
<RAOF> This has not escaped my notice as I'm reviewing the SRU queues, yes.
<Unit193> Heh, SRU's being more important, and strict of course.
<RAOF> I'm not actually sure whose job it is to accept things into backports, either. I don't believe I'm supposed to ð
<Unit193> Nah there's a team for it, but so far it's...Not really had much movement.
<Unit193> (https://launchpad.net/~ubuntu-backporters/+members FWIW)
<tjaalton> seems like the administrators could've done a better job :) most of the pending members left years ago
<tarzeau> updated, but i didn't just want to add the complete installer log tarred up, please select which one you want: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1769044
<ubottu> Launchpad bug 1769044 in debian-installer (Ubuntu) "Ubunut 18.04 d-i preseeded installer hangs at 66 % of update-grub..." [Undecided,New]
<tarzeau> when will the debian2ubuntu archive sync start again?
<cjwatson> tarzeau: a few days ago
<tarzeau> cjwatson: then it failed to pickup cloudcompare and pushover
<tarzeau> or it's lagging
<tarzeau> (or the web interface is lagging)
<cjwatson> tarzeau: No it didn't - those are both in cosmic-proposed
<tarzeau> ah then the debian qa page lags
<cjwatson> tarzeau: I don't know which page that is, but it may very well track cosmic and not cosmic-proposed
<cjwatson> tarzeau: pushover failed to build everywhere: https://launchpad.net/ubuntu/+source/pushover/0.0.5+git20180420-2
<tarzeau> also possible, thanks for the info though
<tarzeau> interesting, also failed for me with manual building.. but i couldn't figure out why
<cjwatson> cloudcompare is actually in cosmic already.  it needed a no-change rebuild for a pdal soname change, and that's currently in cosmic-proposed
<cjwatson> so maybe whatever page this is in fact tracks bionic and hasn't been updated yet
<tarzeau> many thanks!
<cyphermox> !dmb ping!
<cyphermox> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<NoImNotNineVolt> regarding apache2, say i have a prod ubuntu 14.04 box running apache2 2.4.7 from the repos... and i have a 14.04 dev box, and built apache2 from source... shouldn't i have binary compatibility?
<NoImNotNineVolt> i take mod_autoindex.so from the build on my dev box, overwrite the prod box's copy, restart, segfault.
<infinity> NoImNotNineVolt: Define "built from source".  Which source?
<infinity> NoImNotNineVolt: The part where you're building it at all sort of implies you're not using the exact source used to build the packaged version (or you'd just use the packages...)
<NoImNotNineVolt> infinity: vanilla upstream
<NoImNotNineVolt> but indeed, that's a valid point.
<infinity> NoImNotNineVolt: Then no, that definitely won't provide binary compat.
<NoImNotNineVolt> so, i mean, i know i can just use a third party ppa to give me a newer apache2 in 14.04, and i'm still considering that as a fallback..
<infinity> Or you could upgrade to 16.04 or 18.04? :)
<NoImNotNineVolt> 16.04's apache2 still doesn't have the fix and 18.04 isn't approved for prod by my org yet.
<NoImNotNineVolt> but also i wouldn't mind learning something :P
<NoImNotNineVolt> e.g. how to shoehorn an updated mod_foo.so into an os-managed apache
<NoImNotNineVolt> (which is very hackish, i know)
<infinity> Well, if you know the patches required to fix mod_foo, the answer is to take the 14.04 sources, apply the patches to fix mod_foo, build, and go.
<NoImNotNineVolt> oh.
<NoImNotNineVolt> that makes too much sense :P
<infinity> Alternately, backport mod_foo wholesale into the 14.04 source tree, if it's still compatible.
<NoImNotNineVolt> thankfully, it's a tiny patch.
<infinity> The tiny cherrypick approach is certainly going to be the best option.
<NoImNotNineVolt> i guess my problem was starting with the wrong source tree.
<NoImNotNineVolt> instead of cherrypicking.
<NoImNotNineVolt> advice much appreciated.
<infinity> Also, is there a bug filed?  If it's a simple cherrypick and a clear verifiable bug, we could (and should) SRU it for the benefit of everyone who isn't you.
<infinity> (Welcome to being part of a community :))
<NoImNotNineVolt> so, debian won't backport it. not sure how you guys would feel. technically, it's a "new feature".
<NoImNotNineVolt> https://github.com/apache/httpd/commit/bd2ccbb8ef9b783117573cd9452e66b8c7d813fa#diff-e76e37d6c1f852034ce1989fb72c9e72
<infinity> NoImNotNineVolt: Hrm, new feature to restore old behaviour.  That's curiously borderline.
<NoImNotNineVolt> backstory: apache2 2.4.0 introduced an unexpected change in the date format of directory indexes generated by mod_autoindex.
<NoImNotNineVolt> exactly.
<NoImNotNineVolt> i could argue it either way. it's an optional bugfix exposed as a new feature :P
<NoImNotNineVolt> of course, for people depending on the traditional output (clients downstream are parsing our indexes, like idiots)
<infinity> NoImNotNineVolt: It's a pretty simple and easily reviewable patch, I don't think I'd be against it in principle.
<NoImNotNineVolt> the fact that preserving the traditional behavior is a "new feature" is no consolation :P
<NoImNotNineVolt> i'm really ignorant of how much the ubuntu maintainers do with a package like apache2 vs what upstream debian does.
<NoImNotNineVolt> i already discussed this with some debian folks and the consensus is that it would be wishlist priority, extremely unlikely to get backported.
<infinity> NoImNotNineVolt: It's muddy.  I mean, Ubuntu maintainers (ie: me, thom, daniels) were the ones who originally packaged apache2 for Debian.  Since then, participation shifts one direction or the other every once in a while.
<NoImNotNineVolt> in that case, brief aside: thank you so much for your work
<infinity> NoImNotNineVolt: But yeah, if we fixed this in an Ubuntu SRU, it certainly wouldn't get fixed in Debian as a result.  That may well still be worth it.
<NoImNotNineVolt> having dabbled in packaging, i salute you :P
<infinity> Ahh, it's the distant and hazy past at this point.
<NoImNotNineVolt> in any case, i doubt it's an issue affecting many people. i mean, it didn't get fixed til 2.4.26.
 * NoImNotNineVolt ends up arguing against himself somehow
<NoImNotNineVolt> by all means, if you guys want to backport it, don't let me talk you out of it :P
<infinity> NoImNotNineVolt: Heh.  Well, I have a slight bias as someone who does this for a living, but I despise maintaining local forks if I can avoid it.  Cause then I have to rebase on every security update, etc.
<infinity> NoImNotNineVolt: So, if a bug annoys me enough, I'll fix it for everyone.
<NoImNotNineVolt> yea, that's the other question i was going to ask.
<NoImNotNineVolt> what's apt/dpkg going to do to my .so? presumably it'll just clobber it on every security update, right?
<infinity> NoImNotNineVolt: And hey, if you fix it for everyone, you get your name in a changelog, which is spiffy, right?
<NoImNotNineVolt> but presumably something as hackish as a cron job to compare hashes and overwrite with my custom one as needed (and then apache restart) would do the trick, right?
<sarnold> you'd probably want to dpkg-hold the package in place and manage every update manually
<infinity> You can dpkg-divert the .so out of the way, so dpkg installs its copy to mod_foo.so-ermagerdno instead of clobbering yours.
<NoImNotNineVolt> ah, even cleaner.
<NoImNotNineVolt> mod_autoindex changes very rarely, and i don't mind just leaving my custom one in there.
<NoImNotNineVolt> awesome. thank you so much.
<infinity> Still, highly recommend getting it fixed in the distro.  You'll learn something new, be less afraid of doing the same thing in the future, and your infra won't live with hacky forks of packages.
<NoImNotNineVolt> hm.
<NoImNotNineVolt> so how would that work?
<NoImNotNineVolt> i don't know how to submit a pr for a backport :P
<infinity> File a bug, provide a patch.  If you want your name on it, provide a debdiff (and I'll work with you to get it uploaded), if you don't care whose name is on it, just a pointer to the commit is good enough for me to go ahead.
<infinity> But the most important part is a bug with a testcase.
<infinity> (This testcase is, thankfully, simple... enable autoindex, look at dates on a dir, change option, look at dates again, win)
<NoImNotNineVolt> this seems like a great easy way to dip my toes into learning a f/loss workflow
 * infinity runs off to hunt the elusive pizzabeast, back in a few.
<infinity> NoImNotNineVolt: Bug me this afternoon.  I need lunch. :)
 * infinity is always keen to turn a local hack into a community submission.
<NoImNotNineVolt> yea, i'll have to do this in the evening also. will need to spin up a clean vm for this on my own box.
<NoImNotNineVolt> employer is f/loss-friendly but better safe than sorry.
<NoImNotNineVolt> okay, i don't understand. trusty has apache2 2.4.7. i have trusty. i `apt-get source apache2`. i end up with source for 2.4.10. am i losing my mind?
<Faux> Backports has 2.4.10?
<tumbleweed> IIRC apt-get source always gets the highest version available, ignoring pin priorities
<NoImNotNineVolt> yea, indeed, i'm an idiot.
<NoImNotNineVolt> so, should i target trusty-backports or trusty?
<NoImNotNineVolt> (regarding backporting a "new feature" that exposes a user option to fix a bug introduced in 2.4.0)
<NoImNotNineVolt> (which didn't get added until 2.4.26)
<NoImNotNineVolt> i'll just work against trusty's 2.4.7 for now.
<mwhudson> morning
<nacc> NoImNotNineVolt: infinity: you can do a git MP now, fwiw, and in theory a server team member can review it and sponsor
<NoImNotNineVolt> https://github.com/apache/httpd/commit/bd2ccbb8ef9b783117573cd9452e66b8c7d813fa
<NoImNotNineVolt> that's the commit i'm trying to backport. nice and easy.
<NoImNotNineVolt> but i figure this is a good opportunity for me to figure out how the whole "contribution" workflow works :P
<nacc> NoImNotNineVolt: snap install git-ubuntu; git ubuntu clone apache2; cd apache2; git checkout pkg/ubuntu/trusty-devel; git remote add upstream https://github.com/apache/httpd.git; git cherry-pick bd2ccbb8ef9b783117573cd9452e66b8c7d813fa; dpkg-source --commit`
<nacc> :)
<nacc> err, should be a `git fetch upstream` before the cherry-pik
<NoImNotNineVolt> oh that's easier than this whole http://packaging.ubuntu.com/html/fixing-a-bug.html thing
<nacc> yes
<nacc> I can explain the bits there, if you want
<nacc> but the above is the one-liner (almost)
<NoImNotNineVolt> .. snap?
<NoImNotNineVolt> SNAP - Semi-HMM-based Nucleic Acid Parser (version 2006-07-28)
<nacc> NoImNotNineVolt: https://snapcraft.io/
<nacc> NoImNotNineVolt: no, the packaging format (enabled by default in Ubuntu these days)
<nacc> NoImNotNineVolt: git-ubuntu is shipped as a snap. You can also use git directly, but git-ubuntu does some niceness for you (e.g. clone a srcpkg as above, handle building in a LXD, etc.)
<NoImNotNineVolt> oh god. i think i'm installing systemd :|
<nacc> NoImNotNineVolt: are you not on Ubuntu already?
<NoImNotNineVolt> trusty.
<NoImNotNineVolt> this is for 14.04, remember? :P
 * NoImNotNineVolt sighs and blows up that vm
<nacc> NoImNotNineVolt: you don't need to be on 14.04 to develop for 14.04
<nacc> NoImNotNineVolt: https://code.launchpad.net/ubuntu/+source/apache2/+git
<nacc> NoImNotNineVolt: if you want to use git directly
<nacc> NoImNotNineVolt: but YMMV
<NoImNotNineVolt> i was having enough trouble getting binary-compatibility building on the same os as the target.
<nacc> NoImNotNineVolt: then you're bulding it wrong :)
<nacc> NoImNotNineVolt: as you said, you were building it in the source, not as a package
<NoImNotNineVolt> indeed. no need to throw extra hurdles in my path :P
<nacc> NoImNotNineVolt: use a PPA
<NoImNotNineVolt> i actually built a deb and pulled the so out
<NoImNotNineVolt> greatly prefer to avoid a ppa, though that is my absolute fallback
<nacc> that seems ... weird
<nacc> NoImNotNineVolt: why?
<NoImNotNineVolt> requires a long conversation with cto
<nacc> NoImNotNineVolt: if you actually want to contribute to Ubuntu, you have to eventually test a package
<NoImNotNineVolt> that's fine.
<NoImNotNineVolt> that's not the same thing as using a ppa in production
<nacc> I never said that
<nacc> I don't really care about your company :)
<nacc> I'm speaking from the Ubuntu developer side
<nacc> you, as a single user, can set up a PPA, build your package there, and can test from there
<nacc> I would never suggest doing that for production
<NoImNotNineVolt> ah, understood.
<nacc> :)
<NoImNotNineVolt> i thought you meant use a third party ppa. i found a good one with 2.4.33 for trusty.
<nacc> no, that would be a bad idea in production, imo
<NoImNotNineVolt> OndÅej SurÃ½ has a ppa.
<NoImNotNineVolt> seems trustworthy, but still, that's my absolute last ditch option.
<NoImNotNineVolt> best solution would be to get the backport into 14.04 eventually, but in the meantime i've gotta get a .so i can shoehorn into my existing server.
<NoImNotNineVolt> clients are yelling :P
<NoImNotNineVolt> but thanks for the git tip. that's much easier for me.
#ubuntu-devel 2018-05-08
<NoImNotNineVolt> okay, so, it still segfaults, and ldd says: https://bpaste.net/show/2e17f1127688
<NoImNotNineVolt> but i'm guessing that's not a good thing.
<NoImNotNineVolt> weird. building on 14.04, ala https://bpaste.net/show/fe1a425ea23b
<NoImNotNineVolt> i guess i should try shoehorning it into a clean 14.04 vm with vanilla apache2. maybe our prod vm is stupid because it's provisioned by our IT guy.
 * NoImNotNineVolt sighs
<NoImNotNineVolt> thanks again for the help building. pretty confident in the process now.
<NoImNotNineVolt> will bug you about how backports work once i get this tested.
<Lin-Buo-Ren> I would like to request to review a patch on https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1751850
<ubottu> Launchpad bug 1751850 in grub2-signed (Ubuntu) "package grub-efi-amd64-signed 1.66.17+2.02~beta2-36ubuntu3.17 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed]
<Lin-Buo-Ren> The package's post-installation program assumes that the user has EFI variant of GRUB installed, which is not always true.
<Lin-Buo-Ren> A user could install PC variant of GRUB while still install grub-efi-amd64-bin, grub-efi-amd64-signed and shim-signed to keep UEFI bootability
<Lin-Buo-Ren> As a result the post installation script should always specify the --target platform they're installing, and even allow non-fatal errors where efivarfs is not always available(i.e. the system is not run in UEFI bootmode)
<Lin-Buo-Ren> s/non-fatal errors/non-fatal efibootmgr errors/
<Lin-Buo-Ren> The post-installation script in the shim-signed package has the same issue
<rbasak> Was there some debian/control syntax change permitting trailing commas in Build-Depends etc?
<rbasak> It seems to work now. I swear it didn't before, but I can't find any documentation about a change.
<Laney> It's worked for some years at least
<Laney> they used to insist on it for daily landing packages back in the day
<tjaalton> who should own bug 1746710?
<ubottu> bug 1746710 in snapcraft (Ubuntu) "Snap creates redundant duplicate directories in home folder" [High,Confirmed] https://launchpad.net/bugs/1746710
<tjaalton> it's a really annoying bug
<NoImNotNineVolt> okay, it's official, my desire to have my name on that patch pales in comparison to my desire to have it backported :P
<NoImNotNineVolt> i think PIE may be preventing me from just sticking my .so into an existing apache2 deployment.
<joelkraehemann> hi all
<joelkraehemann> I have just reported https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1769958
<ubottu> Launchpad bug 1769958 in gsequencer (Ubuntu) "broken clipboard" [Undecided,New]
<joelkraehemann> the patch is provided, the clipboard messes with the object organization
* infinity changed the topic of #ubuntu-devel to: Archive: open | 18.04 released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | #ubuntu-app-devel for app development on Ubuntu
#ubuntu-devel 2018-05-09
<RAOF> mvo: Hey there! Are you aware of the autopkgtest failures blocking snapd 2.32.5 from migrating to -updates?
<cpaelzer> doko: I'd be impressed, but if there is any chance you remember why seabios carries this since vivid
<cpaelzer> "* Build with -fgnu89-inline for GCC 5 (doko)"
<cpaelzer> what I wonder is was that just an FTBFS (then we can drop) or soemthing else?
<doko> cpaelzer: most likely, change of the inline sementics with c99, afaik
<doko> or was it c11?
<cpaelzer> doko: no c11, but ok
<cpaelzer> I checked the build and the result LGTM
<cpaelzer> I'll drop the delta this cycle then
<cpaelzer> thanks for confirming that it most likely was just an FTBFS
<jbicha> LocutusOfBorg: does https://github.com/ubuntu/gnome-shell-extension-appindicator support libayatana-appindicator ?
<LocutusOfBorg> jbicha, ayatana is a drop-in replacement
<LocutusOfBorg> just need to tweak the include file and link a different library name
<LocutusOfBorg> this is what I get with all the patches
<LocutusOfBorg> anyway, #debian-devel and sunveawer (IIRC) will help you with a patch if you need one
<LocutusOfBorg> but again, I'm trying to get ayatana into main
<LocutusOfBorg> I don't care right now about what in universe still don't use it
<jbicha> gnome-shell-extension-appindicator is in main and it's very important that it works :)
<jbicha> slangasek or anyone from TB: could you handle bug 1769694?
<ubottu> bug 1769694 in ubuntu-community "Please update DMB members" [Undecided,New] https://launchpad.net/bugs/1769694
<Laney> is there something special that you need to do to move from a M-A same package to an arch: all transitional?
<Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1768541
<ubottu> Launchpad bug 1768541 in gnome-keyring (Ubuntu) "package libp11-kit-gnome-keyring 3.20.1-1ubuntu1 failed to install/upgrade: libp11-kit-gnome-keyring:all 3.28.0.2-1ubuntu1 (Multi-Arch: no) is not co-installable with libp11-kit-gnome-keyring which has multiple installed instances" [Undecided,Confirmed]
<Laney> I can't make it happen but evidently there is some problem here
<Laney> not sure making it MA: foreign per my latest suggestion is right
<infinity> Laney: You can't move from MA:same to arch:all.
<infinity> Laney: You need to use an MA:same transitional as well.
<infinity> Laney: arch:all by definition can only have one version/copy installed, so your transitional upgrades on the primary arch, and ends up conflicting out any other arch versions of the old package.
<infinity> Laney: Ran into this same issue with e2fslibs when Ted tried to do what you did.  Went very poorly until I fixed it. :P
<Laney> infinity: I didn't do it, I'm just trying to clean up the mess
<Laney> But thanks
<infinity> Laney: Righto.
<infinity> Laney: I copy-and-pasted the above to the bug as well.
<Laney> ta
<infinity> Laney: Thankfully, the fix is trivial.
<Laney> Yeah, looks fine.
<Laney> I never managed to reproduce it though when installing multiple arches and dist-upgrading
<Laney> Probably need something that depends on it on both arches, or something like that
<Laney> hmm, this is part of the delta
<Laney> I suppose the transitional can be dropped entirely in cosmic
<infinity> Laney: Fix in bionic and drop in cosmic sounds lovely indeed.
<infinity> Laney: And yes, it only explodes if something else deps on it.  Which is why it was so trivial to reproduce in e2fsprogs/e2fslibs.
<Laney> Trying to get a reproducer.
<Laney> Now I'm yak shaving because I have about 1 byte free and can't start a new container.
<Laney> (big SSDs are cheap these days, yes?)
<infinity> Cheap, ish.
<infinity> Well, and big, ish.
<nacc> can anyone explain to me why the 'unstable' link here is the 'stable' version per rmadison? https://ci.debian.net/packages/p/php-horde-activesync/
<infinity> nacc: Because the last time it was tested in "unstable" was 2017-03-17
<ginggs> nacc: i asked in #debci, but it looks to me like it stopped testing unstable in march
<elbrus> nacc: click on the link an you see that the package hasn't been tested
<infinity> nacc: Debian recently rejiggered how and when they run autopkgtests (moving/moved to britney triggers now), and I suspect the results pages need some love.
<elbrus> like ginggs says
<elbrus> that happens sometimes
<elbrus> I don't know why yet
 * elbrus will trigger a new one, usually debci-batch will pick it up again
<nacc> elbrus: infinity: ginggs thanks! i have stuff i need to send to Debian that will fix most of the php* stuff for phpunit6 compt
<nacc> but was a bit confused by that output :)
<elbrus> nacc: next time feel free to join #debci on oftc with your questions regarding ci.d.n
 * elbrus wasn't reading here
<nacc> elbrus: sorry about that, will do :)
<nacc> elbrus: was a more casual, 'does infinity know what's going on and is he listening' kind of thing :)
<infinity> nacc: Turns out I only sort of know what's going on, elbrus is definitely more authoritative on Debian's debci instance. :)
<nacc> infinity: heh
#ubuntu-devel 2018-05-10
<Unit193> LocutusOfBorg: Thanks, mate!
<StevenK> slangasek: When you have a second, can you poke at https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1573982 ?
<ubottu> Launchpad bug 1573982 in lvm2 (Ubuntu) "LVM boot problem - volumes not activated after upgrade to Xenial" [Undecided,Confirmed]
<LocutusOfBorg> Unit193, I don't know why, but you are welcome :)
<Unit193> Irssi.
<Unit193> LP never notified me, so didn't notice.
<LocutusOfBorg> :)
<LocutusOfBorg> thanks tsimonq2 :)
<ahasenack> hi, can someone please accept the bionic task for me for this bug? https://bugs.launchpad.net/debian/+source/postfix/+bug/1753470
<ubottu> Launchpad bug 1753470 in postfix (Ubuntu) "Postconf segfaults every 5 minutes" [Low,Fix released]
<StevenK> ahasenack: Done
<ahasenack> StevenK: thanks
<rbasak> ahasenack is getting https://lintian.debian.org/tags/hardening-no-bindnow.html for a proposed new package. On review, I asked why, if hardening=+bindnow is needed, why it isn't already default in dpkg-buildflags. What would be best practice here? For all Ubuntu-specific packages to individually maintain a hardening=+bindnow in debian/rules, for Ubuntu to adjust dpkg-buildflags when we want everything
<rbasak> to do it, or to just ignore the lintian note?
<rbasak> https://wiki.ubuntu.com/Security/Features#bindnow seems relevant
<rbasak> That suggests to me that it should be on by default on amd64 already?
<rbasak> On Bionic, I have to specify hardening=+bindnow to get -Wl,-z,now in LDFLAGS
<jbicha> rbasak: I use   export DEB_BUILD_MAINT_OPTIONS = hardening=+all   in many of my packages
<jbicha> even with that, I get the lintian warning for some of the packages
<rbasak> I understand that in Debian the general approach is one where maintainers slowly opt in to a new thing.
<rbasak> In Ubuntu though, I'm not sure that makes sense.
<rbasak> If project-wide we decide to enable something, we can just do it across some set of packages.
<rbasak> And that's how hardening flags have been enabled over time in Ubuntu, AIUI.
<sbeattie> rbasak: indeed, our gcc is set to enable bind-now by default if its being built with pie. I have to step into a meeting in a little bit, but can you point me at ahasenack's code?
<ahasenack> sbeattie: https://git.launchpad.net/~ahasenack/ubuntu/+source/ndctl/tree/debian/rules
<ahasenack> and https://git.launchpad.net/~ahasenack/ubuntu/+source/pmdk/tree/debian/rules
<ahasenack> upstream is https://github.com/pmem/pmdk and https://github.com/pmem/ndctl
<jbicha> sbeattie: it doesn't seem like it works, for instance, lintian says that bindnow isn't used if you build https://salsa.debian.org/gnome-team/gnome-characters after
<jbicha> commenting out the hardening line in debian/rules
<ahasenack> yeah, same for me
<ahasenack> I removed the line that added hardening=+all and got the lintian warning
<sbeattie> ahasenack: how are you building the package? I'm not that proficient with gpb
<ahasenack> checkout that branch (master), sudo apt-get builddep ./, dpkg-buildpackage -uc -us
<ahasenack> you'll need the orig tarball, it's the upstream release from github
<sbeattie> ahasenack: ah, okay
<rbasak> sbeattie: if it helps, I think that the build uses dpkg-buildflags, which should show you everything that's going on wrt. flags including interpreting DEB_BUILD_MAINT_OPTIONS=hardening=+foo etc
<rbasak> If that's true, then you should be able to experiment just with that and not the entire build environments I think.
<ahasenack> sbeattie: pmdk takes a while to build, ndctl is much faster
<sbeattie> ahasenack: thanks
 * sbeattie vanishes into a meeting black hole
 * ahasenack -> lunch
<ahasenack> sbeattie: oh, I forgot, there is a ppa which you might find more convenient: ppa:canonical-server/nvdimm it has both
<sbeattie> ahasenack: are you seeing this with bionic builds or cosmic builds?
<ahasenack> bionic, haven't tried cosmic yet, but will
<sbeattie> okay, I'm not able to reproduce in a local bionic schroot, rebuilding with the DEB_BUILD_MAINT_OPTIONS line commented out entirely gives me a daxctl binary that hardening-check tells me is set up with immediate binding.
<sbeattie> how is lintian being invoked?
<sbeattie> (I don't see it in my ndctl buildlog)
<ahasenack> sbeattie: lintian -iI --pedantic $@
<ahasenack> it complains about the libraries
<sbeattie> ahasenack: ah okay, I see that.
<jbicha> infinity: could you handle bug 1769694?
<ubottu> bug 1769694 in ubuntu-community "Please update DMB members" [Undecided,New] https://launchpad.net/bugs/1769694
<infinity> jbicha: Yep, on it.
<infinity> jbicha: Hrm, the bug links to the IRC meeting, but I don't actually see the election results anywhere to confirm. :P
<infinity> jbicha: And the bug fails to mention what's up with the other two expiring members.  Ben and Brian stepping down tomorrow?
<jbicha> yes
<jbicha> were you looking for https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_b99fd5c7c9572192 ?
<infinity> jbicha: Exactly that, yes.  Thanks.
<infinity> jbicha: Oh, I see, 5 slots and 5 candidates.  "Democracy!"
<jbicha> NOTA never wins anything fun :( Maybe next time
<infinity> jbicha: I should have gotten around to expressing concern about non-core-devs on the DMB before the election happened.
<infinity> jbicha: Oh well, now I just get to pressure tsimonq2 to up his game and get core-deve.
<infinity> s/deve/dev/
<tsimonq2> infinity: Man, I've been trying.
<tsimonq2> I did send a signed statement to the DMB saying I won't review applications for  people seeking upload access I  don't have.
<tsimonq2> But I totally get your point.
<infinity> jbicha: https://launchpad.net/~developer-membership-board/+members Look right to you before I close the bug?
<infinity> tsimonq2: Yeah, and I appreciate that you did that, but that also makes it harder to meet quorum for core-dev applications if you have to recuse yourself from those.
<tsimonq2> infinity: True.
<jbicha> infinity: I asked about that issue a year ago https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2017-May/thread.html
<infinity> tsimonq2: (plus, you still have the keys to various kingdoms, signed statement or no)
<jbicha> infinity: yes that looks fine. Feel free to close the bug
<infinity> jbicha: You guys might want to discuss voluntarily mangling some of your terms, if the intent is to rotate slots with coninuity (US senate style).
<infinity> jbicha: Since there are 5 expiring at the same time, and 2 in the other batch.  A bit weird.
<infinity> jbicha: And the 2019 batch should, ideally, expire in May, not Sep.
<tsimonq2> infinity: Indeed, but by being voted onto the DMB, enough Ubuntu Developers trust me with those keys to not do anything malicious; I appreciate that. But I'll keep my word and not press buttons I shouldn't be pressing. Feel free to remove me from whatever team you want if I break that.
<tsimonq2> infinity: And yes, pressure me to become a Core Developer. ;)
<infinity> tsimonq2: Yeah, I'm not actually concerned, it's just a principle thing.  So, let's get you on your way to core-dev, so when I suggest that DMB members must be core-devs, the current DMB already conforms. :P
<jbicha> infinity: we'll just nominate you to sit on the DMB then if we can't find enough enthusiastic core dev volunteers to fill the board :)
<infinity> jbicha: Tried that.  I sucked at caring enough to attend meetings and stepped down.
<infinity> Though, a big part of that was the calendar being perpetually wrong during my entire tenure.
<tsimonq2> infinity: Alright. I did do an sbuild merge, slang2 merge, brltty merge, and a transmission sync in the past day or so. If you have more things to do, feel free to throw them at me, otherwise I'll stick to the strategy of stealing merges (with consent) by scanning merges.u.c for good candidates.
<infinity> And, hilariously, fixed shortly after, but without removing me from the invite list.
<infinity> tsimonq2: Talk to your fellow DMB members for their perspective, but I prefer to see bugfixes over merges.  Merges don't often demonstrate any real understanding of complexity (I mean, except when they do, but the complex ones are rare, most are so mechanically simple that MoM can spit out the result)
<tsimonq2> infinity: Good point.
<tsimonq2> infinity: Can you please press buttons so I can be subscribed to the DMB mailing list?
<tsimonq2> (I submitted a subscription request.)
<infinity> jbicha: In fact, I appear to still be on the DMB meeting invite list.  Please clean that up. ;)
<jbicha> infinity: more details please :)
<infinity> jbicha: Fridge calendar DMB meeting.  List of invites does not match current board.
<infinity> tsimonq2: I don't moderate that list.  At least, I don't think I do.  If I do, I do it really poorly.
<tsimonq2> infinity: The TB moderates it. :P
<infinity> Yeah, that's not how mailman works.
<jbicha> infinity: sil2100 owns that calendar appt
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> infinity: The footer of lists.u.c/developer-membership-board disagrees.
<infinity> tsimonq2: Yes, that just means that's who admin notifications get sent to.
<infinity> tsimonq2: Still need the admin password to actually get in and do stuff.  And I don't think I have that one.  That's all I'm saying. :P
<tsimonq2> infinity: Ah, right.
<jbicha> infinity: are you able to moderate my u-devel-announce email re: DMB Election Results ?
<infinity> jbicha: That, I can do.
<infinity> jbicha: And done.
<tsimonq2> #ubuntu-flavors is now a thing, fyi.
<Unit193> To what end?
<tsimonq2> Unit193: Hm?
<tsimonq2> It was in response to Kev's ML thread.
<valorie> to what end? we need moar *buntu chans, obv
<tsimonq2> hehe
<sarnold> more channels to <3 each other in :)
<tsimonq2> ^
<tsimonq2> And really, that's the point of this.
<tsimonq2> So flavors can really start to communicate better.
<Unit193> So, no purpose..?
<tsimonq2> Unit193: :P
<wxl> what's the point of you?
<sarnold> the '3' looks pretty pointy...
<wxl> what's the point of any of this?
 * wxl cries
<wxl> oh
<tsimonq2> hah
<Unit193> Also what tsimonq2 said a second before I did was more the answer I was looking for, "A place to check on issues that may affect multiple flavors" what the goal of the channel was.  Or, if it's some cross flavor effort for the new ubiquity re-write, or calamares, or what.
<tsimonq2> Just in general, a place for coordinated albeit informal discussion among flavors that doesn't fit here or in -release, I think.
<tsimonq2> Unit193: Anyway, can I consider this checking the "let the IRCC know" box? :)
<Unit193> ACL looks about right, no logbot so no entry message.  So I'd say good enough.
<tsimonq2> Alright.
#ubuntu-devel 2018-05-11
<mattfly> hello
<mattfly> https://bugs.launchpad.net/ubuntu/+source/uswsusp/+bug/1770491
<ubottu> Launchpad bug 1770491 in uswsusp (Ubuntu) "Hibernation doesnt work after installing nvidia-384(s2disk hangs)" [Undecided,New]
<mattfly> installing nvidia drivers = no more hibernation to me (aka s2disk hangs while trying to hibernate)
<mattfly> does it have something to do with meltdown patches?
<mattfly> s/does it/can it/
<tarzeau> i'm not sure, if i'm right here: we run ubuntu for linux workstations, and we manage them centrally, users has no installed: network-manager, nor gnome-software store, nor aptdeamon gui update manager
<tarzeau> yet we want them be able to set background image, i.e have gnome-control-center installed (which has depends on the three things mentioned above)
<tarzeau> what worked for us is: rebuild gnome-control-center with the depends ripped away. i'm not sure if that'd be useful for others too
<tarzeau> in numbers: 33 bionic, 142 xenial machines (and another 10 trusty)
<jpleau> tarzeau: nice to know it works, I was wondering doing that myself for my own machine (disabling dependencies I will never use like network-manager and friends so I can uninstall them)
<ScottE> I came across an interesting gcc regression that can result in corrupt pointers when code is compiled with -O2. Reproducable on xenial and bionic (and likely other versions). Simple testcase attached here: https://bugs.launchpad.net/ubuntu/+source/gcc-7/+bug/1770676
<ubottu> Launchpad bug 1770676 in gcc-7 (Ubuntu) "gcc optimizer bug" [Undecided,New]
<rbasak> ScottE: interesting. Though that could be an issue in libc rather than gcc.
<rbasak> (depending on how it's defined)
<ScottE> It could be, except that it only occurs when compiling the testcase with -O2 - libc would be the same in either case? Hard to say though, sometimes these sort of issues happen in a different place than where the symptom is.
<rbasak> libc could be depending on undefined behaviour.
<rbasak> I'm not familiar enough with the many levels of indirection libc function definitions go through to be able to tell quickly.
<ScottE> It could be, although on xenial, if I reproduce the original issue I was chasing (with cronolog), it doesn't surface with the cronolog binary in xenial until I recompile cronolog. Still not definitive, though...
<ScottE> I'll add the cronolog testcase to that bug, too - it's easy to reproduce there too
<jbicha> doko: could you merge ilmbase? it's needed by openexr
<jbicha> doko: maybe a compromise with Debian would be to only use a symbols file for amd64 where it's more easily maintained?
<doko> jbicha: ilmbase belongs to the desktop team. and no, dropping the symbols file would invalidate the constraints for being in main
<jbicha> doko: could Foundations please take ilmbase? it's only in main because of imagemagick (via openexr) which is Foundations
<jbicha> I didn't say drop the symbols file, I said only use it on amd64. Wouldn't that be sufficient to tell if there was an API break?
<jbicha> I imagine there's several C++ libraries in main that don't use symbols files
<jbicha> symbols files aren't mentioned as a strict requirement at https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<jbicha> so how about I just sync ilmbase now to fix openexr and you can deal with symbols files later if it's important enough to you?
<doko> jbicha: absolutely no. please properly merge
<doko> jbicha: "I imagine there's several C++ libraries in main": sorry, I don't think your imaginations are relevant for main inclusion. and I hate your exaggerations and unprecise statements, like "hundreds of runtime failures for missing dependencies".  this is a technical channel, not an advocating channel
<jbicha> it sounds like you're referring to Debian bug 893755 now. I think it was a correct statement at the time since your change broke glib for instance
<ubottu> Debian bug 893755 in src:python3.6 "python3.6: Dropped python3-distutils dependency makes hundreds of packages FTBFS" [Serious,Open] http://bugs.debian.org/893755
#ubuntu-devel 2018-05-12
<tarzeau> jpleau: gnome-control-center even handles network-manager is not around, display a message, rest works all fine
<jbicha> doko: your link-grammar upload looks really wrong, you know :(
<jbicha> isn't it a regression in python3.6?
<doko> no
<jbicha> can you explain why the behavior changed then?
#ubuntu-devel 2018-05-13
<kashem> which firewall i can use?
<sbeattie> sudo -l
<sbeattie> bah
<mdeslaur> sbeattie is not in the sudoers file.  This incident will be reported.
<ktosiek> Hi! How do I build a package from source in a chroot? I want to test a patch for gvfs
<ktosiek> gbp buildpackage --git-pbuilder --git-dist=bionic --git-ignore-new doesn't even try to use the cowbuilder environment
<jbicha> honestly, sbuild is a lot more popular than pbuilder/cowbuilder now
<ktosiek> thanks, I'll look into that
<jbicha> or you could use --git-builder=" " to specify your exact build commands
<ktosiek> but how do I make cowbuilder use a chroot?
<ktosiek> I mean, it should install the build dependencies itself, right? Not just complain that they are not installed in the host OS?
<ktosiek> sbuild dies wit: dh: unable to load addon gnome: Can't locate Debian/Debhelper/Sequence/gnome.pm
<jbicha> I haven't used pbuilder in several years so I can't help there
<jbicha> by default, the build tries to run the clean step, you can either add   --no-clean-source  to your sbuild command or install gnome-pkg-tools
<ktosiek> did the latter, now it complains about source changes :-)
<jbicha> other packages have other helper tools, but gnome-pkg-tools is used by nearly all the GNOME related stuff
<jbicha> that's strange, are you using the official VCS for gvfs?
<kashem> is it possible to know if anyone pinging me?plz...Help
<jbicha> I suggest starting with:  gbp clone https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gvfs
<jbicha> kashem: this is not a user support channel, try #ubuntu or https://askubuntu.com/
<ktosiek> I think so, I've cloned the one suggested by `apt source gvfs`
<jbicha> ktosiek: please pastebin the exact "complaint"
<ktosiek> it's doing something now, after removing the source directory and starting again with `gbp clone`
<ktosiek> it's building now, thank you!
<acheronuk> jbicha: did the rebuilds you requested in #kubuntu-devel
<acheronuk> wider issues. in your hands :P
#ubuntu-devel 2019-05-06
<sil2100> oSoMoN: hey! Could LP: #1822839 be SRUified? It's included in the changelog of the libreoffice SRU
<ubottu> Launchpad bug 1822839 in libreoffice (Ubuntu Bionic) "LibreOffice doesn't detect JVM because of unexpected java.vendor property value" [Undecided,Triaged] https://launchpad.net/bugs/1822839
<oSoMoN> sil2100, yes, of course! marcustomlinson, can you update the description of the bug to make it SRU-compliant ?
<marcustomlinson> sil2100, oSoMoN: sure, bank holiday today though, will do tomorrow
<sil2100> marcustomlinson, oSoMoN: thanks guys o/
<Eickmeyer> Does anybody know if there is a reason that exfat-fuse isn't included by default? The question came up in #ubuntustudio-devel as to if we should include it in the future.
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/exfat-utils/+bug/1649537
<ubottu> Launchpad bug 1649537 in fuse-exfat (Ubuntu) "[MIR] exfat-utils and fuse-exfat" [Undecided,Won't fix]
<Eickmeyer> cjwatson: Thanks!
<tsimonq2> rbasak, bdmurray: What's the SRU team stance on flavors SRUing their metapackage to add a dependency?
<tsimonq2> Does that follow the same process and such?
<bdmurray> yes
<tsimonq2> Sounds good, thanks.
<Eickmeyer> Still looking for someone to put on their MOTU hat to sponsor this guy: #1827288
<Eickmeyer> bug 1827288
<ubottu> bug 1827288 in Ubuntu Studio "[Needs Packaging] LSP-Plugins for Eoan" [Medium,In progress] https://launchpad.net/bugs/1827288
#ubuntu-devel 2019-05-07
<pieq> Hi!
<pieq> copy-pasting something I just wrote on #ubuntu-desktop:
<pieq> I was playing with the grub menu configuration today and I was wondering why we don't have something a little bit more fancy in the live USB menu and later, if for instance the user has a dual boot or something like this
<seb128> pieq, what sort of fancyness?
<pieq> currently, it's very bare-bone (white text on black bacground) â https://www.tecmint.com/wp-content/uploads/2018/05/Select-Install-Ubuntu.png
<pieq> This is probably quite intimidating for newcomers who might be trying the live USB, and it's not super nice either after you installed Ubuntu as dual boot with your Windows partition, for instance
<pieq> It's possible to achieve nicer results (e.g. https://www.gnome-look.org/p/1009236/). I tried this theme on an install with Secure Boot, UEFI and a 4k display and it was not too bad
<seb128> that would be nice indeed
<seb128> I guess it's mainly a priority/ressource allocation issue if we don't get to work on such changes
<seb128> but it could be lead by anyone interested, we would probably find time to do reviews if someone was working on it and proposing the changes
<pieq> OK I see. I was wondering if there was big blocker... cause for instance I remember the "legacy" boot menu is very advanced compared to a default GRUB2 screen: https://i.stack.imgur.com/TTC70.png
<seb128> there might be technical blockers, I'm not really familiar with grub and not the best placed to comment about that
<seb128> but if you say the theming works with secure boot/uefi then it's encouraging
<pieq> I guess a problem is to handle both regular screen resolutions and 4k+ screens
<seb128> the syslinux menu you just mentioned is still used, but not compatible with secure boot afaik
<seb128> well, 4k is another topic
<pieq> seb128, indeed! I'll dig a bit more and maybe prepare something. Where should I discuss this? Maybe a mailing list or forum would be more appropriate?
<seb128> pieq, https://community.ubuntu.com/ or https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
<pieq> <seb128> the syslinux menu you just mentioned is still used, but not compatible with secure boot afaik â that's probably the thing I heard, but I don't have the details on why it doesn't work. Do you know where/who I could annoy with my questions? :)
<pieq> seb128, merci !
<seb128> de rien!
<LocutusOfBorg> seb128, hello, do you remember why you patched gambas3 for new poppler?
<LocutusOfBorg> according to this: http://launchpadlibrarian.net/405787223/gambas3_3.11.4-6_3.12.1-1.diff.gz gambas3 was already fine, I dropped your patch and everything still works
<LocutusOfBorg> #if POPPLER_VERSION_0_72 #define getCString c_str #endif
<LocutusOfBorg> I don't like to remove patches without contacting the maintainer first, maybe you have good reasons for it, even if I can't find them
<seb128> LocutusOfBorg, " I don't like to remove patches without contacting the maintainer first" ... seems like you did though? https://launchpad.net/ubuntu/+source/gambas3/3.13.0-1~exp3~build1
<LocutusOfBorg> seb128, yes, because the patch FTBFS in Debian...
<seb128> I was just pointing out that your statement was incorrect, you didn't ask first :p
<LocutusOfBorg> seb128, sure! if you want to see the result of your patch, this is one: https://buildd.debian.org/status/fetch.php?pkg=gambas3&arch=s390x&ver=3.13.0-1%7Eexp1&stamp=1557160666&raw=0
<LocutusOfBorg> when I debugged the issue, I found that the "patched" version should have built without patch at all...
<LocutusOfBorg> while the upstream approach (added in 3.12.1) seems compatible with poppler from debian/ubuntu old and new versions
<LocutusOfBorg> I tried to see if you attempted a "no change rebuild" that failed before the ubuntu1 version and I didn't find one
<LocutusOfBorg> neither a ppa, so I wild guessed "Seb probably grepped for that getCString and patched without bothering to see a build failure, because it was evident that the old api was not usable anymore" :)
<seb128> LocutusOfBorg, it failed to build
<seb128> LocutusOfBorg, 3.12.2 was missing https://gitlab.com/gambas/gambas/commit/a03ffa0c
<seb128> so the issue is fixed in 3.13.0 in a different way, you can drop the patch with that version
<LocutusOfBorg> I see, thanks
<LocutusOfBorg> of course config.h was making all the #ifdefs useless :p
<LocutusOfBorg> thanks for pointing it out! so, yeah for dropping it
<LocutusOfBorg> while we are talking... a new poppler is out!
 * LocutusOfBorg runs away
<seb128> haha
<LocutusOfBorg> seb128, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3714/+packages I prepared new poppler here, lets see if we can do a quick transition :)
<seb128> LocutusOfBorg, haha, good luck :p
<seb128> there is no such thing with poppler sadely :/
<LocutusOfBorg> I did look at the debdiff, looks like no deprecated foobar
<seb128> I would wait a bit, we don't need to update poppler that ealier in the cycle and it's quite likely we get another update with a soname bump before long
<seb128> yeah
<seb128> still you end up needing to rebuild and migrate libreoffice and some kde bits
<seb128> which usually manage to cross another transition
<LocutusOfBorg> actually this is the first time since eoan opening that it wouldn't entangle transitions
<LocutusOfBorg> kde is all migrated, libreoffice is in release pocket
<LocutusOfBorg> this is why it might be a quick one :) (if bileto is ok to land)
<rbasak> vorlon: sorry about the iptables-persistent bionic unapproved upload cruft. I usually review my own uploads with debdiffs. I must have missed it.
<rbasak> (and thank you for fixing up)
<Unit193> tsimonq2: There is a *lot* of noise in your popcon merge, https://ubuntudiff.debian.net/q/package/popularity-contest
<seb128> ahasenack, re bug #1827467, I usually set "fix commited" for things that has fixed upstream, it helps in spotting later things to close when upload the next version or things that have a patch to cherry pick
<ubottu> bug 1827467 in psmisc (Ubuntu) "killall does not find processes with names longer than 15" [Low,Triaged] https://launchpad.net/bugs/1827467
<seb128> ahasenack, that workflow might be specific to me/desktop and un-usual for others though, sorry about the confusion
<seb128> that are fixed*
<marcustomlinson> sil2100: hey! LP: #1822839 has been SRUified
<ubottu> Launchpad bug 1822839 in libreoffice (Ubuntu Bionic) "LibreOffice doesn't detect JVM because of unexpected java.vendor property value" [Undecided,Triaged] https://launchpad.net/bugs/1822839
<Unit193> tsimonq2: Additionally, that same upload had a change not noted in the changelog switching the submit url to https, introducing LP 1822672 and effectivly breaking popularity-contest for Ubuntu.  Please fix.
<ubottu> Launchpad bug 1822672 in popularity-contest (Ubuntu) "popularity-contest is probably broken" [Medium,New] https://launchpad.net/bugs/1822672
<sil2100> marcustomlinson: excellent, thanks! I'll try looking at it again later today
<LocutusOfBorg> seb128, I suspect gst-plugins-{good,bad}1.0 and on your radar? I retried gst-plugin-base1.0 a few seconds ago, it should unblock some bd-uninstallabilities
<seb128> LocutusOfBorg, yes they are, also no need to retry things that are depwaiting
<LocutusOfBorg> this is true, but the automatic retry is toooo slow :P
<LocutusOfBorg> GooList being removed from poppler makes me sad
<seb128> LocutusOfBorg, and for the record, I find it stressful to be nagged about ongoing work 30min after I started uploaded a stack of updates, there is enough work to do in the archive and enough things in flux that putting pressure on people like that in an early unstable cycle shouldn't be needed
<LocutusOfBorg> actually I was proposing to help, sorry if I wasn't clear... also poppler, its meant to help you!
<seb128> poppler is helpful :)
<seb128> nagging about gstreamer build issues when things are depwait and need to cascade is not
<LocutusOfBorg> I mean, I can do the merges of bad and good if you want an extra hand
<seb128> I was planning to do them in a bit, but if you are borred feel free :)
<seb128> I've enough to do without those
<LocutusOfBorg> that was my intention, so doing them now :D
 * LocutusOfBorg tries to remember how to merge without MoM :D
<Laney> those merges are done using git
<LocutusOfBorg> Laney, I'm looking right now, but looks like the gst-plugins-good1.0 git is outdated?
<Laney> dunno, I didn't do the last one
<Laney> ask the uploader if they still have it, or gbp import-dsc
<LocutusOfBorg> seb128, ^^
<LocutusOfBorg> gst-plugins-good1.0 1.15.90-1ubuntu1 seems missing from git history... shall I import it?
<seb128> LocutusOfBorg, I didn't use git
<seb128> if you wish
<seb128> it's too much overhead to use git for that one imho
<seb128> but if you prefer to do it this way
<LocutusOfBorg> I should, otherwise I can't do the work for 1.16... :)
<Laney> I'd hugely prefer it if those branches weren't abandoned
<Laney> they make resolving any conflicts so much easier
<seb128> just gbp import the .dsc then
<seb128> I should perhaps do that next time
<LocutusOfBorg> done
<seb128> or I really need to wrap some tooling to fetch the tarball/upstream branches from salsa for me
<seb128> it probably makes sense for -good though
<seb128> I couldn't be bothered to update the vcs for -base since that's a direct sync
<seb128> and I probably kept on that same thinking line when I continued with the other updates then
<Laney> I don't usually do it when things to back into sync indeed
<seb128> sorry, for the rumbling, summary is: sorry for not dealing with the vcs when I did that update :)
<LocutusOfBorg> mmm looks like camerabin and jpegformat haven't been copied from the gst-plugins-ugly 1.15.90...
<LocutusOfBorg> :/
<seb128> LocutusOfBorg, you mean?
<LocutusOfBorg> gst-plugins-good1.0 imports from the equivalent "bad" package the camerabin2 and jpegformat
<LocutusOfBorg> e.g. https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-good1.0/tree/debian/patches/import-camerabin
<LocutusOfBorg> I think each time we have a new plugins-bad, we have to redo the patches from scratch
<LocutusOfBorg> to update our "embedded copy"
<Laney> I used to just check the git diff of bad and copy it again if there had been any changes
<Laney> cp is enough, you don't have to re-create the whole diff
<LocutusOfBorg> I'm doing cp right now, it worked fine for jpegformat
<LocutusOfBorg> but camerabin needs cp of ~10 dirs
<Laney> not 10 is it
<ahasenack> seb128: hi
<ahasenack> seb128: yeah, for me that was confusing, because fix committed in an ubuntu task usually means it's committed to the package, and just not yet in the archive
<ahasenack> had it been the upstream project's task, that would be fine in my eyes :)
<Wafficus> hi there can anyone help me modify the iso tracker to instead test lubuntu isos?
<Wafficus> https://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/ubuntu-server-iso-testing/trunk/view/head:/docs/README.devhttps://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/ubuntu-server-iso-testing/trunk/view/head:/docs/README.devhttps://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/ubuntu-server-iso-testing/trunk/view/head:/docs/README.dev
<Wafficus> whoops double link sorry
<Wafficus> https://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/ubuntu-server-iso-testing/trunk/view/head:/docs/README.dev
<Wafficus> would i set DEGAULY_FLAVOR to Lubuntu?
<tsimonq2> Unit193: ack
<sahid> Laney: o/ did you had chance to look at my update for autopkgtest?
 * mitya57 notices that we now have the animal name
<mitya57> ah, 14 hours ago, I am slow :))
<paride> kirkland, Hi! Do you think you'll get a chance to review https://code.launchpad.net/~legovini/byobu/fix-lp-1827202/+merge/366986 anytime soon?
<tumbleweed> aww, I was hoping for an echidna
<LocutusOfBorg> seb128, a nightmare, not a merge :D
<seb128> LocutusOfBorg, one you volunteered for :)
<infinity> tumbleweed: I considered Echnida, but two Australian animals in a row?  Seems unfair to everyone else!
<vorlon> rbasak: iptables-persistent> no worries
<tumbleweed> infinity: oh, you get executive animal powers these days? :)
<infinity> tumbleweed: It was delegated to me just as I left for the weekend.  It would have perhaps been nicer had the delegation happened a few weeks earlier. :P
<tumbleweed> heh
<sarnold> ermine, how royal :)
<infinity> sarnold: It's an animal, not a coat.
<infinity> sarnold: Pretty sure they're just adorable when they're alive.  Only hoity toity if you skin them.  Please don't skin our cute mascot.
<sarnold> infinity: omg those are adorable.
<Laney> Nope. Sorry. I'm going to be picturing the House of Lords for this whole cycle.
 * Laney scoffs at you all from the Woolsack
<infinity> Hah.
<infinity> sarnold: I think the best thing about Google Images searches for Ermines (or weasels in general, but the problem is made worse when they're all white, as ermine stoats are) is that one genuinely has a very hard time telling which ones are real and which are plush toys.
<infinity> sarnold: Nothing in nature should be that cute.
<sarnold> oh man.. some cute little ubuntu ermine plushies..
<Laney> shame the shop's dead now
<infinity> It also says a lot about the British upper class that they saw these adorable creatures and thought "you know, thirty seven of those sewn together would make a dashing scarf."
<xnox> LocutusOfBorg, the crmsh upload looks fine. Had no idea that moved to be honest =) also that is so old since i last touched it ;-)
<xnox> mwhudson, i do not understand why in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html golang-github-prometheus-client-golang regresses golang-github-grpc-ecosystem-go-grpc-prometheus
<xnox> looks like a generic decay?
<vorlon> infinity, stgraber, kees, mdeslaur: TB meeting in 20?
<mdeslaur> vorlon: ack
<seb128> ahasenack, I just wanted to say thank you for the work you are doing on those gvfs/samba issues!
<ahasenack> seb128: cheers! I whish I knew more about the technical details
<ahasenack> but sometimes I have to timebox this research :)
<seb128> well, it's good to have someone who has a clue about samba looking at those!
<seb128> I try to triage report/upstream problems/help debugging but I don't know much about samba and I'm too busy to do a proper job figuring out the details
<ahasenack> it gets worse when real windows is thrown into the mix
<seb128> yeah :/
#ubuntu-devel 2019-05-08
<xnox> vorlon, LocutusOfBorg - corosync in a lxd container seems sad. cannot start it on amd64
<xnox> at first seemed like low default limits:
<xnox> lxc config set CONTAINER-NAME limits.kernel.memlock 33554432
<xnox> helped to get past one error in corosync, but now logs don't initialize, and i'm not sure why
<xnox> May 08 00:10:42 nice-mako corosync[349]:   [MAIN  ] Can't initialize log thread
<xnox> May 08 00:10:42 nice-mako corosync[349]:   [MAIN  ] Corosync Cluster Engine exiting with status 7 at main.c:1507.
<xnox> or maybe worse.
<sarnold> xnox: kinda looks like that needs posix semaphores https://sources.debian.org/src/libqb/1.0.4-2/lib/log_thread.c/?hl=142#L142
<sarnold> xnox: any idea if those work or are disallowed by your container? seccomp rules?
<sarnold> .. hmm, or maybe it's the scheduling priority
<xnox> hmmm
<xnox> max locked memory       (kbytes, -l) 65536
<xnox> max memory size         (kbytes, -m) unlimited
<xnox> i don't like this in ulimit -a
<xnox> i think i need more
<xnox> and i did do $ lxc config set nice-mako limits.kernel.memlock 6553600
<xnox> so why does my container not do more?!
<sarnold> systemd can fiddle rlimit_memlock https://sources.debian.org/src/systemd/241-3/src/core/main.c/?hl=1376#L1376
<xnox> sarnold, sigh $ sudo systemctl edit snap.lxd.daemon.service
<xnox> [Service]
<xnox> LimitMEMLOCK=655360000
<xnox> and it looks like it doesn't respect units right....
<xnox> as if that's in bytes, instead of kb
 * xnox tries a suffix
<xnox> https://paste.ubuntu.com/p/mCnQfD6StH/
<sarnold> heh :/
<xnox> i think that's progress!
<xnox> cause i get new errors =)
<sarnold> hey! :)
<xnox> "File name too long" lovely
<sarnold> new errors are always great
<xnox> stgraber, what insanity do i need to set on my snap.lxd.daemon.service to make it "production"? also, do you want to try installing corosync from eoan-proposed to make it start in the lxd container? at the moment, that fails for me =(
<xnox> [pid   336] setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
<xnox> hmmm
<xnox>                 if (savederrno == EPERM) {
<xnox>                         errno = ENAMETOOLONG;
<xnox> kwalitee =)
<sarnold> bingo
<sarnold> systemd again?
<sarnold> or apparmor this time? :)
<xnox> nah, kronosnet-1.8
<xnox> but the eprm is real
<xnox> i do not see things in apparmor denials....
<xnox> sarnold, i think it wants the real CAP_NET_ADMIN for no reason.
<xnox> cause reading SO_RCVBUF & SO_RCVBUFFORCE in http://manpages.ubuntu.com/manpages/disco/en/man7/socket.7.html
<sarnold> xnox: yeah it's really annoying that this cap is needed for something that feels so bland
<xnox> it's normal that i can't do the later, but if the former succeeded... i fail to see why we force things?!
<xnox> root@nice-mako:~# strace -s99999 -f /usr/sbin/corosync 2>&1 | grep setsock
<xnox> [pid   386] setsockopt(12, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
<xnox> [pid   386] setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
<sarnold> xnox: loads of apparmor profiles either have to decide to grant this terrifying priv, or force a failure here :(
<xnox> ah, maybe it did fail!
<xnox> [pid   401] setsockopt(12, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
<xnox> [pid   401] getsockopt(12, SOL_SOCKET, SO_RCVBUF, [425984], [4]) = 0
<xnox> [pid   401] setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
<xnox> cause it's trying to set 8388608, but gets back 425984 instead. smells like one more "ulimit" imposed on me.
<xnox> and calling it a night.
<xnox> exit
<sarnold> this one might be a cgroup for kmem or similar? you wouldn't be happy if your fart app container went crazy and allocated half your kernel memory in silly receive and send buffers..
<sarnold> gnight xnox ;)
<LocutusOfBorg> mdeslaur, FYI, I syncd libcaca, discarding your doxygen-latex switch, basically because the fix is now probably in doxygen, and the package doesn't FTBFS anymore https://launchpad.net/ubuntu/+source/libcaca/0.99.beta19-2ubuntu2
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/libcaca/0.99.beta19-2.1
<mwhudson> rbasak: does the git source package importer have some magic way of getting things out of the debian NEW queue?
<mwhudson> (it seems unlikely but i thought i'd ask)
<mwhudson> oh wait you can't even download stuff from new
<rbasak> mwhudson: yeah, sorry. I was going to say wishlist but you've reminded me it's impossible.
<rbasak> mwhudson: you might find git/bin/git-dsc-commit in the source tree useful. If you have a source package you can "force commit" it into a branch. Eg. an orphan branch. Then you can at least diff it against other things, etc.
<TomyWork> hi
<TomyWork> I'm trying to install ibm notes (formerly known as lotus notes) from the vendor's .debs. It's a 32 bit package that depends on gdb. This has always been a problem, since I'm on a 64 bit system and I have a 64 bit gdb package. On 14.04, I used an otherwise empty package with this control file in order to get it to work: https://paste.ubuntu.com/p/wKRXyfzFk3/  On 18.04, when trying to install that package, I now get a conflict: https://paste.ubuntu
<TomyWork> .com/p/GRXHwrBzPG/  this is likely due to the fact that the 18.04 gdb:amd64 package conflicts with "gdb", which the 14.04 gdb:amd64 package did not. How do I install a package that requires gdb:i386 while that gdb:amd64 package is installed and conflicting with any other package that even *provides* "gdb"
<TomyWork> oops, that link got cut in half. here's the whole link: https://paste.ubuntu.com/p/GRXHwrBzPG/
<juliank> ugh I merged wpa from experimental but wrote unstable in the changelog, sorry
<juliank> I merged unstable first, then copied changelog over and forgot to replace it :D
<marcustomlinson> sil2100: hey! any chance you got around to https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1826560
<ubottu> Launchpad bug 1826560 in libreoffice-l10n (Ubuntu Disco) "[SRU] libreoffice 6.2.3 for disco" [High,In progress]
<mdeslaur> LocutusOfBorg: cool, thanks!
<mwhudson> rbasak: ah yeah that might be handy indeed
<mwhudson> rbasak: i can probably get the uploader to give me the dsc
<mwhudson> (or just make one from git)
<rbasak> mwhudson: if it's already in git, then surely you already have it in git? :-)
<xnox> sarnold,
<xnox> sudo sysctl -w net.core.wmem_max=8388608
<xnox> sudo sysctl -w net.core.rmem_max=8388608
<xnox> was the answer to the other one, and i do have corosync/pacemaker in the container now. Opened: https://bugs.launchpad.net/auto-package-testing/+bug/1828228
<ubottu> Launchpad bug 1828228 in Auto Package Testing "corosync fails to start in container (armhf) bump some limits" [Undecided,New]
<rbasak> ahasenack: on bug 1616123, did we already make a decision to SRU it? I remember something like bug - is this the only instance or was there another variable affected in another bug?
<ubottu> bug 1616123 in nfs-utils (Ubuntu Cosmic) "rpc-svcgssd.service uses incorrrect variable SVCGSSDARGS" [Undecided,In progress] https://launchpad.net/bugs/1616123
<ahasenack> rbasak: we will want to sru it, we were waiting on what debian was going to do, but they made the same change
<rbasak> ahasenack: I'm wondering from the perspective of "is this worth an SRU?"
<rbasak> Because a workaround is to override via systemd in /etc, right?
<ahasenack> it's a low hanging fruit
<ahasenack> yes
<rbasak> OK
<ahasenack> a good one for someone new perhaps? :)
<michael-vb> Hello, does anyone here feel responsible for the update-secure-boot-policy script in shim-signed?  It is intended to be used by DKMS modules, but I have experimental changes to the VirtualBox installer to use it as well, and wanted to talk about that.
<michael-vb> I e-mailed Mathieu Trudel-Lapierre, who is in various change logs, but didn't get a response.
<xnox> michael-vb, well, talk about it. how are you using it?
<michael-vb> Well, the bit in my script I like the least is this:
<michael-vb> # update-secureboot-policy "expects" DKMS modules. Work around this and talk to the authors as soon as possible to fix it.
<michael-vb> mkdir -p /var/lib/dkms/vbox-temp
<michael-vb> update-secureboot-policy --enroll-key 2>/dev/null || [...]
<michael-vb> rmdir -p /var/lib/dkms/vbox-temp 2>/dev/null
<michael-vb> If you see what I mean.
<michael-vb> At this point that will have to stay in my script so that it works with existing versions of update-secureboot-policy, but it would be great if it were not needed.
<michael-vb> And the other thing was whether there were any thoughts about a cross-distribution solution, say with the freedesktop/XDG people.  I would assume that
<michael-vb> they would want to see a bit more protection of the private key, like
<michael-vb> optionally adding a protection password (if that is possible), or
<michael-vb> letting the user specify the location at signing time and optionally
<michael-vb> mounting external storage containing the key.
<michael-vb> (Sorry, pasted that from an e-mail which was of course line-split.)
<xnox> michael-vb, no passwords is an Ubuntu UX decision.
<xnox> michael-vb, so even if passwords / unlocking / tpm / usb-stick is added, we'd need/want to keep "unprotected/passwordless/unattended" mode as well.
<xnox> michael-vb, re bogus directories to enroll-key => please open a bug report and propose a patch? to either just do things, or do things if there is like '--force' or something?
<michael-vb> Happy to do that (the bug report).
<xnox> michael-vb, and well do wait for response from cyphermox cause i think he does maintain that script. and we do keep changing what we do by default, and etc.
<michael-vb> I just wanted to talk to someone first to get your thoughts.
<michael-vb> Like if someone was going to say "no way, this is only for DKMS".
<cyphermox> michael-vb: I have been writing that email response to you, I just want to get it just right
<cyphermox> michael-vb: essentially, you probably don't want to use update-secureboot-policy; it's not needed for what you want aside maybe to create the key to begin with
<cyphermox> for everything else it's just a wrapper, so if you don't want to use DKMS, you might as well just call mokutil --import yourself if needed, and sign things yourself using kmodsign
<cyphermox> for anything else, I mean, sure, protecting the key more is possible, but it's not necessarily going to do much aside from making it more hoops for users to jump through to get something signed, even if it's automated
<michael-vb> There were two reasons I was keen to use update-secureboot-policy.  One was that I don't want to replicate all the debconf bits but still get a native "experience".  And the second is more evil, if I do it myself I am responsible for the security decisions.
<michael-vb> Those added hoops are what I imaging other distributions might want to see, not what I am interested in myself.
<cyphermox> well, you can also call update-secureboot-policy --enroll-key as part of your build it will do the password asking
<michael-vb> Right, so then the question is - can you remove that "if [ $dkms_modules -lt 2 ]; then" part?
<michael-vb> Working around it for existing deployments of the script is no problem, I just feel better when I am not fighting against the tools I am using.
<cyphermox> not really
<cyphermox> this is specifically so upgrades happen seemlessly without prompting the user again
<michael-vb> Could you add a couple of words to that?
<cyphermox> if you don't have a key enrolled and already had a dkms module installed, you don't necessarily want to prompt to enroll again unless a new DKMS module appears
<michael-vb> Oh, I thought that that line would detect any DKMS modules, not just new ones.
<LocutusOfBorg> seb128, can I abuse your patience once more and see if you can help me in xpdf poppler sadness? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3714/+packages its the last one
<seb128> LocutusOfBorg, hey, not today but I can have a look tomorrow
<LocutusOfBorg> basically I have to replace goolist with std::vector, but my c++foo sucks :)
<LocutusOfBorg> I'll try again tonight
<michael-vb> cyphermox: have to go for a bit (will stay in the channel), but actually what I would like would be a way of using update-secureboot-policy without having the feeling that I am using it in a way I should not be.  So removing that line was an idea, but any other way to say "please continue even though no DKMS modules are there" is fine too.
<michael-vb> An environment variable would be nicer than a switch of course, as the switch would break on current versions.
<michael-vb> Oh, actually "sudo /usr/sbin/update-secureboot-policy --enroll-key --foo" works without complaining.
<michael-vb> Forget the environment variable thing then.
<michael-vb> Back later.
<cyphermox> yup
<michael-vb> (Why does everyone in software love the word "foo" so much?)
<ginggs> fooknows
<michael-vb> cyphermox: oh yes, the other thing - did you have any ideas of co-operating with other distributions about handling this at some point, or is that something you are not interested in starting?  If the second I would ping Hans again myself to ask who to talk to.
<michael-vb> Away again.
<cyphermox> michael-vb: it's not about not being interested, tbh it's more that I'm not sure I currently have any time to put to that endeavor; and it really needs to work on desktop and servers equally well.
<cyphermox> (so that means a gtk-only solution is out of the way, that's partly why debconf was a "good idea" for this)
<cyphermox> essentially, that means some amounts of UI engineering work; it's not like a shell script that can be banged together in a couple of hours :)
<michael-vb> I read that as I am welcome to ask people, but on my time.
<cyphermox> michael-vb: I sent my response by email already; best is to file a wishlist bug and we can discuss that; maybe I can get time blocked to work on that
<michael-vb> Thanks.
<sarnold> xnox: nice, thanks
<plongshot> Please forgive me if I've come to the wrong place but I'm not connecting with people in the regular channel and I don't know if it's because my question is a bit dense or what.  Can anyone kindly advise on the best way to find what I need?
<plongshot> My original qestion was thus..
<plongshot> I dont' know the connections under the hood with ubuntu but is the location for the default directory for bluetooth file transers determined by something else in the system?  In other words, is it going off of some default setting for "Downloads" folder location and create the folder if ti down't exist?  If that is so then maybe I should look for a way to change the setting for the defalult "Downloads" location and the things
<plongshot> the rely on it will  honor that?
<plongshot> ty
<plongshot> I need to seriously mitigate mutations to my directory structure - It drives me nutz!  :>
<plongshot> I'm on / talking about 18.04
<mwhudson> rbasak: you make a good point
#ubuntu-devel 2019-05-09
<LocutusOfBorg> seb128, I might have some patch soon for xpdf, I would appreciate if you can just review it
<seb128> LocutusOfBorg, k
<LocutusOfBorg> patch mostly finished
<juliank> I extended bug #1825972 to cover some more old gnome 2 packages without reverse deps (gnome-vfs, libbonobo, libbonoboui, libgnome, orbit2)
<ubottu> bug 1825972 in libgnome-keyring (Ubuntu) "Remove gnome 2 stack + linsmith from eoan" [Undecided,Incomplete] https://launchpad.net/bugs/1825972
<juliank> Initially filed only to get libgnome-keyring out, I today realized that the whole gang can go
<GunnarHj> Hi bdmurray, would you have time to look at bug #1825733 again? I submitted a couple of debdiffs.
<ubottu> bug 1825733 in ubuntu-release-upgrader (Ubuntu Disco) "ubuntu-release-upgrader-core shows upgrading from 18.10 to 18.10" [High,In progress] https://launchpad.net/bugs/1825733
<bdmurray> GunnarHj: Do you want to fix bug 1727472 at the same time?
<ubottu> bug 1727472 in ubuntu-release-upgrader (Ubuntu Eoan) "[RFE] Automatically update the Ubuntu version string in ubuntu-release-upgrader" [Medium,Triaged] https://launchpad.net/bugs/1727472
<GunnarHj> bdmurray: I'm afraid that I don't know enough about gtk and qt to do that, sorry. I suppose the strings would need to me moved from respective .ui file to python. So I think it would be good if the qt oversight could be fixed separately.
<bdmurray> GunnarHj: okay, I'll get the eoan change uploaded the disco one might be a bit as there is a current SRU
<GunnarHj> bdmurray: That would be a good first step. As I stated in the bug report, I'm not 100% sure that the change is sufficient. But having it in eoan will make it possible to test Kubuntu 19.04->19.10 upgrades at least.
<GunnarHj> bdmurray: autopkgtest complaint for update-manager:
<GunnarHj> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-release-upgrader
<ddstreet> vorlon you might not remember, but it looks like you added a patch to sudo to keep HOME in the keep_env list, way back in 2011 (so that running 'sudo' doesn't change $HOME by default, without -i or -H)...do you remember what the reason for setting that as default was?  I'm just curious as to why
<vorlon> ddstreet: I only know that the changelog points to LP: #760140
<ubottu> Launchpad bug 760140 in sudo (Ubuntu Natty) "HOME environmental variable no long preserved with sudo by default" [Medium,Fix released] https://launchpad.net/bugs/760140
<ddstreet> ah! thnx, i was git blaming the patch to see how far back it was added, should have checked the changelog for that release
<ddstreet> vorlon do you still agree with that decision?  it has some unfortunate side effects, like sudo-run applications creating root-owned files/dirs in $HOME
<vorlon> ddstreet: I will not attempt to defend that decision 8 years later :)
<ddstreet> lol
<vorlon> things have moved on and there's certainly a new normal in terms of sudo expected behavior elsewhere
<ddstreet> vorlon i suppose an email to ubuntu-devel would be best if i wanted to revive the discussion
<vorlon> sounds good to me
<connor_k> How can I increment a package version in just an older release (backporting something to Bionic) such that if they were to upgrade to Cosmic they wouldn't be forced to remain on the Bionic version (because it's now technically greater than the one in Cosmic)?
<connor_k> Otherwise before the change, both packages are the same version number in Bionic and in Cosmic
<tyhicks> I was talking with connor_k about this previously and don't have any good ideas myself
<tyhicks> to give a specific example, he needs to SRU some patches that back to Bionic's ndiswrapper, but not Cosmic's, in order to let the module build with hwe kernels
<tyhicks> the problem is that Bionic and Cosmic ndiswrapper are both at 1.60-6
<tyhicks> bah... s/SRU some patches that back to/SRU some patches back to/
<tyhicks> infinity, bdmurray: I feel like one of you two might have some solid advice here for connor_k ^
<infinity> Without backporting to both releases, you can't achieve what you want.
<infinity> (Well, uploading to both, at least)
<infinity> Is there harm in cosmic having the same fixes?
<tyhicks> I didn't think so but is it acceptable to only upload to Bionic in this case?
<tyhicks> infinity: no harm other than needless risk of regression
<infinity> It wouldn't particularly hurt anything to upload just to bionic either.
<tyhicks> that was my feeling, too
<infinity> Or, upload to bionic, verify, then binary copy forward to cosmic too, if one really cares about the version oops.
<infinity> Once cosmic goes EOL, these sorts of version disparities happen all the time anyway.
<tyhicks> exactly and cosmic EOL isn't far away
<infinity> Cause someone will backport $pkg from $devel to bionic and disco, but cosmic is closed.
<infinity> It's 2.5 months out.  That's far enough. :P
<infinity> But if the patches are useless in cosmic anyway, it's all a bit of a meh.
<tyhicks> after talking it over, I feel comfy enough sponsoring connor_k's upload only to bionic as this is a pretty harmless version oops (I wouldn't want to do it to an LTS release)
<tyhicks> thanks
<connor_k> infinity, tyhicks thanks!
#ubuntu-devel 2019-05-10
<lag> xnox: Morning o/
<xnox> lag, hey
<lag> xnox: It's been a while - how are you?
<xnox> lag, busy bee =)
<lag> xnox: Best way
<lag> xnox: I won't take up too much of your time then
<xnox> lag, well shoot =) what's up?
<lag> xnox: Have you made any progress with making Mainlined DTBs available during initial install?
<xnox> lag, some for current devel series. not yet done or retried with bionic.
<xnox> lag, sorry about that.
<lag> xnox: What does that mean?  I can download the AAarch64 Disco installer and they will be present?
<xnox> no
<xnox> locally on my system
<xnox> (and my local .isos)
<lag> xnox: Okay.  Any idea when I might be able to download a public installer ISO where they are present?
<xnox> lag, no eta. but hopefully soon.
<xnox> lag, but maybe i should upgrade to your new kernel actually
<xnox> wait, 13th of march, i should have that already actually.
<lag> xnox: Our kernel hasn't been updated in a long time (I have been away on Shared Parental Leave)
<xnox> ah nice =)
<lag> xnox: In either 3 days, or 1 week and 3 days, you should be able to boot Mainline
<xnox> lag, ooooh! i want that!
<lag> xnox: In theory (I need to test that)
<lag> xnox: You might still need our DTB, but again, I need to test that for myself (just getting back on my feet after some time away)
<xnox> lag, so 5.1 will not be enough right? needs 5.2rc1 basically?
<xnox> (tentitavly)
<lag> xnox: You could try it - I'm not sure what is lacking
<lag> xnox: I think it would boot, but there might be issues booting into Ubuntu GUI
<lag> xnox: Give it a go?
<xnox> i guess i can
<tkamppeter> vorlon, tjaalton, hi
<tjaalton> tkamppeter: yo
<tkamppeter> vorlon, tjaalton, I want to ask you something about the Bionic SRUs on network-manager and modemmanager, bug 1754671 , bug  1828102, bug 1809132
<ubottu> bug 1754671 in systemd (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Triaged] https://launchpad.net/bugs/1754671
<ubottu> bug 1828102 in modemmanager (Ubuntu Disco) "regression in modemmanager" [Undecided,New] https://launchpad.net/bugs/1828102
<ubottu> bug 1809132 in network-manager (Ubuntu Bionic) "Updated bionic to the current 1.10 stable version" [Low,Fix committed] https://launchpad.net/bugs/1809132
<tkamppeter> The autopkg test of network-manager 1.10.14-0ubuntu1 (the nm SRU but also blocking the tests of the mm SRU) is failing due to a triviality.
<tkamppeter> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/n/network-manager/20190509_170311_4f39f@/log.gz
<tkamppeter> which can be fixed with a simple patch:
<tkamppeter> http://paste.ubuntu.com/p/9Hpsw3Fbhp/
<tkamppeter> Could you allow a re-upload of nm with this patch applied without re-doing the full SRU testing process?
<tkamppeter> Or simply pass through these SRUs skipping this test?
<tjaalton> tkamppeter: yes, fix the test.. since it doesn't touch anything besides that, there's no need to re-test everything
<tkamppeter> tjaalton, thank you very much.
<Laney> tjaalton: it's in the queue if you have a minute to review please? trivial debdiff vs the current sru
<tjaalton> Laney, tkamppeter: yup, accepted
<Laney> thanks!
<Laney> tkamppeter: so ask the vanguard on Monday if they would kindly release it
<Laney> assuming it builds / passes and everything
<seb128> tjaalton, can you accept the gvfs "no change rebuild" uploads to cosmic/bionic? That's to fix smb browsing and got blocked for a while by other SRUs but some people are waiting on those
<tkamppeter> tjaalton, thank you very much.
<seb128> is errors.ubuntu.com sloooow to load for others as well?
<seb128> bah and launchpad timeouts, maybe same cause :-/
<lag> xnox: What is a polite amount of time to wait before asking for this again?
<lag> xnox: Does Ubuntu have a rolling release that I can target?
<tsimonq2> lag: Ubuntu does not have a rolling release, but we do have an open development release.
<xnox> lag, we do have 'devel' which is an alias for uploads, currently points at eoan.
<xnox> as in your debian/changelog can target devel
<xnox> lag, kernel team maintains an 'unstable' tree (which i'm sure you know) which always is prepped for the next major release kernel.
<lag> tsimonq2: xnox: Yes, I've seen devel - perhaps that's the way to go
<xnox> lag, but like last time i tried to use gnome-shell from disco it didn't start =(
<xnox> just a black screen
<xnox> bionic one works.
<tkamppeter> tjaalton, I have seen now in my e-mail that on all the three Bionic nm SRU bugs a new call for testing got posted and the "verification-done" tags got reset to "verification-needed". Is this correct? You told that there will be no new testing process needed for these SRUs.
<seb128> tkamppeter, the script they use to accept uploads do that, just change the tags back
<lag> xnox: Yes, gnome-shell was broken for me too -- culminated in a flashing '_'
<tkamppeter> seb128, OK, thanks.
<xnox> lag, did we engage anybody on fixing that? or do we need to try something else like mate / xfce / lubuntu?
<xnox> to see if that's all graphics, or just gnome-shell
<seb128> lag, do you have details on that issue/did you report it?
<lag> seb128: Not yet, I just carried on using Bionic
<LocutusOfBorg> bdrung, can you please add me to the videolan launchpad team? probably my membership expired...
<LocutusOfBorg> https://launchpad.net/~videolan
<tkamppeter> seb128, tjaalton, I have reset the tags to verification-done now.
<seb128> tkamppeter, thx
<tkamppeter> tjaalton, could you approve the Bionic systemd SRU for bug 1754671, so that this bug does not block the network-manager SRU process? Thanks.
<ubottu> bug 1754671 in systemd (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Triaged] https://launchpad.net/bugs/1754671
<tjaalton> tkamppeter: sorry, no sru's are accepted to updates on afriday ;)
<tjaalton> seb128: there's another version of gvfs in cosmic-proposed
<seb128> tjaalton, that should be deleted, let me do that, vorlon did it for bionic but not for cosmic for some reason
<tjaalton> well, i'm actually afk already, maybe he can check the new upload too?
<seb128> tjaalton, no worry I was asking in case, I will try my chance with the next SRU review
<seb128> tjaalton, have a nice w.e!
<tjaalton> thx!
<ddstreet> juliank i opened RFC-only MP for software-properties for lp #645404, it's still a work in progress but wanted to start getting your feedback on it
<ubottu> Launchpad bug 645404 in software-properties (Ubuntu Eoan) "Support Private PPAs" [Low,In progress] https://launchpad.net/bugs/645404
<GunnarHj> bdmurray: Will there be a sensible way to verify the disco fix of bug #1825733? Can you start a release upgrade with -proposed enabled?
<ubottu> bug 1825733 in ubuntu-release-upgrader (Ubuntu Disco) "ubuntu-release-upgrader-core shows upgrading from 18.10 to 18.10" [High,In progress] https://launchpad.net/bugs/1825733
<bdmurray> GunnarHj: do-release-upgrade -p is the way to test the release-upgrader from -proposed
<GunnarHj> bdmurray: Ah, thanks!
<juliank> ddstreet: that's complicated
<ddstreet> juliank that's why i broke it up into multiple commits
<ddstreet> but yeah, it's major refactoring of how the shortcuts work - simplifies it a lot
<juliank> ddstreet: Now, optimally, could you retarget that against the actual software-properties git repo https://git.launchpad.net/software-properties?
<ddstreet> sure, i'll close that MP and move it over if you prefer that
<juliank> That's where we do the development :)
<ddstreet> yeah, hard to keep track when i work on so many different packages, some do, some don't :)
<juliank> seb128: please push a 0.98.1 tag for your software-properties upload, thanks
<cjwatson> sil2100: Could you update the langpack-o-matic cron jobs for eoan?
<cjwatson> sil2100: See https://code.launchpad.net/~cjwatson/lp-production-crontabs/translations-eoan/+merge/366913 for the schedule on our side (if you can see that)
<sil2100> cjwatson: hey! Sure, thanks! ;)
<vorlon> tkamppeter, tjaalton: if systemd needs changed in order for the network-manager SRU to be correct, should network-manager not declare a versioned dependency on the fixed systemd?
<cyphermox> wait, wat?
<cyphermox> why would systemd need to be changed for the NM SRU?
<coreycb> hi, would anyone from the SRU team be able to review neutron in the cosmic unapproved queue? this is for bug 1606741.
<ubottu> bug 1606741 in neutron (Ubuntu Cosmic) "[SRU] Metadata service for instances is unavailable when the l3-agent on the compute host is dvr_snat mode" [High,Triaged] https://launchpad.net/bugs/1606741
<coreycb> it's a bit of a hot one
<coreycb> tjaalton: vorlon: in case you happen to have cycles in the rotation today
<coreycb> ^
<vorlon> coreycb: looking now
<coreycb> vorlon: thanks!
<seb128> juliank, software-properties tag pushed, thanks for the reminder (those git based workflow don't make it easy to not overlook steps :/)
<Unit193> stgraber: Hello, it looks to me that lxc-templates could be sync'd from Debian, no?
#ubuntu-devel 2019-05-11
<stgraber> Unit193: yeah, assuming it's packaged in a similar way, no reason it couldn't
<stgraber> Unit193: I didn't know they had it now
<Unit193> stgraber: Yeah the diff to their 3.0.2 was very minimal.
<tsimonq2> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Open | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots: tsimonq2
<tsimonq2> Whew, that's a nice-looking queue. :)
<tsimonq2> jamespage: Hello, could you (or someone on the OpenStack team) please take a look at bug 1827340, which showed up in the sponsorship queue?
<ubottu> bug 1827340 in swift (Ubuntu) "swift-container package is missing Upstart and System V files for the container-sharder service" [Undecided,In progress] https://launchpad.net/bugs/1827340
<tsimonq2> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Open | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-May/040680.html
<valorie> tsimonq2: thanks for your work
<valorie> where are you on the effort to get a unified report state?
<valorie> finally read that mail thread you told me about
<valorie> "Improving the Sponsorship Queue"
#ubuntu-devel 2019-05-12
<Ramzis> hi, following this tutorial http://packaging.ubuntu.com/html/getting-set-up.html#get-set-up-to-work-with-launchpad  trying to execute 'pbuilder-dist eoan create' inside lxc container and getting 'mknod: /var/cache/pbuilder/build/502/test-dev-null: Operation not permitted E: Cannot install into target '/var/cache/pbuilder/build/502' mounted with noexec or nodev'
<Ramzis> It must be something with lxc config files but I am unable to comprehend anything on https://linuxcontainers.org/lxc/manpages//man5/lxc.container.conf.5.html any help please?
<Ramzis> found a bad solution here: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1642251  X_X
<ubottu> Launchpad bug 1642251 in lxd (Ubuntu) "Can't use sbuild in an lxd container" [Undecided,Invalid]
#ubuntu-devel 2020-05-04
<guiverc> I asked this on weekend, but flavor ISOs for 20.10 are being created, but http://iso.qa.ubuntu.com/qatracker/milestones/413/builds does not have anything, however iso.qa does have new daily builds for 20.04? but no ISOs there (http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/211606/testcases) - is this related & a config mixup?
 * guiverc notices it's still 'weekend' for UK/EU/US folks, sorry
<ricotz> doko, hi, lib32stdc++6 (gcc-10/groovy-proposed) still creates an internal versioned dep to lib32gcc1
<Laney> guiverc: there was a typo in a config file. fixed, hopefully that'll do it for the next builds
<guiverc> Thanks Laney
<santa_> hi everybody
<oSoMoN> is there a plan to backport python 3.6 (or newer) to xenial, given that 3.5 will be EOL on 2020-09-13, before xenial's own EOL ?
<wgrant> oSoMoN: That would be unusual, given the usual distribution practice is to provide support beyond the upstream lifetime. Do you have a specific reason for asking?
<oSoMoN> wgrant, yes, it looks like firefox will soon need to build-depend on python3 >= 3.6
<cjwatson> SRUing a newer minor release Python would be a gigantic and disruptive effort
<cjwatson> *of Python
<cjwatson> Almost certainly much easier to make the probably relatively few changes to keep Firefox running on 3.5
<oSoMoN> I thought so, just wanted to check before I put an item on my to-do list
<oSoMoN> I'll actually most probably create a python3.6-mozilla package and will b-d on it, as we already do for a few other firefox build deps that require newer versions than what's in xenial
<cjwatson> !
<cjwatson> I really recommend against it
<cjwatson> Python has a lot of integration
<wgrant> It really isn't that hard to fix 3.6-only code
<wgrant> Far far easier than backporting the whole interpreter
<wgrant> (also, that's pretty anti-social of Mozilla)
<wgrant> I can see the justification for something fast-moving like Rust. But doing it for Python seems wwied
<wgrant> Weird
<oSoMoN> well their build system is python2-only for now, but they're working on migrating to python3, so they're targetting a version that will be supported by the time they switch, which makes sense
<cjwatson> Migrating to Python 3 makes sense, but even if they target 3.6 it's very unlikely to be hard to make it work on 3.5 as well
<wgrant> It sounds like it would be worth it for distributions to contribute to that discussion. Keeping 3.5 support upstream isn't hard.
<wgrant> But it also isn't hard to add it back later if they decline.
<oSoMoN> right, I don't know how much work it will be to fix 3.6-only code, I'm not very familiar with the inners of mozilla's build system, but potentially much easier than backporting the whole interpreter indeed
<wgrant> With almost complete certainty.
<oSoMoN> wgrant, cjwatson: thanks for your input, I'm talking to a mozilla dev and I've forwarded that feedback, hopefully they can make this easy for us
<wgrant> oSoMoN: Great, hopefully they're receptive. It's not much work for them, and makes the lives of multiple downstreams easier.
<Odd_Bloke> waveform: Where are we at with https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1870346?  Are you still investigating the Pi WiFi issues, or is it on our plate fully now?
<ubottu> Launchpad bug 1870346 in cloud-init (Ubuntu) "Wifi configuration" [Medium,Triaged]
<waveform> Odd_Bloke, given Ryan's last comment I was going to try and tackle the netplan guys this week to see if they could take a look at it - but I can say the bug he linked to (LP: #1874377) doesn't fix this one (1870346)
<ubottu> Launchpad bug 1874377 in netplan.io (Ubuntu Focal) "Netplan does not connect to Wireless after `sudo netplan apply` until reboot" [High,Fix released] https://launchpad.net/bugs/1874377
<Odd_Bloke> waveform: Yep, and we have a report from a user that the follow-up fix (that landed in ubuntu3 in groovy) is also exhibiting the same issues. ;.;
<waveform> Odd_Bloke, yeah - tested that over the weekend with no joy - still, if rharper think it's not cloud-init, I figured I ought to try the netplan angle as we haven't looked at netplan specifically for this bug yet (although it has been touched for several vaguely related ones as you've noted!)
<rbasak> bryce: I see you tagged git-ubuntu 0.9.3 and 0.9.4, but I don't see release announcements for these. Should we treat them as never released?
<rbasak> I'd like to roll a 0.10.
<Odd_Bloke> waveform: Cool, so long as this isn't sitting waiting for us, I'll leave you to it.  Is there a Ubuntu Pi channel or something that I can direct this user to hang out in?
<waveform> I keep an eye on mentions of "ubuntu" in #raspberrypi (which is where the vast majority of pi support on IRC happens), and for "r?pi" mentions on #ubuntu and here (and a few other ubuntu sub-channels)
<waveform> Odd_Bloke, ^^
<Odd_Bloke> Ack, thanks!
<sil2100> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<seb128> doko, do you have any idea why https://launchpadlibrarian.net/459994405/buildlog_ubuntu-focal-amd64.mailnag_1.2.1-1.1ubuntu1_BUILDING.txt.gz is not building anything?
<seb128> the packaging is outdated and it's using 'dh build --with python2'
<seb128> but that used to work / call 'python setup.py build --force' but in focal that stopped working, it's not doing anything
<bdmurray> seb128: Have you seen https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/comments/15?
<ubottu> Launchpad bug 1871538 in dbus (Ubuntu Focal) "dbus timeout-ed during an upgrade, taking services down including gdm" [High,Incomplete]
<seb128> bdmurray, I didn't see it but it doesn't seem to have much info, it's similar to previous comment, systemd/dbus going down for some reason
<seb128> bdmurray, we would need bug #1870060 to get fixed to get more info on whether a service segfault ... do you know what's the status of that one/if we have an eta?
<ubottu> bug 1870060 in apport (Ubuntu Focal) "systemd ProtectSystem/mount namespace makes apport fail (impact most of our default system services)" [High,New] https://launchpad.net/bugs/1870060
<seb128> bdmurray, also bug #1862553, the fix is in the review queue since friday, hint hint *g*
<ubottu> bug 1862553 in gnome-control-center (Ubuntu) "gnome-control-center crashed with SIGSEGV in cc_panel_get_title_widget()" [High,Fix released] https://launchpad.net/bugs/1862553
<doko> seb128: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949372
<ubottu> Debian bug 949372 in src:dh-python "dh-python doesn't accept python2 or python2.7 in the build dependencies" [Important,Open]
<doko> b-d on python-all is a workaround
<eoli3n__> Hi
<eoli3n__> any chance to get zsys working on any other distro ?
<eoli3n__> should i try to build an aur package, or the project is not ready to be port ?
<seb128> doko, thanks
<Unit193> xnox: Thanks for asking -ftp about the openssl issue.
#ubuntu-devel 2020-05-05
<mwhudson> kanashiro: congrats!
<Unit193> Dang, he was quick to get coredev, I'm still only a MOTU after 6 years. :3
<cpaelzer> If a bug is in the postrm of the current package, has the new update any way to flag that so that it is not run?
<cpaelzer> I mean obviously the new package will have a fixed postrm, but is there any way to avoid running oldver->postrm on upgrade?
<wgrant> cpaelzer: If the old postrm fails then failed-upgrade is called on the new one instead. But if the old postrm does the wrong thing before it fails, or doesn't fail, I think you're out of luck.
<cpaelzer> wgrant: no it does not fail, it does things it should not do
<cpaelzer> yeah out of luck is hwo I feel for this one ...
<Unit193> One can personally fix it, but as far as the package goes...
<cpaelzer> thanks for confirming, I wanted to make sure before I pick a path to go on this
<RAOF> cpaelzer: From https://www.debian.org/doc/debian-policy/ap-flowcharts.html, it looks like you *could* wedge something in to the new preinst script?
<RAOF> As long as it's the postrm script of the existing package that's failing, your new preinst gets a chance to be run before it.
<Unit193> xnox: You seem to have done a lot of opencryptoki uploads, have you considered going the ITS route in Debian?
<xnox> Unit193:  ITS?
<Unit193> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging 'Package Salvaging' process, a polite way to take over if the maintainer is MIA.
<xnox> Unit193:  i am mostly interested around z13/z14/z15 support on s390x. Debian targets z196 but i don't have access to that hardware to test it there. So I don't know if my uploads at all work on Debian / for Debian. But they do on Ubuntu / for Ubuntu.
<xnox> Unit193: And I can only setup Ubuntu on the mainframes i have access to with the crypto hardware.
<xnox> Unit193:  so i'm not in a position to takeover the package in Debian, nor deal with Debian Bugs about it unfortunately.
<Unit193> I see.
<seb128> doko, the python-all B-D tricks didn't work, dh --with python2 is still not calling setup.py ... any idea how to debug? DH_VERBOSE if of no help there
<xnox> seb128:  which package, and which buildsystem is detected?
<xnox> seb128:  maybe you need --buildsystem=pybuild ?
<seb128> xnox, mailnag, the packaging is outdated but it built fine before focal, now it's empty, dh_auto_build doesn't call setup.py
<seb128> xnox, https://launchpadlibrarian.net/460064000/buildlog_ubuntu-focal-amd64.mailnag_1.2.1-1.1ubuntu2_BUILDING.txt.gz
<seb128> xnox, doko pointed to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949372 and suggested to build-depends on python-all as a workarund but that doesn't work ... and yes, pybuild would probably work but it's disturbing that a valid package build stop building, it's still a supported tool even if deprecated and should still work, other packages might be impacted
<ubottu> Debian bug 949372 in src:dh-python "dh-python doesn't accept python2 or python2.7 in the build dependencies" [Important,Open]
<doko> seb128: yes, pybuild is required
<seb128> doko, but that's a regression still and should be fixed, the same package builds fine and give a working deb in 19.10
<seb128> without using pybuild
<xnox> seb128:  non-pybuild has been deprecated for years now.
<seb128> also if pybuild is requied then dh should error out when it's not enabled
<seb128> xnox, right, deprecated != broken
<seb128> either it's deprecated and works or not surported  and removed
<xnox> seb128: it says it will be removed, and when, and it is removed when it was said it will be removed.
<xnox> seb128:  anyway, this is python2 package, why do we care?
<seb128> xnox, I'm not sure to parse correctly what you said, my point is that if it's not surported it should error out and not just do nothing, successful finish the build and give an empty deb
<xnox> seb128:  if you want old things to work, use old debhelper, on an older release.
<seb128> that's just error prone and misleading
<xnox> seb128:  debhlper does not provide backwards compat.
<seb128> that's an old package, synced for debian
<xnox> seb128: so the "should error out, instead of doing something odd" => is a bug in debhelper, it does that with all the things all the time.
<xnox> it pisses me off too
<seb128> glad we agree it's a bug/annoying, you seemed to argue it's fine to just silently give the wrong result
<xnox> seb128:  i don't think that's pybuild/dist-utils specific issue, that implicit build-systems go MIA
<xnox> seb128:  i'm saying that it was wrong to rely on implicit distutils behaviour for years now, and the transition to pybuild has been ongoing in debian, and i thought was complete.
<seb128> xnox, anyway, it's an old universe package, so not worth the effort
<xnox> it's not in testing
<seb128> right, it got recently removed because ti's still using python2
<xnox> RC buggy, we shouldn't have it either
<xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936981
<ubottu> Debian bug 936981 in src:mailnag "mailnag: Python2 removal in sid/bullseye" [Serious,Open]
<seb128> well, we have it in focal
<xnox> and blocking dbus / pygobject removals
<seb128> and the deb is empty
<seb128> do we do removal in released archived?
<seb128> archives
 * xnox still believes we should have just dropped python2 all the things
<xnox> seb128:  no, it's frozen.
<seb128> so I would prefer to see it fixes
<seb128> which is why I was looking at it
<xnox> seb128:  you can only upload SRU of a package that is empty, and fails to install.
<xnox> seb128:  "to see it fixes" => as in fix FTBFS in focal-sru?
<seb128> fixed
<seb128> it doesn't ftfbs
<xnox> i'm not sure we would be doing that for this package.
<xnox> oh in groovy?
<xnox> in groovy we should just RM remove it
<seb128> https://launchpad.net/ubuntu/+source/mailnag/1.2.1-1.1ubuntu2/+build/18546104
<seb128> no, focal
<seb128> xnox, bug #1874275 is what I was after fixing
<ubottu> bug 1874275 in mailnag (Ubuntu) "focal package doesn't contain executables, only manpages" [High,Confirmed] https://launchpad.net/bugs/1874275
<xnox> hahahhahahahhaha
<seb128> and yes, for groovy we can remove it
<xnox> so it's empty in focal good
<seb128> yes
<seb128> as said, dh_auto_build silently does nothing
<xnox> that looks perfect to me =))))))))))))))))
<seb128> :p
<xnox> yeah, you should have had an autopkgtest
<xnox> seb128:  so you are saying that most of our python2 packages in focal are empty?! that's great!
<seb128> troll mode on?
<seb128> I'm stopping there, I was looking at fixing a practical issue, we wasted more time in discussion that the issue is worth now
<xnox> =)))))))))))
<seb128> thanks for not helping me with a suggestion on how to get the actual problem resolved
<xnox> seb128:  do you want to open a bugreport against debhelper? i guess a task on https://bugs.launchpad.net/ubuntu/+source/mailnag/+bug/1874275 ?
<ubottu> Launchpad bug 1874275 in mailnag (Ubuntu) "focal package doesn't contain executables, only manpages" [High,Confirmed]
<seb128> I will still try pybuild
<xnox> maybe we can do soemthing to focal's debhelper/distutils/pybuild to figure out why distutils "is as if active"
<seb128> xnox, is it debhelper or dh-python?
<xnox> yet "clearly does nothing at all"
<xnox> seb128:  debhelper
<xnox> $ dpkg -S python_distutils.pm
<xnox> libdebhelper-perl: /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm
<xnox> seb128:  dh-python ships pybuild buildsystem, which is not active/used in this build at all.
<xnox> (but should be used, but must be manually activated with --buildsystem=pybuild)
<seb128> k, right
<seb128> xnox, thanks for the reply, I will do that after lunch
<xnox> seb128:  see https://wiki.debian.org/Python/Pybuild
<xnox> on how to move to pybuild
<xnox> pybuild was the preffered/default python build system since 2013 it seems *sigh*
<seb128> right, I was trying to avoid doing more work and updating the packaging but I guess that's the right way to fix it
<xnox> yeah
<xnox> seb128:  it's like me rewritting packaging in dh, instead of piles of manual debhelper calls interviened with cdbs and dpatch all of which stopped working because bugs got fixed.
<xnox> =/
<xnox> cause ain't nobody will fix that pile of things
<seb128> LocutusOfBorg, hey, what does '  * Rebuild against bootstrapped gdk-pixbuf' means in https://launchpad.net/ubuntu/+source/gdk-pixbuf/2.40.0+dfsg-4build3 ? it seems to have made it unhappy, http://autopkgtest.ubuntu.com/packages/g/gdk-pixbuf/groovy/amd64
<seb128> ERROR:../tests/pixbuf-jpeg.c:46:test_inverted_cmyk_jpeg: assertion failed (error == NULL): has 4 channels but should have 3 (gdk-pixbuf-error-quark, 0)
<wgrant> seb128: gdk-pixbuf has a very tight build-dep loop with itself, which means that it's impossible to build it if its arch-indep and arch-dep binaries are out of sync at all (e.g. amd64 finishes before riscv64 starts). That version was built in a silo against the version in -release
<kanashiro> thanks mwhudson :)
<seb128> wgrant, k, thanks, looks like the tests are in fact new and started failing with -4 but due to the hackery the -4, build1 and build2 uploads never got tested
<wgrant> Ah, makes sense.
<wgrant> (also it's a really really gross loop)
<ahasenack> cjwatson: hi, just a ping that I finally updated https://salsa.debian.org/auth-team/libfido2/-/merge_requests/4
<LocutusOfBorg> seb128, you can see tests for build1 and build2 probably on bileto!
<seb128> LocutusOfBorg, it's not easy to jump back from launchpad ubuntu page to there: )
<cjwatson> ahasenack: ah, thanks, queueing up
<ahasenack> cool
<ogra> tjaalton, seems there is some strange behaviour left with using fullscreen apps when using the modesetting driver ... looks like all apps i switch to fullscreen cause several iterations through possible frambuffer resolutions with re-scales of the screen
<ogra> tjaalton, i.e. this is my journal when i swithc vlc to fullscreen: https://paste.ubuntu.com/p/VnRGRgcxJx/
<ogra> each of these "Allocate new frame buffer ***** stride" causes a re-scale and flash of the screen ... eventually it finds a proper resolution and stays there ... but the experience is rather odd ... i see the same using i.e. stellarium ..
<tjaalton> ogra: using fractional scaling?
<ogra> yes
<tjaalton> blame that then
<tjaalton> .)
<ogra> 4k 13" screen :)
<tjaalton> :)
<ogra> ok
<tjaalton> well, use a non-fractional scaling value
<tjaalton> does it still suffer from it with that?
<ogra> then i need to turn the touchscreen back on to manage the buttons with my palm :P
<ogra> non-fractional has really no usable values ... but i can try later with it to see if that behaves differenty
<tjaalton> how about '2'?
<ogra> giant :)
<tjaalton> okay
<ogra> 10 is perfect :)
<ogra> err
<ogra> 150
<tjaalton> try wayland?
<ogra> yep, 200 causes no scaling or flashing ... i'll go and blame duflu then
<ogra> :)
<tjaalton> not saying there isn't a bug in the X stack.. but it's caused by FS
<ogra> yep, it definitely is
<Trevinho> wgrant: hey, thanks for the riscv patches for the shell stack, however please next time we would appreicate if you could update also the vcs (in debian's salsa as per https://discourse.ubuntu.com/t/psa-ubuntu-gnome-packages-development-moved-to-debian-salsa/14900)
<rharper> smoser: for cloud-utils, I'm planning to branch ubuntu/devel -> ubuntu/focal and then push in the deb/control changes for fdisk/gdisk into ubuntu/devel ;  similar to our new series process, that sound good ?
<smoser> https://code.launchpad.net/~smoser/cloud-utils/+git/cloud-utils/+merge/383431
<smoser> rharper: ^
<rharper> ok
<smoser> but as far as a branch goes.. yeah, the intent is to do the same general workflow as cloud-init does.
<rharper> smoser: ok
<bdmurray> marcustomlinson: could you please stop setting apport bugs to incomplete?
<bdmurray> marcustomlinson: Oh, those emails are from March my bad
 * Eickmeyer is once again trying to figure out why Ubuntu Studio's groovy iso failed, and can't blame Inkscape
<Eickmeyer> I could really use some help on this one.
<Eickmeyer> Bad timing: I am trying to change the DE but something unrelated has caused the ISO to FTB.
<Trevinho> anyone in the SRU team, could please reject mutter with version   3.28.4+git20200505-0ubuntu20.04.1 in the bionic queue? I've re-uploaded it with the right version :/
<xevious> bryce: Congrats on Inkscape 1.0!
<bryce> xevious, thanks :-)
<xevious> I'm very excitedly downloading the Mac version now.
#ubuntu-devel 2020-05-06
<bryce> xevious, seen our video?  https://www.youtube.com/watch?v=f6UHXkND4Sc
<xevious> WAIT Canvas rotation??
<xevious> Great video! Thanks for the link
<seb128> ddstreet, hey, could you commit your network-manager fixes to the vcs?
<ddstreet> seb128 sure, i forgot again, sorry
<seb128> ddstreet, np!
<paride> Hey. Has Focal been left out from https://changelogs.ubuntu.com/meta-release-lts on purpose, perhaps waiting for the first point release?
<paride> Laney, maybe you know this bit ^^
<Unit193> LTS to LTS usually is available at the first point release.
<paride> Hi Unit193 :) I thought that was the reason. Yet I think it prevents `do-release-upgrade -d` from upgrading from focal to groovy
<paride> Maybe Focal should be put in meta-release, and put in meta-release-lts after .1 is out?
<Unit193> I believe you can change the prompt in /etc/update-manager/* to 'normal'
<paride> Unit193, yeah, that doesn't work
<paride> actually I quite remember it working on my laptop just a few days after the Focal release, now I can't get it working anymore, and can easily reproduce it on a Focal LXD container
<Unit193> Development usually takes a month or two for a normal upgrade, I *think*.  I could be wrong.
<paride> OK, maybe everything is just as it should be
<Unit193> The LTS choice obviously won't ever offer groovy.
<Unit193> If you want to hop, you can use the Debian way.
<paride> That works, I'm already using Focal on my laptop, but now I wanted to upgrade a development machine and I was surprised of not being able to do so using do-release-upgrade
<paride> this with Prompt=normal in /etc/update-manager/release-upgrades
<cpaelzer> Hi, I have a very weird FTBFS in bionic that still worked 4 weeks ago, after tracking down what I thought to be the root cause I'm kind of lost - there must be a rootier one that I still miss.
<cpaelzer> it comes down to a puzzling 'warning: "sizeof" is not defined, evaluates to 0 [-Wundef]'
<Laney> paride: It's really a bdmurray thing, but it's in meta-release-lts-development which I think is normal
<cpaelzer> shouldn't that be part of the language - how can it be missing?
<Laney> for upgrading to *groovy*, perhaps we want groovy in meta-release-development, not sure
<cpaelzer> to make it more weird, not only did it work a few weeks ago - it also works in a bionic-VM but fails in a bionic-sbuild chroot
<paride> Laney, thanks, I missed the -development one. Let's wait for bdmurray then.
<cpaelzer> doko: ^^ would you have any idea why sizeof could be considered missing?
<cjwatson> cpaelzer: I think anyone looking at this is going to need more context
<cpaelzer> I didn't want to drop too much text into IRC, but you are right cjwatson - anyone needing more context can find it in https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361/comments/55 and later comments
<ubottu> Launchpad bug 1847361 in qemu (Ubuntu Eoan) "Upgrade of qemu binaries causes running instances not able to dynamically load modules" [Undecided,Fix committed]
<paride> juliank, hi. On https://bugs.launchpad.net/ubuntu/+source/rust-ripgrep/+bug/1868517 , it seems to me that fd-find *does* include the file
<ubottu> Launchpad bug 1868517 in rust-fd-find (Ubuntu) "Stray /usr/.crates2.json file" [Undecided,Incomplete]
<juliank> paride: where?
<paride>  /usr/lib/cargo/.crates2.json as the others
<juliank> paride: I looked at the deb on amd64, and it's not in there
<paride> oops that's the normal place for that file to be?
<juliank> paride: huh, now i see it
<juliank> Not sure what happened, sorry
<juliank> paride: Ah, I guess it installs into a different place
<juliank> paride: The others install into /usr/.crates2.json, this installs to /usr/lib/cargo/.crates2.json
<paride> not sure on the reason for the difference, but I think we want it rebuilt too
<juliank> Also dotenv needs rebuild too
<juliank> paride: I basically piped apt-file find /usr/.crates2.json output to rebuild-for script, hence did not notice /usr/lib/cargo ones
<juliank> Building rebuilds
<paride> that was certainly a good idea. I didn't notice some packages put that file elsewhere
<paride> thanks!
<juliank> rebuilds uploaded
<juliank> I think some stuff is FTBFS
<paride> :/
<juliank> Yeah rust-sniffglue
<juliank>  sbuild-build-depends-rust-sniffglue-dummy : Depends: librust-syscallz-0.12+default-dev
<juliank> not sure what's going on there
<juliank> as the matching librust-syscallz is in proposed
<juliank> provided by librust-syscallz-dev 0.12.0-1 (= 0.12.0-1)
<juliank> it's also not in dep-wait, which you'd expect if the dep were missing
<smoser> anyone able to review https://code.launchpad.net/~chad.smith/ubuntu/+source/sbuild-launchpad-chroot/+git/sbuild-launchpad-chroot/+merge/382529 and comment on bug 1872163 ?
<ubottu> bug 1872163 in sbuild-launchpad-chroot (Ubuntu) "focal chroots broken due to change in sources.list" [Undecided,Confirmed] https://launchpad.net/bugs/1872163
<smoser> how is it that sbuild-launchpad-chroot can be so busted?
<rbasak> ahasenack: here's the fix for your bug: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/383513
<rbasak> If you fancy reviewing it, but if not I guess bryce will get to it?
<rbasak> I'm going to hold on announcing 0.10 and put this in a 0.10.1 instead.
<Odd_Bloke> smoser: It's in universe, who would you expect to be making sure it isn't busted?
<ahasenack> rbasak: ok for 0.10.1
<ahasenack> yeah, I'll let him review
<smoser> Odd_Bloke: I honestly thought that package specifically was used by developers.
<smoser> so... "everyone".
<smoser> it really is the easiest way to get a launchpad-like build environment locally.
<Odd_Bloke> smoser: I wasn't aware of it until I joined the server team, FWIW.
<smoser> i didn't use it until i was aware of it either.
<smoser> and i had some list of "create and  maintain schroot" commands
<smoser> that never exactly mimic'd what was on launchpad
<smoser> and were a pita to set up
<rbasak> cpaelzer: reimport of qemu, chrony and gpsd in progress. They will be force pushed as they complete. I'll let you know.
<cpaelzer> thanks rbasak
<ackk> hi, could someone please sponsor this upload to groovy https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/383411 ?
<rbasak> cpaelzer: gpsd done. qemu still in progress. chrony failed - more on that after I investigate.
<rbasak> I've just spotted a potential problem in the gpsd reimport
<rbasak> Only minor but will cause hash mutation, so I may have to reimport again after fixing it
<ackk> juliank, hi, any chance you could take a look at the MP above? ^
<juliank> ackk: not today likely
<ackk> juliank, ok, no worries. it's not super-urgent
<juliank> ackk: If still needed, ping me tomorrow at 9 CEST?
<juliank> Or I can look myself
<juliank> s/at/after|around/
<ackk> juliank, yeah sure, thanks
<cpaelzer> ok rbasak
<cpaelzer> png me once done
<ogra> waveform, FYI https://ograblog.wordpress.com/2020/05/06/using-the-new-12mp-pi-cam-for-video-conferencing-on-your-desktop/ ... the new cam works really well on UbuntuCore18 !
<rharper> is there a command line tool to print out your own launchpad ppas?
<rbasak> rharper: lp-shell -c'print("\n".join(ppa.web_link for ppa in lp.me.ppas_collection))'
<rbasak> Or if you want something other than the web_link, choose from https://launchpad.net/+apidoc/devel.html#archive
<Eickmeyer> LocutusOfBorg: Looks like a nasty dep-wait on inkscape for i386. I talked to vorlon about it, and he said it was another component that is FTBFS causing the problem?
<Eickmeyer> I had to remove inkscape from Ubuntu Studio
<Eickmeyer> Temporarily
<rbasak> cpaelzer: bug found and fix proposed: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/383522
<rbasak> cpaelzer: qemu is still going. I'll cancel it.
<rbasak> cpaelzer: so the current status is: qemu and chrony: no changes yet, until I land a bugfix. gpsd is reimported, but I'm afraid I'll have to do it again after the bugfix lands. Sorry.
<rbasak> And thank you for letting me test on you!
<rharper> rbasak: nice, thanks
 * rharper finds lptools 
<LocutusOfBorg> Eickmeyer, should we keep inkscape/i386? vorlon ^
<LocutusOfBorg> ?
<vorlon> LocutusOfBorg: yes, the germinate output will tell you why.
 * Eickmeyer has no objections to removing inkscape/i386
<LocutusOfBorg> I'm not sure I know that germinate link
<LocutusOfBorg> https://people.canonical.com/~ubuntu-archive/germinate-output/ ?
<vorlon> https://people.canonical.com/~ubuntu-archive/germinate-output/i386.groovy/
<LocutusOfBorg> pacemaker
<LocutusOfBorg> https://people.canonical.com/~ubuntu-archive//germinate-output/i386.groovy/rdepends/inkscape/inkscape
<LocutusOfBorg> and game-data-packager
<LocutusOfBorg> sigh
<Eickmeyer> Well, wonderful.
<LocutusOfBorg> I wanted to fix riscv64, and looks like I got it right
<Eickmeyer> Yeah, so far so good.
<LocutusOfBorg> next step after I finish this bootstrap is to look at it
<LocutusOfBorg> https://bileto.ubuntu.com/#/ticket/4042
<Eickmeyer> The issue with inkscape/i386 is gtkmm3.0/i386 which is FTBFS, looks like it will need some work that is way over my head.
<waveform> rbasak, I think I know what's going on with the git-ubuntu u-boot merge
 * ahasenack thinks under the water
<waveform> rbasak, the thing that got committed as the 2019.07+dfsg-1 commit wasn't *quite* 2019.07+dfsg-1; there's several files in there that shouldn't be
<waveform> rbasak, specifically the rpi patches (and u-boot-rpi.postinst) which are unique to us; I must've done something wrong in that rebase, and it didn't get caught. Anyway it means that there's no commit there that can be accurately marked as import/2019.07+dfsg-1
<waveform> rbasak, if you want to fix up the history by burning the manually imported commits there I'm okay with that?
<rbasak> waveform: thanks; I'll look at it later if that's OK
<RikMills> apt-get install libclang-9-dev
<RikMills> The following packages have unmet dependencies:
<RikMills>  lib32gcc1 : Depends: gcc-10-base (= 10-20200425-1ubuntu2) but 10-20200502-1ubuntu1 is to be installed
<RikMills> doko: ? ^
<waveform> rbasak, sure - no prob - ping me if you need any details
<blackboxsw> paride: thanks for the review on my sbuild-launchpad-chroot branch & smoser for continued efforts there
#ubuntu-devel 2020-05-07
<seb128> hey SRU team, where is the code that generate the 'Autopkgtest regression report' comments/emails?
<seb128> sil2100, ^ you probably know?
<seb128> sil2100, also could you review the pulseaudio/focal pending SRU, it's a trivial fix to a recent oem patch that landed before release and create a regression with jack headsets, would be nice to see it accept
<seb128> sil2100, also accountsservice, another one for a segfault which takes gdm and the session down (also mutter, gnome-shell would be nice but those aren't trivial to review if you want to read the diff so depends how buy you are)
<sil2100> seb128: hey! It's in the britney2 code if anything
<sil2100> seb128: I'll try to look at some of those, I'm doing SRUs now but I don't know how many more I'll be able to do!
<seb128> sil2100, thanks, small annoyance but e.g https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1876125/comments/3 the p.c.c url is cut by a new line in tb and such clicking on it doesn't work for me, it's fine on launchpad though
<ubottu> Launchpad bug 1876125 in evolution-data-server (Ubuntu Focal) "SRU the current 3.36.2 stable update" [Undecided,Fix committed]
<seb128> sil2100, pulseaudio is trivial and accountsservices as well, and they are high impact, please just open the diffs to give them a chance, shouldn't take you long :)
<seb128> sil2100, I understand if gnome-shell&co you don't have time for today, no worry
<seb128> sil2100, k, so the email / url issue is an ancient launchpad issue, bug #28649
<ubottu> bug 28649 in Launchpad itself "mail word wrapping breaks urls and other words" [Low,Triaged] https://launchpad.net/bugs/28649
<seb128> at least not your fault :)
<ackk> juliank, hi, any chance you could review https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+ref/snap-channel-2.7-default today?
<juliank> ackk: on it
<ackk> juliank, thanks!
<seb128> sil2100, also gnucash is a one liner fix to the icon so it's valid
<seb128> sil2100, thanks!
<sil2100> seb128: I think that's as much as I can do today! Since I need to move on to non-SRU work now :)
<seb128> sil2100, that's enough to make me happy, thanks again and sorry for the nagging :)
<sil2100> No worries, yw!
<sil2100> I don't mind being pinged for this stuff, especially that we do have a few packages in the queue
<sil2100> I think we all need more hours in a day!
<Unit193> Try cutting sleep back to 5 or 6 hours, it helps a bit.
<Unit193> (I find less than 4 makes the day a bit long though.)
<LocutusOfBorg> vorlon, I fixed inkscape gtk+mm dependency, but I'm left with gdl one. According to build logs, the previous version was embedding gdl while now it is used the system one. Would it be possible to add i386 back to libgdl-3-dev?
<LocutusOfBorg> mapreri, ^^ please tell me if I'm wrong
<LocutusOfBorg> cjwatson, looks like libpoe-test-loops-perl autopkgtest is now failing because of new perl autodep8. I'm dropping the delta you introduced back in xenial days
<steveire> When I run ldd I get this:
<steveire> jenkins@0b769a54e699:~/root/workspace/products/build$ ldd /usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so | grep tiff
<steveire>         libtiff.so.5 => /lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fca14345000)
<steveire>         libgeotiff.so.5 => /lib/x86_64-linux-gnu/libgeotiff.so.5 (0x00007fca109cc000)
<steveire> But when I try to link to the lib, I get this:
<steveire> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so: undefined reference to `TIFFReadRGBAStrip@LIBTIFF_4.0'
<steveire> /usr/bin/ld: /lib/x86_64-linux-gnu/libgeotiff.so.5: undefined reference to `_TIFFmemcpy@LIBTIFF_4.0'
<cjwatson> locutus_: fine by me
<steveire> Note the different SO numbers. Is opencv broken on 20.04?
<cjwatson> steveire: I haven't looked in detail, but you can't necessarily assume that the SONAME in the actual library matches the filename
<steveire> cjwatson: Ok, nevertheless, linking fails.
<cjwatson> Right, it might be broken for some other reason, just not that one :)
<steveire> Ok. Known issue?
<cjwatson> (I don't mean SONAME, I mean version definitions)
<cjwatson> I don't know, sorry, not a libtiff/opencv person myself
<cjwatson> # objdump -p /lib/x86_64-linux-gnu/libtiff.so.5 | grep -A2 'Version definitions'
<cjwatson> Version definitions:
<cjwatson> 1 0x01 0x0bba1ce5 libtiff.so.5
<cjwatson> 2 0x00 0x0dfcf290 LIBTIFF_4.0
<cjwatson> Have you looked in the bug tracker?
<steveire> Not yet
<steveire> Does that objdump output mean something relevant?
<steveire> Not so familiar with it.
<cjwatson> It means that libtiff.so.5 does indeed contain symbol versions ending with @LIBTIFF_4.0, so just confirming my earlier note that the apparently 4 vs. 5 difference is a red herring
<steveire> Ok thanks
<steveire> Can I somehow tell if TIFFReadRGBAStrip is in the library? nm doesn't work because it's stripped I guess.
<cjwatson> nm -D should work
<cjwatson> This feels more likely to be a linker invocation bug
<cjwatson> Do you have -ltiff on your ld command line after -lopencv_imgcodecs?
<cjwatson> (Well, probably a gcc command line in fact, since normally you'd use gcc as the linker, but either way)
<steveire> Indeed. I had an old libtiff on my system which the buildsystem was finding.
<steveire> Fixed that and the issue is gone, thanks!
<cjwatson> Ah good
<cpaelzer> hi, is there any minimum amount of cpus I can expect our autopkgtest environments to always have?
<danboid> Does zsys plan to support hot-swapping spare ZFS disks?
<danboid> zed doesn't seem to be able to do this
<suniel> Hi all, I have a board based on Rockchip RK3399 64-bit SOC based on ARMv8A.The board can boot from the following devices:Micro SD, emmc, USB, NVMe SSD.I have installed ubuntu focal fossa with LXDE Display manager.(I have downloadedfocal-base-arm64.tar.gz and installed all the necessary packages). The board boots fine with ubuntu focal fossa
<suniel> installed on Micro SD, emmc, USB.I am using Linux kernel 5.5.10 from kernel.org.When the board is booted via NVMe SSD(this NVMe SSD is connected via PCIe on to the main board), the board looses power(powered off) automatically during the bootprocess. This happens and once kernel loads and systemd trying to fully load ubuntuuser space.In the process
<suniel> of identifying what is causing the problem, found out that systemd-udevd is the one.when loading rules from udev/rules.d, some of them are creating a problem.so removed all the rules apart from:50-udev-default.rules, 60-drm.rules, 90-console-setup.rules, 60-block.rules60-serial.rules, 99-systemd.rules.By doing the above change, i am able to get a
<suniel> basic command prompt. It says LXDE displaymanager is started but I couldnt get display.Can any one please comment on this issue. Thanks
<xnox> rs2009:  hi
<rbasak> waveform: I'm looking at your u-boot "git ubuntu merge start" failure
<rbasak> waveform: import/2019.07+dfsg-1 is correctly an ancestor of debian/sid
<rbasak> waveform: but your supplied upload/2019.07+dfsg-1ubuntu1 commit, which was adopted, didn't have import/2019.07+dfsg-1 from Debian as an ancestor
<rbasak> So I think your assessement is accurate, but this isn't a bug in git-ubuntu
<waveform> rbasak, yup
<rbasak> You'll need to rebase by hand - so you can still use the workflow, but you'll have to determine the base by hand, and "merge start" won't help you
<waveform> rbasak, (well other than the fact it didn't pick it up on import :)
<rbasak> It's not supposed to pick it up on import
<rbasak> Your upload tag was trusted on a "developer knows best" basis
<waveform> me? know best? ha! :)
<rbasak> :)
<rbasak> BTW, there's a separate bug whose fix is awaiting review
<rbasak> After that I'd like to reimport u-boot again
<rbasak> Hopefully that will be the final time
<waveform> ok
<rbasak> So maybe hold off for a day or two if you're in no hurry?
<waveform> sure
<rbasak> Thanks
<Teduardo> Hello, I noticed that if you don't specify a storage configuration in an autoinstall file the usable space in the final install is 1% of the size of the drive. Also it doesn't really follow the default of the installer.
<Teduardo> Anyone know which project I should file a bug in?
#ubuntu-devel 2020-05-08
<jbicha> doko: Ubuntu's containerd currently needs this delta: https://launchpad.net/ubuntu/+source/golang-defaults/2:1.13~1ubuntu1 (as seen on the NBS report)
<suniel17> Hi all, I have a board based on Rockchip RK3399 64-bit SOC ARMv8A.I have installed Ubuntu focal fossa with LXDE Display manager. I am bootingvia NVMe SSD, the board loses power(powered off) automatically duringthe boot process. found out that this is happenning when systemd-udevd is setting up ubuntu user space (loading rules from udev/rules.d).Can
<suniel17> any one please comment on this issue and suggest how to fix the problem. Thanks
<LocutusOfBorg> vorlon, xnox can I please have initramfs-tools merged? the merge is trivial, I need some shellcheck test fixes
<LocutusOfBorg> http://launchpadlibrarian.net/478820694/initramfs-tools_0.136ubuntu6_0.136ubuntu7.diff.gz
<LocutusOfBorg> for now I went to this ^^
<theloudspeaker> Can someone confirm this: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1877553
<ubottu> Launchpad bug 1877553 in gdm3 (Ubuntu) "wifi gets automatically disabled when screen is locked and can be enabled only after a reboot." [Undecided,New]
<theloudspeaker> Was there in 19.10 too.
<ackk> juliank, hi, replied to your comments on https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/383411. I guess I should drop the focal MP as that's not the way to SRU it?
<juliank> ackk: right, you probably want an SRU bug and then a 0.6.1 for focal (or 0.7~ubuntu20.04.1, meh)
<juliank> ackk: I think I need to consult with vorlon on installing snaps without /ubuntu-$series branches, as I think the same rationale we have for seeded snaps also applies to deb2snap transitional packages.
<juliank> ackk: Per-release branches should always be opened for a new release at archive opening (or earlier)
<ackk> juliank, ok, yeah we're not entirely sure about the policy, the reason for the fallback is that if we don't do that, we'll need to create /ubuntu-XX.YY branches for all tracks for each ubuntu release
<juliank> ackk: The thing is that you also don't want someone to install foo/ubuntu-20.04 in bionic, then move them to mainline foo branch in 20.10 because there is no foo/ubuntu-20.10 branch
<juliank> and then later when they reach 22.04 they are still on foo, when you'd probably want them back on foo/ubuntu-22.04
<juliank> ackk: I don't think opening and closing the ubuntu-XX.YY branches is a huge effort, though I have not done it
<juliank> AFAIUI, It's like a one-time thing you do at archive opening and then you don't need to worry about it
<ackk> juliank, sure, it's more that we have to do it for multiple tracks I guess
<ackk> I guess you need to have tracks for all LTS->LTS+1 releases for all maas versions that get releases between LTS and LTS+1
<ackk> juliank, which becomes quite a maintenance burden if you have to later keep them open
<ackk> although I guess since maas is maintained by canonical there's no real reason to have different versions in 2.7/stable/ubuntu-20.04 and 2.7/stable
<juliank> ackk: I thought you close them, and snapd automatically falls back to the 2.7/stable one until it sees something published in 2.7/stable/ubuntu-20.04, so there is no overhead until you have to do it for some reason
<juliank> Its just giving you that option to publish a snap specifically for 20.04, does not mean you have to make use of it
<ackk> juliank, right. I was talking about the overhead of keeping them open if you need (as you'll eventually end up with a lot of them. but I think we basically never care about having /ubuntu-X.Y open
<ackk> juliank, out of curiosity, does d-r-u move all snaps across /ubuntu-$release channels, or just the seeded ones?
<juliank> ackk: I've not looked at what it does
<ogra> ackk, how would it do that for snadom snaps ? not all snaps have an /ubuntu-$release channel
<ogra> *random
<ackk> ogra, not all snaps. I was wondering if d-r-u would look at all snaps currently tracking /ubuntu-$release and move them to /ubuntu-$release+1
<ackk> well, or whatever you're upgrading to
<ackk> ogra, IOW if there's an assumption that if you'r on an /ubuntu-* branch, one will exist for the target release
<ackk> is there a documented policy about this somewhere?
<ogra> i know there is such an assumption ... for all canonical maintained official snaps (i.e. snap-store, livepatch ...)
<ogra> but i have also no idea if the upgrader switches you over (though i would expect so)
<ackk> ogra on all risks, or just stable?
<ogra> i think just stable
<ogra> $ snap info snap-store|grep tracking
<ogra> tracking:     latest/stable/ubuntu-20.04
<ogra> thats an upgraded system ... (16.04->18.04->20.04)
<ackk> ogra, so, groovy gets opened, expectation is that /ubuntu-20.10 are created for all tracks of a canonical-maintained snap
<ackk> ?
<ackk> ogra or just current track onwards?
<ogra> heh, good question
<ackk> I guess it would have to be all, if I'm on 2.7/stable/ubuntu-20.04 and upgrade to groovy I'd get to 2.7/stable/ubuntu-20.10, right?
<ackk> even if by 20.10 2.8 is released and it's the default track
<ackk> ogra, and I haven't even mentioned epochs :)
<bswartz> Anyone know where I can find the current maintainer of the open-iscsi package?
<ahasenack> bswartz: ubuntu doesn't have the concept of specific  maintainers, you are better off checking the changelog file for recent entries
<ahasenack> see if there is a pattern
<ahasenack> bswartz: that being said, https://launchpad.net/ubuntu/+source/open-iscsi hints that the ubuntu foundations team is its owner
<bswartz> Or do I need someone who works for Canonical to press the button?
<bswartz> I also want this fix to go into Debian, but one step at a time
<ackk> juliank, when you say "it's part of archive opening to create branches" do you mean as a policy, or is there something in place that does it for all seeded snaps?
<juliank> ackk: there's a step in archive opening guide to ping maintainers of seeded snaps, probably should also ping maintainers of deb2snap transitioned snap I suppose
<ackk> juliank, I see. should maas be on the list? (or maybe it is already?)
<juliank> I think this is a broader policy question that needs to be discussed in a broader, less real-time forum
<juliank> I think maas is a unicorn of sorts wrt seeding, but not sure
<juliank> The deb was seeded, but maas was then unseeded
<juliank> but as I said, I think it makes sense to apply the same rules to deb2snap transitional packages as for seeded snaps
<juliank> and hence, that also involves pinging the relevant people at archive opening
<juliank> ackk: are you subscribed to ubuntu-devel?
<juliank> ackk: I figure i'd write an email
<ackk> juliank, I don't think I am
<juliank> I'll use a CC then
<ackk> juliank, I am now :)
<ackk> at least, I think
<xnox> ackk: have you seen https://wiki.ubuntu.com/UbuntuSeededSnaps ?
<irreleph4nt> Hi. Have any issues with booting 20.04 over the network (iPXE) been brought to your attention yet? I found the following but it's marked as fixed: https://bugs.launchpad.net/subiquity/+bug/1866775
<ubottu> Launchpad bug 1866775 in Ubuntu on IBM z Systems "subuquity installation on s390x fails (zVM and LPAR)" [Critical,Fix released]
<ackk> xnox, I think I've seen it in the past, anything specific you're pointing out?
<irreleph4nt> The problem I am having is that booting 20.04's kernel and initrd fails with "Unable to find a live file system on the network"
<irreleph4nt> Booting the 20.04 squashfs with a kernel and initrd from 1910 however works. So the problem seems to be with those 2004 ships with
<irreleph4nt> This is on amd64 BTW
<juliank> xnox: maas is not a seeded snap, but it is transitioning a formerly seeded deb to a snap
<juliank> Anyway, my email is complete
<juliank> I shall send it
<juliank> I wish I could send from my @ubuntu.com address, but gmail does not let me
<juliank> developers should have mail
<juliank> :D
<ogra> gmail lets you if you set up an alias for it
<juliank> xnox: Maybe we should just seed all snaps that are deb2snap transition targets without actually installing them anywhere
<juliank> ogra: Well, my personal one does, but canonical.com one does not
<ogra> (unless you send from canonicals gmail i guess ... never used that)
<ogra> yeah ...
<juliank> ogra: I need to resplit my email accounts at some point
<ogra> i'm using IMAP over here ...
<juliank> The plan was to split email into canonical | foss | personal, rather than canonical + ubuntu | personal + debian
<ackk> juliank, ftr gmail is also telling me that it can't verify that your address is actually valid, which seems weird...
<ackk> juliank, thanks for the email, btw
<juliank> ackk: It's probably because it was resent by the mailing list,rather than directly from the server
<ogra> yeah, sounds sane ... i split mine into two ..  canonical| all-other
<ahasenack> tjaalton: hi, any plans to update sssd's source format to 3.0 quilt?
<xnox> juliank:  my gmail sends emails from @ubuntu.com
<xnox> (from webui)
<xnox> irreleph4nt:  hi, the bug you point to has nothing to do with amd64
<xnox> irreleph4nt:  are you booting server or desktop? and what is your full commandline?
<irreleph4nt> xnox, I am booting amd64 Desktop. Let me get you the cmdline real quick
<xnox> irreleph4nt:  to boot amd64, I expect something like: ip=dhcp url=http://releases.ubuntu.com/focal/ubuntu-20.04-live-server-amd64.iso for server
<xnox> irreleph4nt: to desktop i expect something like: ip=dhcp url=http://releases.ubuntu.com/focal/ubuntu-20.04-desktop-amd64.iso
<xnox> you can also use https i think as well.
<xnox> irreleph4nt:  also would be nice to see what arguments you used with 19.10 release, vs the 20.04 LTS release
<irreleph4nt> xnox, the following works just fine for 19.10 but as said earlier fails for 20.04:
<irreleph4nt> "vmlinuz initrd=initrd root=/dev/nfs boot=casper netboot=nfs nfsroot=192.168.0.8:/var/www/html/pxe/live/ubtu2004/ locale=de_DE.UTF-8 quiet splash ip=dhcp"
<irreleph4nt> The only other arguments in the iPXE config point to the vmlinuz and initrd of 20.04
<irreleph4nt> the folder this config points to obviously contains an extracted 20.04 Desktop iso
<xnox> irreleph4nt:  ok, so you are using nfs mount (btw you don't have to, http is usually faster)
<xnox> irreleph4nt:  can you please check if the uuids match? i.e.
<xnox> irreleph4nt:  i.e. what is $ cat /var/www/html/pxe/live/ubtu2004/.disk/casper-uuid-generic
<xnox> and what is uuid in the initrd?
<irreleph4nt> how do I find the uuid in initrd?
<xnox> one sec.
<xnox> temp=$(mktemp -d)
<xnox> unmkinitramfs /mnt/casper/initrd $temp
<xnox> cat $temp/main/conf/uuid.conf
<xnox> 7e9d6f34-8cf6-41a3-9cbd-7532e21aedc0
<xnox> so the initrd that is served over ipxe should contain above uuid.conf & it should match the nfs mount's .disk/casper-uuid-generic
<xnox> irreleph4nt:  because the kernel&initrd you boot, must match the iso you try to nfs mount, because it must have all the right runtime kernel modules. If the two don't match, it means that you have missmatched vmlinuz&initrd vs the .iso you are trying to boot.
<xnox> irreleph4nt:  sometimes that is intentional, in case you want to like modify your iso. In that case you can pass kernel cmdline argument "ignore_uuid" => but then your installs might fail.
<xnox> irreleph4nt:  are you sure that the vmlinuz & initrd that ipxe is serving to boot, are the identical ones as the ones in /var/www/html/pxe/live/ubtu2004/casper/{initrd,vmlinuz} ?
<irreleph4nt> xnox, unless my brain malfunctioned, I am 90% sure I copied those from the same loop mount of the iso. Just getting you the uuids.... gimme one sec
<alkisg> lsinitramfs initrd.img|grep casper, should tell you if it has casper
<xnox> alkisg:  that's not sufficient to distinguish 19.10 vs 20.04
<xnox> irreleph4nt:  you may have copied the right ones, but like your ipxe is for some reason serving the old one.
<alkisg> I mean, in case the initrd.img didn't come from an iso, but it came from some local installation, and doesn't have casper
<irreleph4nt> Okay, so I found one potential problem: the .disk folder does not exist at the nfsroot
<irreleph4nt> let me nonetheless check the uuid in initramfs
<xnox> irreleph4nt:  you can also boot with "break=top" which will give you shell inside the initrd, and then you can do just $ cat conf/uuid.conf
<tjaalton> ahasenack: probably should
<ahasenack> :)
<xnox> irreleph4nt:  right "cp /mnt/*" will not copy .disk, ideally you should rsync or mount stuff at /var/www/html/pxe/live/ubtu2004/
<xnox> like $ cp -a /mnt /var/www/html/pxe/live/ubtu2004/
<xnox> irreleph4nt:  did the 1910 one have .disk dir?
<xnox> irreleph4nt:  i wonder, if I should be printing more help on how to troubleshoot when we fail to find network mounts.
<xnox> irreleph4nt:  we really do need .disk (cause we fetch a lot of configuration from there, which id "dynamic")
<irreleph4nt> xnox, so I just tried your sequence from above
<irreleph4nt> at step two tho I am getting "unkminitramfs not found"
<irreleph4nt> unmk*
<xnox> irreleph4nt:  i see typo
<xnox> oh
<xnox> irreleph4nt:  it's a tool shipped on ubuntu by default. from the initramfs-tools package.
<xnox> initramfs-tools-core that is
<irreleph4nt> well, my stock initramfs (as copied from the disk image) tells me it can't find it :/
<irreleph4nt> let me check the spelling again
<xnox> irreleph4nt: hm? unmkinitramfs is to be used on a regular host system, to unpack initramfs. We don't ship that, inside the initrd.
<xnox> irreleph4nt:  if you have unpacked the initrd, or have dropped to shell inside the initrd, simply cat conf/uuid.conf
<xnox> irreleph4nt:  if you want we can google hangout and i can share my screen to show you things.
<irreleph4nt> xnox, ah, now I get it
<xnox> =) sorry if i gave confusing instructions
<irreleph4nt> Okay. I just compared the UUID from within initrd to the UUID in the iso's .disk file. Those two match
<irreleph4nt> So is the issue that my nfsroot does not contain a .disk folder then?
<xnox> yes
<xnox> it should
<xnox> btw, if i were you i would switch from nfs to http, i.e.
<irreleph4nt> xnox, well I switched from http to nfs actually
<irreleph4nt> reason being that PXE requires HTTP instead of HTTPS
<irreleph4nt> which I can't serve easily in my local network
<xnox> I.e. vmlinuz initrd=initrd url=http://192.168.0.8/ubuntu-20.04-desktop-amd64.iso locale=de_DE.UTF-8 quiet splash ip=dhcp
<xnox> irreleph4nt:  fair enough.
<irreleph4nt> xnox, just checked: 1910's nfsroot also does not have a .disk folder
<irreleph4nt> but works flawlessly
<xnox> irreleph4nt: so yes, recreate /var/www/html/pxe/live/ubtu2004/ with better copy of all the hidden files.
<irreleph4nt> color me surprised
<xnox> irreleph4nt:  i may have added the uuid validation for network mounts, and fixed a bug, where we somtimes skipped it =/
<irreleph4nt> :D
<irreleph4nt> okay, let me google the correct rsync command real quick
<xnox> irreleph4nt:  like you can do $ sudo mount -o bind ubuntu-20.04-desktop-amd64.iso /var/www/html/pxe/live/ubtu2004/
<xnox> or yeah, rsync / cp -a should do it.
<xnox> irreleph4nt:  but like without .disk you can't open release notes, bug reports fail to say what image you used to install it with, etc.
<xnox> or like $ cp -r /mnt/.disk /var/www/html/pxe/live/ubtu2004/
<irreleph4nt> that's the cp command I used earlier
<irreleph4nt> just managed to mount the iso in the right folder as a loop device
<irreleph4nt> now rebooting
<irreleph4nt> xnox, no dice, still getting the same error
<xnox> irreleph4nt: can you pastebin / picture the whole output you see?
<xnox> Full error and everything before it?
<irreleph4nt> that'll take a moment
<xnox> irreleph4nt: also please open a bug on launchpad against Ubuntu, package ubiquity.
<xnox> irreleph4nt: I might need to go soon, but don't want to loose contact.
<irreleph4nt> will you be notified as I create the bugreport?
<irreleph4nt> xnox, solved!
<irreleph4nt> I'll still create the bugreport tho
<xnox> irreleph4nt:  solved?
<xnox> irreleph4nt:  yes, as a ubiquity / casper / initrd developer for Ubuntu, i better be notified =)
<irreleph4nt> xnox, mounting the iso to the right folder wasn't enough, as during boot that triggers a "mount: permission denied" error
<irreleph4nt> and - in a not so helping fashion - ends up throwing the same error message at the very end that I quoted earlier
<irreleph4nt> so at first I thought the issue was still the same
<irreleph4nt> I now rsynced the iso contents to the folder, which includes .disk
<irreleph4nt> and now it works
<vorlon> juliank: what packages are doing deb2snap transitions that aren't also seeded, or which shouldn't follow the policy for per-series channels?
<irreleph4nt> now all I need to do is figure out how to use launchpad correctly to actually create a bug, instead of always being routed to the ubuntu docs page :S
<juliank> vorlon: maas was seeded as a Deb, but is not seeded as a snap
<juliank> I'm not sure if there are others
<juliank> I think they should also follow the seeded snaps policy
<xnox> irreleph4nt: there is magic skip that URL option
<xnox> irreleph4nt: which the help page tells you about.
<juliank> vorlon: see ubuntu-devel email
<vorlon> juliank: ack
<xnox> irreleph4nt: or use $ ubuntu-bug ubiquity => that skips all redirects too
<xnox> irreleph4nt:  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug?no-redirect
<xnox> irreleph4nt:  so, i want you to still file the bug report. To say that it was unexpected that you saw the error, and that it didn't guide you, as to how / what you are meant to fix.
<irreleph4nt> thanks! I am on it now
<xnox> irreleph4nt:  also you can ask us to stop using .disk or like have /meta/ directory instead. Cause then, it would have been copied when you first unpacked the iso.
 * xnox hates that .disk is hidden
<irreleph4nt> I'll add that as possible fixes to the report :) Ideal solution would be if no such directory would be needed to begin with
<irreleph4nt> I have used many linux distros in the past and ubuntu is the only one I encountered with such a folder
<xnox> irreleph4nt:  hm. that's hard though. Because we ship systems that have _multiple_ of these, and we have to find the right one.
<irreleph4nt> :O
<xnox> irreleph4nt:  for example, if you have two usb sticks plugged in, with 19.10 and 20.04 => without .disk/uuid check we boot random grub, random kernel+initrd, and use random rootfs.
<irreleph4nt> that must be a pain to deal with
<xnox> irreleph4nt:  like random, any combination in that matrix of 3x3
<irreleph4nt> but then again, having both of these plugged in should rarely happen. Also, what you are doing there - which might be an inherent problem of using grub - is that you do the systems BIOS / EFI's work
<irreleph4nt> which TBH you probably shouldn't to begin with
<xnox> irreleph4nt:  or like boot 20.04 live session, whilst your laptop has a 19.10 OEM recovery system with it's own .disk/uuid
<irreleph4nt> it's really not ubuntu's job to figure out what disk to boot
<xnox> irreleph4nt:  so people do usb sticks, on servers. because they have access to remote console, and they can remotely pick the right usb stick, cause they see bios menu.
<xnox> irreleph4nt:  but physically they are not present in teh datacentre.
<irreleph4nt> xnox, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1877618
<ubottu> Launchpad bug 1877618 in ubiquity (Ubuntu) "20.04 fails to boot via PXE (amd64)" [Undecided,New]
<tjaalton> ahasenack: committed to git
<ahasenack> \o/
<coreycb> hello SRU Team, could we have cinder and neutron rejected from the focal unapproved queue please?
<coreycb> bdmurray: hi, do you know if the SRU team is aware of the openstack ussuri final release scheduling?
<bdmurray> coreycb: No, I don't know
<coreycb> bdmurray: it's not a great way to make friends so apologies in advance. let me find some background to link you to.
<coreycb> bdmurray: https://lists.ubuntu.com/archives/ubuntu-release/2020-March/004911.html
<bdmurray> coreycb: March 2nd? that was like *forever* ago
<coreycb> bdmurray: heh, well the schedule in that first email is the part to read
<coreycb> bdmurray: the part about May 19, 2020
<bdmurray> coreycb: Okay, so now I've been reminded
<coreycb> bdmurray: the upstream final release is next wed and we plan to jump on it and start uploading to the focal unapproved queue. I just want to coordinate with the release team and hopefully we can get everything into focal-proposed fairly soon after.
<coreycb> s/release/sru/
<bdmurray> coreycb: Its not clear to me what you are asking for.
<coreycb> bdmurray: we just have a lot of packages that we need to SRU into focal for the final release of openstack ussuri
<coreycb> bdmurray: and would like the SRU Team to be aware
<bdmurray> coreycb: Okay, if you are looking for somebody to be available to review them then I think the thing to do would be email the team via the ubuntu-release mailing list.
<coreycb> bdmurray: sure I can do that, sorry to pick on you I just know you're avail timezone wise
<bdmurray> coreycb: No problem
<coreycb> bdmurray: thanks
<LocutusOfBorg> jamespage, hello, stuff is now depending on openstack-pkg-tools (>= 109~)
<LocutusOfBorg> please merge?
<vorlon> bdmurray: currently, for snap channel transitions via u-r-u, is that strictly based on a whitelist of known snaps?
<bdmurray> vorlon: yes
<vorlon> bdmurray: should we do this instead by introspection of what snaps are installed that are tracking ubuntu release channels?  So that e.g. we don't have to update u-r-u for things like the maas snap (ubuntu-devel)
<bdmurray> vorlon: marcustomlinson has redone the deb2snap transition so he might be the best person to talk about this to
<vorlon> marcustomlinson: ^^ ping :)
<bswartz> Hi, I'm trying to fix a bug in the open-iscsi package for Ubuntu, and I need someone to sponsor this SRU: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1877617
<ubottu> Launchpad bug 1877617 in open-iscsi (Ubuntu) "Automatic scans cause instability for cloud use cases" [Undecided,New]
<bswartz> I've done most of the work required to fix this, and I'm willing to do anything else necessary to get the fixes merged
<sarnold> bswartz: nice report; for the fix to be released, it'll go through the SRU process https://wiki.ubuntu.com/StableReleaseUpdates
<sarnold> bswartz: one step of that is to fix the issue in the -devel release, too, so a patch for groovy would probably help speed things along
<bswartz> sarnold: Okay, I can do that
<bswartz> sarnold: I just realized I don't know how to upgrade to the -devel version
<bswartz> I'm trying something that might work
<bswartz> No it didn't work
<bswartz> This is weird, because I used the installer from the groovy directory, but I ended up with focal anyways
<bswartz> I'm going to flush all my caches and start over
<sarnold> bswartz: do-release-upgrade -d *might* do it -- the meaning of the -d changes over the course of a release
<bswartz> That ended up in a crash loop when I tried that
<sarnold> ouch :(
<bswartz> I might have to install from ISO
<bswartz> Look like the legacy network installer doesn't work well
<bdmurray> sarnold: do-release-upgrade -d will take you to groovy now
<sarnold> bdmurray: cool, thanks
<sarnold> bdmurray: have you seen the crash loop bswartz mentioned?
<bdmurray> sarnold: no, who would upgrade to groovy?
<sarnold> bdmurray: bswartz is trying to get a fix for open-iscsi sru'd into our releases, and I pointed that one of the requirements is the fix being in -devel -- and bswartz sounds thorough enough to want to test the change :)
<bdmurray> I'm running a test upgrade now and it seems fine to me.
<sarnold> thanks bdmurray :)
<bswartz> So what I actually did, was install groovy using the network installer, but I ended up with something that appeared to be focal
<bswartz> Then I tried to upgrade that to groovy, and it went all pear-shaped
<bswartz> It could be that my installation automation is broken by something new in groovy, or that it doesn't work well with -devel releases
<bswartz> I used http://us.archive.ubuntu.com/ubuntu/dists/groovy/main/installer-amd64/current/legacy-images/netboot/ubuntu-installer/amd64/linux and http://us.archive.ubuntu.com/ubuntu/dists/groovy/main/installer-amd64/current/legacy-images/netboot/ubuntu-installer/amd64/initrd.gz to boot up
<bswartz> But those gave me focal instead of groovy
<bswartz> I'm doing a manual ISO install now
<bswartz> sarnold: Okay, I pushed a build for groovy to the same PPA. FWIW, it looks like there are no differences from focal
<sarnold> bswartz: nice nice
#ubuntu-devel 2020-05-09
<f209> Hi guys! question for folks in the channel. Starting a new web development project. Done stuff in about 20 different languages over the years, Classic ASP, ASP.NET, Python, PHP, Java, ColdFusion, Heavy Client Side JS and HTML Experience. Want to do something that will architecturally support scalability and HA practices that make sense for modern cloud applications, so planning whatever
<f209> I write to leverage docker/kub and cloud, likely AWS EKS, data layer..on the fence between Postgres/Mongo or just going straight AWS RDS...any suggestions, thinking node.js because of non-blocking i/o and generally employing a microservices architecture...but curious if GO or something else, i heard something about Julia recently...
<f209> anyone here that can give me some preferences and why you'd suggest them?
<f209> understand julia to be compiled code
<f209> and node.js is interpreted but i have been hearing more about go apps that run all code we'd typically leave to an interpreter
#ubuntu-devel 2020-05-10
<ubusr> hi, found another bug in 16.04 LTS  "file" app cuts the interpreter path (didn't use to do that)
<ubusr> "/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.32, BuildID[sha1]=6f072e70e3e49380ff4d43cdde8178c24cf73daa, stripped"
<ubusr> this bug hapepns in 18.04 LTS as well, but not in 20.04 LTS
<ubusr> it's seems to be related that /lib64 is a link in ubuntu 20.04 (where it works) but on 16.04 and 18.04 it'snot (atleast in latest docker image)
<ubusr> Can anyone verify the bug with the docker of ubuntu 16.04 + 18.04 (latest versions) where there is a bug in "file" where it truncates ELF interpreter paths ? (works in ubuntu 20.04)
<ubusr> it's somehow related to the layout of the filesystem maybe and not to the "file" itself (i.e. the bug may exist in 20.04), in 20.04 /lib64 is a link where in others it's not
<ubusr> https://github.com/tzickel/docker-trim/issues/1 <-- this is how I found out the bug :/
<orogor> hi
<orogor> can anyone on focal run /usr/bin/apt | head -n1
<orogor> package version is 2.0.2 , but i get apt 1.9.4 (amd64)
<orogor> also my apt/apt-get is broken, it segfault after focal upgrade
<orogor> and i unpacked http://fr.archive.ubuntu.com/ubuntu/pool/main/a/apt/libapt-pkg6.0_2.0.2_amd64.deb , i still get a  1.9.4 inside
<cjwatson> $ /usr/bin/apt | head -n1
<cjwatson> apt 2.0.2 (amd64)
<cjwatson> But also, this is probably more #ubuntu material
<orogor> cjwatson, would you have a rought explaination for this ?  https://pastebin.com/gbihtKgU
<orogor> i tried with 3 different mirrors
<orogor> :/
